https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot
== Summary ==
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš
Popela]], [[User:jkonecny| Jiří Konečný]]
* Email: siosm(a)fedoraproject.org, tpopela(a)fedoraproject.org, jkonecny(a)redhat.com
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] ngompa(a)fedoraproject.org
== Detailed Description ==
On rpm-ostree based systems, the real root (the root directory of the
root partition on the disk) is mounted under the `/sysroot` path. By
default it contains the state of the system (the content of `var` and
`etc`) as well as the system versions themselves (each versioned copy
of `/usr`) in the ostree repository (`/ostree/repo`).
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
Example of issue: https://github.com/fedora-silverblue/issue-tracker/issues/232
This change replicates for Fedora Silverblue/Kinoite what has been
done in Fedora CoreOS in a previous release.
== Feedback ==
None so far.
== Benefit to Fedora ==
This will make Fedora Silverblue/Kinoite more robust to accidental
damage from users.
== Scope ==
* Proposal owners:
** Work on the changes requires for new installations (potentially
Anaconda configuration changes) and support for in place updates for
existing installations (requires a two step process).
* Other developers:
** Potential Anaconda changes required.
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
We will create a systemd unit that perform the updates in place for
existing systems. This will require a two step process (changing the
existing kernel arguments, and then enabling the ostree feature). Once
the feature is enabled, user won't be able to rollback to previous
deployments where the kernel argument is not set. We will have to
clearly document that in the documentation for easier troubleshooting.
== How To Test ==
Only try the following if you are confortable debugging an un-bootable
system and have made backups!
`$ sudo rpm-ostree kargs --append-if-missing=rw`
`$ sudo ostree config --repo=/sysroot/ostree/repo set "sysroot.readonly" "true"`
`$ sudo systemctl reboot`
Note that you can not "rollback" to the previous deployment to undo
this change. You will have to boot into a Live ISO and edit the config
file in the ostree repo to remove this config option.
== User Experience ==
There should be no visible change in user experience.
== Dependencies ==
Requires changes in Anaconda (maybe just config?) to set default kargs
and property on ostree repo for new installations.
== Contingency Plan ==
Revert the change before the release.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TODO
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi
I've packaged liblerc which I'd like to use for the upcoming gdal-3.5.0.
Review request is here [1]. It's a simple cmake/c++ library, and I've
also added the mingw subpackages.
Happy to review in exchange.
Thanks
Sandro
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2082662
Hello all,
You might have heard some rumours that the Packit team is working on
automation for downstream activities you need to do when working on a new
release of a package to Fedora. And the rumours are true – I am really
pleased to announce that Packit now covers the whole workflow from upstream
development to Bodhi update. We try to reduce the human interaction with
the system to places where it’s needed and wanted and do all the mundane
work and busy waiting for you.
If you want to take a look at how it works, here is a blog post showing
this on one of our packages: https://packit.dev/posts/downstream-automation
We have used the automation ourselves for a couple of weeks for our
packages[0] and already got bored of the releases. It’s too simple.
And if you haven’t heard about Packit at all, check our web page:
https://packit.dev
We know that people can have different needs, so let us know what you think
about it. And if you hit any issues or have any suggestions, get in touch
with us – ideally, in #packit:fedora.im on Fedora Matrix or in form of an
upstream issue created here:
https://github.com/packit/packit-service/issues/new
On behalf of the Packit team,
František
[0]: As an example, take a look at `packit`
<https://src.fedoraproject.org/rpms/packit/> or `python-ogr`
<https://src.fedoraproject.org/rpms/python-ogr/> package. You can also
check the activities of the packit FAS user in Koji (
https://koji.fedoraproject.org/koji/userinfo?userID=4641) or Bodhi (
https://bodhi.fedoraproject.org/users/packit).
libgps from the gpsd package had an API and ABI break. As usual, the
following packages need to be rebuilt:
collectd
direwolf
foxtrotgps
marble
plasma-workspace
vfrnav
viking
I tried to rebuild them locally. It seems only direwolf needs a new
patch. The direwolf-gpsapi12 patch needs to be replaced with
https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi14.patch
The new gpsd package has been built in f37-build-side-53409.
Could a proven packager please replace the patch and rebuild the
dependant packages in this side tag?
Thanks,
--
Miroslav Lichvar
Hi,
It is quite common, to have some sources, which are not available as a
tarball from upstream. In case of rubygem- packages, they quite often do
not ship their test suites. In this case, our .spec file contains
something like [1]:
~~~
# Tests are not packaged with the gem. You may get them like so:
# git clone --no-checkout https://github.com/discourse/mini_mime
# git -C mini_mime archive -v -o mini_mime-1.1.0-test.txz v1.1.0 test
Source1: %{gem_name}-%{version}-test.txz
~~~
This is quite fine. However, if there is opened PR [2], the CI would
work only as long sources are in the look a side cache, which is not
always desirable, because this might be just some WIP.
I while ago, I proposed [3] this "executable" comments instead:
~~~
Source1: %{gem_name}-%{version}-test.txz
%{echo:%(
[ ! -e %{S:1} ] &&
rm -rf %{name} &&
git clone https://github.com/discourse/mini_mime %{name} &&
git -C %{name} archive -v -o %{S:1} v%{version} test/
)}
~~~
I know, that some may say "it won't work in Koji", that is true, but
won't necessarily be issue for CI. The other argument might be "it is
creating some random tarball from random source", but if the accompanied
`sources` file contains the right checksums, `fedpkg srpm` ensures that
only the tarballs with the right content is used.
While others might just handwavy upload the random sources into look a
side cache, I think this is way better approach.
Now I am looking for feedback about general approach. Of course it could
be somehow polished and improved to hide some boiler plate.
Vít
[1]:
https://src.fedoraproject.org/rpms/rubygem-mini_mime/blob/c25611d64d17c374a…
[2]: https://src.fedoraproject.org/rpms/rubygem-mini_mime/pull-request/2
[3]: https://pagure.io/packaging-committee/issue/1132#comment-769233
Dear all,
You are kindly invited to the meeting:
ELN SIG on 2022-05-06 from 12:00:00 to 13:00:00 US/Eastern
At fedora-meeting(a)irc.libera.chat
The meeting will be about:
Source: https://calendar.fedoraproject.org//meeting/10133/