devel March 2022

devel@lists.stg.fedoraproject.org

191 participants
388 discussions

Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname bumps
by Ben Beasley 09 May '22

09 May '22

In one week (October 6), or slightly later, I will build grpc 1.41.0 for Rawhide (F36). Fedora 35 will remain on 1.39.1. As is traditional for minor releases of grpc, the C++ ABI was broken (soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was also broken (soversion bumped from 18 to 19). I will coordinate builds in a side tag of packages that use the C (core) and/or C++ libraries. Maintainers of the following packages should have received this email directly: • bear • frr • perl-grpc-xs Packages that use the Python bindings should be unaffected, as there should be no incompatible API changes: • buildstream • python-chirpstack-api • python-etcd3 • python-google-api-core • python-google-cloud-core • python-grpc-google-iam • python-opencensus (orphaned) • python-opencensus-proto • python-opentelemetry • python-pytest-grpc • python-xds-protos

1 1

F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
by Ben Cotton 06 May '22

06 May '22

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

7 8

F36 Final blocker status summary
by Ben Cotton 29 Apr '22

29 Apr '22

F36 Beta is go, so it's time to shift to Final blockers. The Final freeze begins on 5 April, with a target release date of 19 April. Action summary ==================== Accepted blockers ----------------- 1. grub2 — Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader — NEW ACTION: Maintainers to determine if this can be supported in time for F36 2. gtk4 — gtk_widget_measure: assertion 'for_size >= -1' failed — VERIFIED ACTION: none 3. mutter — The input string via Input Method isn't renderred properly at the search box on Activities — ASSIGNED ACTION: Upstream to diagnose and fix issue 4. nss-mdns — Require authselect for use in scriptlets — ON_QA ACTION: QA to verify FEDORA-2022-09f077aa3a 5. plasma-discover — The About button sends Discover into loop and the application stops responding. — NEW ACTION: Upstream to diagnose and fix issue Proposed blockers ----------------- 1. gnome-connections — [abrt] gnome-connections: _mid_memalign(): gnome-connections killed by SIGSEGV — NEW ACTION: Maintainers to diagnose issue 2. gvfs — [abrt] gvfs: type_class_init_Wm(): gvfsd-dav killed by SIGABRT — MODIFIED ACTION: QA to verify FEDORA-2022-a69718b1e1 3. mutter — Workstation Live is frozen in a VM with QXL video driver (Virtio works OK) — NEW ACTION: Maintainers to diagnose issue 4. rpm — symlink /var/lib/rpm->/usr/lib/sysimage/rpm does not exist — ON_QA ACTION: QA to verify FEDORA-2022-c564d315fc 5. tracker-miners — tracker-extract-3 killed by SIGSYS — NEW ACTION: Maintainers to diagnose issue 6. xorg-x11-server — Basic graphics mode broken for KDE (BIOS/UEFI) and GNOME (UEFI+X11) — NEW ACTION: Maintainser to diagnose issue Bug-by-bug detail ============= Accepted blockers ----------------- 1. grub2 — https://bugzilla.redhat.com/show_bug.cgi?id=2049849 — NEW Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader By default, dual-boot systems that use Bitlocker on Windows cannot boot to Windows without prompting for the recovery key. There are workarounds for this and it's not exactly a *bug* in grub. 2. gtk4 — https://bugzilla.redhat.com/show_bug.cgi?id=2043335 — VERIFIED gtk_widget_measure: assertion 'for_size >= -1' failed Searching for applications in Software resulted in a hang. Fixed in gnome-software-42~beta-2.fc36. 3. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2062660 — ASSIGNED The input string via Input Method isn't renderred properly at the search box on Activities Pre-edit strings are not rendered in some cases, only showing the first keypress. Filed upstream as https://gitlab.gnome.org/GNOME/mutter/-/issues/2188 4. nss-mdns — https://bugzilla.redhat.com/show_bug.cgi?id=2056927 — ON_QA Require authselect for use in scriptlets nss-mdns does not require authselect, which it uses in scriptlets. This can result in the scriptlet failing. FEDORA-2022-09f077aa3a contains a candidate fix. 5. plasma-discover — https://bugzilla.redhat.com/show_bug.cgi?id=2057563 — NEW The About button sends Discover into loop and the application stops responding. Clicking the About button causes a loop which renders Discover unresponsive (except when the window is maximized). Proposed blockers ----------------- 1. gnome-connections — https://bugzilla.redhat.com/show_bug.cgi?id=2068015 — NEW [abrt] gnome-connections: _mid_memalign(): gnome-connections killed by SIGSEGV Attempting to connect to an RDP server causes Connections to crash. 2. gvfs — https://bugzilla.redhat.com/show_bug.cgi?id=2066717 — MODIFIED [abrt] gvfs: type_class_init_Wm(): gvfsd-dav killed by SIGABRT Connecting to a DAV share on a remote F35 computer causes Nautilus to crash. F35->F35 and F35->F36 work. FEDORA-2022-a69718b1e1 contains a candidate fix. 3. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2063156 — NEW Workstation Live is frozen in a VM with QXL video driver (Virtio works OK) VMs that initially use the QXL driver appears frozen. Using virtio (including to switching to QXL after?) avoids this. KDE Lives do not display (heh) this behavior. There appears to still be a fair amount of uncertainty about what exact conditions cause this. 4. rpm — https://bugzilla.redhat.com/show_bug.cgi?id=2066427 — ON_QA symlink /var/lib/rpm->/usr/lib/sysimage/rpm does not exist The symlink for RPM DB relocation did not exist on clean installs. FEDORA-2022-c564d315fc contains a candidate fix. 5. tracker-miners — https://bugzilla.redhat.com/show_bug.cgi?id=2066703 — NEW tracker-extract-3 killed by SIGSYS In some cases, shortly after login, tracker-miners crashes. The crash appears several (or 100+) times in abrt. 6. xorg-x11-server — https://bugzilla.redhat.com/show_bug.cgi?id=2067151 — NEW Basic graphics mode broken for KDE (BIOS/UEFI) and GNOME (UEFI+X11) Basic graphics mode in F36 KDE is broken universally. For GNOME, it is broken, but only on X11+EFI. It is unclear if these are the same or separate issues. All combinations work as expected in F35. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

4 10

Problem with SSL in Fedora 36
by José Abílio Matos 29 Apr '22

29 Apr '22

In one, and just one, of my email accounts the upgrade to F36 failed with this: The underlying socket is having troubles when processing connection to imap.xxx.xx.xx:993: Error during SSL handshake: error:0A0C0103:SSL routines::internal error No email program works, I tried kmail, trojitá, thunderbird. The connection fails immediatelly with the above error. Where should I fill this report, under openssl? Searching a bit this seems related to: https://fedoraproject.org/wiki/Changes/OpenSSL3.0 Regards, -- José Abílio

5 11

Landing a larger-than-release change (distrusting SHA-1 signatures)
by Alexander Sosedkin 28 Apr '22

28 Apr '22

Hello, community, I need your wisdom for planning a disruptive change. Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 I believe we should start planning for the next cryptographic defaults tightening. And next time it's gonna be even more disruptive because of SHA-1 (again). SHA-1 is a hash function from 1995, which collision resistance is no longer to be relied upon for security [1]. At the same time, it's not like software has successfully migrated off it, not even close. It's not a question of "if" the world should migrate from it, sooner or later we must part ways with it. (Technically, some acute energy crisis or a collapse of civilization forever raising the costs of computations thousandfold would also do, but let's agree that migrating to a more modern hash is the way =) We've been disabling it in TLS, but its usage is much wider than TLS. The next agonizing step is to restrict its usage for signatures on the cryptographic libraries level, with openssl being the scariest one. Good news is, RHEL-9 is gonna lead the way and thus will take a lot of the hits first. Fedora doesn't have to pioneer it. Bad news is, Fedora has to follow suit someday anyway, and this brings me to how does one land such a change. --- Fedora is a large distribution with short release cycles, and the only realistic way to weed out its reliance on SHA-1 signatures from all of its numerous dark corners is to break them. Make creation and verification fail in default configuration. But it's unreasonable to just wait for, say, Fedora 37 branch-off and break it in Rawhide for Fedora 38. The fallout will just be too big. Maintainers need time to get bugs, look into them, think, analyze, react and test --- and that's just if it fails correctly! Unfortunately, it's not just that the error paths are as dusty as they get because the program counter has never set foot on them before. Some maintainers might even find that picking a different hash function renders their code non-interoperable, or even that protocols they implement have SHA-1 hardcoded in the spec. Or that everything is ready, but real world deployments need another decade. Or that on-disk formats are just hard to change and migrate. Took git years to migrate from SHA-1, and some others haven't even started. There are gonna be investigations, planning, exceptions, upstream changes, opt-out mechanisms, arguing, compromises, waiting out, all kinds of things. It's gonna be big. Too big for a single release cycle. --- But how does one land something and give the distribution the extra cycles needed to react? That's not really clear to me. An obvious thing is to announce it in one cycle and land in another one. The downsides are well-documented in "The Hitchhiker's Guide to the Galaxy": announcements are one weak measure, and then it's too late. A second scheme I can come up with is a "jump scare". Break the functionality in Fedora 37 Rawhide, make most of the affected people realize the depth of the problem, then unbreak it. Break again for Fedora 38 and never fix. This could also be extended into "let one stable release slide'. Break in 37 Rawhide, unbreak on branched off 37, but never in Rawhide. But these are all rather... crude? Sure there should be better ways, preferably something explored before. I'm all for pulling this tooth out smoothly, but I need hints on how to do it. I hope that together we can devise a better plan than these. So, how does one land a change that's bigger than a release cycle? [1] https://eprint.iacr.org/2020/014

