Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Thu, 2024-04-25 at 07:42 +0200, Jan Kolarik wrote: > Hello everyone, > > We've prepared a side-tag for testing Rawhide with dnf5 as the default > package manager. Instructions for installing the packages from the side-tag > can be found at the following link [1]. > > Please provide feedback in Bodhi or on this mailing list regarding the use > cases you're familiar with from the existing dnf command, and share your > experience with this new version. > > If there's no negative feedback regarding any critical functionality, we > plan to push the packages from the side-tag to Rawhide next week. > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2 The update failed a couple of openQA tests. I will take a closer look into the reason in the morning, I'm busy reneedling things for the GTK update at present. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libarrow (Apache Arrow) SONAME bump in rawhide
On Tue, 2024-04-23 at 10:15 -0700, Adam Williamson wrote: > On Mon, 2024-04-22 at 11:04 -0400, Kaleb Keithley wrote: > > Coming soon. > > > > Updating to Arrow 16.0.0 > > Thanks for the minimal notice, but that is not how this is supposed to > be done. > > You are supposed to mail all the maintainers of dependent components > and provide at least a week to co-ordinate rebuilds in a side tag, then > send out an update with all the rebuilds together. > > Not send one email to one mailing list then dump the soname bump, > alone, into Rawhide the next day: > https://bodhi.fedoraproject.org/updates/FEDORA-2024-5dedc1906c > > this has broken KDE installs, because digikam-libs requires opencv- > imgcodecs which requires gdal-libs which is built against a library > which had its soname bumped in the libarrow bump (libparquet.so.1500 to > libparquet.so.1600 ). That library is also required by three ceph > subpackages - ceph-common, ceph-radosgw, and ceph-test - and by librgw2 > . libarrow.so also had its soname bumped, and that is required by > groonga-libs and root-tree-dataframe . A bunch of other libraries were > also bumped but on a quick look appear not to be required by anything > else. It looks like Kaleb rebuilt ceph after libarrow went stable, and other packagers subsequently noticed the bump and rebuilt gdal and root, so only groonga remains to be rebuilt. But still, that's not how this should go, ideally. The time lags allowed a Rawhide compose to happen after libarrow was bumped but before gdal or root had been rebuilt. Ideally, next time, please build libarrow on a side tag, then build all the dependencies you have the privileges to build on the same side tag and notify the maintainers of other dependencies to build them in the same side tag, then create an update from the side tag. This is documented at https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages . Thanks. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libarrow (Apache Arrow) SONAME bump in rawhide
On Mon, 2024-04-22 at 11:04 -0400, Kaleb Keithley wrote: > Coming soon. > > Updating to Arrow 16.0.0 Thanks for the minimal notice, but that is not how this is supposed to be done. You are supposed to mail all the maintainers of dependent components and provide at least a week to co-ordinate rebuilds in a side tag, then send out an update with all the rebuilds together. Not send one email to one mailing list then dump the soname bump, alone, into Rawhide the next day: https://bodhi.fedoraproject.org/updates/FEDORA-2024-5dedc1906c this has broken KDE installs, because digikam-libs requires opencv- imgcodecs which requires gdal-libs which is built against a library which had its soname bumped in the libarrow bump (libparquet.so.1500 to libparquet.so.1600 ). That library is also required by three ceph subpackages - ceph-common, ceph-radosgw, and ceph-test - and by librgw2 . libarrow.so also had its soname bumped, and that is required by groonga-libs and root-tree-dataframe . A bunch of other libraries were also bumped but on a quick look appear not to be required by anything else. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RC 1.14 fails in VirtualBox, has problems in UTM
On Fri, 2024-04-19 at 15:19 +0100, Liam Proven wrote: > Tested this morning in the latest VBox 7.0.16 (which in theory > supports kernel 6.8). Running on macOS Monterey, 12.7.4 (latest > release for my hardware). > > GNOME edition: I got a message that my VM had outdated Guest > Additions, which I took as a good sign. However, installation froze > hard, locking the mouse pointer and whole VM, at 8% complete. > > KDE edition: severe text corruption made it inoperable; almost no text > visible in the installer. Did a bit more testing. I can't reproduce the install freeze at all, when I avoid the graphics issues, installs always complete fine for me. How much RAM did you allocate to the VM? I noticed VBox and VMware both seem to want to default to 2GB, which is adorably optimistic; 3GB or 4GB is much safer. (This isn't specific to Fedora, I had an Ubuntu 22.04 test install grind to a halt in a VM when I only gave it 2GB). I did all my testing with 3GB RAM. Using the 'VMSVGA' video adapter with 3D passthrough enabled, on KDE, the desktop and most apps render fine but I see severe installer corruption that makes it unusable (if anything worse than you described, the entire UI is kinda shot through with corrupted black triangles, not just text). Other GTK 3-based apps are fine, weirdly, only the installer is messed up, no idea why. I forgot to try GTK 4- based apps on KDE but I'd guess they're broken. On GNOME, the desktop displays fine, but GTK 4-based apps don't display correctly at all - that's https://bugzilla.redhat.com/show_bug.cgi?id=2274930 / https://gitlab.freedesktop.org/mesa/mesa/-/issues/11008 - and I see the same corruption in the installer, so I'm actually surprised you got as far as you did; maybe you had 3D acceleration disabled for the GNOME test, or something? Using 'VMSVGA' with 3D passthrough disabled, GNOME works fine in every way and installs fine. KDE consistently plays its login sound but never actually manages to render a desktop. Using 'VBoxSVGA' adapter with 3D passthrough disabled (it seems you cannot use 3D passthrough with this adapter, if you select this adapter but check the 3D passthrough box, vbox will silently switch back to 'VMSVGA', so be careful...), both desktops work fine and install fine. So, I guess that would be my recommendation for VirtualBox. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RC 1.14 fails in VirtualBox, has problems in UTM
On Fri, 2024-04-19 at 15:19 +0100, Liam Proven wrote: > Tested this morning in the latest VBox 7.0.16 (which in theory > supports kernel 6.8). Running on macOS Monterey, 12.7.4 (latest > release for my hardware). > > GNOME edition: I got a message that my VM had outdated Guest > Additions, which I took as a good sign. However, installation froze > hard, locking the mouse pointer and whole VM, at 8% complete. > > KDE edition: severe text corruption made it inoperable; almost no text > visible in the installer. > > I tried again in the latest UTM, which uses QEMU under the hood. > > GNOME: worked fine, nicely responsive. > > KDE: installer draws a blank featureless blue screen. I turned off GPU > passthrough and tried again. Completed fine, and works fine, although > it is a little sluggish. > > Sound does not work in either desktop, though. > > I just thought you might like to know. Just tested KDE. I can reproduce the installer corruption on VirtualBox with 3D passthrough enabled. On my first try to boot with 3D passthrough disabled it wouldn't get to a desktop at all, I'll try again later. On VMware (Player, current version, 3D passthrough enabled) it seems fine - didn't actually run through the install yet as my partner needed his computer back, but I'll try it later :P I'm testing on an HP all-in-one with Intel graphics running Windows 11 23H2. Sound was fine on VirtualBox. On VMWare it plays but is distorted, don't know why. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RC 1.14 fails in VirtualBox, has problems in UTM
On Fri, 2024-04-19 at 15:19 +0100, Liam Proven wrote: > Tested this morning in the latest VBox 7.0.16 (which in theory > supports kernel 6.8). Running on macOS Monterey, 12.7.4 (latest > release for my hardware). > > GNOME edition: I got a message that my VM had outdated Guest > Additions, which I took as a good sign. However, installation froze > hard, locking the mouse pointer and whole VM, at 8% complete. > > KDE edition: severe text corruption made it inoperable; almost no text > visible in the installer. > > I tried again in the latest UTM, which uses QEMU under the hood. > > GNOME: worked fine, nicely responsive. > > KDE: installer draws a blank featureless blue screen. I turned off GPU > passthrough and tried again. Completed fine, and works fine, although > it is a little sluggish. > > Sound does not work in either desktop, though. > > I just thought you might like to know. Thanks, Liam. I tested GNOME on a Windows host (seemed like the most likely common configuration, plus I don't have a Mac) and found https://bugzilla.redhat.com/show_bug.cgi?id=2274930 . It works fine without 3D passthrough for me. I didn't have time to test KDE (honestly, also thought it'd be less likely to have issues as I didn't think it had changed its rendering approach since F39). GNOME on VMware Player works fine for me with 3D passthrough enabled in F40 Final, though some folks testing Ubuntu 24.04 have reported issues - https://bugs.launchpad.net/ubuntu/+source/gtk4/+bug/2061118 . -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Mon, 2024-04-15 at 10:44 +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Apr 15, 2024 at 10:46:39AM +0200, Lukáš Nykrýn wrote: > > Just for record, the removal of network-scripts was done because > > https://fedoraproject.org/wiki/Changes/dhclient_deprecation > > That page has Category:ChangePageIncomplete. > dhcp-client is present in F40, even though it has Provides:deprecated(). > > > Network-scripts heavily depend on dhclient and there is no plan to rework > > them to use a different dhcp implementation. > > Ack. So it sounds like we could keep using both in F40 > and prepare for removal in F41. There are various uses of the service that do not need a DHCP client, like the one I referred to in the bug report and FESCo ticket. Heck, you can kinda *assume* anyone still using the service at this point is doing something weird with it, not just a 'normal' "bring up this interface for me with DHCP" kinda thing. The removal of the network service should still be treated as its own significant operation, not a natural consequence of the removal of dhclient. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-04-15 @ 16:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-04-15 # Time: 16:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 1 proposed blocker (kinda...) and 4 proposed freeze exceptions for Final. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240415T16=1440=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-04-15 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-04-15 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting=20240415T15=1440=1 If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Sat, 2024-04-13 at 18:17 -0400, Matthew Miller wrote: > On Fri, Apr 12, 2024 at 06:00:41PM -0700, Adam Williamson wrote: > > > This should have been an announced Change. This is a significant > > > change with wide impact. > > > > I've filed a bug, proposed it as a blocker, and filed a FESCo ticket > > asking FESCo to designate the bug as a blocker. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2274830 > > https://pagure.io/fesco/issue/3196 > > I admit I was also initially surprised. But, this actually has been going > through the Change process for a while: > > F33: > https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh > F36: https://fedoraproject.org/wiki/Changes/NoIfcfgFiles > F39: https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile I would argue that it has not. Those Changes are all about the NetworkManager plugin that reads ifcfg files. The network service - /etc/init.d/network - is a different thing. They may be tied together in the maintainers' minds, I don't know, but they are not tied together technically and none of those Changes, IMHO, at all clearly conveys "the network service is going away in Fedora 40". -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Fri, 2024-04-12 at 19:03 -0500, Neal Gompa wrote: > On Fri, Apr 12, 2024 at 4:41 PM Adam Williamson > wrote: > > > > Michel Lind just prompted me to notice that the 'network' service > > appears to have been removed from initscripts in Fedora 40+. This > > change seems to have landed in February without any fanfare - > > https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide > > . There is no Change for it, AFAICS. > > > > This does not appear to be driven by upstream removing it, because the > > commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove > > it from the build. Presumably without that, it would still be built. > > > > I'm a bit worried about this arriving unannounced and apparently mostly > > unnoticed. There *are* still reasons to use the network service; I > > still use it on the openQA worker hosts, for instance, because there is > > integration between openvswitch and the legacy network service, but no > > integration between openvswitch and NetworkManager. I also use an ifup- > > pre-local script to pre-create tap devices; NetworkManager apparently > > does not support this natively. There's a suggested workaround at > > https://access.redhat.com/solutions/6900331 , which is helpful, but > > still, it's a significant change if you're using that mechanism. > > > > As a user of this service, I would've expected more of a heads-up that > > it was going away; if I hadn't happened to catch Michel's message I > > might have upgraded openQA staging to F40 immediately on release (as I > > usually do) and been rather surprised that the network setup stopped > > working. I'm sure I will find a way to re-engineer this rather > > complicated network setup without network.service, but a bit more of a > > heads up would have been nice. > > > > Should this have been a Change? How worried are we about it going out > > in Fedora 40 without having been through the Change process? > > This should have been an announced Change. This is a significant > change with wide impact. I've filed a bug, proposed it as a blocker, and filed a FESCo ticket asking FESCo to designate the bug as a blocker. https://bugzilla.redhat.com/show_bug.cgi?id=2274830 https://pagure.io/fesco/issue/3196 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Fri, 2024-04-12 at 14:40 -0700, Adam Williamson wrote: > unnoticed. There *are* still reasons to use the network service; I > still use it on the openQA worker hosts, for instance, because there is > integration between openvswitch and the legacy network service, but no > integration between openvswitch and NetworkManager. it seems since I last looked at this, NM has grown some level of openvswitch support, but it seems to be limited, and I don't know off- hand if it's sufficient for what openQA needs. I will need to look into that. https://github.com/NetworkManager/NetworkManager/blob/main/man/nm-openvswitch.xml -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
network service removed in Fedora 40 without a Change proposal(?)
Michel Lind just prompted me to notice that the 'network' service appears to have been removed from initscripts in Fedora 40+. This change seems to have landed in February without any fanfare - https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide . There is no Change for it, AFAICS. This does not appear to be driven by upstream removing it, because the commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove it from the build. Presumably without that, it would still be built. I'm a bit worried about this arriving unannounced and apparently mostly unnoticed. There *are* still reasons to use the network service; I still use it on the openQA worker hosts, for instance, because there is integration between openvswitch and the legacy network service, but no integration between openvswitch and NetworkManager. I also use an ifup- pre-local script to pre-create tap devices; NetworkManager apparently does not support this natively. There's a suggested workaround at https://access.redhat.com/solutions/6900331 , which is helpful, but still, it's a significant change if you're using that mechanism. As a user of this service, I would've expected more of a heads-up that it was going away; if I hadn't happened to catch Michel's message I might have upgraded openQA staging to F40 immediately on release (as I usually do) and been rather surprised that the network setup stopped working. I'm sure I will find a way to re-engineer this rather complicated network setup without network.service, but a bit more of a heads up would have been nice. Should this have been a Change? How worried are we about it going out in Fedora 40 without having been through the Change process? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Fri, 2024-04-12 at 10:10 -0700, Carlos Rodriguez-Fernandez wrote: > Yes that works too. By the time I was setting up MFA everywhere, and > doing the code printing, I recall not all systems giving me that option, Yeah, FreeOTP resisted doing backups for a long time on the basis that it wasn't "secure" enough, which may be what you're remembering. (you could still kinda back it up from a rooted phone, but it was a bit weird.) These days it has a native backup option, though. > and finding the paper thing not very good as recovery mechanism for me, > so I went with Yubikeys and my own backup-in-the-cloud mechanism. I was > just sharing an option just in case it could serve someone that is > hesitating by giving some ideas :). For sure, whatever works for you is always the best way :) -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote: > I was hesitant to have MFA for a while. Imagine losing a phone with tons > of tokens. What a hassle to recover from that. I found it less than > ideal for practical reasons. This is one reason most systems provide a sheet of one-time backup codes that you're meant to print out and keep in a safe place, for recovery from exactly that scenario. Alternatively, if you have an old phone or tablet lying around, just install an MFA app on that and enrol it too, lock it in a cabinet, then if you ever lose your primary phone, use it to recover. Also, these days, most authenticator apps support some kind of backup mechanism. FreeOTP lets you back up to a file (which you should, of course, keep somewhere safe and ideally encrypted). Google Authenticator can backup To The Cloud. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote: > > What is the best way to formally propose > that 2FA is required for packagers after > some date There is already a FESCo ticket. https://pagure.io/fesco/issue/3186 / Please don't discuss there, discuss here; FESCo will vote in that ticket or a meeting when they feel it appropriate. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Re: Fedora 40 Candidate RC-1.12 Available Now!
On Wed, 2024-04-10 at 12:50 +, rawh...@fedoraproject.org wrote: > According to [the schedule][1], Fedora 40 Candidate RC-1.12 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://openqa.fedoraproject.org/testcase_stats/40 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_RC_1.12_Summary > > The individual test result pages are: > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_RC_1.12_Installation > https://fedoraproject.org/wiki/Test_Results:Fedora_40_RC_1.12_Base > https://fedoraproject.org/wiki/Test_Results:Fedora_40_RC_1.12_Server > https://fedoraproject.org/wiki/Test_Results:Fedora_40_RC_1.12_Cloud > https://fedoraproject.org/wiki/Test_Results:Fedora_40_RC_1.12_Desktop > https://fedoraproject.org/wiki/Test_Results:Fedora_40_RC_1.12_Security_Lab An update on this: we have RC-1.13 coming in a few hours, but it just fixes some filenames and updates uboot-tools from the RC to the final release. Most 1.12 testing will be valid, so please continue to test 1.12 while 1.13 is cooking. At Go/No-Go tomorrow we'll decide whether to ship 1.13 based on the testing of both. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for people to be stewards of rpminspect-data-fedora
On Tue, 2024-04-09 at 14:14 -0700, Kevin Fenzi wrote: > On Tue, Apr 09, 2024 at 01:55:41PM -0400, David Cantrell wrote: > > Hello all, > > > > I am looking for multiple people to help be upstream stewards of the > > rpminspect-data-fedora project. This is a project that contains config > > files and rules for running rpminspect on Fedora builds. It is a package > > containing distribution policy. It needs people to look over it and review > > and merge contributions from other developers, do occassional releases, and > > ensure that it is updated as new releases of Fedora are started (and we get > > new dist tags). > > > > The project currently lives here: > > > > https://github.com/rpminspect/rpminspect-data-fedora > > > > But absolutely can move depending on the desires of the individuals who > > take over maintenance. I created these rules files in the data package for > > rpminspect so that different vendors can customize how rpminspect runs and > > reacts to findings. Maintenance of the rules is independent of the > > software maintenance. > > > > If you are interested, please email me directly and we can get going on the > > logistics. If you have general questions, feel free to ask here. > > I wonder if this isn't something we should have the QE or releng teams > manage... ie, adding new branch info (releng), adjusting tests (qe)? potentially we can be involved in this, yes. I did not have time to look at it yet because of F40 release. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-04-08 @ 16:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-04-08 # Time: 16:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 4 proposed blockers and 5 proposed freeze exceptions for Final. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240408T16=1440=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Thu, 2024-04-04 at 18:35 -0400, Neal Gompa wrote: > On Thu, Apr 4, 2024 at 6:17 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Apr 03, 2024 at 11:21:36AM -0500, Michael Catanzaro wrote: > > > So here are three brainstorming proposals: > > > > > > (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be > > > careful about how we do it. I would still promote Fedora Workstation as > > > the > > > main/recommended "leading" desktop, would call Plasma an "alternative > > > desktop option," and would strongly caution against use of the word > > > "Workstation" anywhere in the branding for the Plasma version. That is, > > > let's continue to steer undecided users towards Fedora Workstation, while > > > making Plasma easier to find and presenting it more prominently than it is > > > today. > > > > I like this proposal. It would give the KDE spin more prominence and > > would be a good reply to the huge work that has been put into the spin > > in recent times. It also wouldn't disrupt our story about Fedora > > Workstation. > > > > If we call it "Fedora KDE Plasma Desktop" or similarly, it won't be > > confused with Fedora Workstation. > > > > So, effectively no change other than it moves from the Spins section > to the Editions section? That would also mean it should be on the > front page too, like the other Editions. Being an Edition is a very significant thing, though, as we conceive of Fedora more widely than just the download page. We put a bunch of hoops in the way of IoT and CoreOS becoming editions, and there are hoops in the way of Silverblue becoming one (or, you know, wherever we go with that path in the end). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Switch to DNF5 (system-wide)
On Wed, 2024-04-03 at 14:27 -0400, Przemek Klosowski via devel wrote: > On 4/3/24 06:36, Aoife Moloney wrote: > > the dnf-automatic command will be obsoleted. > > https://dnf5.readthedocs.io/en/latest/changes.html does not say anything > about automatic updates, and > > https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/ > > simply suggests that dns update be executed from systemd timers or cron > jobs. > > > dns-automatic provided a simple interface to a setup-and-forget > automatic updates; will DNF5 leave it to be set up by hand? > > I am asking because systemd timers have surprising behavior for > suspendable systems, which leads to problems if updates are scheduled > for off-hours. > > My experience is that even |WakeSystem=true does not make them reliable, > but I am not sure how to debug this (because the system is suspended, heh). > We do use dnf-automatic quite extensively within infra, I think. Has this been discussed with infra? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Wed, 2024-04-03 at 20:24 +0200, Marc Deop i Argemí wrote: > > Let's assume that we all agree with what you stated ( and I personally partly > do). > > Why do we promote Workstation (with Gnome) over any other alternative that > might arise? (in this case, a Fedora Workstation KDE) It's an interesting question. I would say my answer is "because it works better if we promote *something*". Forcing the choice on people who just want "desktop Fedora" is awkward. The reason we default to GNOME is because we ~always have. To me, this is a reasonable justification. Change is always uncomfortable and disruptive. If you have two equally good options and you already picked one, you should stick with it, not just switch between them every so often for the sake of it. If Plasma were demonstrably, markedly and uncontroversially *superior* to GNOME (please don't take this as an excuse to start a holy war, I am positing for the sake of this post that neither of the two is demonstrably, markedly and uncontroversially better than the other), the case would be different. > I understand that the Change Proposal is about switching the "Workstation" > concept to using Plasma KDE and that approach might have been flawed but... > how > do we challenge the "status quo" where everybody assumes that Fedora's > default > is Gnome? Again personally, I would set a very high bar for this to happen, purely on the grounds of conservatism. Don't change for the sake of change. I would only support changing Fedora's default desktop if it was very clear that the current default was sufficiently flawed that it was hurting the project. I don't think we are at that point. > And I am not arguing for the sake of arguing. I genuinely want to know how to > make Fedora's default to be Plasma KDE because I do believe the whole *linux* > (and Fedora's) community will benefit from having a major distro like Fedora > not defaulting to Gnome. There already is at least one. The most prominent download option for openSUSE is their "Offline image" (equivalent of our old Everything DVD), and the top item in the list of possible "roles" for the system (effectively the choice we are discussing here) is "Desktop with KDE Plasma" (at least in the screenshot in the install guide). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Tue, 2024-04-02 at 21:15 -0400, Steve Cossette wrote: > I get your point, Kevin. I would argue though that, if a user is looking to > use Linux, they probably got a decent idea as to what DE they want to use. > There are SO MANY LINUX DISTROS! Making a choice between two is > honestly probably not that jarring imo. I mean, we really don't need to speculate about this much. We did an entire overhaul of the project - Fedora.next - which was explicitly based around making it much more focused and less of a choose-your-own- adventure, specifically including making the download page much more opinionated. AFAIR, the numbers Matthew tracks strongly indicate this was associated with a very significant immediate bump in Fedora usage. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Wed, 2024-04-03 at 00:15 +0200, Kevin Kofler via devel wrote: > Adam Williamson wrote: > > It occurs to me - maybe you don't agree, but this is how it looks to me > > - that, ironically, you and I usually argue the exact *opposite* side > > of this case, no? I argue in *favor* of somewhat-arbitrary delays to > > packages appearing in 'stable', and you argue *against* them. :D > > I have never argued against updates-testing existing or that all packages > should skip updates-testing. "Please pick up this new upstream version, it > has some great new features" as was done here is exactly the kind of changes > that SHOULD go through updates-testing. But if the maintainer has something > urgent to push out, such as an important regression fix or a critical > security fix (e.g., a fix for a backdoor like this one), they should be > allowed to decide to skip testing and not be treated as being too > incompetent for that (while at the same time allowing any other person, with > no other credentials than a FAS account, to +1 the package, allowing it to > be autopushed to stable – everyone except the one person most qualified to > make that decision). THAT is what I have been arguing for all this time, and > I do not see how this contradicts my position here in any way. Fair enough. I think the rest of my post stands, though, as it was more about my argument than yours. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote: > > I am a happy KDE user, since the good old days of version 1.0. I celebrate > this decision! My recognition goes to the enormous and sustained work of > the entire KDE community. > Cheers, > Sergiio To be clear, there is no 'decision'. This is a Change proposal. Any Fedora community member can submit a Change proposal proposing just about any change; I could submit one tomorrow proposing we abandon all software development and open a yak farm instead. A Change proposal existing is in no way an indication of any ultimate outcome. Change proposals can be, and frequently are, rejected. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Tue, 2024-04-02 at 21:05 +0200, Kevin Kofler via devel wrote: > Aoife Moloney wrote: > > Switch the default desktop experience for Workstation to KDE Plasma. > > The GNOME desktop is moved to a separate spin / edition, retaining > > release-blocking status. > > It is funny that the KDE SIG is proposing that now. I have a sense of déjà- > vu: > https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default > > Back then, the KDE SIG was NOT willing to support my proposal (even though > the timing would have been ideal, given that GNOME was badly hit at the time > by the GNOME 3 transition and users disappointed by the radical cuts in > customizability). Now they are refloating it as their own, without even > citing my original proposal. Kevin, I know you and I have been around forever and 2011 feels like yesterday, but it was really quite a long time ago. Some of the people involved in the proposal didn't even use Fedora in 2011. Heck, there are probably people using Fedora who weren't *born* in 2011. If you compare the KDE SIG member list from May 2011 (approx. time of your old proposal) and the current one, the only people who appear on both lists are Rex Dieter and Than Ngo, neither of whom is an owner of this Change proposal. https://fedoraproject.org/wiki/SIGs/KDE https://fedoraproject.org/w/index.php?title=SIGs/KDE=239023 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Reminder: F40 final freeze starts next week (2024-04-02)
On Tue, 2024-04-02 at 10:22 -0600, Jerry James wrote: > > - We retroactively change the time to stable of all updates that have > already been submitted. I might have an update that I think will go > stable in 1 more day, and suddenly it isn't going to go stable for 5 > more days. This is a constraint of Bodhi's current implementation. It doesn't keep a permanent record of what the value was at creation time for each update, it re-calculates it from the current configured value at various points, including when you try to do a push. I think we kinda want this behaviour, but we *could* do a better job of communicating when it changes, at least. Currently it's rather confusing if you get caught in the change, because you see the "this update can be pushed stable" comment as the last thing on the update, but it actually can't. We *could* detect when this changes and post a new 'oops, sorry, no it can't any more' comment. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, 2024-04-01 at 23:37 +0200, Kevin Kofler via devel wrote: > Adam Williamson wrote: > > > * Deleting ALL files automatically generated or imported by autotools in > > > %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it > > > would NOT have done the right thing here. Delete the files, THEN run > > > autoreconf.) > > > > No. This would not have avoided the attack, because it would not have > > regenerated the malicious file. We have already established that. > > Just running autoreconf would not. As I wrote: "DO NOT trust autoreconf, it > would NOT have done the right thing here." Deleting the file with an > explicit rm -f in %prep, and THEN running autoreconf would have regenerated > (reimported, actually, this comes from gnulib and is copied unchanged, but > in any case it would NOT have contained the malicious additions) the file. > > That said, autoreconf needs fixing too, because -f is supposed to regenerate > all files that can be regenerated, which is not happening. But if you > explicitly delete the files before running autoreconf, then it has to > regenerate them no matter what. Sure, but as others posted upthread, this still doesn't help much. To do this you have to know what m4s are 'standard' and will actually be regenerated, and which are custom and you can't wipe them. And then an attacker could just slip in an extra custom one instead of modifying a 'standard' one. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Outage alert: openQA result reporting (affects critical path gating), nightly page updating, candidate compose nominations
On Mon, 2024-04-01 at 08:53 -0700, Adam Williamson wrote: > Hi folks! I just discovered this so I'm still investigating it, but > wanted to give a quick heads-up. > > It looks like the message consumers on openqa01 all broke on Saturday > when a fedora-messaging update landed. This affects a lot of things, > but by far the most important is that openQA test results are not > getting reported to resultsdb. This will be causing all critpath > updates to be stuck in gating. > > I am going to investigate this urgently, of course, and as a stopgap I > will manually trigger submission of all reports from the last couple of > days shortly. Very sorry for the inconvenience. > > Also affected: https://openqa.fedoraproject.org/nightlies.html and > .json are not getting updated, validation test events are not being > created, check-compose emails not being generated, possibly something > else I've forgotten. OK, I've found the cause of this: a 'modernization' of the fedora- messaging spec caused the hashbang of /usr/bin/fedora-messaging to change so it is run with `python3 -sP`, which causes python not to use libraries from /usr/local/lib . This was a surprising and unexpected change in a stable release update, and it may affect other folks too. See https://bugzilla.redhat.com/show_bug.cgi?id=2272526 . I'll work around this for now and wait to see what comes of the bug report. The consumers will gradually catch up with all the stuff they should have been doing for the last two days over the next little while. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
On Mon, 2024-04-01 at 12:16 -0500, Michael Catanzaro wrote: > On Mon, Apr 1 2024 at 10:12:55 AM -07:00:00, Adam Williamson > wrote: > > This is not really correct, or at least at all relevant. The bug > > wasn't > > in F40 Beta simply because the update never made it to 'stable'. Only > > 'stable' packages go into *composes*. However, saying that is not > > really useful because anyone who *installed* Beta and then updated it > > regularly may have got the vulnerable package. We should not say > > anything to give people the impression that if they installed Beta, > > they don't need to worry. That is not true or helpful. > > Thing is, the bug was fixed before Fedora 40 Beta was released. If you > installed the beta on or after the release date, you never got the > builds with ifuncs enabled. This is why it's correct to say that only > "pre-beta" builds were backdoored. Oh, ISWYM. Well, I suppose yes, that does happen to be true. We could communicate that if it's done very carefully and made really clear that it's about the *time frame*, nothing to do with the repositories. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
On Mon, 2024-04-01 at 09:32 -0500, Michael Catanzaro wrote: > On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz > wrote: > > "Fedora Linux 40 branched users (i.e. pre-Beta) likely received the > > potentially vulnerable 5.6.0-2.fc40 build if the system updated > > between March 2nd and March 6th. Fedora Linux 40 Beta users only > > using stable repositories are NOT impacted. Fedora Linux 39 and 38 > > users are also NOT impacted." > > > > -> only pre-beta, not beta, affected > > -> F40 beta using stable NOT impacted (without challenging the > > previously distributed assumption that testing is disabled by default) > > > > That's still the same false information, isn't it? > > > It looks correct to me. The bug was fixed prior to the final release of > F40 beta, This is not really correct, or at least at all relevant. The bug wasn't in F40 Beta simply because the update never made it to 'stable'. Only 'stable' packages go into *composes*. However, saying that is not really useful because anyone who *installed* Beta and then updated it regularly may have got the vulnerable package. We should not say anything to give people the impression that if they installed Beta, they don't need to worry. That is not true or helpful. > so describing it as "pre-beta" makes sense. And people who > used only the stable repos were indeed not affected. The article later > clarifies that updates-testing is enabled by default (although it would > be nicer to do this higher up rather than lower down the page). For the same reason I think it's dangerous and not useful to try and draw this distinction between notional "people who only use stable repos" and people who use testing. Who would actually install F40 but then manually turn updates-testing off? Very few people. I don't think we should talk about this because it just confuses the issue. It would be like saying a stable release security issue that appeared in a stable update didn't affect people who turned off the updates repo. Technically true, but people don't do that, why would we say it? We should have a simple and clear message that covers the most common and important case: if you installed Fedora 40 and updated regularly during the vulnerable time frame, you very likely got the vulnerable package and should take appropriate action. We should not confuse this with unnecessary verbiage about stable and testing and pre-Beta and post-Beta. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]
On Mon, 2024-04-01 at 12:27 -0400, Neal Gompa wrote: > > > > ii) the fact that this attack reinforces the painful truth that > > sophisticated attackers *are* extremely interested in attacking the > > supply chain of which we form a significant component > > Can we please reframe it for what it actually is? This is an attack on > open source communities. "Supply chain" implies a lot of things that > simply don't exist in open source development. Almost the entirety of > the sophistication of the attack was social engineering, not technical > engineering. There *are* technical things to improve, for sure, but > let's not try to make it sound like it's a wholly technical thing that > can be solved with technical solutions exclusively. There are people > and community problems that need addressing too. This feels like a derail, so splitting it into a separate subthread. Honestly, I don't see how the first part of your paragraph relates to the second. I agree with a lot of the second part, but not the first. I think we *are* part of a supply chain, regardless of any handwaving about The Open Source Model. If you are part of producing stuff that people use to do Real Life Stuff, you are part of a supply chain. You might want to disclaim various responsibilities for various reasons, but you still are. If you don't want to be part of a supply chain, stop supplying stuff. I get the argument that there's a difference between putting a plank over a stream with a CROSS AT YOUR OWN RISK sign and charging people to cross your toll bridge, but there are *also* some similarities. I agree that the social engineering aspects of this attack were very significant (though I disagree that was "almost the entirety of the sophistication" - the technical elements were also pretty sophisticated). But I don't see why that leads to bikeshedding about whether this is a "supply chain" attack or not. Why is a "social engineering attack" not a supply chain attack, but a "technical attack" is? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, 2024-04-01 at 05:58 -0700, Carlos Rodriguez-Fernandez wrote: > Test isolation is still assuming the attack comes in the test phase. As I initially suggested it, it does not. My suggestion was that we ensure the test code is not available to the prep / build / install phases *at all*, and is only made available to the test phase. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote: > > Adam Williamson wrote: > > > Maybe this needs to go on the growing pile of reasons why the > > > traditional Linux model *does* need to go away. Maybe Fedora, with its > > > foundation of First, should be kind of at the forefront of making that > > > happen. > > > > Switching to a container-based model is just going to introduce more > > different library versions (in the worst case, one per container) with a > > higher probability that one of them is compromised. > > Our traditional distro model is not perfect — far from it — and we > certainly try to improve it. But I agree with Kevin that in _this > particular case_, the other models have smaller chances of catching > the issue. > > Here the upstream was compromised, so 2FA, upstream signatures, and any > other checks don't help at all. Yes, to be clear, my "this" was not "the specific technical details of this attack". It was more: i) the factors I listed in my email about just how many people are trusted to build 'Fedora', when 'Fedora' is essentially a collection of arbitrary scripts executed as root ii) the fact that this attack reinforces the painful truth that sophisticated attackers *are* extremely interested in attacking the supply chain of which we form a significant component -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Outage alert: openQA result reporting (affects critical path gating), nightly page updating, candidate compose nominations
On Mon, 2024-04-01 at 08:53 -0700, Adam Williamson wrote: > as a stopgap I > will manually trigger submission of all reports from the last couple of > days shortly. correction: I won't do this right away, as there would be a flood of duplicate reports if I did then fix the consumers. If I can't fix the consumers relatively soon I'll bite that bullet and do it, though. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Outage alert: openQA result reporting (affects critical path gating), nightly page updating, candidate compose nominations
Hi folks! I just discovered this so I'm still investigating it, but wanted to give a quick heads-up. It looks like the message consumers on openqa01 all broke on Saturday when a fedora-messaging update landed. This affects a lot of things, but by far the most important is that openQA test results are not getting reported to resultsdb. This will be causing all critpath updates to be stuck in gating. I am going to investigate this urgently, of course, and as a stopgap I will manually trigger submission of all reports from the last couple of days shortly. Very sorry for the inconvenience. Also affected: https://openqa.fedoraproject.org/nightlies.html and .json are not getting updated, validation test events are not being created, check-compose emails not being generated, possibly something else I've forgotten. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, 2024-03-31 at 20:27 -0700, Adam Williamson wrote: > > > What WOULD have greatly reduced the impact of this attack: > > * NOT enabling updates-testing by default for Branched releases. > > This would only have helped by coincidence - the coincidence that the > compromise was discovered so quickly. Otherwise, we were busy trying to > get this update pushed stable as fast as possible, because rwmj wanted > that. If the compromise had happened to be caught a few days later, the > update would have been pushed stable anyway. Our gating and manual > testing processes are not designed to catch security issues, and > certainly do not reliably do that job. They did not in this case. So it > seems wrong, to me, to suggest we should rely on them to do it in > future. Thus I disagree that any possible security benefit gained by > doing this would outweigh the substantial disadvantage that we wouldn't > get testing of stuff promptly any more. > Having thought this over a bit, I think I should moderate my position here and make it a bit more nuanced. It occurs to me - maybe you don't agree, but this is how it looks to me - that, ironically, you and I usually argue the exact *opposite* side of this case, no? I argue in *favor* of somewhat-arbitrary delays to packages appearing in 'stable', and you argue *against* them. :D So, I don't think I can in full conscience justify being so categorical. So let me put more emphasis on the "difference between security and quality" aspect here. Let's look at the *intent* of the existing policies, here. Practically speaking, what our policies *achieve* is that for stable releases, updates-testing acts to *guard Fedora users' systems*. That is its function there. That's why it is not enabled by default, and we ask only people who want to contribute to testing to enable it, and understand that they are "taking a bullet for quality" by doing so. The idea is that by preventing updates reaching 'ordinary' users' systems before our testers have at least had an opportunity to try the packages out, we will catch at least some quality issues and prevent ordinary users from being affected by them. The process is specifically designed to achieve this. We have automated *quality* checks on packages in updates-testing (but almost nothing in the way of automated *security* checks). We have a whole process geared towards getting testers to test out the packages and report their findings - in *quality* terms. This is, to me, a job it's reasonable to ask a fairly broad range of folks to help with. It works reasonably well. We have done a reasonable job of implementing a process that lets a person without really specific training install a test update, experience a problem in it, and communicate that they encountered that problem in such a way that we are able to prevent the package reaching a wider swathe of users. It's not *perfect*, but it does provide some demonstrable value. Similarly on the automated testing side, both Fedora CI and openQA provide useful gating of some packages. It is by no means comprehensive, but it *is* useful. We catch bugs and prevent them reaching regular users. We don't catch *all* bugs, but we can reasonably claim to be purposefully and intentionally catching a reasonable number with this system. OK, that's for stable releases. What about development releases? It's key to realize that for development releases, the process looks very similar, but just that one change - updates-testing defaulting to off - *changes its entire purpose*, and this is by intent. For development releases, the purpose of updates-testing is **NOT** to protect 'ordinary users'. It is to protect **the Fedora development process**. We don't really intend for there to *be* "ordinary users" of Fedora development releases. We make it fairly clear that, by using a development release, you are taking yourself out of the "regular user" category and putting yourself in the "tester / developer" category. We do not feel such an obligation to provide users of development releases with quality-tested code. On the contrary, to a degree, they are supposed to be *helping* with the process of quality testing for the ultimate goal of making the *final* release good for "ordinary users". So if you're a user of a development release, we do not really feel an obligation to provide the same "safety net" for you that updates- testing provides for "regular users" of stable releases. Instead, the point of updates-testing in development releases is to let us prevent breakages in *the process of building the distribution*. We expect *all* users of development releases to help with this by flagging up when they see breakage, so we can prevent broken packages appearing in the buildroot or the compose process. *That* is why we have updates-testing for development releases.
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote: > Adam, > > Is there a way already to achieve test isolation during the rpm build? Nothing systematic that I'm aware of, no. It would be tricky because there is no one universal Standard Test System (not even within a single language ecosystem, let alone across all of them). Currently you'd have to design something unique, if you wanted to implement this for your package. I suppose one approach would be to split the sources-required-for-build and the test suite into Source0 and Source1 (respectively) and only extract Source0 during %prep. Don't extract Source1 until %check (i.e. after %build and %install are already done). I'm just spitballing, though, haven't checked if this is really practical. Of course, another approach is to really do what Kevin suggests and not ship the test suite in the package source at all, but instead run the tests via Fedora CI, and configure the package to be gated on that CI check (so it wouldn't go to stable without the tests passing). But that's rather a different approach (and would still require 'custom' work to cut the tests out of the source, or at least delete them before running the build). And I still think at this point we are falling into the trap of thinking too specifically about an attack vector which just *happens* to be the one chosen in *this specific instance*. It's still worthwhile, on some level, for someone to think about that kind of hardening, of course. I am just not convinced it is the most useful thing Fedora could be doing right now in the general area of "supply chain hardening". -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-04-01 @ 16:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-04-01 # Time: 16:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 3 proposed blockers for Final. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240401T16=1440=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-04-01 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-04-01 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting=20240401T15=1440=1 If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 status and Final planning 3. xz compromise discussion 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, 2024-03-31 at 20:12 +0200, Kevin Kofler via devel wrote: > Adam Williamson wrote: > > I would argue there's a danger of getting too tied up in very specific > > technical details of this attack. > > But the fact is: > > What WOULD have stopped this attack: (one or more of:) > * Deleting ALL unit tests in %prep (and then of course not trying to run > them later). This comes with the huge cost that we no longer have any idea if many things actually work in Fedora. There are much better options here, such as ensuring the package build process *isolates* the test data from the compile process without just *removing* it. but again, this is getting far too tied up in the details of this *one* attack. it's the "everyone has to take their shoes off at the airport forever" mistake: just because the *last* attack involved a binary test file, does not mean the *next* one will. This is also known as preparing for the last war, in military strategy. > * Deleting ALL files automatically generated or imported by autotools in > %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it would > NOT have done the right thing here. Delete the files, THEN run autoreconf.) No. This would not have avoided the attack, because it would not have regenerated the malicious file. We have already established that. > * NOT patching OpenSSH downstream to link it against libsystemd against > upstream's recommendation. Again, this is far too tied to the specific attack. I'm not interested, as I said, in Monday morning quarterbacking this specific attack. I'm interested in the question of what are the most immediate and effective ways Fedora can lower its likelihood to be directly targeted in a supply chain attack *in future*. Not the last one. > What WOULD have greatly reduced the impact of this attack: > * NOT enabling updates-testing by default for Branched releases. This would only have helped by coincidence - the coincidence that the compromise was discovered so quickly. Otherwise, we were busy trying to get this update pushed stable as fast as possible, because rwmj wanted that. If the compromise had happened to be caught a few days later, the update would have been pushed stable anyway. Our gating and manual testing processes are not designed to catch security issues, and certainly do not reliably do that job. They did not in this case. So it seems wrong, to me, to suggest we should rely on them to do it in future. Thus I disagree that any possible security benefit gained by doing this would outweigh the substantial disadvantage that we wouldn't get testing of stuff promptly any more. > > What WOULD NOT have stopped this attack: (any or all of:) > * 2FA. GitHub already enforces 2FA. It did NOT stop this attack. Again. I'm not interested in what, with hindsight, might have stopped the attack that already happened. We know for sure that weak authentication processes absolutely are a giant flashing ATTACK HERE neon sign for *future* attackers. > * Any stricter vetting of Fedora contributions. The attack was performed > upstream, NOT in Fedora. See above. > * More distrust of new Fedora contributors. The offending upgrade was > imported by a TRUSTED Fedora contributor. The untrusted new person operated > upstream, NOT in Fedora. See above again. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, 2024-03-31 at 07:42 -0400, Neal Gompa wrote: > On Sun, Mar 31, 2024 at 7:36 AM Arthur Bols wrote: > > > > On 31/03/2024 13:03, Kevin Kofler via devel wrote: > > > > This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for > > contributors for a while, starting with "important" projects, then getting > > stricter and stricter. It has done absolutely nothing to stop this attack. > > How could it, when the backdoor was apparently introduced by the authorized > > maintainer? (Or if not, the attacker must have had access to their 2FA > > secret as well.) So, 2FA DOES NOT SOLVE THIS PROBLEM! STOP FORCING 2FA ON > > US! And especially DO NOT abuse this incident as an excuse to force 2FA down > > our throats, since 2FA DOES NOT SOLVE THIS PROBLEM. Sorry for being > > repetitive, but you were, too. THIS 2FA NONSENSE NEEDS TO STOP! > > > > > > 2FA for Fedora packagers doesn't solve this issue, but that wasn't Adam's > > point. What Adam is saying is that we're in danger of focusing too much on > > a specific issue while we should spent our time and energy on the general > > security aspect of Fedora. 2FA isn't nonsense, it strengthens security by a > > lot. A compromised (proven)packager account can do a lot of harm and can > > take a while to be noticed. If this would happen to us, Fedora's reputation > > would tank immediately. Mint is still regarded as a insecure distro (in my > > circles) for things that happened before I even entered the linux scene... > > > > Like it or not, this is 2024 and passwords are not as secure as they used > > to be. Yelling about it isn't going to solve anything. Meanwhile, enabling > > 2FA helps A LOT even if used incorrectly (e.g. storing it in the same > > keepassxc database). > > > > At this point, I'm used to MFA for stuff (and I use a password manager > that handles 2FA OTPs too), but the Fedora implementation of MFA is > uniquely bad because we have to do a lot in the terminal, and our MFA > implementation sucks for terminal usage. > > If MFA is turned on: > > 1. The Fedora account integration in GNOME breaks > 2. You need to concatenate password and OTP for getting a krb5 session ticket > 3. The recovery mechanism involves GPG signed emails > > The experience using 2FA for Fedora accounts is sufficiently > unpleasant that I really don't want to use it. Copying this comment here from the FESCo ticket at Kevin's request - please follow up here, not there: I think the points above and others made later about areas where the 2FA experience on Fedora are bad are absolutely correct and justified. I also think there is a solid argument that we should do this anyway. I think the vulnerability associated with having packager (and provenpackager? Do we require 2FA for provenpackager yet? I wasn't actually sure, when I wrote my list post) accounts without 2FA is sufficiently horrendous that we just cannot accept it. Yes, our implementation of 2FA is suboptimal and would frustrate people. Is that worse than the consequences of letting ourselves be compromised? Imagine how brutal the response would be if it came to light that Fedora had been compromised through exploitation of single-factor authentication. It would not be kind. It would be a huge and lasting stain on our reputation. People would say, justifiably so, that it was absolutely unacceptable for us to be allowing single-factor authentication for contributors to a general-purpose operating system in 2024. It is. We now have incontrovertible evidence that extremely sophisticated attackers are willing to mount extremely sophisticated attacks on the supply chain of which we are a significant component. We are busy Monday morning quarterbacking about extremely complex ways to try and counteract an attack of that sophistication. Meanwhile we are still leaving this huge vulnerability to much less sophisticated attacks, which has been known to be one for literal decades at this point, open. We know that much less sophisticated attackers exploit single-factor authentication for purposes as trivial as stealing cryptocurrency, and it happens frequently. I don't think we can pretend we can't connect the dots here. On a practical level, if we just made 2FA compulsory, it would provide people with a much stronger motivation to contribute and make the experience of it better. So long as we let people not use it, that motivation does not exist. I suspect if we just did it, we'd get a more sophisticated experience with Kerberos and recovery tokens and all the rest of it much faster than we will if we don't. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, 2024-03-31 at 13:28 +0100, Daniel P. Berrangé wrote: > > > > 3. We have no mechanism to flag when J. Random Packager adds > > "Supplements: glibc" to their random leaf node package. As a reminder, > > *we are a project that allows 1,601 minimally-vetted people to deliver > > arbitrary code executed as root on hundreds of thousands of systems*, > > and this mechanism allows any one of those people to cause the package > > they have complete control over to be automatically pulled in as a > > dependency on virtually every single one of those systems. > > This is as much a distro design problem, as a Fedora process > problem. The typical Linux distro model is that everything is > installed in the same namespace, and we only avoid interference > (whether accidental or intentional) by careful packaging design > and review. > > This is somewhere where the image based Linux distro model has > a potential benefit, with a comparatively slim distro base, and > then applications as self contained separated entities, whether > server apps in podman containers, or GUI apps in flatpaks. > > No easy anwere here though, as the traditional Linux model isn't > going away any time in the forseeable future. Well, definitely no easy answers, but I would argue this is the kind of thing we as a distributor *should* be worrying about and addressing, maybe with more urgency than things that are not primarily the responsibility of the distributor, in the supply chain. Maybe this needs to go on the growing pile of reasons why the traditional Linux model *does* need to go away. Maybe Fedora, with its foundation of First, should be kind of at the forefront of making that happen. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, 2024-03-31 at 13:35 +0200, Arthur Bols wrote: > On 31/03/2024 13:03, Kevin Kofler via devel wrote: > > This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for > > contributors for a while, starting with "important" projects, then getting > > stricter and stricter. It has done absolutely nothing to stop this attack. > > How could it, when the backdoor was apparently introduced by the authorized > > maintainer? (Or if not, the attacker must have had access to their 2FA > > secret as well.) So, 2FA DOES NOT SOLVE THIS PROBLEM! STOP FORCING 2FA ON > > US! And especially DO NOT abuse this incident as an excuse to force 2FA down > > our throats, since 2FA DOES NOT SOLVE THIS PROBLEM. Sorry for being > > repetitive, but you were, too. THIS 2FA NONSENSE NEEDS TO STOP! > > 2FA for Fedora packagers doesn't solve *this* issue, but that wasn't > Adam's point. What Adam is saying is that we're in danger of focusing > too much on a specific issue while we should spent our time and energy > on the general security aspect of Fedora. 2FA isn't nonsense, it > strengthens security by a lot. Thanks Arthur, yes, that was *exactly* the point. I would argue there's a danger of getting too tied up in very specific technical details of this attack. Yes, it's reasonable to think of ways to mitigate those specific mechanisms, at least at the appropriate levels (arguably, most of this is really directly an issue upstream of us). But it has been - for me - persuasively argued that the specific technical details were decided based on the wider goals of the attack. I buy the scenario where the starting point was "how can we poison the major distributions?" and everything from there derived from that starting point. xz was picked as the target because of all the specific technical stuff about systemd and ssh links which people are keen to dive deep into the details of, but *if that vector hadn't existed the attacker would just have chosen the next best one*. The specific form of the attack was then customized to the specific properties of xz, very cunningly - the whole thing about hiding the payload in binary test files. But if the attacker had chosen to attack a different project with different properties, they would have customized their attack to *that* environment with equal cunning, and it would probably look quite different. Worrying *only* about binary blobs in source repos or the specific details of how systemd opens compression libraries feels a bit narrow, to me - and especially so when we do it down at the distribution level where it's not necessarily primarily our responsibility, and I would argue is definitely not the *lowest* hanging fruit if we take a broader view of "what should we as a project be doing to raise the difficulty of supply chain attacks?" -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sun, 2024-03-31 at 13:03 +0200, Kevin Kofler via devel wrote: > > > 2. Our process for vetting packagers is, let's face it, from a security > > perspective almost *comically* patchy. There are 140 sponsors in the > > packager FAS group. Any one of those people - or someone who > > compromises any one of those 140 accounts - can grant any other person > > on earth Fedora packager status. Our policy on how they should do this > > is > > https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection > > . The words "trust" and "identity" do not appear in it. There is, > > AFAIK, no policy or procedure by which inactive sponsors have this > > power removed. There is no mandatory 2FA policy for sponsors. > > We already have a manpower problem, how is removing sponsors going to > improve the situation? Removing inactive sponsors makes it harder for an attacker to compromise an inactive sponsor's account and use it for evil. However, looking into it it looks like I made a mistake here: we do have an inactive *packager* policy, as well as an inactive *proven packager* policy. I had misremembered that we did not have the former, only the latter. So at *least* a sponsor who becomes completely inactive in the project will eventually get removed as a packager entirely (and hence also as a sponsor). I don't think that's entirely sufficient, but it's better than I thought. > > 3. We have no mechanism to flag when J. Random Packager adds > > "Supplements: glibc" to their random leaf node package. As a reminder, > > *we are a project that allows 1,601 minimally-vetted people to deliver > > arbitrary code executed as root on hundreds of thousands of systems*, > > and this mechanism allows any one of those people to cause the package > > they have complete control over to be automatically pulled in as a > > dependency on virtually every single one of those systems. > > This would get noticed pretty quickly, when that package comes up in update > transactions for no reason. I believe this has never happened so far. It is > just too obvious. "Would get noticed pretty quickly" is not really acceptable. It should not be possible to do it at all. This was just an example really, too. I am not a very good red teamer. I'm not imaginative enough. There are probably all sorts of more subtle ways a malicious person with packager privileges could leverage them to attack more people than they could attack just through 'normal' maintenance of a leaf package. Just for another example, we have had two significant cases recently of "package X incorrectly provides capability Y". 1. sdubby was providing grubby with a higher version than the real grubby package, which seems to have caused it to get installed in preference to grubby on fresh installs and upgrades when it should not have been. 2. some relatively obscure package somehow started including bundled copies of dozens of core system libraries, which made the auto-provides generator generate provides for those libraries. dnf then started preferring it over the 'real' providers of some of those libraries, I think because it had a shorter dep chain. Neither of these was, AFAICT, flagged as a potential security issue by anyone, but it seems reasonable to me that they should have been. I know about them because we happened to catch them as quality issues, but it is not hard to imagine that a malicious packager may be interested in using the same effect intentionally for evil, and they would obviously be careful to try and set things up such that this would *not* cause anything easily noticeable as a quality defect. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, 2024-03-30 at 09:37 +, Richard W.M. Jones wrote: > I'm not pretending these will solve everything, but they should make > attacks a little harder in future. I don't disagree with Richard's list. However...more in regards to some of the grandiose ideas in later posts than Richard's list...I think we're in danger of building castles in the sky while not cleaning up the poop in our backyard, here. Before we start in on the grand fantasies about converting the world off autotools or banning binaries in repos or centralized source depots authenticated by a committee of Top People, can we remember: 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE COMPULSORY 2FA FOR FEDORA PACKAGERS*. 2. Our process for vetting packagers is, let's face it, from a security perspective almost *comically* patchy. There are 140 sponsors in the packager FAS group. Any one of those people - or someone who compromises any one of those 140 accounts - can grant any other person on earth Fedora packager status. Our policy on how they should do this is https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection . The words "trust" and "identity" do not appear in it. There is, AFAIK, no policy or procedure by which inactive sponsors have this power removed. There is no mandatory 2FA policy for sponsors. 3. We have no mechanism to flag when J. Random Packager adds "Supplements: glibc" to their random leaf node package. As a reminder, *we are a project that allows 1,601 minimally-vetted people to deliver arbitrary code executed as root on hundreds of thousands of systems*, and this mechanism allows any one of those people to cause the package they have complete control over to be automatically pulled in as a dependency on virtually every single one of those systems. 4. Our main auth system was written years ago by someone who no longer contributes and nobody is really actively maintaining it[0]. These are just the ones that leap to my tired mind at this moment. I'm sure we can think of many more things we should probably look at before we start pontificating (or, worse, lecturing) about how things should be done upstream of us. [0]: https://pagure.io/ipsilon/commits/master -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
On Sat, 2024-03-30 at 16:41 -0700, Kevin Fenzi wrote: > On Sat, Mar 30, 2024 at 11:12:02PM +0100, Sandro wrote: > > > > From what I understood, F40 Beta, the official Beta release, available from > > the website as of March 26, has updates-testing disabled by default. That > > Nope. > > > was confirmed by several people in #devel yesterday when the Fedora Magazine > > article was still being worked on. > > I am pretty sure I said the opposite... > > nirik: Branched enables updates-testing... so if you installed f40 anytime, > you will have it enabled and if you then applied updates it would be in them > nirik: yes, we disable updates-testing by default right before release. > > I guess that could have been read as right before beta release, but > thats not the case or what I meant. ;) > > It's before _Final_ release that we disable updates-testing. > It's enabled by default from when we branch the release off until the > time right before release when we switch it (usually with a freeze > break/blocker bug) Yes. https://dl.fedoraproject.org/pub/alt/stage/40_Beta-1.10/Everything/x86_64/os/Packages/f/ contains fedora-repos-40-0.4.noarch.rpm . That is from fedora-repos-40- 0.4 . The Koji build for that is https://koji.fedoraproject.org/koji/buildinfo?buildID=2411685 . It records that the dist-git commit was b0be9579a9b45a44bc2e30fbd7d5ef4a268f05a2 . Here is the dist-git repo at that commit: https://src.fedoraproject.org/rpms/fedora-repos/tree/b0be9579a9b45a44bc2e30fbd7d5ef4a268f05a2 . Note this line: https://src.fedoraproject.org/rpms/fedora-repos/blob/b0be9579a9b45a44bc2e30fbd7d5ef4a268f05a2/f/fedora-repos.spec#_2 . QED. updates-testing is enabled by default in Fedora 40 Beta. This is normal, intended, and expected. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, 2024-03-30 at 12:53 +0100, Kevin Kofler via devel wrote: > I think the issue is that there is just too much stuff in critpath these > days. Whole desktop environments and all their transitive dependencies > probably ought to not be in there. If at all, I would put the display > manager in there, maybe the window manager, and no further. I wrote a mail about this a while ago. The problem is really that the "critical path" concept has changed somewhat over time, and gotten a bit overloaded. The original idea of critical path was to require special testing attention for it. Back in Ye Earlie Days, critpath packages had all kinds of special rules around them, including requiring +2 or +3 (it's a long time ago, I forget) from "proven testers" (remember those?) *Most* of that has now gone. The only significant of critpath for manual testing in the current update policy is that critpath packages have a longer minimum wait in updates-testing (14 days vs. 7 days, at least after a certain point in the release cycle). They do not have higher karma requirements (at least, not by policy; Bodhi doesn't actually implement the policy correctly ATM, but I'm fixing that). The karma minima defined in the updates policy are currently identical at all points in the cycle for critpath and non-critpath updates. The "proven testers" concept was put on ice long ago. The primary 'meaning' of critpath these days is that it triggers openQA testing, and critpath updates are gated on openQA testing. I set things up this way really just because it was convenient, and as is the way of things, now it's kinda baked in. We probably want to look at separating out the concepts a bit. It's certainly technically possible, it just requires some work. The 'releng.py' script that "generates the critical path" is really just a comps-informed depsolver that spits out JSON. It could generate all kinds of groups besides "critical path" groups. We'd just have to wire them up to *mean*...whatever we want them to mean. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
On Fri, 2024-03-29 at 15:01 -0500, Michael Catanzaro wrote: > On Fri, Mar 29 2024 at 07:56:49 PM +00:00:00, Richard W.M. Jones > wrote: > > secalert are already well aware and have approved the update. Kevin > > Fenzi, myself and others were working on it late last night :-( > > Sorry, I linked to the wrong article. I meant to link to [1] which says > that "At this time the Fedora Linux 40 builds have not been shown to be > compromised. We believe the malicious code injection did not take > effect in these builds." But this statement contradicts my findings > above, and you just replied "yes" to those, implying that my > understanding is correct. So I guess either this blog post is wrong and > needs to be updated, or you're wrong about me being right. Er, correct? > :) FWIW, I wrote that text, modified from a slightly different version in the earlier draft that was briefly published, and based on my best understanding at the time (which was that *no* build that reached F40 actually had a working version of the exploit). If Richard says the exploit potentially worked in 5.6.0-2, then F40 potentially *was* vulnerable for some time, because 5.6.0-2 reached updates-testing. You can use `dnf history info xz` to check if you ever had the vulnerable version installed. I'll see if we can get the post tweaked again; it will be hard to word it with the appropriate level of accuracy and urgency and still be readable, but I'll try... Oh, and we can't easily fix the URL of the blog post, apparently, because CMSes suck. It seems we're more less stuck with the "41" in that. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Reminder: F40 final freeze starts next week (2024-04-02)
On Tue, 2024-03-26 at 21:34 +0100, Sandro wrote: > On 26-03-2024 16:25, Kevin Fenzi wrote: > > So, please take this time to do any last minute testing and bugfixing > > and make sure any packages you expect to be in the final f40 base > > repositories are pushed stable before next Tuesday (2024-04-02). > > I was just wondering, and someone else with me, if today's updates would > still make it in time? > > If not, I thank you for the reminder nonetheless, but would also like to > ask to have it sent in time for updates to still be able to land in the > release before freeze happens. > > Of course, there's always the option of going around begging for > (instant) karma ... You still have a week until next Tuesday, so...yes. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-03-25 @ 16:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-03-25 # Time: 16:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 3 proposed blockers for Final. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240325T16=1440=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Test-Announce] Invitation to Contribute to Fedora Test Days: Podman Desktop Testing
On Wed, 2024-03-20 at 23:33 +1100, Philip Rhoades via devel wrote: > People, > > I am happy to do some testing but what is "Podman Desktop"? - I don't > see anything like that to install "dnf list" . . I have been on F40 for > a while now and am a regular user of Podman. It's a GUI for Podman, basically. https://podman-desktop.io/ . That page and the test cases for the test day should have more info on how to install and test it. The point of the test day is to make sure Podman Desktop, installed on Fedora in a recommended way, is working well with all the underlying bits in Fedora (podman itself and the things it depends on). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Re: Fedora 40 Candidate Beta-1.8 Available Now!
On Tue, 2024-03-19 at 05:58 +, rawh...@fedoraproject.org wrote: > According to [the schedule][1], Fedora 40 Candidate Beta-1.8 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://openqa.fedoraproject.org/testcase_stats/40 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.8_Summary Note on this: a 1.9 will be coming which should be identical to 1.8 except with Cinnamon and Budgie fixed (they were broken by the GNOME 46 FE in 1.8, and their images are missing). Testing on 1.8 is still useful and can mostly be transferred to 1.9, but you might want to wait 6-7 hours for 1.9 to show up before starting testing. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora container images no longer include gzip?
On Sun, 2024-03-17 at 23:12 +, Gary Buhrmaster wrote: > It appears that the quay.io container images > for F40 (and F41/rawhide) do not contain > the gzip package. I noticed due to an indirect > use of tar with a gzip archive on a github > workflow (the checkout failed due to no gzip). > > Did I miss an announcement (very possible), > or did something else change to no longer > pull in gzip (also possible)? Almost certainly. What changed is https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages - these images (all 'Cloud' and 'Container' images) are now built with Kiwi instead of ImageFactory/oz. I had "run a comparison of included packages" on my todo list, but hadn't got around to it yet, except for one image I sent a diff for to Neal last week. > If it was not intentional, I would like to > petition to have gzip added back explicitly. > If it was intentional, I'll adjust my workflow > accordingly. This probably wasn't intentional, and we can probably get it put back... -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-03-18 @ **15:00** UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-03-18 # Time: **15:00** UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. As a reminder, clocks went forward in North America last week, so the meeting is an hour earlier in UTC than it was before. If you have changed your clocks forward recently the meeting will be at the same local time as before, it not it will be earlier. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting=20240318T15=1440=1 If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 status (including Beta testing plans) 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-03-18 @ ** 16:00 ** UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-03-18 # Time: ** 16:00 ** UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 1 proposed freeze exception for Beta, and 10 proposed blockers for Final. As a reminder, clocks went forward in North America last week, so the meeting is an hour earlier in UTC than it was before. If you have changed your clocks forward recently the meeting will be at the same local time as before, it not it will be earlier. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240318T16=1440=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Re: Fedora 40 Candidate Beta-1.4 Available Now!
On Wed, 2024-03-13 at 19:26 +, rawh...@fedoraproject.org wrote: > According to [the schedule][1], Fedora 40 Candidate Beta-1.4 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan Sorry for the flood of composes, folks. At this point we still have open issues to address, including https://bugzilla.redhat.com/show_bug.cgi?id=2269385 , so there's almost certainly going to be a 1.5 at some point. Testing on pretty much any of the composes so far is still welcome and useful and you can pretty much assume if you hit something that looks like a significant bug in any of them you should report it and propose it as a blocker if appropriate. We're going to reassess where we stand later tonight (US time) and then tomorrow morning (again US time) to decide if there's any realistic prospect of a go decision on Thursday, and run a new candidate if so. Otherwise we may hold fire for a bit to let things settle and land some FEs. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Re: Fedora 40 Candidate Beta-1.3 Available Now!
On Wed, 2024-03-13 at 13:24 +, rawh...@fedoraproject.org wrote: > According to [the schedule][1], Fedora 40 Candidate Beta-1.3 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan For Deeply Technical Release Engineering Reasons (somebody forgot to update the right config file), 1.3 is effectively identical to 1.2. Please test either at your leisure, we'll treat results for both as interchangeable. There will be a 1.4 soon which should hopefully, really, really, really be built with kiwi and osbuild. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Re: Fedora 40 Candidate Beta-1.2 Available Now!
On Wed, 2024-03-13 at 04:50 +, rawh...@fedoraproject.org wrote: > According to the schedule [1], Fedora 40 Candidate Beta-1.2 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan A quick heads-up here: a Beta-1.3 compose will likely follow shortly, because we wanted to build some Beta images using new tools - see https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages and https://fedoraproject.org/wiki/Changes/ArmMinimalImageOSBuild - but these were mistakenly not used for the Beta-1.2 compose, the images were all built with the older tool instead. We'll likely try and do a Beta-1.3 which should be identical to Beta-1.2 but with the Cloud, Container and ARM minimal disk images built with the new tools instead of the old one. Testing of both candidates will be useful. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: perl segfault in F40
On Sun, 2024-03-10 at 21:06 -0600, Jerry James wrote: > > Your choices are to wait for the F40 beta freeze to end, or lobby for > a freeze exception for the perl-PkgConfig-LibPkgConf update. Thanks for the detailed debugging, Jerry. If someone wants to propose this as an FE, it'd be great to get it in soon as the review meeting is starting in half an hour. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-03-11 @ ** 16:00 ** UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-03-11 # Time: ** 16:00 ** UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 2 proposed blockers and 5 proposed freeze exceptions for Beta, and 4 proposed blockers for Final. Please note that summer time starts in most of North America on Sunday, and we follow that time for these meetings, so the meeting time in UTC has changed. If you put your clocks forward this Sunday, the meeting will be at the same local time as it was last week. If you do not, the meeting will be one hour *earlier* than it was last week. You can always run `date -u` to see the current UTC time and check, if you're not sure. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240311T16=1440=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-03-04 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-03-04 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-03-04 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-03-04 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 2 proposed freeze exception for Beta, and 5 proposed blockers for Final. The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 13:27 -0600, Jason Tibbitts wrote: > > > > > > Adam Williamson writes: > > > Honestly, we could really use more automation here, but it's a fairly > > hard thing to do *reliably* and there just isn't anybody specifically > > tasked with it so it doesn't happen. > > So sure, we could use something but it doesn't have to start out as some > complex fully automatic system. (Would be nice, but...) > > Can we agree that we'd be at least half of the way there if we just had > a well defined way to: > > * Know what package depend on the one you're updating > > * Easily bump and chain-build all of that in a side tag > > Surely there's a reopquery or fedrq command line that will find at least > most of what needs to be rebuilt. It doesn't have to be absolutely > perfect but it can't be that hard to get close. I know there's a > distinction between build and runtime dependencies and rich/conditional > dependencies complicate things a bit, but those much smarter than I am > must have already figured out how to get something that's at least > somewhat useful. > > Once you have the package list, maybe it needs some kind of sorting > before you can just bump and chain-build things, but I think in many > cases it doesn't. So, yes, a 100% tool would be really hard but the 80% > tool really shouldn't be that bad, and almost any tool would really help > people out. Yeah, for sure, that's why I'm trying to nibble around the edges by updating the docs to strongly encourage chain builds, document using fedpkg chain-build on a side tag, and hopefully get fedpkg chain-build enhanced so it can create the side tag and the final update automatically. If we can get that, then I can make the docs explain how to use it. ISTR there've been several recent discussions of complex dep chains on this very list where people have floated candidates for repoquery/fedrq commands...if there's one we're pretty confident is The Best, we can definitely plumb that into the docs at least (plumbing it all the way into fedpkg might be a step too far, though). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 09:34 +0100, Michael J Gruber wrote:
> Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius
> :
> >
> > Hi,
> >
> > I intend to update gumbo-parser to 0.12.1 in rawhide.
> > This comes along with an soname bump libgumbo to libgumbo.so.2
> >
> > This requires a rebuilt of several dependent packages, AFAICT:
> > claws-mail
> > litehtml
> > mupdf
> > perl-HTML-Gumbo
> > python3-PyMuPDF
> > qpdfview
> > zathura-pdf-mupdf
> >
> > I'll try to rebuild these packages on side-tag f41-build-side-84865
> > (Please, bear with me, I haven't used side-tags, before. I couldn't find
> > any usable docs on how to use them)
> >
> > Preliminary tests indicate, something unrelated to libgumbo.so.* has
> > changed with these packages (Probably mupdf), causing gpdfview to FTBFS
> > and dependency changes in rawhide.
>
> Interesting. I wasn't aware of that dependency - I guess I have to
> re-run detection more often. Speaking of - do we have a policy about
> this? This is not about blaming, but how do we ensure that everyone is
> aware of new dependencies? Frequent re-runs to detect them or
> announcements the other way round?
Unless I've missed something, the general situation in Fedora is all
the onus is on the party bumping the depended-upon package. We don't
require dependent packages to announce their dependencies in any way
(except, you know, through an actual package dependency).
If you're changing a package in any way that could be fairly considered
"not backwards compatible" for another package depending on it in a
"typical" way, I'm pretty sure the onus is on you to find those
dependencies and make sure they are handled, not vice versa.
Honestly, we could really use more automation here, but it's a fairly
hard thing to do *reliably* and there just isn't anybody specifically
tasked with it so it doesn't happen. I had an interesting chat with
Martin Pitt about britney -
https://release.debian.org/doc/britney/what-is-britney.html - which
Debian and Ubuntu use in this area. If I understood the explanation
correctly, it's a sort of automated update bundler; Debian and Ubuntu
devs can just throw builds at a staging area, and britney takes care of
grouping them into logical sets based on their dependencies. So to do
an soname bump you'd build the bumped library in the staging area, wait
for it to appear in the staging area buildroot (I guess), then build
all the dependencies, and britney would figure out that this group of
packages needs to go out of the staging area and into stable together
and make that happen, so the packager doesn't have to group them
manually. If you've got a build in the staging area which britney can't
"solve", I think, you get alerts so you know what needs doing ("package
X needs rebuilding against your thing", or whatever).
Something along those lines for Fedora would be awesome! But we can't
just lift-and-shift britney - we'd have to adapt it to RPM dependencies
(if that hasn't been done already) and integrate it with Bodhi
(definitely not done already). That's a lot of work for someone. We
could conceivably code an equivalent feature into Bodhi ourselves, but
again, a lot of work for someone. And it'd probably need some thought
about a way to allow cutoffs/exceptions so you could get an soname bump
through if it has 500 dependencies and you've fixed 499 and the other
is some obscure package that hasn't been maintained for a year. All of
that is work that isn't #1 on anybody's priority list, I think :( I
would love to say I'm gonna work on it, but I've added three neat
projects to my "neat side project backlog" since *yesterday* and it's
about a thousand items long at this point, so, hmm.
It'd also be nice to have a reliable distro-wide automated check for
"does this update break the dependencies of anything else?" so we could
at least prevent all updates that break dep chains going stable. Right
now openQA catches some such cases, but *only* ones that affect
critical path packages *and* happen to involve a package that actually
gets installed during an openQA test. The CI rpmdeplint test is
supposed to cover this, I think, but historically hasn't proven
reliable enough to be made universally gating (and I think maybe only
works on Rawhide). But again...somebody has to clear the time to work
on it :|
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 07:54 +0100, Ralf Corsépius wrote: > Hi, > > I intend to update gumbo-parser to 0.12.1 in rawhide. > This comes along with an soname bump libgumbo to libgumbo.so.2 > > This requires a rebuilt of several dependent packages, AFAICT: > claws-mail > litehtml > mupdf > perl-HTML-Gumbo > python3-PyMuPDF > qpdfview > zathura-pdf-mupdf > > I'll try to rebuild these packages on side-tag f41-build-side-84865 > (Please, bear with me, I haven't used side-tags, before. I couldn't find > any usable docs on how to use them) Thanks for trying! This doc should be pretty good: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#_side_tags I have an active PR to revise that page a bit, but it doesn't change much about the side tag instructions themselves. One neat thing I found out while working on various docs around this today is that you can use `fedpkg chain-build --target (side tag name)` to do a chain build to a side tag. I haven't tried it, but it ought to work fine. So, just create your side tag, wait for it to exist, run the chain-build, and if it all goes OK, create the update from the side tag. I think it'd make sense these days for `fedpkg chain-build` to *default* to creating a new side tag and doing the builds there automatically (and then maybe creating an update when they're all done), so I filed https://pagure.io/fedpkg/issue/540 for that. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: "ABSENT" test results from Fedora CI: status update
On Wed, 2024-02-28 at 09:03 -0800, Adam Williamson wrote: > Hey folks! Just an update on an issue I know some packagers are running > into. > > In the last few days, some Fedora CI jobs have been getting stuck and > timing out. Packagers will usually experience this as a test result > showing as "ABSENT" in Bodhi, e.g. for this update: > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce1fb5a0db > > the fedora-ci.koji-build.tier0.functional result shows as ABSENT (red > line, question mark icon which shows ABSENT if you hover over it). > > We don't have any CI tests that are universally gating by default, but > some packages have opted in to gating on some CI tests, and some of > these have been stuck in updates-testing for a few days due to this > problem. > > It seems the issue was caused by a kernel 6.8 bug which broke quite a > lot of stuff last week - see > https://lore.kernel.org/all/6a150ddd-3267-4f89-81bd-6807700c5...@redhat.com/ > . The fix for that bug was in kernel 6.8rc6, which is now in both > Fedora 40 and Rawhide. Miroslav Vadkerti is aware of this and is > working to try and clean things up (update the base images for Fedora > CI and get all the timed-out tests re-run). I don't know what the ETA > is, but just wanted to let folks know it's at least being worked on. Update on this: turns out the kernel bug wasn't the main thing, that was causing some test errors but the main problem was that reporting of Fedora CI results to resultsdb simply broke on Saturday and nobody spotted that was the problem till today. We got that fixed today, and I have hacked up and am now running a script which should report all the results that were missed (hopefully correctly, and hopefully without overriding or duplicating or missing anything). Once it's finished running I'll do a sweep for updates still stuck in updates-testing and see where we are. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
"ABSENT" test results from Fedora CI: status update
Hey folks! Just an update on an issue I know some packagers are running into. In the last few days, some Fedora CI jobs have been getting stuck and timing out. Packagers will usually experience this as a test result showing as "ABSENT" in Bodhi, e.g. for this update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce1fb5a0db the fedora-ci.koji-build.tier0.functional result shows as ABSENT (red line, question mark icon which shows ABSENT if you hover over it). We don't have any CI tests that are universally gating by default, but some packages have opted in to gating on some CI tests, and some of these have been stuck in updates-testing for a few days due to this problem. It seems the issue was caused by a kernel 6.8 bug which broke quite a lot of stuff last week - see https://lore.kernel.org/all/6a150ddd-3267-4f89-81bd-6807700c5...@redhat.com/ . The fix for that bug was in kernel 6.8rc6, which is now in both Fedora 40 and Rawhide. Miroslav Vadkerti is aware of this and is working to try and clean things up (update the base images for Fedora CI and get all the timed-out tests re-run). I don't know what the ETA is, but just wanted to let folks know it's at least being worked on. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: google-re2 pacakge update and facebook vs google python bindings ?
On Fri, 2024-02-23 at 13:36 -0500, Paul Wouters wrote: > On Wed, 7 Feb 2024, Ben Beasley wrote: > > > Subject: Re: google-re2 pacakge update and facebook vs google python > > bindings > > I haven't heard back from any of the maintainers. > > I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the > first step towards getting python-google-re2 working. > > https://src.fedoraproject.org/rpms/re2/pull-request/6 You now seem to have just built re2 for Rawhide without any of the deps: https://bodhi.fedoraproject.org/updates/FEDORA-2024-daa3669e4d that's not how you're supposed to do things, these days. You should build re2 on a side tag and then get all the deps rebuilt on the same side tag, then create a combined update. The update failed tests because of this. The best thing to do at this point would be to create a side tag, bump re2 and do a new build on the side tag, then ask maintainers of dependencies and/or provenpackagers to rebuild the dependencies on the side tag. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-02-26 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-02-26 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 7 proposed blockers and 4 proposed freeze exception for Beta, and 5 proposed blockers for Final. The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. I'll be on vacation on Monday, so Frantisek Zatloukal will be running the meeting, thanks Franta! If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Kickstart install of Rawhide fails
On Thu, 2024-02-22 at 15:32 -0700, Orion Poplawski wrote: > I've seeing: > > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: > glibc-common-2.39.9000- > 1.fc41.x86_64 1708040026 > e4113ddcb7a4bf591492c0bf4644932b0dad7691ff19c65111751675336cb0c8 > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: > bash-5.2.26-3.fc40.x86_64 1707490454 > 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring > (running scriptlet for): bash-5.2.26-3.fc40.x86_64 1707490454 > 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: > dbus-common-1:1.14.10-3.fc40.noarch 1706087027 > 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring > (running scriptlet for): dbus-common-1:1.14.10-3.fc40.noarch 1706087027 > 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d > INFO:dnf.rpm:error: failed to exec scriptlet interpreter /bin/sh: No such file > or directory > warning: %post(dbus-common-1:1.14.10-3.fc40.noarch) scriptlet failed, exit > status 127 > > ERROR:dnf.rpm:Error in POSTIN scriptlet in rpm package dbus-common > ERROR:anaconda.modules.payloads.payload.dnf.transaction_progress:Error in > POSTIN scriptlet in rpm package dbus-common > > > But /bin/sh is present and runnable when I try in /mnt/sysroot (the log shows > that bash was just installed as well). > > Anyone else hitting this? Yes, someone else is, when installing in VirtualBox: https://bugzilla.redhat.com/show_bug.cgi?id=2244744 It's confusing, isn't it? Are you using VirtualBox? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: openQA update test backlog - now clearing
On Mon, 2024-02-19 at 23:28 +, Leslie Satenstein via devel wrote: > 4) After logging in, the keyboard layouts(user and root) are correct. > It is only the login screen. This is https://bugzilla.redhat.com/show_bug.cgi?id=2264930 . -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openQA update test backlog - now clearing
Hey folks! just a quick note in case anyone was waiting for openQA tests on their update. it seems one of the worker hosts got into some kind of stuck state, a lot of jobs were stuck at 'uploading'. unfortunately these are jobs that are set to *only* run on that host, so they were stuck permanently. I've rebooted that host and it's picking up the backlog now, it should work through it over the next few hours. the most-delayed update seems to be FEDORA-2024-84788cb473 , which is 16 hours old. sorry again! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-02-19 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-02-19 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 6 proposed blockers and 1 proposed freeze exception for Beta, and 4 proposed blockers for Final. The meeting will be on Matrix, as we're trying to move to more modern systems and the meeting bot is working on Matrix now. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-19 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-02-19 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 status, including anaconda web UI test planning 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-19 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-02-19 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 6 proposed blockers and 1 proposed freeze exception for Beta, and 4 proposed blockers for Final. The meeting will be on Matrix, as we're trying to move to more modern systems and the meeting bot is working on Matrix now. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide
On Wed, 2024-02-14 at 12:57 -0600, Michael Catanzaro wrote: > I checked the build log for > https://koji.fedoraproject.org/koji/taskinfo?taskID=113473592 but > unfortunately I don't actually see any error message. I searched for > "error:" (indicating a compiler error) and I also searched for "Killed" > (indicating OOM). > > No doubt something is wrong somewhere in that build log, but I'm not > sure where. We have untagged the update for now - https://pagure.io/releng/issue/11952 - so this won't break Rawhide. Once webkitgtk is buildable we can figure out how to take another cut at this (I'm not sure exactly what the procedure is to get a side tag update like this edited and retagged, we may *possibly* have to create a new side tag, tag all the existing builds onto that, add a webkitgtk build, and create a new update?) -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Re: 2024-02-12 @ 17:00 UTC - Fedora 39 Blocker Review Meeting
On Sun, 2024-02-11 at 10:16 -0800, Adam Williamson wrote: > # F39 Blocker Review meeting > # Date: 2024-02-12 > # Time: 17:00 UTC > # Location: > https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Of course, this should say 'F40' and the subject should be 'Fedora 40 Blocker Review Meeting'. Sigh. Somehow I always miss *something* when editing these damn announcements. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-12 @ 17:00 UTC - Fedora 39 Blocker Review Meeting
# F39 Blocker Review meeting # Date: 2024-02-12 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! Fedora 40 branches this coming week, and we have some blockers to check in on, so it seems like a good time for a blocker review meeting. We are still on standard time in places that use daylight savings, so the meeting is at 17:00 UTC. The meeting will be on Matrix, as we're trying to move to more modern systems and the meeting bot is working on Matrix now. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-05 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-02-05 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-02-03 06:16, Marc Deop i Argemí wrote: - As the packages stand right now, the KDE general updates will have to wait for the proposed packages to be updated by their maintainers or we will have to do the updates ourselves (which defeats completely the point of our change proposal). Why? This is the part I don't understand. Can you explain it in more detail? Thanks. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-02-01 07:40, Sérgio Basto wrote: I have an obvious answer is when the authors decide, in this case Xorg, when Xorg decides that it will stop supporting X11, like happened to Python2 or PHP5 and 7 or Gnome In fact, it is something I've been thinking about, IMHO, downstream shouldn't decide when software is deprecated or not like KDE and Red HAt did , it's weird to me [1], although in RHEL we could have the packages via EPEL, I think, and RHEL 10 is only in a year and a half A lot of the people involved at different parts of the stack are just the same people wearing different hats. Wayland and X.org are both part of freedesktop. Whatever maintenance is still happening on X.org is mostly being done by people who primarily work on Wayland. There isn't some kind of holy war going on between The Wayland Developers who want to kill X.org, and The X.org Developers who believe it is great and want to keep it. They're nearly all the same people, and they all want X.org to die. AFAIK there isn't anybody who is actually clamoring to *do the work of maintaining X.org upstream*. There are people who don't want it to die because Wayland doesn't yet have the features they need or the NVIDIA proprietary driver doesn't work well on Wayland or whatever, but AFAIK, none of those people is actually volunteering to maintain X.org long-term. If you look through https://gitlab.freedesktop.org/xorg/xserver/-/commits/master you will see the majority of commits are from people who also work on Wayland (and most of the commits are actually to Xwayland). A lot of the same people who are the graphics stack maintainers for freedesktop.org are *also* involved in distribution efforts to move to Wayland. So it's not as simple as "distributions making the decisions instead of upstream". AFAIK, most of the upstream folks dearly *want* distributions to move off of X.org and onto Wayland, but they feel kind of obliged to continue minimal maintenance of X.org upstream until this move is further along. Apologies if any of that is inaccurate, and I'm sure folks will correct me if so. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-02-01 04:08, Steve Cossette wrote: So, if you all don't mind, I'd like to steer this discussion in a slightly different way: What /is/ the definition of a Fedora Change Proposal? I was under the impression it was an announcement of intent by the maintainers of a specific subset of the fedora project to "change" something. Once said announcement has been discussed publicly, Fesco (Sorry if the capitals are incorrect) discusses it internally (albeit, publicly) and either blocks or approves the change, making it official. /(Please note: The following paragraphs will use "we" as a pronoun which is intended to be the Fedora project as a whole)/ / / Once approved, we announced our intent to drop X11 from the KDE spin of Fedora. That announcement has gained traction everywhere, got publicized and everything. As Neal Gompa also stated, it has already caused some substantial development effort upstream to effectively iron out the rough edges of many of the problems, with what I assume is more to come. I would not read it quite like that. I would say that by approving the Change, "we" - in the sense of "Fedora as a whole" - approved of the KDE SIG's decision to stop maintaining Plasma X11. I can't speak for FESCo, but if I had been on FESCo, I don't think I would've had in my mind "approving this Change creates a ban on anybody at all maintaining Plasma X11 packages in Fedora" when voting on it. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-01-30 05:45, Stephen Gallagher wrote: One additional point I forgot to address: the initial concern was that the KDE SIG would be implicitly responsible for maintaining these packages if they are included in the main repository. From a purely technical perspective, I think that we should state clearly that the KDE SIG would be required only to provide advance notice of major changes but would NOT be responsible for ensuring that these packages adapt to them. Of course, communicating that to users is harder (and they'll naturally report bugs to the wrong place in many cases), but I think the KDE SIG is completely permitted to refuse and retarget any issues that come up to the appropriate group. I think this is a case where it's more useful to focus on technical details than grand philosophy. So, let's game out what might actually happen here. Say these packages are accepted, and we have, to simplify, a large blob of packages maintained by the KDE SIG that represents "Plasma on Wayland, supported by the KDE SIG, release blocking" - henceforth "PLASMA-WAYLAND" - and a small blob of packages maintained by other folks that represents "Plasma on X.org, not supported by the SIG, not release blocking" - henceforth PLASMA-XORG. If I'm correct, the situation would be this: * PLASMA-XORG would depend on PLASMA-WAYLAND, but not vice versa * Updates to PLASMA-WAYLAND could break PLASMA-XORG, but not vice versa * PLASMA-XORG could not block any releases * PLASMA-XORG would not gate any updates. This is because only openQA tests gate Plasma updates, and openQA only tests the default Plasma configuration, Plasma-on-Wayland Given all of this...I am not sure there is really a problem for the Plasma SIG beyond expectations they are choosing to place on themselves. To put it brutally, they *could* choose to just create and ship PLASMA-WAYLAND updates and tell the PLASMA-XORG maintainers to deal with it. No procedures or processes would stop them doing this. There would be no release-blocking bugs, and no update gating, so long as PLASMA-WAYLAND itself worked. The sole exception I can think of would be if enough people filed negative karma due to X.org failures to derail an update, but negative karma restrictions are really pretty loose in Fedora. Karma more or less does not affect Rawhide updates (except possibly in one rather specific case, I am coincidentally in the middle of figuring this out). For non-Rawhide updates, the "auto-unpush" threshold is completely configurable, you can set it to -100 if you like. A single negative karma disables autopush, but it doesn't force it off: you can turn it back on. You only need a net +2, in the worst case, to push an update stable manually. So I would argue in favour of accepting the packages, because I don't think the negative impact the SIG is worried about is really that significant. I don't think they really are "forced to maintain" the Xorg packages. I think it will prove to be practical for them to just maintain the Wayland stack and leave maintaining the Xorg packages to those who volunteer to do it. They can *choose* to co-ordinate megaupdates with those maintainers if they like, but I don't think any distro rule or mechanism will *require* it, in practice. I also think that, in practice, things will turn out to be manageable in a much nicer fashion. The folks who are volunteering to maintain the X.org packages are longstanding and responsible Fedora maintainers who are capable of doing it. If problems do emerge after trying this in good faith for a while, it's always possible to re-evaluate. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openQA test failures for Rawhide: heads up
Hey folks! You may have noticed unpredictable openQA test failures on Rawhide updates ATM. This is mainly because of the mass rebuild. All the packages from the mass rebuild have been tagged into the buildroot repo (which the openQA tests use), so now there are far more on-the-fly updates than is usually the case, and various test steps are hitting timeouts depending on how fast the download / update process runs. I'll re-run tests opportunistically for now, but some may still fall through the cracks. Once the currently-running Rawhide compose completes (fingers crossed), I can regenerate the base disk images so they're up to date with the mass rebuild package set, and things should settle down again. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: A reminder: you cannot just "revert" package version bumps
On 2024-01-29 16:00, Sérgio Basto wrote: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily you may do a new build with lower EVR That is not what that guideline says. It says the Rawhide build can be lower-versioned than a current build from *a different branch* *temporarily*. It says nothing about allowing a new Rawhide build to be lower versioned than the previous one. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
A reminder: be careful with snapshot versioning, especially with %autorelease
nirik ran a script that checks for versioning issues in Rawhide today, and it found several: https://pagure.io/releng/issue/11922#comment-893797 Aside from rogue version downgrades (see other mail), a few of these followed a different pattern: problems with snapshot versioning. 1. patool: highest tagged build patool-1.12-22.fc39, most recent tagged build patool-1.12-0.27.20231014gitab64562.fc40 2. python-pyunicorn: highest tagged build python-pyunicorn-0.7.0a1-1.20230730gitmaster.fc40 , most recent tagged build python-pyunicorn-0.7.0~a1-5.20230730gitmaster.fc40 3. vim-devicons: highest tagged build vim-devicons-0.11.0-10.20200509gitd12c9b4.fc39 , most recent tagged build vim-devicons-0.11.0-0.20221001git71f239a.13.fc40 In the python-pyunicorn case, the packager simply made a mistake with pre-release versioning, then fixed it. The current version is correct, but unfortunately evaluates as lower than the incorrect one which was missing the tilde. This means that anyone who happened to get python-pyunicorn-0.7.0a1-1.20230730gitmaster.fc40 installed will likely never see an update until 0.7.1 comes out (even a 0.7.0 final release will evaluate lower than "0.7.0a1"). In the other two cases, %autorelease is involved. autorelease is a great tool, but use it carefully when using snapshot builds. Without any additional guidance, %autorelease assumes that if you're building from a snapshot, it is a pre-release snapshot for the specified "Version". So it'll use a release like 0.(date)git(tag).(rel). If your snapshot is a post-release snapshot, you need to provide %autorelease with more cues about how to version it to get the desired effect. This is the problem for vim-devicons and patool. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
A reminder: you cannot just "revert" package version bumps
nirik ran a script that checks for versioning issues in Rawhide today, and it found several: https://pagure.io/releng/issue/11922#comment-893797 Some of these followed a pattern, so I figured a reminder was in order. In all these cases, a new version was pushed to Rawhide, then "reverted" some time later: golang-github-nats-io-jwt - bumped to 2.4.1 in July, reverted to 1.2.2 in September golang-google-grpc - bumped to 1.58.0 in September, reverted to 1.48.0 in October; no 1.58.0 build ever landed, but the revert left the %release much lower than before python-mizani - bumped to 0.10.0 on September 10, reverted to 0.9.3 on September 12 python-pywlroots - bumped to 0.16.6 on November 4, reverted to 0.16.4 later the same day so the reminder is this: you cannot simply "downgrade" RPM package versions like this. Especially not if the upgraded version ever made it into a Rawhide compose. If a Rawhide user has your package installed, and got the upgraded version, they will be marooned on that build forever unless they manually run `dnf distro-sync`. A `dnf upgrade` will not downgrade the package to the build you now consider to be the "current" one. If you have to downgrade a package that made it to a Rawhide compose, you must use an epoch. If the package did not have an epoch before, make it `Epoch: 1`. If it had an epoch already, bump it by 1. People tend not to like epochs, so *try* not to have to do this. Be really certain before pushing out version bumps. If the "upgraded" build never made it into a compose (as is likely the case for python-pywlroots) you're *probably* okay, but it's still something to be careful about - for instance you might fall into the trap golang-google-grpc fell into with the %release tag. Thanks folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openQA Rawhide update failures - we're working on it!
Hi folks! I want to apologize to packagers who have Rawhide updates stuck on failed openQA tests, and provide an update. There were two big problems today. First, the Server base disk image used for some of the tests got regenerated (this happens weekly). Unfortunately, this meant it got affected by https://bugzilla.redhat.com/show_bug.cgi?id=2259266 , and no longer booted. I should have got that grub2 build untagged or the change reverted sooner - sorry. I was expecting the package to be fixed sooner, and it didn't occur to me that this image being regenerated was a risk. I've now got the package untagged, and forced a rebuild of the disk image using a grub2 build with the patch re-applied (otherwise I'd have had to wait for the next Rawhide compose to rebuild the image). I'm now working through re-running all affected tests. Second, shell-color-prompt was changed[0] to apply the color prompt to virtual consoles. This broke a large number of openQA tests, as they often need to do things at root consoles, and to do that they need to know when they've actually managed to log in to one, and they do this by screen matching the prompt. Any test which needed to know it was at a root console was failing. I've updated the 'needle' to match the color prompt, and am re-running all affected tests. I anticipate the mess should be cleaned up in about three or four hours (there are a lot of failures to re-run, and some of the tests take a while to run). Sorry again for the inconvenience. I'll probably propose adding shell-color-prompt to the critical path. That would mean openQA would have gated the update (allowing me to update the needles *before* it got pushed and broke tests for every other update), but it also just seems appropriate - theoretically, a bad change to the package could cause all sorts of consequences, since it fiddles with the default prompt. [0] https://src.fedoraproject.org/rpms/shell-color-prompt/c/1dd8c6c16d760cacfb9fd70a249b28a1fd853dd1?branch=rawhide -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up: openQA update test failures due to ongoing FAS outage
Due to the ongoing FAS outage - https://status.fedoraproject.org/ - many updates failed openQA testing, because part of the openQA web browser test happens to be to open https://accounts.fedoraproject.org and check it looks as expected. Obviously right now it does not. As this is not a critical part of the test, I have just disabled it until the FAS outage is resolved, and re-run the failed tests. Affected updates should be unblocked soon. Sorry for the trouble. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-01-22 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-01-22 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 Change review and check-in 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -fcf-protection dropped from i686 compiler flags
On 2024-01-18 12:28, Michael Catanzaro wrote: Unfortunately this is causing gating tests to fail for rawhide builds, e.g.: https://artifacts.dev.testing-farm.io/081ad2a3-76cd-4aa0-b95e-e870ff75a65c/ Hardened: /usr/bin/pkcon: FAIL: cf-protection test because .note.gnu.property section did not contain the necessary flags I'm not sure whether to report a bug to rpminspect or to annocheck. One or the other needs to stop testing for this. The timing is unfortunate because the mass rebuild has started today. I'm not sure what the impact will be. I guess packages will build, but get stuck in gating? rpminspect does not gate by default. None of the tests run by Fedora CI (any test whose name as shown in Bodhi begins with 'fedora-ci') gates by default, in fact. Only packages which opt in to gating on these tests via their per-package gating.yaml files should be gated by failures of Fedora CI tests. The only tests that gate packages *without* a per-package gating.yaml are the openQA tests that gate critpath packages (the names for these always start with 'update.'). In Bodhi's 'automated test results' table, gating tests have an asterisk as the first item in their row. Non-gating tests do not. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 37 is EOL
On Mon, 2024-01-08 at 13:57 -0500, Ben Cotton wrote: > On 08-01-2024 17:16, Adam Williamson wrote: > > > Doing it this way was Ben's preference (he wanted to be able to see > > that every bug was updated and get a notice from the script for any > > single bug change that failed), > > Historically, the script ran much faster than Bugzilla, which meant > after a while, we'd start getting timeouts. This is why there are > pauses built into the script. A few years ago, the performance of > Bugzilla improved greatly, but I never felt like exploring where the > boundaries are. Updating all matching bugs in one transaction is still > probably going to result in timeouts, but smaller chunks should work > well enough. If Bugzilla is engineered *at all* sanely, it should be much less work for it to process a single request to do the same thing to 500 bugs than it is to process 500 individual requests to do the same thing to a single bug. There probably *is* a limit on the number of bugs you can request changes to at once, but it should be simple enough to find out what that ceiling is and work in batches below it. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 37 is EOL
On Mon, 2024-01-08 at 18:10 +0100, Vít Ondruch wrote: > Dne 08. 01. 24 v 13:00 Sandro napsal(a): > > On 05-12-2023 18:45, Tomas Hrcka wrote: > > > Fedora Linux 37 has gone end of life for updates and support on > > > 2023-12-05. > > > No more updates of any kind, including security updates or security > > > announcements, will be available for Fedora Linux 37 after the said > > > date. All the updates of Fedora Linux 37 being pushed to stable will be > > > stopped as well. > > > > > > As part of the EOL tasks all bugs open for F37 receive an EOL notice, > > first, and sometime later they will change status to CLOSED | EOL, > > unless the version is changed. > > > > It seems the first step (notification) happened, but the second step > > (closing) has not completed. IIRC, I saw some bugs being closed, but I > > also see a lot of F37 bugs still open [1]. > > > > Is that an oversight or did something go wrong during the procedure? I > > cc'ed Aoife, who appears to have run the first step. I'm happy to open > > a ticket if required. > > > There also used to be Rawhide bugs reassigned to latest stable Fedora, I > might have missed something, but I don't think that has happened. I don't think that's quite right. What happens is that Rawhide bugs get moved to the *new branched* (not stable) release, and naturally, this happens at branch time, which hasn't happened for F40 yet. https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/branch/ -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 37 is EOL
On Mon, 2024-01-08 at 16:10 +, Aoife Moloney wrote: > I'll get the EOL-close script running again, it kept timing out so I > thought it was finished but clearly not - my mistake and apologies :-/ Just so folks are aware, the EOL closure uses a script: https://pagure.io/fedora-pgm/pgm_scripts/blob/main/f/closebugs/fedora_bz.py which runs bug-by-bug - so it comments on, or closes, one bug at a time. This means it takes a very long time to do the ~2-3k bugs that are typically commented-on then closed at EOL time. Doing it this way was Ben's preference (he wanted to be able to see that every bug was updated and get a notice from the script for any single bug change that failed), but if it causes problems for Aoife we can have it mass-update bugs instead, since Bugzilla and its API allow that (now, they probably didn't when the predecessors to this script were written). I'll just have to check with the BZ admin whether there's any upper limit on how many bugs you can request a mass change to at once. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-01-08 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-01-08 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org Greetings testers! It's time for the first QA meeting of 2024! Using Matrix went fine last time, so we'll do it again this time. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in 3. Communications overhaul: Discourse? 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Error updating libvirt-dbus in F38
On 2024-01-04 00:20, Peter Boy wrote:
Just started to update one of our Fedora Servers (F38)
I got the message:
Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
Cleaning up : libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
/var/tmp/rpm-tmp.BXEIBt: Zeile 1: fg: No Job control in this shell.
Warning: %postun(libvirt-dbus-1.4.1-1.fc38.x86_64) Scriptlet failed,
Exit-status 1
Error in POSTUN scriptlet in rpm package libvirt-dbus
Cleaning up: libacl-2.3.1-6.fc38.x86_64 125/132
Warning or error, what is it?
Both. It's an error in the scriptlet. As far as dnf/rpm is concerned,
scriptlet errors are warnings (it warns you about them, but continues,
as failing the entire transaction on them is unlikely ever to be a
better choice).
Can I be sure that a reboot will be successful?
Nope. This is a fundamental issue with packages in general: package
scriptlets are just...entirely arbitrary code running as root on your
system. What does a scriptlet do? Nobody but the packager can say with
much confidence. How bad is it if it fails? Again, impossible to say
except on a case-by-case investigation basis.
My experiences with reports of this kind are quite mixed. From problem-free
reboots to total failure, everything is possible. Unfortunately, reports of
this kind do not exactly boost confidence in the reliability and usability of
our Fedora.
We should improve this and make reports of problems clearer.
It's fundamentally difficult to do so in the context of RPM packages.
All the package system can know is "the scriptlet of this package failed".
Looking into this specific case, it looks like the 1.4.1-1 package
%postun tries to do:
%systemd_postun_with_reload %{name}.service
but that macro doesn't seem to exist on F38, AFAICT. It exists on
Rawhide, but not F38.
The 1.4.1-2 package changes this to:
%systemd_postun_with_restart %{name}.service
which *does* exist on F38, so it should work. Ironically, you see the
bug in the 1.4.1-1 package when you upgrade to 1.4.1-2, as the %postun
of 1.4.1-1 runs when it's being removed to install 1.4.1-2.
This particular case shouldn't cause any real problems, since the macro
does nothing on upgrade anyway (only on package removal), and the
scriptlet did not want to do anything after that.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Erlang 26 broke rabbitmq
Lately I'm working on the Bodhi development environment, and I reached
a point where I noticed rabbitmq was not working inside my current,
Fedora 39-based version of it.
This appears to be because rabbitmq 3.11 simply does not work with
Erlang 26. Fedora 39 has erlang 26 and rabbitmq 3.11. See:
https://stackoverflow.com/a/76286720
I notice there were "Self-Contained" changes proposed for Erlang 24 and
25, but no Change was proposed for Erlang 26. Those changes probably
shouldn't have been listed as "self-contained", but as usual, the
"self-contained" vs. "system-wide" distinction is a vague and
unsatisfactory one. Those Changes did correctly consider the impact of
Erlang major version updates on its dependencies, e.g. from the 24
Change:
** Upgrade outdated packages:
*** {{package|riak|Riak}}
{{package|riak|Riak}} has has been retired. We have to re-add it
back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
** {{package|erlang-rebar3|rebar3}}
*** Provide/adjust RPM macros for rebar3.
and from the 25 Change:
** Upgrade outdated packages:
*** {{package|riak|Riak}}
{{package|riak|Riak}} has has been retired. We have to re-add it
back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
{{package|riak|CouchDB}} has has been retired. We have to re-add
it back.
** {{package|erlang-rebar3|rebar3}}
However, no Change seems to have been proposed for Erlang 26, and
nobody seems to have considered the impact on dependent packages, at
least judging from the lack of any handling of rabbitmq.
Can we please avoid this circumstance in future by again using the
Change process and considering dependencies for any future major Erlang
bump? Thanks. It looks like we will need to update rabbitmq to 3.12 for
it to stand any chance of working in 39 or Rawhide. I will see if
that's a straightforward change next, and try to send a PR if so.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-12-11 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-12-11 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org Greetings testers! It's time for the last QA meeting of the year! We're going to try moving back to Fedora Chat (Matrix) for this meeting, as the bot should be working there now. Remember, the IRC bridge is out of commission, so you'll really have to be on Matrix to join the meeting. You can log in with your Fedora account. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in 3. Communications overhaul: Discourse and Matrix? 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Should we retire the mailx package?
On Fri, 2023-12-08 at 10:38 -0800, Kevin Fenzi wrote: > I'm definitely in favor. I hit this broken step a while back myself. ;( > > Hopefully the current maintainers are on board with this? Yeah, honestly, I'm not sure a Change is the right way to go about this, it seems like it could just be handled between maintainers. nforro - who maintains mailx - has not committed to it for two years, but is very active on other packages (adding him to CC). If he is OK with the change, I would think you could just go ahead and do it (have nforro retire mailx) without needing to go through the Change process. If you file a Change, I think all that will happen is that a lot more bureaucracy will happen before somebody says "hey, we'd better ask nforro about this" anyway. :D -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
