[Test-Announce]Proposal to CANCEL: 2024-08-05 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. It's a holiday in Canada and will be a travel day for Flock for quite a lot of folks. If anyone thinks we should have a meeting and wants to run it instead of me, please go ahead and send out an agenda and plan to run the meeting - see https://fedoraproject.org/wiki/QA:SOP_Matrix_meeting_process Thanks folks! -- 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-09-16 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-09-16 # 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&iso=20240916T15&p1=1440&ah=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 41 status 3. Criteria ideas from Beta 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
2024-09-16 @ 16:00 UTC - Fedora 41 Blocker Review Meeting
# F10 Blocker Review meeting # Date: 2024-09-16 # 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 a Fedora 41 blocker review meeting! We have 1 proposed blocker 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+41+Blocker+review+meeting&iso=20240916T16&p1=1440&ah=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: Fedora CI - installability gone wild, cannot dnf install base packages
On Sat, 2024-09-14 at 03:33 +, Chen Chen wrote: > I just made a PR on https://src.fedoraproject.org/rpms/glfw/pull-request/6 > Then the installability test failed because it got a 403 on "dnf install > createrepo_c". > https://artifacts.dev.testing-farm.io/ef6b74c1-7335-499c-a15a-c367b6dfa25a/ > > Checked that the package indeed lives in el8 > > [root@sirius ~]# dnf info createrepo_c-libs > > Last metadata expiration check: 2:04:56 ago on Sat 14 Sep 2024 09:11:34 AM > > CST. > > Available Packages > > Name : createrepo_c-libs > > Version : 0.17.7 > > Release : 6.el8 > > Architecture : x86_64 > > Size : 115 k > > Source : createrepo_c-0.17.7-6.el8.src.rpm > > Repository : appstream > > Summary : Library for repodata manipulation > > URL : https://github.com/rpm-software-management/createrepo_c > > License : GPLv2+ > > Description : Libraries for applications using the createrepo_c library > > : for easy manipulation with a repodata. > > and the URL from the log is not accessible from public Internet > > wget > > https://composes.stream.centos.org/stream-8/production/latest-CentOS-Stream/compose/AppStream/x86_64/os/Packages/createrepo_c-0.17.7-6.el8.x86_64.rpm > > Connecting to composes.stream.centos.org > > (composes.stream.centos.org)|2600:9000:271a:a800:16:bca0:9700:93a1|:443... > > connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2024-09-14 11:23:04 ERROR 403: Forbidden. > > How can I trigger another CI run and whom should I report this problem to? > testing-farm.io or CI group guys? The problem is not in CI, it's in CentOS infra - that URL ought to work fine but is currently 403. I've filed a ticket at https://pagure.io/centos-infra/issue/1495 , hopefully that will get it resolved. -- 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: Summary/Minutes from today's FESCo Meeting (2024-09-10)
On Wed, 2024-09-11 at 19:02 +0200, Fabio Valentini wrote: > As I said, I have no option to *not* send it with wrapped lines ... > sorry about that. You can use real mail clients (Thunderbird, Evolution) with gmail and they let you wrap your mails however you darn please. :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
Re: [Test-Announce]Fedora 41 Candidate Beta-1.1 Available Now!
On Wed, 2024-09-11 at 09:27 +0200, Luna Jernberg wrote: > Testing at the moment, install of > https://kojipkgs.fedoraproject.org/compose/41/Fedora-41-20240910.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-41_Beta-1.1.iso > worked as it should, but it was not fully updated still 297 packages > to update with sudo dnf5 update This is normal. updates-testing is enabled by default for Beta installs but packages from updates-testing are not included in the compose, so there will always be a substantial first update. We intend it to be this 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: [Test-Announce]Fedora 41 Candidate Beta-1.1 Available Now!
On Wed, 2024-09-11 at 03:40 +, Andre Robatino wrote: > I'm not seeing a "Create Fedora 41 Beta Candidates" ticket at > https://pagure.io/releng/issues - is there one? No, in this case we just ran a compose with whatever was in the stable tag in order to test out the new release candidate script. I'll probably request a 'real' candidate tomorrow. -- 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: Orphaning python3-oslo-concurrency, python3-oslo-service, python3-oslo-messaging and python3-k2hr3-osnl
On Tue, 2024-09-10 at 13:39 +, Hirotaka Wakabayashi wrote: > Hello Adam, Thanks for the information!! > > While I really feel that it might be worth waiting a bit longer, as a > Fedorauser who wants a new version, I should close my blocker tickets > soon...I plan to un-retire them if and when the bug is fixed. I understand > that > un-retiring is a straightforward but time-consuming process. :( If you're concerned that this is blocking the Fedora 41 release, do not be. It isn't. I don't remember all the details of the forced orphaning/retirement process for FTBFS/FTI packages - it may be that this is forced into retirement in some kinda sync with the F41 schedule, I don't know - but it definitely doesn't block the release, I should know since I look at the blocker list more than anybody. :D https://qa.fedoraproject.org/blockerbugs/milestone/41/beta/buglist -- 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: Orphaning python3-oslo-concurrency, python3-oslo-service, python3-oslo-messaging and python3-k2hr3-osnl
On Mon, 2024-09-09 at 14:47 +, Hirotaka Wakabayashi via devel wrote: > Hello, I am going to orphan following packages because the dependent > package, python3-eventlet, could not build in this cycle. > > python3-oslo-concurrency > python3-oslo-concurrency-tests > python3-oslo-messaging > python3-oslo-messaging-tests > python3-oslo-service > python3-oslo-service-tests > python3-k2hr3-osnl > > Upstream of python3-eventlet recommends migrating to Python’s asyncio > and I tried to stop using the package but it is too difficult for me to deal > with. > > If you need the packages above and you can fix the problem, please take them. > Best, > Hirotaka It does seem like there's some work ongoing here: https://lists.openstack.org/archives/list/openstack-disc...@lists.openstack.org/thread/MBQ4NVRS4GHA3PGGYXVSYJ6PEBVKCU2T/ so it might be worth waiting a little longer to see if that shakes out? -- 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-09-09 @ 16:00 UTC - Fedora 41 Blocker Review Meeting
# F10 Blocker Review meeting # Date: 2024-09-09 # 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 a Fedora 41 blocker review meeting! We have 1 proposed blocker and 10 proposed freeze exceptions for Beta. 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+41+Blocker+review+meeting&iso=20240909T16&p1=1440&ah=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!** Especially since we have so many proposed FEs right now, it would really help make the meeting shorter if people can vote on them today. 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: Something wrong with rawhide (41) keys?
On Thu, 2024-09-05 at 20:48 -0400, Gabriel L. Somlo wrote: > Hi Kevin, > > On Thu, Sep 05, 2024 at 2024 11:01:07 -0700, Kevin Fenzi wrote: > > On Thu, Sep 05, 2024 at 07:03:05AM GMT, Gabriel L. Somlo wrote: > > > As of right now (09/05/2024, 7:00am EDT), I'm getting an error when > > > running `mock -r fedora-rawhide-x86_64 --clean --init` on an > > > up-to-date f40 machine: > > > > > > ... > > > > You need to update to the latest mock-core-configs and > > distribution-gpg-keys packages, then do a 'mock --scrub=all'. > > My mock-core-configs (well, all mock-* packages) and distribution-gpg-keys > are all up to date (on f40). I removed /var/lib/mock/* AND ran > `mock --scrub=all`, and still keep getting the same `transaction > failed: Signature verification failed.` error as before when I attempt > to build anything for `mock -r fedora-rawhide-x86_64 foo.src.rpm` > > > Basically we have branched f41 from rawhide, and rawhide is now moving > > toward f42. So it's signed by a different key, but your mock/keys thinks > > it's still f41 and may have old f41 cached packages it's trying to use? > > I figured that's what must have happened, but from where I'm sitting > there are some lingering remaining side-effects that seem out of my > control :) Any further ideas as to what might be happening much > appreciated! When I ran into stuff like this around the dnf5 and container transition, I just wiped every dir under /var/lib/mock and /var/cache/mock , and it seemed to clear it up. -- 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-09-03 (**TUESDAY**) @ 16:00 UTC - Fedora 41 Blocker Review Meeting
# F10 Blocker Review meeting # Date: 2024-09-03 (**TUESDAY**) # 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 a Fedora 41 blocker review meeting! As Monday is a holiday in North America, let's do it on Tuesday instead. We have 7 proposed freeze exceptions for Beta. 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+41+Blocker+review+meeting&iso=20240903T16&p1=1440&ah=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 holiday weekend and see you on Tuesday! [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: GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide
On Fri, 2024-08-30 at 14:24 -0600, Leo Sandoval wrote: > On Fri, Aug 30, 2024 at 2:16 PM Leo Sandoval wrote: > > > Hi Adam / Team > > > > On Thu, Aug 1, 2024 at 10:01 AM Adam Williamson < > > adamw...@fedoraproject.org> wrote: > > > > > On Thu, 2024-08-01 at 07:46 -0600, Leo Sandoval wrote: > > > > > > > > > > > > Again, once we have something solid, I will share relevant links for > > > > > further community reviewing & testing. > > > > > > > > > > > > > > > > Any progress on this? We're gearing up to Flock and branching will be > > > > > the week after Flock... > > > > > > > > > > > > > No progress since last email... Still in the testing phase. > > > > > > If you can post a scratch build or COPR, I can run our openQA tests on > > > it, so we can find any issues those tests run into nice and early. > > > > > > > Netboot fixes are now integrated into rawhide, no official build yet just > > a scratch one > > > > Sorry, my last email was sent too fast without completing my phrase (I am > emacs user and sometimes I do Ctrl + something on non-emacs environments > and things can go wild), I meant > > Netboot fixes are now integrated into rawhide, no official build yet just a > scratch one: https://koji.fedoraproject.org/koji/taskinfo?taskID=122703223 > > Adam, please kick the OpenQA tests again using the new set of packages. > Chris, can you do your testing based on > https://bugzilla.redhat.com/show_bug.cgi?id=2303727 ? Tests running at https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=42&build=Kojitask-122703223-NOREPORT&groupid=2 (I usually run this kinda thing on staging, but mistakenly did it on prod, oh well). -- 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 failures over the last ~12 hours
Hey folks! If you maintain a critical path package you may have noticed multiple bogus test failures from openQA in the last 12 hours or so. One of the worker hosts flipped out somehow and was failing about half the jobs it ran immediately on startup because of some kind of qemu port mapping collision. I've rebooted it and it seems to be behaving now. I've re-scheduled all the failed tests. It should catch up over the next few hours. Apologies for the inconvenience! -- 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: SWIPL moves to Fedora (packages.fpo page generation)
On Wed, 2024-08-28 at 11:52 -0700, Adam Williamson wrote: > > I guess I'll try and patch up the app's usage of Bodhi release data and > send a PR, that should sort it out. https://pagure.io/fedora-packages-static/pull-request/50 -- 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: SWIPL moves to Fedora (packages.fpo page generation)
files based on those. So if it *did* consider the Rawhide release, it would call it "fedora-42" and name the db files that way. And third, the script looks at each existing database file, and if it didn't find a matching release in the Bodhi data, it *removes it*. What this means is that the HTML output script is meant to always wind up using the data for each package from Rawhide (the latest data), but it currently isn't, because it's not running against Rawhide at all. It will use the data from the first repository it happens to run against that contains the package, and ignore data from all other repositories. At this point I got to wondering how the code got this way - it seems weird that there is special purpose code for Rawhide which we can never reach. And, aha, turns out this is all new code, because it used to use PDC: https://pagure.io/fedora-packages-static/c/9463d3793272c349a1377fd22830b3c0ab8e80e1 PDC was decommissioned a couple of weeks back. I checked the logs for the current fedora-packages-static deployment, and it looks like we're definitely using the Bodhi code now, and it's behaving as I surmised: bin/fetch-repository-dbs.py --target-dir /etc/packages/repositories Fetching active releases from Bodhi... Found: ['epel-10', 'epel-10-testing', 'epel-8', 'epel-8-testing', 'epel-9', 'epel-9-testing', 'fedora-39', 'fedora-39-updates', 'fedora-39-updates-testing', 'fedora-40', 'fedora-40-updates', 'fedora-40-updates-testing'] Note how it did *not* find 'fedora-42', or 'fedora-rawhide'. So here's my theory about what's going on. Up until PDC got decommissioned, this was probably working fine, and I'd guess the data for the pl package was up to date. When PDC got decommissioned, updating would've been broken - `fetch-repository-dbs.py` was written to just exit if it can't reach PDC. So the data would've stayed the same. Then, whenever our fedora-packages-static deployment switched over to the Bodhi code, this happened: 1. fetch-repository-dbs.py ran, did not collect Fedora 41 or 42/Rawhide from Bodhi because they're 'pending' not 'current', and deleted the existing database files for those releases. 2. generate-html.py ran, and because there were no Rawhide database files, regenerated the HTML output using the data from the first repository it encountered that contained the pl package. From the logs, it looks like it reads the files in alphabetical order (or uses the same order fetch-repository-dbs.py encountered them), so it went: > Processing database files for epel-10. > Processing database files for epel-10-testing. > Processing database files for epel-8. > Processing database files for epel-8-testing. > Processing database files for epel-9. > Processing database files for epel-9-testing. > Processing database files for fedora-39. > Processing database files for fedora-39-updates. > Processing database files for fedora-39-updates-testing. > Processing database files for fedora-40. > Processing database files for fedora-40-updates. > Processing database files for fedora-40-updates-testing. > Processing database files for epel-10. > Processing database files for epel-10-testing. > Processing database files for epel-8. > Processing database files for epel-8-testing. > Processing database files for epel-9. > Processing database files for epel-9-testing. > Processing database files for fedora-39. > Processing database files for fedora-39-updates. > Processing database files for fedora-39-updates-testing. > Processing database files for fedora-40. > Processing database files for fedora-40-updates. > Processing database files for fedora-40-updates-testing. The pl package is not in EPEL 10, so it used the data from EPEL 8. And on the EPEL 8 branch, it still has the old-style License: https://src.fedoraproject.org/rpms/pl/blob/epel8/f/pl.spec#_76 Elementary, my dear Jerry. ;) I guess I'll try and patch up the app's usage of Bodhi release data and send a PR, that should sort it out. -- 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: Pyliblo3 fails to build on Fedora 41 with python 3.13.0
On Mon, 2024-08-26 at 07:40 +, Martin Gansser wrote: > I am trying to build pyliblo3 from your repo on Fedora 41 with python 3.13.0. > I've got a build error during compilation: > > # wget https://github.com/gesellkammer/pyliblo3/archive/refs/heads/master.zip > # unzip pyliblo3-master.zip; cd pyliblo3-master; ./setup build > > root@fc41:/tmp/pyliblo3-master# ./setup.py build > running build > running build_py > creating build > creating build/lib.linux-x86_64-cpython-313 > creating build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/__init__.py -> build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/_liblo.pyi -> build/lib.linux-x86_64-cpython-313/pyliblo3 > running build_ext > Compiling pyliblo3/_liblo.pyx because it changed. > [1/1] Cythonizing pyliblo3/_liblo.pyx > /usr/lib64/python3.13/site-packages/Cython/Compiler/Main.py:381: > FutureWarning: Cython directive 'language_level' not set, using '3str' for > now (Py3). This has changed from earlier releases! File: > /tmp/pyliblo3-master/pyliblo3/_liblo.pxd > tree = Parsing.p_module(s, pxd, full_module_name) > building 'pyliblo3._liblo' extension > creating build/temp.linux-x86_64-cpython-313 > creating build/temp.linux-x86_64-cpython-313/pyliblo3 > gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 > -DNDEBUG -fcf-protection -fexceptions -fcf-protection -fexceptions > -fcf-protection -fexceptions -O3 -fPIC -Ipyliblo3 -I/usr/include > -I/usr/local/include -I/usr/include/python3.13 -c pyliblo3/_liblo.c -o > build/temp.linux-x86_64-cpython-313/pyliblo3/_liblo.o -fno-strict-aliasing > -Werror-implicit-function-declaration -Wfatal-errors > pyliblo3/_liblo.c: In function ‘__pyx_f_8pyliblo3_6_liblo__msg_callback’: > pyliblo3/_liblo.c:9011:92: error: passing argument 1 of ‘lo_blob_dataptr’ > from incompatible pointer type [-Wincompatible-pointer-types] > 9011 | __pyx_t_7 = __Pyx_PyBytes_FromCString(((unsigned char > *)lo_blob_dataptr((__pyx_v_argv[__pyx_v_i]; if (unlikely(!__pyx_t_7)) > __PYX_ERR(0, 274, __pyx_L1_error) > | > ~^~~~ > | > | > | > lo_arg * > pyliblo3/_liblo.c:1353:78: note: in definition of macro > ‘__Pyx_PyBytes_FromCString’ > 1353 | #define __Pyx_PyBytes_FromCString(s) > __Pyx_PyBytes_FromString((const char*)s) > | >^ > compilation terminated due to -Wfatal-errors. > error: command '/usr/bin/gcc' failed with exit code 1 > > if i edit pyliblo3-master/pyliblo3/_liblo.c > and change the line 9011 to: > __pyx_t_7 = __Pyx_PyBytes_FromCString((unsigned char > *)lo_blob_dataptr(*(struct lo_blob_ **)&__pyx_v_argv[__pyx_v_i])); if > (unlikely(!__pyx_t_7)) __PYX_ERR(0, 274, __pyx_L1_error) > > pyliblo3 compiles with ./setup build. > but how can I patch this file permanently ? I'm a bit confused who you're directing this to. Who is the "you" in "your repo"? You seem to be the person who submitted the review request for this package: https://bugzilla.redhat.com/show_bug.cgi?id=2307912 If you want to maintain a package, you should probably know how to generate and include patches, it's a basic skill for package maintenance. There is a guide at https://rpm-packaging-guide.github.io/#patching-software , although for software maintained in git, I would usually do it by checking out upstream git, committing the change to my local checkout, then using git format-patch to produce a patch file and copying it to the package directory. Miro already posted a patch for this issue in the FTBFS bug for pyliblo: https://bugzilla.redhat.com/show_bug.cgi?id=2248131#c5 -- 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-08-26 @ 16:00 UTC - Fedora 41 Blocker Review Meeting
# F10 Blocker Review meeting # Date: 2024-08-26 # 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 a Fedora 41 blocker review meeting! We have 1 proposed blocker and 1 proposed freeze exception for Beta, and 2 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+41+Blocker+review+meeting&iso=20240826T16&p1=1440&ah=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: Orphaned m2crypto
On Wed, 2024-08-21 at 09:29 -0700, Kevin Fenzi wrote:
> On Tue, Aug 20, 2024 at 02:33:32PM GMT, Neal Gompa wrote:
> > Hey all,
> >
> > I've just orphaned m2crypto. I and a couple of other folks tried to
> > fix it this cycle and it's too difficult for us to deal with. I have
> > no need for this anymore, and upstream is moribund and more or less
> > recommending people to port away from it.
>
> Yeah, understandable. ;(
>
> > Here's the list of reverse dependencies from DNF:
> >
> > ngompa@fedora ~> dnf rq --qf "%{SOURCERPM}" --whatrequires
> > "python3-m2crypto"
> > dmlite-1.15.2-21.fc41.src.rpm
> > dnsviz-0.10.0-3.fc41.src.rpm
> > fts-rest-client-3.13.2-1.fc41.src.rpm
> > hash-slinger-3.2-5.fc41.src.rpm
> > module-build-service-3.9.2-9.fc41.src.rpm
> > oz-0.18.1-15.fc41.src.rpm
>
> ^ This is the only one I care about...
> I know we can/are moving away, so perhaps we can do that before we need
> to move builders to f41.
Peter merged the fix earlier today -
https://github.com/clalancette/oz/pull/315 . He's rolling up some other
PRs too, I guess a new release is imminent.
--
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-08-19 @ 16:00 UTC - Fedora 41 Blocker Review Meeting
# F10 Blocker Review meeting # Date: 2024-08-19 # 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 a Fedora 41 blocker review meeting! We have 1 proposed blocker and 1 proposed freeze exception for Beta, and 6 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+41+Blocker+review+meeting&iso=20240819T16&p1=1440&ah=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-08-19 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-08-19 # 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. Sorry it's been a while - I was traveling for Flock and Devconf.us. 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&iso=20240818T15&p1=1440&ah=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 41 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: Disabling extra subpackages wallpaper for Fedora 41
On Mon, 2024-08-12 at 17:12 -0700, Luya Tshimbalanga wrote:
> On 2024-08-12 17:03, Miro Hrončok wrote:
> > On 13. 08. 24 1:31, Luya Tshimbalanga wrote:
> > > Hello spin maintainers,
> > >
> > > As the subpackage wallpaper i.e. fxx-extras-{gnome,kde,mate,budgie}
> > > series, are stale for a while since at least Fedora 30, I would like
> > > to disable it for Fedora 41 so the default
> > > wallpaper is the only active package. If there is an objection for
> > > the change, let it know.
> >
> > What's the motivation for disabling it?
> >
> > If they are stale, maybe we can move them to a package that is not
> > Fedora-versioned?
> >
> That subpackage contains only a blank blue background as a fallback for
> community submitted supplementary wallpapers until at least Fedora 30.
> The benefit as a maintainer is to focus packaging the default wallpaper
> until the contest for submitting supplemental wallpapers got reactivated.
>
Yeah, I've noticed this when working on the package and wondered what
was going on. As long as we don't actually *have* any extra
backgrounds, I support this idea.
--
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: GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide
On Thu, 2024-08-01 at 07:46 -0600, Leo Sandoval wrote: > > > > Any progress on this? We're gearing up to Flock and branching will be > > the week after Flock... > > > > No progress since last email... Still in the testing phase. There's progress now - the last build that was sent passed openQA testing, so it landed. We've had grub 2.12 in Rawhide for the last two days. So, uh, yay? If anyone can't boot any more...please fax us the details, I guess? -- 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: GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide
On Thu, 2024-08-01 at 07:46 -0600, Leo Sandoval wrote: > > > > > > Again, once we have something solid, I will share relevant links for > > further community reviewing & testing. > > > > > > > Any progress on this? We're gearing up to Flock and branching will be > > the week after Flock... > > > > No progress since last email... Still in the testing phase. If you can post a scratch build or COPR, I can run our openQA tests on it, so we can find any issues those tests run into nice and early. -- 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: FedoraWorkstation default firewall rules unsafe
On Sun, 2024-07-28 at 10:25 +0200, Arthur Bols via devel wrote: > Hi all, > > Yesterday, while assisting a user with connecting a printer, I noticed > that the default firewall zone on Fedora Workstation is set to > "FedoraWorkstation". This zone has ports 1025-65535 open by default > [0]. Is there a historical reason for this, just an oversight, or am I > missing something? This configuration doesn't seem ideal for typical > users and developers. For example, I often run dev servers that I assume > are secure due to the default firewall settings, but it appears that > even the Home zone is more restrictive. > > I'm considering to open a change request to remove these firewall rules > for better security but want to ensure I'm not overlooking anything. It's intentional. It's been that way since the first release of Workstation. It's called "Workstation". If you want to run a server, install the one called "Server". -- 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: sbin-merge: what to do?
On Wed, 2024-07-17 at 16:20 +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jul 16, 2024 at 09:19:24AM -0700, Kevin Fenzi wrote: > > On Tue, Jul 16, 2024 at 11:51:28AM GMT, Neal Gompa wrote: > > > On Tue, Jul 16, 2024 at 11:13 AM Adam Williamson > > > wrote: > > > > > > > > On Tue, 2024-07-16 at 08:08 +0100, Daniel P. Berrangé wrote: > > > > > On Mon, Jul 15, 2024 at 05:07:57PM -0700, Kevin Fenzi wrote: > > > > > > On Mon, Jul 15, 2024 at 08:23:05AM GMT, Zbigniew Jędrzejewski-Szmek > > > > > > wrote: > > > > > > > > > > > > > So… the question now: should I pull the plug on the change for > > > > > > > F41, > > > > > > > dump the side tag, and try again for F42? Or wait for some of the > > > > > > > patches > > > > > > > above to be merged? The mass rebuild is supposed to start in two > > > > > > > days… > > > > > > > > > > > > How hard would it be to move back to the old state? > > > > > > Does that mean a bunch of reverts and rebuilds? or ? > > > > > > > > > > Assuming there was nothing impactful outside of the mentioned side > > > > > tag, > > > > > then no rebuilds should be required, just abandon the tag, and do > > > > > dist-git reverts. > > > > yes, but... that has to happenright now or the mass rebuild will > > just build all those things again and it will land in rawhide anyhow. > > FTR: > > I reverted (*) the changes in dist-git for rpm and filesystem. > All other changes are either appropriate independently of the merge or > conditionalized on %_sbindir==%_bindir, so they didn't need to be > touched. > > The current plan is to wait for the f41 branching, and try again after > that. To be clear: do you mean try again for F41, or try again for F42? If the latter, the Change should be formally deferred to F42, as currently folks are seeing this as planned for F41, e.g. https://fosstodon.org/@Linux@kitty.social/112856419312942208 . -- 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: Announcing fmt library soversion bump
On Thu, 2024-07-18 at 07:58 +0200, Alexander Sosedkin wrote: > This broke dnf5 in ELN: > nothing provides libfmt.so.10()(64bit) needed by > libdnf5-plugin-actions-5.2.4.0-1.eln141.x86_64 from ELN-Extras > > Not sure where to report such ELN issues to, so, please, dispatch accordingly. I guess the fmt10 compat package needs to be imported to ELN (or everything patched/rebuilt to so.11). -- 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: Announcing fmt library soversion bump
On Tue, 2024-07-16 at 20:51 +0800, kefu chai wrote: > On Tue, Jul 16, 2024 at 5:48 PM Frantisek Zatloukal > wrote: > > > > > > > On Tue, Jul 16, 2024 at 11:19 AM Vitaly Zaitsev via devel < > > devel@lists.fedoraproject.org> wrote: > > > > > I've rebuilt some important dependent packages (spdlog) in this side > > > tag, so technically we can merge this side tag today before the mass > > > rebuild starts. > > > > > > > Yeah, you're right, missing that would've caused some fallout, thanks a > > lot Vitaly! > > > > Kefu, so now you can go ahead and submit the side via bodhi :) > > > > Thank you Frantisek and Vitaly! just created an update at > https://bodhi.fedoraproject.org/updates/FEDORA-2024-bcf368c2e9 . fingers > crossed. It failed tests because image builds are pulling in the old fmt, not the new one. This implies that the new one does not satisfy all dependencies needed by the images. This affects Workstation and KDE live and ostree images, and the standard container image. It will take a bit of detective work to figure out what, exactly, is the problem that prevents the newer fmt being included in the images. -- 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: aarch64 iso images - can we link the Everything installer?
On Tue, 2024-07-16 at 09:28 +0200, Adam Samalik wrote: > I noticed we're no longer link to aarch64 isos: > https://fedoraproject.org/spins/kde/download > Not even for Workstation: https://fedoraproject.org/workstation/download > > I heard it failed to build. Fair enough. > > But the Everything installer iso for aarch64 works fine, we just don't seem > to link it from anywhere: > https://mirror.serverion.com/fedora/releases/40/Everything/aarch64/iso/ > > Can we link it from the website? We do. It's at https://alt.fedoraproject.org/alt/ , fourth from the bottom of the aarch64 list. (Unless someone added it since you wrote your mail). -- 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: sbin-merge: what to do?
On Tue, 2024-07-16 at 08:08 +0100, Daniel P. Berrangé wrote: > On Mon, Jul 15, 2024 at 05:07:57PM -0700, Kevin Fenzi wrote: > > On Mon, Jul 15, 2024 at 08:23:05AM GMT, Zbigniew Jędrzejewski-Szmek wrote: > > > > > So… the question now: should I pull the plug on the change for F41, > > > dump the side tag, and try again for F42? Or wait for some of the patches > > > above to be merged? The mass rebuild is supposed to start in two days… > > > > How hard would it be to move back to the old state? > > Does that mean a bunch of reverts and rebuilds? or ? > > Assuming there was nothing impactful outside of the mentioned side tag, > then no rebuilds should be required, just abandon the tag, and do > dist-git reverts. > > > It sounds to me like there's still a lot of outstanding questions, so I > > would say moving it to f42 (and trying to land it after branching in > > rawhide) would be best, but that depends somewhat on how hard the revert > > is... if it's hard it might be better to power on through? > > Agree it sounds like the wise thing to do is to postpone to F42, to give > further time to fully explore the implications. If done right at the > start of the F42 dev cycle, there'll be a greater window for finding > and resolving any fallout before the F42 beta freeze point. Yeah, +1 to this. What concerns me about the openQA experience so far is the broad range of issues we hit, including ones that were kinda 'coincidental' (not actually the thing the test was trying to test). Since openQA is nowhere close to comprehensive, this implies more weird failures will show up even once it passes all the openQA update tests, and we will need time to identify and fix those. -- 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: the sad state of installability tests
On Tue, 2024-07-16 at 09:19 -0400, Stephen Gallagher wrote: > On Mon, Jul 15, 2024 at 4:06 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Mon, Jul 15, 2024 at 08:55:03AM -0400, Stephen Gallagher wrote: > > > This seems like overkill. Wouldn't the simplest valid installability > > > test just be to test whether each subpackage *individually* could be > > > installed? > > > > That's a really nice idea. > > > > > If we have 20 subpackages, just launch 20 separate minimal containers > > > and see if `dnf install subpackageN` succeeds. Then it doesn't matter > > > if there are conflicts; we know that at least installing that package > > > directly will work. (Dependency resolution may pull in other > > > subpackages of course, which is proving that it works properly.) > > > > I'm not sure if we actually want a container. Because if it's a container, > > then we need _some_ packages inside. But that creates a problem for > > some packages like cannot be just installed, but need to be swapped > > with other packages. (systemd-standalone-*, coreutils-single, etc.) > > I think it'd be more reliable to do something like > > dnf install --enablerepo=/path/to/repo/with/updates > > --sysroot=/var/tmp/inst-package1 /path/to/repo/with/updates/package1.rpm > > dnf install --enablerepo=/path/to/repo/with/updates > > --sysroot=/var/tmp/inst-package1 /path/to/repo/with/updates/package2.rpm > > ... > > > > And to make this work reliably, the invocation of dnf should be > > wrapped in 'bwrap' to set up /dev, /proc for the invocation. > > > > This should be quick and more reliable than the current tests, > > even with no config. > > > > Sure, I oversimplified by saying "container", but I agree with your > suggestion. That seems both simple and effective. I predict it would turn up some interesting failures on packages which assumed a more 'realistic' environment. I'm not entirely sure there is a silver bullet for a test like this; what it needs is dedicated and focused attention. -- 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: the sad state of installability tests
On Mon, 2024-07-15 at 08:45 +, Zbigniew Jędrzejewski-Szmek wrote: > > Yes, I've opened many issues regarding Fedora CI. I think the problem is > > that > > the CI maintainer is not a regular packager and thus does not observe CI > > reults in real life. On the other hand, package maintainers do not have > > accces > > to the CI system and need to rely on the CI people. Or a CI person?!. The > > head > > count is probably another problem. > > If there's one "CI person", then that is AdamW. He's doing great work > (also in the update I linked in my original post). IIUC, AdamW's focus > is on the 'update.*' tests, and those are fine, they generally pass. > The bodhi results page says: > > For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora > CI team. > For help debugging failed Fedora CoreOS tests (coreos.*), contact the > Fedora CoreOS team. > For help debugging failed openQA tests (update.*), contact the Fedora > Quality team, ... > > I added c...@lists.fedoraproject.org in CC. > > Zbyszek Just to be really clear about this: I am not personally responsible for Fedora CI, and the Fedora QA team is not responsible for it as a group. This is true at both Fedora and Red Hat levels. "Fedora CI" refers to the Jenkins and Zuul pipelines that run the tests reported to resultsdb with 'fedora-ci.' at the start of their name. I and my team *are* responsible for openQA, which runs the tests reported with 'update.' at the start of their name. To be clear about something else - no "Fedora CI" test is gating for any Fedora update unless a package has configured it to be so in its per-package gating config. There is no project-wide gating on Fedora CI tests. This is because we know none of them is reliable enough to gate project-wide (and it's hard to read the results, and there's no one person whose job it is to look at failures and help resolve them, and so on). The only project-wide gating is on openQA tests, for critical path updates. Due to various...internal considerations, when the system called "Fedora CI" was set up, it was intentionally set up under a different team which is *not* the team I'm on. Resource constraints since then have led to a situation where there really isn't anyone whose primary full-time job is caring about Fedora CI, which is the reason a lot of things to do with it are the way they are. I don't love this situation, and I'd love to have the time and access to work on improving the Fedora CI tests, but I just don't. Like the team that is nominally responsible for it, I have a bunch of other stuff that is considered higher priority. I have contributed a few things to Fedora CI where I can (like the 'results dashboard' for the installability test), but it's never the top of my to-do list, and I don't have admin access to any of it. I'm just an outside contributor to that effort like anyone else. ci@ is indeed the right list for anything to do with Fedora CI. We are aware of many of the problems with the installability test - there's a ticket tracking them at https://pagure.io/fedora-ci/general/issue/448 . There are lots of ideas and plans there for improving things. The problem is just that nobody ever gets a clear week to sit down and do them as their top priority work. I've spent the last two months trying to clear my plate to work on an idea which would necessarily involve some improvements to it and I've never got there. -- 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: libqalculate soname bump
On Sat, 2024-07-06 at 06:46 -0500, Mukundan Ragavan wrote: > > On 7/5/24 15:10, Fabio Valentini wrote: > > On Fri, Jul 5, 2024 at 7:45 PM Mukundan Ragavan > > wrote: > > > I am updating libqalculate to v5.2.0 which bumps the soname version. I > > > will rebuild the following packages that depend on libqalculate. > > > > > > plasma-workspace > > > step > > > cantor > > > qalculate-kde > > Looks like you forgot to rebuild these packages and just submitted the > > update as-is? > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-944fd900df > > > > Fabio > > > I did not forget. koji wait-repo had this output - > > unsuccessfully waited 492:09 for libqalculate-5.2.0-1.fc41 to appear in > the f41-build repo > > I had no idea what had happened until I saw the bodhi email this > morning. I used to do soname builds on rawhide directly but based on the > feedback on bodhi, it looks like I should do it on side-tag now. This is correct, but it's not a recent change. It has been in the updates policy and packager update docs for years: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages If you got away with this before, it was because libqalculate was not in the critical path so openQA did not test it. Possibly plasma- workspace did not depend on it before. -- 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-07-08 @ 15:00 UTC - Fedora Quality Meeting?
# Fedora Quality Assurance Meeting # Date: 2024-07-08 # 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 possibly meeting time again. Or not! It's up to you. I'll be away on Monday morning, so we need someone else to run the meeting, if it's going to run. If you want to volunteer to run the meeting, just reply to this mail and say so. Otherwise, I guess consider it canceled. You can see https://fedoraproject.org/wiki/QA:SOP_Matrix_meeting_process for instructions on running the meeting. 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&iso=20240708T15&p1=1440&ah=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 41 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: Fedora Hosted login for mailing lists error
On Fri, 2024-06-28 at 09:42 +0200, Michal Konecny wrote: > My assumption is that OpenID just checked the client_id server side and > not the origin URL. > I will need to check what are the posibilities in OIDC as it needs > different redirect_uri for each instance as well. Maybe it could be > defined as template or regex in the definition. I'm not expert on > Ipsilon, so I need to check the options. If each instance has its own client id and expected redirects, can't we just add more client configs to Ipsilon? One per instance? -- 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: Bodhi update for mesa stuck waiting on test gating?
On Wed, 2024-06-26 at 14:06 -0400, Scott Talbert wrote: > Hi, > > Can someone please check this update for mesa? [1] > > If I'm reading the results correctly, it seems like it is waiting on > update.server_freeipa_replication_replica for 64bit server, but if you > click on that test, it shows that test passed 3 hours ago. Ugh, it's a thing that happens occasionally and I can't figure out why. Somewhere along the chain (openQA should generate an internal event, a plugin I wrote for openQA receives it and generates a fedora-messaging message, a message listener receives the message and sends a report to resultsdb) something breaks occasionally, and I'm not sure what - either openQA isn't generating the internal "job done" event at all, or my plugin isn't receiving it or is having trouble dealing with it somehow, but no idea which one exactly is happening or why. It's rather hard to figure out. There is a dumb check script running every 24 hours now that catches cases like this and fixes them up, so it would have got cleaned up soonish, but I've gone ahead and done it manually for this one. 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
Re: 2FA policy for provenpackagers is now active
On Tue, 2024-06-25 at 16:21 +0200, Vitaly Zaitsev via devel wrote: > On 25/06/2024 15:06, Stephen Gallagher wrote: > > I am not a lawyer, but I would assume that if Fedora offered to > > provide such a token, it would be reviewed by Legal and provide some > > form of legally-binding assertion that we weren't sending out > > malicious devices. > > Who can guarantee that these devices were not replaced during delivery? > > > In that situation, the > > provenpackagers would be making a three way decision: 1) Stop being a > > provenpackager, 2) buy their own token or 3) accept one provided by > > Fedora. > > 4. Allow classic OTP codes. > > I would prefer this one since I can use open source applications to > generate these codes. I can't find any FIDO2 implementations that are > completely open source which doesn't require proprietary technologies > like TPM or SGX. Relying on a black box is not an option for me. But, uh, any open source application you run is running on a hardware stack vastly more complicated and equally prone to trickery as a simple, cheap USB key. Who guarantees that no component of your PC was replaced during delivery at any point along its supply chain? Who guarantees the bona fides of everyone who has ever contributed to its various firmwares and their updates, and all its components and *their* various firmwares and their updates? Same questions for your phone. Really, if you're going to that level of paranoia, you should swear off electronic devices entirely. In the world of what's realistically possible for Fedora, enabling 2FA and sending everyone a USB stick is a lot better than not enabling 2FA. -- 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-06-24 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-06-24 # 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&iso=20240624T15&p1=1440&ah=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 41 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: heads up: julia has a bunch of incorrect Provides (bug 2291191)
On Mon, 2024-06-10 at 20:57 +0200, Fabio Valentini wrote: > On Mon, Jun 10, 2024 at 8:52 PM Fabio Valentini wrote: > > > > On Mon, Jun 10, 2024 at 8:49 PM Colin Walters wrote: > > > > > > Worth a bit of wide distribution as I'm sure I'm not the only one who got > > > burned: > > > https://bugzilla.redhat.com/show_bug.cgi?id=2291191 > > > > The build of Julia that has this has been unpushed from > > f40-updates-testing already: > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001 > > > > Not sure why these changes landed in the f40 branch only, but not in > > rawhide. > > Side note: The commits that are on the f40 branch *only* definitely > look suspicious: > https://src.fedoraproject.org/rpms/julia/commits/f40 > > Looks like Julia is bundling LLVM, libuv, libunwind, gmp, curl (!), > libssh2 (!), and mbedtls (!) ... > https://src.fedoraproject.org/rpms/julia/blob/f40/f/sources Back story is in https://bugzilla.redhat.com/show_bug.cgi?id=2274270 . Not really suspicious, just an upstream terminally inhospitable to downstreams. It kinda looks like we should just ditch the package, to me. -- 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: Macros stored in a separate file
On Mon, 2024-06-10 at 18:52 +0200, Vít Ondruch wrote:
> Dne 10. 06. 24 v 17:35 Adam Williamson napsal(a):
> > On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
> > > Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
> > > > On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
> > > > > Lately, I noticed that several SPEC files in Fedora use this syntax:
> > > > >
> > > > > Source: macros.vlc
> > > > >
> > > > > And this file defines macros that are loaded by rpmbuild during
> > > > > buildtime and are used in the SPEC file.
> > > > >
> > > > > This makes parsing of the SPEC file harder, because any parser have
> > > > > to have
> > > > > this maro file in current directory - just reading SPEC file is not
> > > > > enough.
> > >
> > > There is also:
> > >
> > > ~~~
> > >
> > > %{load:%{S:1}}
> > >
> > > ~~~
> > >
> > >
> > > Which actually loads the file.
> > >
> > >
> > > > > I mentioned vlc, but it is used in many other packages: valkey, zig,
> > > > > typelib-srpm-macros, ansible-packaging, rakudo, sip and many many
> > > > > other.
> > > > >
> > > > > Why are packagers doing this? I am not saying this is bad, it just
> > > > > surprised
> > > > > me. I am used to put all macros at the top of the SPEC file and this
> > > > > is new
> > > > > to me. What is the benefit?
> > > > I don't know if it is the case for vlc, but the common benefit would be
> > > > where the same macros are to be used in both this local spec, and the
> > > > specs of other dependent RPMs.
> > >
> > > That is precisely the reason I have pioneered this approach and using it
> > > for Ruby.
> > It might be nice to package the macros, in that case.
>
>
> They are packaged of course, either in rubygem-devel or in ruby-devel
But then why would spec files be listing them as a source, which is
where this thread started, instead of buildrequiring the appropriate
package?
--
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: Macros stored in a separate file
On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:
> Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):
> > On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:
> > > Lately, I noticed that several SPEC files in Fedora use this syntax:
> > >
> > > Source: macros.vlc
> > >
> > > And this file defines macros that are loaded by rpmbuild during buildtime
> > > and are used in the SPEC file.
> > >
> > > This makes parsing of the SPEC file harder, because any parser have to
> > > have
> > > this maro file in current directory - just reading SPEC file is not
> > > enough.
>
>
> There is also:
>
> ~~~
>
> %{load:%{S:1}}
>
> ~~~
>
>
> Which actually loads the file.
>
>
> > >
> > > I mentioned vlc, but it is used in many other packages: valkey, zig,
> > > typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.
> > >
> > > Why are packagers doing this? I am not saying this is bad, it just
> > > surprised
> > > me. I am used to put all macros at the top of the SPEC file and this is
> > > new
> > > to me. What is the benefit?
> > I don't know if it is the case for vlc, but the common benefit would be
> > where the same macros are to be used in both this local spec, and the
> > specs of other dependent RPMs.
>
>
> That is precisely the reason I have pioneered this approach and using it
> for Ruby.
It might be nice to package the macros, in that case. That's what we do
for other languages like Python, in python-rpm-macros...
--
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-06-10 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-06-10 # 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&iso=20240610T15&p1=1440&ah=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 41 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: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On Fri, 2024-06-07 at 13:19 +0200, mkol...@redhat.com wrote: > > > > Does RDP support this kind of "reverse connection" mode that VNC has? > > https://serverfault.com/questions/1100655/is-it-possible-to-make-a-reverse-rdp-connection-on-windows-server > > says not, which seems like a significant loss of functionality. > Yeah, I don't think this is really a thing in the RDP world as far as I > can tell. > > Also, we are using GNOME remote desktop to provide the RDP access & its > remote desktop control tool (grdctl) does not seem to provide a way to > configure something like that: > > https://www.mankier.com/1/grdctl > > For the record, it does not seem to support the VNC connect mode as as > well. > > I'm also not sure how well is VNC actually supported in GNOME remote > desktop, as IIRC it is not even exposed as an option in modern Fedora > Workstation options page - only RDP can be configured from there. Well, all you need is any VNC app, and there are lots of those. For the openQA tests we use vinagre for the regular client test and tigervnc for the reverse connection test. GNOME Connections supports regular VNC, I just didn't get around to changing that test to use it yet. -- 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: Anaconda as native Wayland application (System Wide)
On Tue, 2024-06-04 at 14:23 +0200, Jiri Konecny wrote: > > On 04. 06. 24 8:21, Adam Williamson wrote: > > On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote: > > > On 6/1/24 1:04 AM, Adam Williamson wrote: > > > > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote: > > > > > To my knowledge it shouldn't be. Fedora Workstation is already running > > > > > on Wayland by default for quite some time and even Live ISO is already > > > > > Wayland. To my knowledge Wayland don't have issues with graphics cards > > > > > in general. > > > > GNOME has a fallback mechanism where it automatically runs the X.org > > > > session if the Wayland session doesn't work. I believe that is active > > > > on the live image. Of course, as telemetry is evil, we have absolutely > > > > no idea how many Fedora users actually hit this mechanism. > > > One comment I would make is that VirtualBox doesn't *properly* support > > > Wayland [yet] requiring GNOME to be run as an Xorg session (of course > > > not an issue for Xfce etc). > > > > > > If Anaconda is to be Wayland, my concern is that it may make all DEs > > > uninstallable, even ones like Xfce far removed from Wayland. > > Looking at the change, it's not totally clear to me, but it looks like > > this is actually mainly about how anaconda is run in the installer > > environment - netinst, server DVD, and ostree installer images. It's > > not about live images. > > > > I *think* anaconda would continue to run as an X app if launched from a > > live desktop running on X. But it would be nice to have that clarified > > in the Change scope, and any changes to how it would behave in such an > > environment. > Is it better now? I tried to extend the Scope section of the change. Yes, that does look clearer. 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: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On Tue, 2024-06-04 at 14:22 +0200, Jiri Konecny wrote: > > On 03. 06. 24 21:57, Jason L Tibbitts III wrote: > > > > > > > Aoife Moloney writes: > > > === VNC switch to RDP for remote GUI installations === > > I'm curious how my usual install workflow will be affected by this > > change. I use the kickstart "vnc --connect" option extensively in my > > workflow; I may have a bunch of installs running in parallel, and they > > just connect and display when they are ready. I use vinagre as the vnc > > client. > > > > It's not a huge thing; I could come up with another workflow but that's > > the one I've used since before Fedora existed. The installs are fully > > automated and the display connection is only used so that I can see the > > progress and potentially interact with a machine if it encounters a > > problem. I guess in the worst case I could just do the install blind > > and ssh in if something takes too long. > Hi, the only change should be that you will change "vnc --connect" with > the new API we will provide and also use RDP as your client instead of VNC. Does RDP support this kind of "reverse connection" mode that VNC has? https://serverfault.com/questions/1100655/is-it-possible-to-make-a-reverse-rdp-connection-on-windows-server says not, which seems like a significant loss of functionality. The point of the `vnc --connect` mechanism anaconda currently has is to allow remote installs to a heavily-firewalled system, by having that system connect *out* to a server running on the system from which you will run the install, instead of the other way around. -- 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: non-blocking ostree test failures in openQA
Hi folks! This is just a heads up for update maintainers. You may have noticed failures of ostree-related tests in openQA over the last few days - rpmostree_overlay, rpmostree_rebase, or install_default_ostree. These were caused by https://bugzilla.redhat.com/show_bug.cgi?id=2284276 , which is now resolved, and the tests are passing on current runs. The ostree tests are not gating at present (this is because Silverblue is still not release-blocking, though I might reconsider this choice at some point since IoT *is* ostree-based and is release blocking). So these failures are not preventing any updates going stable. Given this, I'm not planning to re-run all the failures, because it'd involve re-doing the image build test for every affected update and each one ties up a worker for a couple of hours. So, you can expect the failure to stay in the update results, but you don't really need to be concerned about it. If you really want the failure cleared from your update, let me know and I can re-schedule the test for that 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
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote: > On 6/1/24 1:04 AM, Adam Williamson wrote: > > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote: > > > To my knowledge it shouldn't be. Fedora Workstation is already running > > > on Wayland by default for quite some time and even Live ISO is already > > > Wayland. To my knowledge Wayland don't have issues with graphics cards > > > in general. > > > > GNOME has a fallback mechanism where it automatically runs the X.org > > session if the Wayland session doesn't work. I believe that is active > > on the live image. Of course, as telemetry is evil, we have absolutely > > no idea how many Fedora users actually hit this mechanism. > > One comment I would make is that VirtualBox doesn't *properly* support > Wayland [yet] requiring GNOME to be run as an Xorg session (of course > not an issue for Xfce etc). > > If Anaconda is to be Wayland, my concern is that it may make all DEs > uninstallable, even ones like Xfce far removed from Wayland. Looking at the change, it's not totally clear to me, but it looks like this is actually mainly about how anaconda is run in the installer environment - netinst, server DVD, and ostree installer images. It's not about live images. I *think* anaconda would continue to run as an X app if launched from a live desktop running on X. But it would be nice to have that clarified in the Change scope, and any changes to how it would behave in such an environment. -- 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: Anaconda as native Wayland application (System Wide)
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote: > To my knowledge it shouldn't be. Fedora Workstation is already running > on Wayland by default for quite some time and even Live ISO is already > Wayland. To my knowledge Wayland don't have issues with graphics cards > in general. GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism. -- 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-05-27 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-05-27 # 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&iso=20240527T15&p1=1440&ah=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 41 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: Fedora Workstation 40 aarch64 download -- How to run Live CD installer?
On Tue, 2024-05-21 at 20:15 -0400, Neal Gompa wrote: > On Tue, May 21, 2024 at 8:11 PM Samuel Sieb wrote: > > > > On 5/21/24 5:08 PM, Brian Masney wrote: > > > I want to put Fedora 40 on my Lenovo Thinkpad x13s laptop, which is an > > > aarch64-based laptop with a Qualcomm SoC. I downloaded the Fedora raw > > > image from [1], and I can boot from USB using the directions at [2]. > > > All of the other supported architectures have an ISO available, > > > however aarch64 only has a raw image available. > > > > > > In the past, I would dd the Fedora image directly to my nvme drive, > > > however this time I'd like to go through the installer so that I can > > > easily setup LUKS encryption on my nvme drive through the installer. > > > The raw image doesn't have the installer, and I didn't have luck > > > installing the anaconda-livecd package. > > > > > > Is there a Live ISO available for aarch64 anywhere with an installer? > > > > https://dl.fedoraproject.org/pub/fedora/linux/releases/40/Workstation/aarch64/iso/ > > That is the experimental osbuild one. There is no official ISO, as it > failed to build. It affected Fedora KDE and other variants too. :( Yes, that. Beyond that, Dennis Gilmore has been poking at Fedora on the x13s for a bit, and has run into some issues you might want to be aware of. See https://bugzilla.redhat.com/show_bug.cgi?id=2254940 and https://bugzilla.redhat.com/show_bug.cgi?id=2264794 . -- 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: Debugging fun (wrt C modernization change)
On Fri, 2024-05-17 at 10:32 +0200, Michael J Gruber wrote: > Kevin Kofler via devel venit, vidit, dixit 2024-05-16 22:39:00: > > Panu Matilainen wrote: > > > Patch and source numbers start from zero, that goes for automatically > > > numbered patches too. So there's an off by one in the application, and > > > the latter %autopatch which is supposed to apply patches >= 2 simply has > > > nothing to do, and falls through silently. That's a bug of course in > > > itself, filed now: > > > https://github.com/rpm-software-management/rpm/issues/3093 > > > > And then they say the automagic is a good idea because it prevents people > > from accidentally forgetting to apply a patch, LOL. > > This would not have happened with autosetup. If you overwrite > automatisms (using invidual patch numbers and flags) you need to know > what you are doing. So this is a very weak argument: > > > %patchlist and %auto* should just go away, or at least banned from Fedora > > by > > a git hook rejecting such specfiles. > > We also have unnumbered patch source definition lines, don't we? Yes, and every package should absolutely use them unless it really needs to refer to individual patches for some reason (e.g. applying them at specific times or not applying them on certain arches). -- 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-05-13 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-05-13 # 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&iso=20240513T15&p1=1440&ah=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 41 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
On Sat, 2024-05-11 at 01:04 +0200, Kevin Kofler via devel wrote: > Florian Festi wrote: > > We have an even easier solution for you: You can just run the script at > > [3] with -n on your own spec files to get them changed to the %patch N > > variant. If you do that right now they will not break nor will they be > > touched during the mass change. > > > > As I said the %patch -PN syntax is the one with the best compatibility - > > reaching back into the dark ages. I am not advocating for people to use > > it. Anyone is free and encouraged to move to something more modern - > > before or after the change. We are using this variant so spec files > > continue to work on older distributions and the chance of breakage is > > minimized. This way packagers that don't care don't have to. > > What I do not understand is why RPM is discontinuing the most commonly used > syntax and breaking hundreds of specfiles. This also leaves us with only the > choice between a backwards-incompatible syntax (added only in RPM 4.18) and > an ugly and redundantly verbose syntax (the -P syntax). And even the modern > syntax is 1 character (space) longer for every patch. The shortest syntax > was the one being dropped. The shortest syntax is just to use Patch: foo.patch , and %autosetup . Much easier on merge requests, too. -- 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: Fedora CI appears to be borked
It looks to me like all tests in Fedora CI are currently failing. I think this is due to a new release of testing-farm having issues. It seems like all tests fail somewhere between Jenkins and testing-farm; Jenkins sends a request to testing-farm, and if you find the log of that request - e.g. https://api.dev.testing-farm.io/v0.1/requests/c9516c80-5375-4548-9e52-c8b22f838dac is one - they all have an error like this: "Command '['ssh', 'artifacts.dev.testing-farm.io', 'mkdir', '-p', '/archive/c9516c80-5375-4548-9e52-c8b22f838dac']' failed with exit code 1" I've tried to ping the relevant folks about this, but it may be past the end of their work day. I don't have the knowledge or access to fix this myself unfortunately. -- 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: Testing package version is spec file
On Wed, 2024-05-08 at 10:38 -0700, Brad Smith wrote: > I help maintain a package where upstream changed the process to > generate installed documentation. In version 1.30 and newer, the spec > file needs to use process A; in versions older than 1.30 (e.g. 1.29.x, > etc) the spec file needs to use process B. I am struggling to find a > workable solution to testing the version like this. > > Can someone please point me in the right direction? Or useful example? There are various strategies for parsing versions, it depends on the upstream version scheme. But I'd actually suggest looking if you can do this indirectly: instead of checking for the version, check for some other marker that indicates which approach you need to use. For instance, maybe some file or other will be present in one case but not the other; can you not just test for that, and choose the process to use based on the result? -- 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote: > On 5/2/24 14:34, Gary Buhrmaster wrote: > > While I follow the philosophy of updating > > regularly, there are likely some who install Fnn, and > > never update, and then would expect an update to > > Fnn+2 to work without issue(s). > > -- > > The CLI update strongly suggests doing 'dnf update --refresh' before > system-upgrade. It doesn't require it though. > > I always thought it's an odd workflow; why doesn't it just force it? > While it might take a long while to complete on a stale system, it's > recommended anyway, isn't it? I would actually hugely prefer we amend that to say `dnf --refresh offline-upgrade download; dnf offline-upgrade reboot` or so. It's a footgun as it stands. -- 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-29 @ 15:00 UTC - Fedora Quality Meeting
# Fedora Quality Assurance Meeting # Date: 2024-04-29 # 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&iso=20240415T15&p1=1440&ah=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 post-release status and recap 3. Fedora 41 Change preview 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: systemd 256~rc1 in rawhide
On Fri, 2024-04-26 at 18:59 +0200, Lennart Poettering wrote: > eOn Fr, 26.04.24 09:05, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > On Fri, 2024-04-26 at 07:36 +, Zbigniew Jędrzejewski-Szmek wrote: > > > Hi, > > > > > > systemd-256~rc1 is building in rawhide. This is a major update, > > > in development for 5 months. We've been doing continuous builds > > > and testing of the development versions in rawhide, but bugs > > > are possible (even likely). Plese report issues in bugzilla or > > > here. > > > > It doesn't boot. That seems like an issue. :D > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-54b3646daf#comment-3506797 > > I guess this is triggered by the new ProtectSystem= feature that you > can configure in /etc/systemd/system.conf. See NEWS file. > > It ensures that /usr/ is marked ready-only during earliest > initialization in PID 1. It defaults to off on the final system, but > to on in initrds, and that appears to trip off dracut. > > I don't know why dracut wants to write around in /usr/, but it seems > very wrong it tries to do that. > > Anyway, a quick work-around is to set the knob to false in the > initrd. But a proper fix is to make dracut not patch around in /usr/ > during runtime. Writing to /usr/ should be off limits for anything > that isn't really a package manager (and maybe very few other > exceptions). Well, it really wants to write to /lib , not to /usr. But of course, on Fedora, /lib is /usr/lib . The specific error I can see in the openQA output is triggered here: https://github.com/dracutdevs/dracut/blob/master/modules.d/98dracut-systemd/parse-root.sh#L28 $hookdir , there, is /lib/dracut/hooks . This is a mechanism used all through dracut - it writes hooks into that directory under all sorts of circumstances. I don't know how disruptive it would be to make it a different directory. CCing pvalena. Another thing I discovered testing this locally: the bug only shows up once the initramfs is regenerated. If you just update systemd alone and reboot, system boots fine. As it happens, all the openQA tests run into the bug because there is a kernel update available since their base disk images were last regenerated, so in the same update transaction as the systemd update being tested, they get a kernel update, and the initramfs gets regenerated. But even if that weren't the case, we would have caught the bug with the advisory_boot test, which rebuilds the initramfs after installing the update and tests that the system still boots, specifically to catch cases like this. -- 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Wed, 2024-04-24 at 22:56 -0700, Adam Williamson wrote: > 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. Just to follow up on this: the Kiwi container build test failure pointed to some changes that will be required to the Fedora kiwi config when this change lands. I have filed a PR for that - https://pagure.io/fedora-kiwi-descriptions/pull-request/46 - which should only be merged when this update is getting pushed. I tweaked the openQA test to make those changes on-the-fly when testing this update, and now it passes. By inference it occurred to me to check the osbuild configs also and I found a likely-required change there, so I sent a PR for that - https://github.com/osbuild/images/pull/637 - which has been merged. We would need the osbuild folks to deploy that change to prod before this update lands in Rawhide, otherwise some osbuild-driven image builds will most likely start to fail. The Cockpit update test failures turned out to be just stricter defaults in the new dnf exposing a bug in how the openQA tests handle the advisory repo (the side repo that contains the packages from the update under testing). I fixed that, and now the tests pass. -- 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Fri, 2024-04-26 at 08:56 +0200, Jan Kolarik wrote: > Hi Kevin, > > Personally, I think this is a beta requirement. > > > > IIUC the Fedora 41 Beta requirement is to successfully upgrade the system > from Fedora 40, as mentioned here: > https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation. > So this still relates to the dnf4 package, which is used in Fedora 40. I > expect this will become relevant for dnf5 at the Fedora 42 Beta. Yup, that makes sense to me. The upgrade is all run by the previous release's DNF, not the new release's DNF. -- 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: systemd 256~rc1 in rawhide
On Fri, 2024-04-26 at 07:36 +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > systemd-256~rc1 is building in rawhide. This is a major update, > in development for 5 months. We've been doing continuous builds > and testing of the development versions in rawhide, but bugs > are possible (even likely). Plese report issues in bugzilla or > here. It doesn't boot. That seems like an issue. :D https://bodhi.fedoraproject.org/updates/FEDORA-2024-54b3646daf#comment-3506797 -- 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: 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&iso=20240415T16&p1=1440&ah=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&iso=20240415T15&p1=1440&ah=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&iso=20240408T16&p1=1440&ah=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&oldid=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 th
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&iso=20240401T16&p1=1440&ah=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