26 60

Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides
by Adam Williamson 21 Apr '22

21 Apr '22

I found quite a big mess today, caused by an attempt to bump perl to 5.34.1 in Fedora 36: https://bodhi.fedoraproject.org/updates/FEDORA-2022-cea638ebd4 Because some packages depend on the exact perl interpreter version, the maintainer made a buildroot override for perl: https://bodhi.fedoraproject.org/overrides/perl-5.34.1-486.fc36 and rebuilt them. Okay. The problem with this is, we have lots of perl modules. People build them all the time. And buildroot overrides apply to *everything*. So, while the buildroot override has been valid, multiple *other* perl modules have been unwittingly built against it: perl-Scalar-List-Utils: https://koji.fedoraproject.org/koji/buildinfo?buildID=1936732 perl-Parallel-Pipes: https://koji.fedoraproject.org/koji/buildinfo?buildID=1937527 perl-PPIx-Regexp: https://koji.fedoraproject.org/koji/buildinfo?buildID=1937522 perl-Crypt-SSLeay: https://koji.fedoraproject.org/koji/buildinfo?buildID=1937521 perl-Crypt-OpenSSL-PKCS10: https://koji.fedoraproject.org/koji/buildinfo?buildID=1937471 ...and those are just the ones I found so far. Because they were built against 5.34.1, all of those builds require "perl(:MODULE_COMPAT_5.34.1)" , which means they require perl-5.34.1 from updates-testing. They cannot be installed with perl-5.34.0 from stable. But the maintainers likely had no idea about this - buildroot overrides are not at all discoverable, there is zero indication your package is building against one when you build it - and have created separate updates for those packages: https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb1170abf2 https://bodhi.fedoraproject.org/updates/FEDORA-2022-d83d0ba901 https://bodhi.fedoraproject.org/updates/FEDORA-2022-fac98e635f https://bodhi.fedoraproject.org/updates/FEDORA-2022-c2203f1964 https://bodhi.fedoraproject.org/updates/FEDORA-2022-0990e3309e Users testing those updates will likely not notice the problem, because they'll have *all* of updates-testing enabled when they update, and perl-5.34.1 will be pulled in. But if any of those updates is pushed stable before the perl update is pushed stable, it will fail to install for anyone who does not have updates-testing enabled. This is quite a mess. I'm going to try and clean it up, but it'll be a bit ugly (there are a couple of ways I can do it, but both will involve doing bumps-and-rebuilds of the affected packages with no changes). I've been worried about this sort of thing happening for a while due to the undesirable properties of buildroot overrides. This is the biggest real-world case I've seen, but it could certainly happen again. It might even have happened without anyone noticing exactly what was going on (just mysterious dependency issues that magically went away after a bit). So: now we have convenient self-service side tags, *please use them*. Especially for something as major as a bump of perl that changes dependencies of packages built against it like this. Side tags avoid this mess entirely. Using the mechanism to produce an update from a side tag also makes it easier to make sure all the right packages are in the update and they don't get incorrectly submitted as separate updates. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

9 17

VERY late notification emails
by Richard Shaw 21 Apr '22

21 Apr '22

I almost wrote this a week ago but decided not to as it's been recently discussed but this is really annoying. 6 days later is more than useless. Previously it was blamed, at least partially, on the mass rebuild, but clearly that should no longer be an issue by now? I know I can turn them off, but I actually LIKE the messages if they were delivered promptly. Is there really nothing we can do about this? Thanks, Richard ---------- Forwarded message --------- From: <notifications(a)fedoraproject.org> Date: Sun, Feb 27, 2022 at 6:09 PM Subject: hobbes1069's mingw-fltk-1.3.8-1.fc36 completed To: <hobbes1069(a)gmail.com> Notification time stamped 2022-02-21 13:42:00 UTC hobbes1069's mingw-fltk-1.3.8-1.fc36 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=1921324

9 20

mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide
by Sandro Mani 20 Apr '22

20 Apr '22

Hi As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38 towards the end of the week. I've completed test-builds here [2]. Sandro [1] https://fedoraproject.org/wiki/Changes/F37MingwEnvToolchainUpdate [2] https://copr.fedorainfracloud.org/coprs/smani/mingw-gcc-12/

2 3

Do we have any policy for disabling inactive users
by Mattia Verga 19 Apr '22

19 Apr '22

Just being paranoid here: do we have any policy / automatism for disabling "power" users (in packager group or like) which have been inactive for long time? I'm no security expert, but an inactive user account may be hacked without noticing and if such account have powers like being in the packager group may inject bad things in the distribution. I also imagine the case where a user no more use their email address and that become available to someone else. The new user may easily reset the password and gain access to the old Fedora account (provided that the old user didn't use 2fa). Does it make sense to start thinking to prune inactive packagers without waiting someone to start the "unresponsive maintainer policy"? Maybe a script could check user activities in src.fedoraproject.org and send a warning email if no activity is made in one year? Mattia

23 91

Unretiring Icedtea-web
by Steve Cossette 18 Apr '22

18 Apr '22

Good morning all, First, I apologize if dumb questions are in this post -- still wet behind the ears when it comes to packaging. I was wondering what was needed to unretire a package, this one specifically: https://src.fedoraproject.org/rpms/icedtea-web It seems to still be developed ( https://github.com/AdoptOpenJDK/IcedTea-Web/releases) I checked the Fedora docs on this: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_… and it says to click a "Take" button on the package sources page, but I see no such thing even after logging in. Just to be clear, I am in the packagers group. Thank you!

5 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2022