2024-03-04 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-03-04 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 2 proposed freeze exception for Beta, and 5 proposed blockers for Final. The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 13:27 -0600, Jason Tibbitts wrote: > > > > > > Adam Williamson writes: > > > Honestly, we could really use more automation here, but it's a fairly > > hard thing to do *reliably* and there just isn't anybody specifically > > tasked with it so it doesn't happen. > > So sure, we could use something but it doesn't have to start out as some > complex fully automatic system. (Would be nice, but...) > > Can we agree that we'd be at least half of the way there if we just had > a well defined way to: > > * Know what package depend on the one you're updating > > * Easily bump and chain-build all of that in a side tag > > Surely there's a reopquery or fedrq command line that will find at least > most of what needs to be rebuilt. It doesn't have to be absolutely > perfect but it can't be that hard to get close. I know there's a > distinction between build and runtime dependencies and rich/conditional > dependencies complicate things a bit, but those much smarter than I am > must have already figured out how to get something that's at least > somewhat useful. > > Once you have the package list, maybe it needs some kind of sorting > before you can just bump and chain-build things, but I think in many > cases it doesn't. So, yes, a 100% tool would be really hard but the 80% > tool really shouldn't be that bad, and almost any tool would really help > people out. Yeah, for sure, that's why I'm trying to nibble around the edges by updating the docs to strongly encourage chain builds, document using fedpkg chain-build on a side tag, and hopefully get fedpkg chain-build enhanced so it can create the side tag and the final update automatically. If we can get that, then I can make the docs explain how to use it. ISTR there've been several recent discussions of complex dep chains on this very list where people have floated candidates for repoquery/fedrq commands...if there's one we're pretty confident is The Best, we can definitely plumb that into the docs at least (plumbing it all the way into fedpkg might be a step too far, though). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 09:34 +0100, Michael J Gruber wrote:
> Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius
> :
> >
> > Hi,
> >
> > I intend to update gumbo-parser to 0.12.1 in rawhide.
> > This comes along with an soname bump libgumbo to libgumbo.so.2
> >
> > This requires a rebuilt of several dependent packages, AFAICT:
> > claws-mail
> > litehtml
> > mupdf
> > perl-HTML-Gumbo
> > python3-PyMuPDF
> > qpdfview
> > zathura-pdf-mupdf
> >
> > I'll try to rebuild these packages on side-tag f41-build-side-84865
> > (Please, bear with me, I haven't used side-tags, before. I couldn't find
> > any usable docs on how to use them)
> >
> > Preliminary tests indicate, something unrelated to libgumbo.so.* has
> > changed with these packages (Probably mupdf), causing gpdfview to FTBFS
> > and dependency changes in rawhide.
>
> Interesting. I wasn't aware of that dependency - I guess I have to
> re-run detection more often. Speaking of - do we have a policy about
> this? This is not about blaming, but how do we ensure that everyone is
> aware of new dependencies? Frequent re-runs to detect them or
> announcements the other way round?
Unless I've missed something, the general situation in Fedora is all
the onus is on the party bumping the depended-upon package. We don't
require dependent packages to announce their dependencies in any way
(except, you know, through an actual package dependency).
If you're changing a package in any way that could be fairly considered
"not backwards compatible" for another package depending on it in a
"typical" way, I'm pretty sure the onus is on you to find those
dependencies and make sure they are handled, not vice versa.
Honestly, we could really use more automation here, but it's a fairly
hard thing to do *reliably* and there just isn't anybody specifically
tasked with it so it doesn't happen. I had an interesting chat with
Martin Pitt about britney -
https://release.debian.org/doc/britney/what-is-britney.html - which
Debian and Ubuntu use in this area. If I understood the explanation
correctly, it's a sort of automated update bundler; Debian and Ubuntu
devs can just throw builds at a staging area, and britney takes care of
grouping them into logical sets based on their dependencies. So to do
an soname bump you'd build the bumped library in the staging area, wait
for it to appear in the staging area buildroot (I guess), then build
all the dependencies, and britney would figure out that this group of
packages needs to go out of the staging area and into stable together
and make that happen, so the packager doesn't have to group them
manually. If you've got a build in the staging area which britney can't
"solve", I think, you get alerts so you know what needs doing ("package
X needs rebuilding against your thing", or whatever).
Something along those lines for Fedora would be awesome! But we can't
just lift-and-shift britney - we'd have to adapt it to RPM dependencies
(if that hasn't been done already) and integrate it with Bodhi
(definitely not done already). That's a lot of work for someone. We
could conceivably code an equivalent feature into Bodhi ourselves, but
again, a lot of work for someone. And it'd probably need some thought
about a way to allow cutoffs/exceptions so you could get an soname bump
through if it has 500 dependencies and you've fixed 499 and the other
is some obscure package that hasn't been maintained for a year. All of
that is work that isn't #1 on anybody's priority list, I think :( I
would love to say I'm gonna work on it, but I've added three neat
projects to my "neat side project backlog" since *yesterday* and it's
about a thousand items long at this point, so, hmm.
It'd also be nice to have a reliable distro-wide automated check for
"does this update break the dependencies of anything else?" so we could
at least prevent all updates that break dep chains going stable. Right
now openQA catches some such cases, but *only* ones that affect
critical path packages *and* happen to involve a package that actually
gets installed during an openQA test. The CI rpmdeplint test is
supposed to cover this, I think, but historically hasn't proven
reliable enough to be made universally gating (and I think maybe only
works on Rawhide). But again...somebody has to clear the time to work
on it :|
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 07:54 +0100, Ralf Corsépius wrote: > Hi, > > I intend to update gumbo-parser to 0.12.1 in rawhide. > This comes along with an soname bump libgumbo to libgumbo.so.2 > > This requires a rebuilt of several dependent packages, AFAICT: > claws-mail > litehtml > mupdf > perl-HTML-Gumbo > python3-PyMuPDF > qpdfview > zathura-pdf-mupdf > > I'll try to rebuild these packages on side-tag f41-build-side-84865 > (Please, bear with me, I haven't used side-tags, before. I couldn't find > any usable docs on how to use them) Thanks for trying! This doc should be pretty good: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#_side_tags I have an active PR to revise that page a bit, but it doesn't change much about the side tag instructions themselves. One neat thing I found out while working on various docs around this today is that you can use `fedpkg chain-build --target (side tag name)` to do a chain build to a side tag. I haven't tried it, but it ought to work fine. So, just create your side tag, wait for it to exist, run the chain-build, and if it all goes OK, create the update from the side tag. I think it'd make sense these days for `fedpkg chain-build` to *default* to creating a new side tag and doing the builds there automatically (and then maybe creating an update when they're all done), so I filed https://pagure.io/fedpkg/issue/540 for that. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: "ABSENT" test results from Fedora CI: status update
On Wed, 2024-02-28 at 09:03 -0800, Adam Williamson wrote: > Hey folks! Just an update on an issue I know some packagers are running > into. > > In the last few days, some Fedora CI jobs have been getting stuck and > timing out. Packagers will usually experience this as a test result > showing as "ABSENT" in Bodhi, e.g. for this update: > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce1fb5a0db > > the fedora-ci.koji-build.tier0.functional result shows as ABSENT (red > line, question mark icon which shows ABSENT if you hover over it). > > We don't have any CI tests that are universally gating by default, but > some packages have opted in to gating on some CI tests, and some of > these have been stuck in updates-testing for a few days due to this > problem. > > It seems the issue was caused by a kernel 6.8 bug which broke quite a > lot of stuff last week - see > https://lore.kernel.org/all/6a150ddd-3267-4f89-81bd-6807700c5...@redhat.com/ > . The fix for that bug was in kernel 6.8rc6, which is now in both > Fedora 40 and Rawhide. Miroslav Vadkerti is aware of this and is > working to try and clean things up (update the base images for Fedora > CI and get all the timed-out tests re-run). I don't know what the ETA > is, but just wanted to let folks know it's at least being worked on. Update on this: turns out the kernel bug wasn't the main thing, that was causing some test errors but the main problem was that reporting of Fedora CI results to resultsdb simply broke on Saturday and nobody spotted that was the problem till today. We got that fixed today, and I have hacked up and am now running a script which should report all the results that were missed (hopefully correctly, and hopefully without overriding or duplicating or missing anything). Once it's finished running I'll do a sweep for updates still stuck in updates-testing and see where we are. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
"ABSENT" test results from Fedora CI: status update
Hey folks! Just an update on an issue I know some packagers are running into. In the last few days, some Fedora CI jobs have been getting stuck and timing out. Packagers will usually experience this as a test result showing as "ABSENT" in Bodhi, e.g. for this update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce1fb5a0db the fedora-ci.koji-build.tier0.functional result shows as ABSENT (red line, question mark icon which shows ABSENT if you hover over it). We don't have any CI tests that are universally gating by default, but some packages have opted in to gating on some CI tests, and some of these have been stuck in updates-testing for a few days due to this problem. It seems the issue was caused by a kernel 6.8 bug which broke quite a lot of stuff last week - see https://lore.kernel.org/all/6a150ddd-3267-4f89-81bd-6807700c5...@redhat.com/ . The fix for that bug was in kernel 6.8rc6, which is now in both Fedora 40 and Rawhide. Miroslav Vadkerti is aware of this and is working to try and clean things up (update the base images for Fedora CI and get all the timed-out tests re-run). I don't know what the ETA is, but just wanted to let folks know it's at least being worked on. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: google-re2 pacakge update and facebook vs google python bindings ?
On Fri, 2024-02-23 at 13:36 -0500, Paul Wouters wrote: > On Wed, 7 Feb 2024, Ben Beasley wrote: > > > Subject: Re: google-re2 pacakge update and facebook vs google python > > bindings > > I haven't heard back from any of the maintainers. > > I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the > first step towards getting python-google-re2 working. > > https://src.fedoraproject.org/rpms/re2/pull-request/6 You now seem to have just built re2 for Rawhide without any of the deps: https://bodhi.fedoraproject.org/updates/FEDORA-2024-daa3669e4d that's not how you're supposed to do things, these days. You should build re2 on a side tag and then get all the deps rebuilt on the same side tag, then create a combined update. The update failed tests because of this. The best thing to do at this point would be to create a side tag, bump re2 and do a new build on the side tag, then ask maintainers of dependencies and/or provenpackagers to rebuild the dependencies on the side tag. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-02-26 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-02-26 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 7 proposed blockers and 4 proposed freeze exception for Beta, and 5 proposed blockers for Final. The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. I'll be on vacation on Monday, so Frantisek Zatloukal will be running the meeting, thanks Franta! If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Kickstart install of Rawhide fails
On Thu, 2024-02-22 at 15:32 -0700, Orion Poplawski wrote: > I've seeing: > > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: > glibc-common-2.39.9000- > 1.fc41.x86_64 1708040026 > e4113ddcb7a4bf591492c0bf4644932b0dad7691ff19c65111751675336cb0c8 > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: > bash-5.2.26-3.fc40.x86_64 1707490454 > 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring > (running scriptlet for): bash-5.2.26-3.fc40.x86_64 1707490454 > 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: > dbus-common-1:1.14.10-3.fc40.noarch 1706087027 > 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring > (running scriptlet for): dbus-common-1:1.14.10-3.fc40.noarch 1706087027 > 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d > INFO:dnf.rpm:error: failed to exec scriptlet interpreter /bin/sh: No such file > or directory > warning: %post(dbus-common-1:1.14.10-3.fc40.noarch) scriptlet failed, exit > status 127 > > ERROR:dnf.rpm:Error in POSTIN scriptlet in rpm package dbus-common > ERROR:anaconda.modules.payloads.payload.dnf.transaction_progress:Error in > POSTIN scriptlet in rpm package dbus-common > > > But /bin/sh is present and runnable when I try in /mnt/sysroot (the log shows > that bash was just installed as well). > > Anyone else hitting this? Yes, someone else is, when installing in VirtualBox: https://bugzilla.redhat.com/show_bug.cgi?id=2244744 It's confusing, isn't it? Are you using VirtualBox? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: openQA update test backlog - now clearing
On Mon, 2024-02-19 at 23:28 +, Leslie Satenstein via devel wrote: > 4) After logging in, the keyboard layouts(user and root) are correct. > It is only the login screen. This is https://bugzilla.redhat.com/show_bug.cgi?id=2264930 . -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openQA update test backlog - now clearing
Hey folks! just a quick note in case anyone was waiting for openQA tests on their update. it seems one of the worker hosts got into some kind of stuck state, a lot of jobs were stuck at 'uploading'. unfortunately these are jobs that are set to *only* run on that host, so they were stuck permanently. I've rebooted that host and it's picking up the backlog now, it should work through it over the next few hours. the most-delayed update seems to be FEDORA-2024-84788cb473 , which is 16 hours old. sorry again! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2024-02-19 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-02-19 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 6 proposed blockers and 1 proposed freeze exception for Beta, and 4 proposed blockers for Final. The meeting will be on Matrix, as we're trying to move to more modern systems and the meeting bot is working on Matrix now. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-19 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-02-19 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 status, including anaconda web UI test planning 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-19 @ 17:00 UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-02-19 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 6 proposed blockers and 1 proposed freeze exception for Beta, and 4 proposed blockers for Final. The meeting will be on Matrix, as we're trying to move to more modern systems and the meeting bot is working on Matrix now. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide
On Wed, 2024-02-14 at 12:57 -0600, Michael Catanzaro wrote: > I checked the build log for > https://koji.fedoraproject.org/koji/taskinfo?taskID=113473592 but > unfortunately I don't actually see any error message. I searched for > "error:" (indicating a compiler error) and I also searched for "Killed" > (indicating OOM). > > No doubt something is wrong somewhere in that build log, but I'm not > sure where. We have untagged the update for now - https://pagure.io/releng/issue/11952 - so this won't break Rawhide. Once webkitgtk is buildable we can figure out how to take another cut at this (I'm not sure exactly what the procedure is to get a side tag update like this edited and retagged, we may *possibly* have to create a new side tag, tag all the existing builds onto that, add a webkitgtk build, and create a new update?) -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Re: 2024-02-12 @ 17:00 UTC - Fedora 39 Blocker Review Meeting
On Sun, 2024-02-11 at 10:16 -0800, Adam Williamson wrote: > # F39 Blocker Review meeting > # Date: 2024-02-12 > # Time: 17:00 UTC > # Location: > https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Of course, this should say 'F40' and the subject should be 'Fedora 40 Blocker Review Meeting'. Sigh. Somehow I always miss *something* when editing these damn announcements. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-12 @ 17:00 UTC - Fedora 39 Blocker Review Meeting
# F39 Blocker Review meeting # Date: 2024-02-12 # Time: 17:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! Fedora 40 branches this coming week, and we have some blockers to check in on, so it seems like a good time for a blocker review meeting. We are still on standard time in places that use daylight savings, so the meeting is at 17:00 UTC. The meeting will be on Matrix, as we're trying to move to more modern systems and the meeting bot is working on Matrix now. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-02-05 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-02-05 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-02-03 06:16, Marc Deop i Argemí wrote: - As the packages stand right now, the KDE general updates will have to wait for the proposed packages to be updated by their maintainers or we will have to do the updates ourselves (which defeats completely the point of our change proposal). Why? This is the part I don't understand. Can you explain it in more detail? Thanks. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-02-01 07:40, Sérgio Basto wrote: I have an obvious answer is when the authors decide, in this case Xorg, when Xorg decides that it will stop supporting X11, like happened to Python2 or PHP5 and 7 or Gnome In fact, it is something I've been thinking about, IMHO, downstream shouldn't decide when software is deprecated or not like KDE and Red HAt did , it's weird to me [1], although in RHEL we could have the packages via EPEL, I think, and RHEL 10 is only in a year and a half A lot of the people involved at different parts of the stack are just the same people wearing different hats. Wayland and X.org are both part of freedesktop. Whatever maintenance is still happening on X.org is mostly being done by people who primarily work on Wayland. There isn't some kind of holy war going on between The Wayland Developers who want to kill X.org, and The X.org Developers who believe it is great and want to keep it. They're nearly all the same people, and they all want X.org to die. AFAIK there isn't anybody who is actually clamoring to *do the work of maintaining X.org upstream*. There are people who don't want it to die because Wayland doesn't yet have the features they need or the NVIDIA proprietary driver doesn't work well on Wayland or whatever, but AFAIK, none of those people is actually volunteering to maintain X.org long-term. If you look through https://gitlab.freedesktop.org/xorg/xserver/-/commits/master you will see the majority of commits are from people who also work on Wayland (and most of the commits are actually to Xwayland). A lot of the same people who are the graphics stack maintainers for freedesktop.org are *also* involved in distribution efforts to move to Wayland. So it's not as simple as "distributions making the decisions instead of upstream". AFAIK, most of the upstream folks dearly *want* distributions to move off of X.org and onto Wayland, but they feel kind of obliged to continue minimal maintenance of X.org upstream until this move is further along. Apologies if any of that is inaccurate, and I'm sure folks will correct me if so. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-02-01 04:08, Steve Cossette wrote: So, if you all don't mind, I'd like to steer this discussion in a slightly different way: What /is/ the definition of a Fedora Change Proposal? I was under the impression it was an announcement of intent by the maintainers of a specific subset of the fedora project to "change" something. Once said announcement has been discussed publicly, Fesco (Sorry if the capitals are incorrect) discusses it internally (albeit, publicly) and either blocks or approves the change, making it official. /(Please note: The following paragraphs will use "we" as a pronoun which is intended to be the Fedora project as a whole)/ / / Once approved, we announced our intent to drop X11 from the KDE spin of Fedora. That announcement has gained traction everywhere, got publicized and everything. As Neal Gompa also stated, it has already caused some substantial development effort upstream to effectively iron out the rough edges of many of the problems, with what I assume is more to come. I would not read it quite like that. I would say that by approving the Change, "we" - in the sense of "Fedora as a whole" - approved of the KDE SIG's decision to stop maintaining Plasma X11. I can't speak for FESCo, but if I had been on FESCo, I don't think I would've had in my mind "approving this Change creates a ban on anybody at all maintaining Plasma X11 packages in Fedora" when voting on it. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On 2024-01-30 05:45, Stephen Gallagher wrote: One additional point I forgot to address: the initial concern was that the KDE SIG would be implicitly responsible for maintaining these packages if they are included in the main repository. From a purely technical perspective, I think that we should state clearly that the KDE SIG would be required only to provide advance notice of major changes but would NOT be responsible for ensuring that these packages adapt to them. Of course, communicating that to users is harder (and they'll naturally report bugs to the wrong place in many cases), but I think the KDE SIG is completely permitted to refuse and retarget any issues that come up to the appropriate group. I think this is a case where it's more useful to focus on technical details than grand philosophy. So, let's game out what might actually happen here. Say these packages are accepted, and we have, to simplify, a large blob of packages maintained by the KDE SIG that represents "Plasma on Wayland, supported by the KDE SIG, release blocking" - henceforth "PLASMA-WAYLAND" - and a small blob of packages maintained by other folks that represents "Plasma on X.org, not supported by the SIG, not release blocking" - henceforth PLASMA-XORG. If I'm correct, the situation would be this: * PLASMA-XORG would depend on PLASMA-WAYLAND, but not vice versa * Updates to PLASMA-WAYLAND could break PLASMA-XORG, but not vice versa * PLASMA-XORG could not block any releases * PLASMA-XORG would not gate any updates. This is because only openQA tests gate Plasma updates, and openQA only tests the default Plasma configuration, Plasma-on-Wayland Given all of this...I am not sure there is really a problem for the Plasma SIG beyond expectations they are choosing to place on themselves. To put it brutally, they *could* choose to just create and ship PLASMA-WAYLAND updates and tell the PLASMA-XORG maintainers to deal with it. No procedures or processes would stop them doing this. There would be no release-blocking bugs, and no update gating, so long as PLASMA-WAYLAND itself worked. The sole exception I can think of would be if enough people filed negative karma due to X.org failures to derail an update, but negative karma restrictions are really pretty loose in Fedora. Karma more or less does not affect Rawhide updates (except possibly in one rather specific case, I am coincidentally in the middle of figuring this out). For non-Rawhide updates, the "auto-unpush" threshold is completely configurable, you can set it to -100 if you like. A single negative karma disables autopush, but it doesn't force it off: you can turn it back on. You only need a net +2, in the worst case, to push an update stable manually. So I would argue in favour of accepting the packages, because I don't think the negative impact the SIG is worried about is really that significant. I don't think they really are "forced to maintain" the Xorg packages. I think it will prove to be practical for them to just maintain the Wayland stack and leave maintaining the Xorg packages to those who volunteer to do it. They can *choose* to co-ordinate megaupdates with those maintainers if they like, but I don't think any distro rule or mechanism will *require* it, in practice. I also think that, in practice, things will turn out to be manageable in a much nicer fashion. The folks who are volunteering to maintain the X.org packages are longstanding and responsible Fedora maintainers who are capable of doing it. If problems do emerge after trying this in good faith for a while, it's always possible to re-evaluate. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openQA test failures for Rawhide: heads up
Hey folks! You may have noticed unpredictable openQA test failures on Rawhide updates ATM. This is mainly because of the mass rebuild. All the packages from the mass rebuild have been tagged into the buildroot repo (which the openQA tests use), so now there are far more on-the-fly updates than is usually the case, and various test steps are hitting timeouts depending on how fast the download / update process runs. I'll re-run tests opportunistically for now, but some may still fall through the cracks. Once the currently-running Rawhide compose completes (fingers crossed), I can regenerate the base disk images so they're up to date with the mass rebuild package set, and things should settle down again. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: A reminder: you cannot just "revert" package version bumps
On 2024-01-29 16:00, Sérgio Basto wrote: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily you may do a new build with lower EVR That is not what that guideline says. It says the Rawhide build can be lower-versioned than a current build from *a different branch* *temporarily*. It says nothing about allowing a new Rawhide build to be lower versioned than the previous one. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
A reminder: be careful with snapshot versioning, especially with %autorelease
nirik ran a script that checks for versioning issues in Rawhide today, and it found several: https://pagure.io/releng/issue/11922#comment-893797 Aside from rogue version downgrades (see other mail), a few of these followed a different pattern: problems with snapshot versioning. 1. patool: highest tagged build patool-1.12-22.fc39, most recent tagged build patool-1.12-0.27.20231014gitab64562.fc40 2. python-pyunicorn: highest tagged build python-pyunicorn-0.7.0a1-1.20230730gitmaster.fc40 , most recent tagged build python-pyunicorn-0.7.0~a1-5.20230730gitmaster.fc40 3. vim-devicons: highest tagged build vim-devicons-0.11.0-10.20200509gitd12c9b4.fc39 , most recent tagged build vim-devicons-0.11.0-0.20221001git71f239a.13.fc40 In the python-pyunicorn case, the packager simply made a mistake with pre-release versioning, then fixed it. The current version is correct, but unfortunately evaluates as lower than the incorrect one which was missing the tilde. This means that anyone who happened to get python-pyunicorn-0.7.0a1-1.20230730gitmaster.fc40 installed will likely never see an update until 0.7.1 comes out (even a 0.7.0 final release will evaluate lower than "0.7.0a1"). In the other two cases, %autorelease is involved. autorelease is a great tool, but use it carefully when using snapshot builds. Without any additional guidance, %autorelease assumes that if you're building from a snapshot, it is a pre-release snapshot for the specified "Version". So it'll use a release like 0.(date)git(tag).(rel). If your snapshot is a post-release snapshot, you need to provide %autorelease with more cues about how to version it to get the desired effect. This is the problem for vim-devicons and patool. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
A reminder: you cannot just "revert" package version bumps
nirik ran a script that checks for versioning issues in Rawhide today, and it found several: https://pagure.io/releng/issue/11922#comment-893797 Some of these followed a pattern, so I figured a reminder was in order. In all these cases, a new version was pushed to Rawhide, then "reverted" some time later: golang-github-nats-io-jwt - bumped to 2.4.1 in July, reverted to 1.2.2 in September golang-google-grpc - bumped to 1.58.0 in September, reverted to 1.48.0 in October; no 1.58.0 build ever landed, but the revert left the %release much lower than before python-mizani - bumped to 0.10.0 on September 10, reverted to 0.9.3 on September 12 python-pywlroots - bumped to 0.16.6 on November 4, reverted to 0.16.4 later the same day so the reminder is this: you cannot simply "downgrade" RPM package versions like this. Especially not if the upgraded version ever made it into a Rawhide compose. If a Rawhide user has your package installed, and got the upgraded version, they will be marooned on that build forever unless they manually run `dnf distro-sync`. A `dnf upgrade` will not downgrade the package to the build you now consider to be the "current" one. If you have to downgrade a package that made it to a Rawhide compose, you must use an epoch. If the package did not have an epoch before, make it `Epoch: 1`. If it had an epoch already, bump it by 1. People tend not to like epochs, so *try* not to have to do this. Be really certain before pushing out version bumps. If the "upgraded" build never made it into a compose (as is likely the case for python-pywlroots) you're *probably* okay, but it's still something to be careful about - for instance you might fall into the trap golang-google-grpc fell into with the %release tag. Thanks folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openQA Rawhide update failures - we're working on it!
Hi folks! I want to apologize to packagers who have Rawhide updates stuck on failed openQA tests, and provide an update. There were two big problems today. First, the Server base disk image used for some of the tests got regenerated (this happens weekly). Unfortunately, this meant it got affected by https://bugzilla.redhat.com/show_bug.cgi?id=2259266 , and no longer booted. I should have got that grub2 build untagged or the change reverted sooner - sorry. I was expecting the package to be fixed sooner, and it didn't occur to me that this image being regenerated was a risk. I've now got the package untagged, and forced a rebuild of the disk image using a grub2 build with the patch re-applied (otherwise I'd have had to wait for the next Rawhide compose to rebuild the image). I'm now working through re-running all affected tests. Second, shell-color-prompt was changed[0] to apply the color prompt to virtual consoles. This broke a large number of openQA tests, as they often need to do things at root consoles, and to do that they need to know when they've actually managed to log in to one, and they do this by screen matching the prompt. Any test which needed to know it was at a root console was failing. I've updated the 'needle' to match the color prompt, and am re-running all affected tests. I anticipate the mess should be cleaned up in about three or four hours (there are a lot of failures to re-run, and some of the tests take a while to run). Sorry again for the inconvenience. I'll probably propose adding shell-color-prompt to the critical path. That would mean openQA would have gated the update (allowing me to update the needles *before* it got pushed and broke tests for every other update), but it also just seems appropriate - theoretically, a bad change to the package could cause all sorts of consequences, since it fiddles with the default prompt. [0] https://src.fedoraproject.org/rpms/shell-color-prompt/c/1dd8c6c16d760cacfb9fd70a249b28a1fd853dd1?branch=rawhide -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up: openQA update test failures due to ongoing FAS outage
Due to the ongoing FAS outage - https://status.fedoraproject.org/ - many updates failed openQA testing, because part of the openQA web browser test happens to be to open https://accounts.fedoraproject.org and check it looks as expected. Obviously right now it does not. As this is not a critical part of the test, I have just disabled it until the FAS outage is resolved, and re-run the failed tests. Affected updates should be unblocked soon. Sorry for the trouble. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-01-22 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-01-22 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again, and once again we'll be on Matrix. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 Change review and check-in 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -fcf-protection dropped from i686 compiler flags
On 2024-01-18 12:28, Michael Catanzaro wrote: Unfortunately this is causing gating tests to fail for rawhide builds, e.g.: https://artifacts.dev.testing-farm.io/081ad2a3-76cd-4aa0-b95e-e870ff75a65c/ Hardened: /usr/bin/pkcon: FAIL: cf-protection test because .note.gnu.property section did not contain the necessary flags I'm not sure whether to report a bug to rpminspect or to annocheck. One or the other needs to stop testing for this. The timing is unfortunate because the mass rebuild has started today. I'm not sure what the impact will be. I guess packages will build, but get stuck in gating? rpminspect does not gate by default. None of the tests run by Fedora CI (any test whose name as shown in Bodhi begins with 'fedora-ci') gates by default, in fact. Only packages which opt in to gating on these tests via their per-package gating.yaml files should be gated by failures of Fedora CI tests. The only tests that gate packages *without* a per-package gating.yaml are the openQA tests that gate critpath packages (the names for these always start with 'update.'). In Bodhi's 'automated test results' table, gating tests have an asterisk as the first item in their row. Non-gating tests do not. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 37 is EOL
On Mon, 2024-01-08 at 13:57 -0500, Ben Cotton wrote: > On 08-01-2024 17:16, Adam Williamson wrote: > > > Doing it this way was Ben's preference (he wanted to be able to see > > that every bug was updated and get a notice from the script for any > > single bug change that failed), > > Historically, the script ran much faster than Bugzilla, which meant > after a while, we'd start getting timeouts. This is why there are > pauses built into the script. A few years ago, the performance of > Bugzilla improved greatly, but I never felt like exploring where the > boundaries are. Updating all matching bugs in one transaction is still > probably going to result in timeouts, but smaller chunks should work > well enough. If Bugzilla is engineered *at all* sanely, it should be much less work for it to process a single request to do the same thing to 500 bugs than it is to process 500 individual requests to do the same thing to a single bug. There probably *is* a limit on the number of bugs you can request changes to at once, but it should be simple enough to find out what that ceiling is and work in batches below it. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 37 is EOL
On Mon, 2024-01-08 at 18:10 +0100, Vít Ondruch wrote: > Dne 08. 01. 24 v 13:00 Sandro napsal(a): > > On 05-12-2023 18:45, Tomas Hrcka wrote: > > > Fedora Linux 37 has gone end of life for updates and support on > > > 2023-12-05. > > > No more updates of any kind, including security updates or security > > > announcements, will be available for Fedora Linux 37 after the said > > > date. All the updates of Fedora Linux 37 being pushed to stable will be > > > stopped as well. > > > > > > As part of the EOL tasks all bugs open for F37 receive an EOL notice, > > first, and sometime later they will change status to CLOSED | EOL, > > unless the version is changed. > > > > It seems the first step (notification) happened, but the second step > > (closing) has not completed. IIRC, I saw some bugs being closed, but I > > also see a lot of F37 bugs still open [1]. > > > > Is that an oversight or did something go wrong during the procedure? I > > cc'ed Aoife, who appears to have run the first step. I'm happy to open > > a ticket if required. > > > There also used to be Rawhide bugs reassigned to latest stable Fedora, I > might have missed something, but I don't think that has happened. I don't think that's quite right. What happens is that Rawhide bugs get moved to the *new branched* (not stable) release, and naturally, this happens at branch time, which hasn't happened for F40 yet. https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/branch/ -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 37 is EOL
On Mon, 2024-01-08 at 16:10 +, Aoife Moloney wrote: > I'll get the EOL-close script running again, it kept timing out so I > thought it was finished but clearly not - my mistake and apologies :-/ Just so folks are aware, the EOL closure uses a script: https://pagure.io/fedora-pgm/pgm_scripts/blob/main/f/closebugs/fedora_bz.py which runs bug-by-bug - so it comments on, or closes, one bug at a time. This means it takes a very long time to do the ~2-3k bugs that are typically commented-on then closed at EOL time. Doing it this way was Ben's preference (he wanted to be able to see that every bug was updated and get a notice from the script for any single bug change that failed), but if it causes problems for Aoife we can have it mass-update bugs instead, since Bugzilla and its API allow that (now, they probably didn't when the predecessors to this script were written). I'll just have to check with the BZ admin whether there's any upper limit on how many bugs you can request a mass change to at once. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2024-01-08 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2024-01-08 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org Greetings testers! It's time for the first QA meeting of 2024! Using Matrix went fine last time, so we'll do it again this time. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in 3. Communications overhaul: Discourse? 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Error updating libvirt-dbus in F38
On 2024-01-04 00:20, Peter Boy wrote:
Just started to update one of our Fedora Servers (F38)
I got the message:
Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
Cleaning up : libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
/var/tmp/rpm-tmp.BXEIBt: Zeile 1: fg: No Job control in this shell.
Warning: %postun(libvirt-dbus-1.4.1-1.fc38.x86_64) Scriptlet failed,
Exit-status 1
Error in POSTUN scriptlet in rpm package libvirt-dbus
Cleaning up: libacl-2.3.1-6.fc38.x86_64 125/132
Warning or error, what is it?
Both. It's an error in the scriptlet. As far as dnf/rpm is concerned,
scriptlet errors are warnings (it warns you about them, but continues,
as failing the entire transaction on them is unlikely ever to be a
better choice).
Can I be sure that a reboot will be successful?
Nope. This is a fundamental issue with packages in general: package
scriptlets are just...entirely arbitrary code running as root on your
system. What does a scriptlet do? Nobody but the packager can say with
much confidence. How bad is it if it fails? Again, impossible to say
except on a case-by-case investigation basis.
My experiences with reports of this kind are quite mixed. From problem-free
reboots to total failure, everything is possible. Unfortunately, reports of
this kind do not exactly boost confidence in the reliability and usability of
our Fedora.
We should improve this and make reports of problems clearer.
It's fundamentally difficult to do so in the context of RPM packages.
All the package system can know is "the scriptlet of this package failed".
Looking into this specific case, it looks like the 1.4.1-1 package
%postun tries to do:
%systemd_postun_with_reload %{name}.service
but that macro doesn't seem to exist on F38, AFAICT. It exists on
Rawhide, but not F38.
The 1.4.1-2 package changes this to:
%systemd_postun_with_restart %{name}.service
which *does* exist on F38, so it should work. Ironically, you see the
bug in the 1.4.1-1 package when you upgrade to 1.4.1-2, as the %postun
of 1.4.1-1 runs when it's being removed to install 1.4.1-2.
This particular case shouldn't cause any real problems, since the macro
does nothing on upgrade anyway (only on package removal), and the
scriptlet did not want to do anything after that.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Erlang 26 broke rabbitmq
Lately I'm working on the Bodhi development environment, and I reached
a point where I noticed rabbitmq was not working inside my current,
Fedora 39-based version of it.
This appears to be because rabbitmq 3.11 simply does not work with
Erlang 26. Fedora 39 has erlang 26 and rabbitmq 3.11. See:
https://stackoverflow.com/a/76286720
I notice there were "Self-Contained" changes proposed for Erlang 24 and
25, but no Change was proposed for Erlang 26. Those changes probably
shouldn't have been listed as "self-contained", but as usual, the
"self-contained" vs. "system-wide" distinction is a vague and
unsatisfactory one. Those Changes did correctly consider the impact of
Erlang major version updates on its dependencies, e.g. from the 24
Change:
** Upgrade outdated packages:
*** {{package|riak|Riak}}
{{package|riak|Riak}} has has been retired. We have to re-add it
back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
** {{package|erlang-rebar3|rebar3}}
*** Provide/adjust RPM macros for rebar3.
and from the 25 Change:
** Upgrade outdated packages:
*** {{package|riak|Riak}}
{{package|riak|Riak}} has has been retired. We have to re-add it
back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
{{package|riak|CouchDB}} has has been retired. We have to re-add
it back.
** {{package|erlang-rebar3|rebar3}}
However, no Change seems to have been proposed for Erlang 26, and
nobody seems to have considered the impact on dependent packages, at
least judging from the lack of any handling of rabbitmq.
Can we please avoid this circumstance in future by again using the
Change process and considering dependencies for any future major Erlang
bump? Thanks. It looks like we will need to update rabbitmq to 3.12 for
it to stand any chance of working in 39 or Rawhide. I will see if
that's a straightforward change next, and try to send a PR if so.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-12-11 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-12-11 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org Greetings testers! It's time for the last QA meeting of the year! We're going to try moving back to Fedora Chat (Matrix) for this meeting, as the bot should be working there now. Remember, the IRC bridge is out of commission, so you'll really have to be on Matrix to join the meeting. You can log in with your Fedora account. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in 3. Communications overhaul: Discourse and Matrix? 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Should we retire the mailx package?
On Fri, 2023-12-08 at 10:38 -0800, Kevin Fenzi wrote: > I'm definitely in favor. I hit this broken step a while back myself. ;( > > Hopefully the current maintainers are on board with this? Yeah, honestly, I'm not sure a Change is the right way to go about this, it seems like it could just be handled between maintainers. nforro - who maintains mailx - has not committed to it for two years, but is very active on other packages (adding him to CC). If he is OK with the change, I would think you could just go ahead and do it (have nforro retire mailx) without needing to go through the Change process. If you file a Change, I think all that will happen is that a lot more bureaucracy will happen before somebody says "hey, we'd better ask nforro about this" anyway. :D -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: goal: booting with an empty /etc
On Fri, 2023-12-08 at 11:49 -0500, Steve Grubb wrote: > On Friday, December 8, 2023 11:23:29 AM EST Zbigniew Jędrzejewski-Szmek > wrote: > > But yeah, there'll always be a few "special" files. But that's fine, > > we have mechanisms to handle those. For the other 99%, we should > > move them out of /etc. > > The problem is that there would need to be a standard that all upstream > authors agree on. There are some like systemd which have a [SECTION_NAME] > followed by config items. Others do not make sections. What if the config is > in > yaml, json, or XML? How can you see the end result? We would need to have a > standard library that everyone can use. From that, we need a utility to > compile the actual configuration that would be consumed by the service so we > can inspect it during troubleshooting. Eh? What does the format of the files have to do with where they live? I don't see any reason we can have heterodox config file formats in /etc, but not in /usr. (Indeed, practically speaking, we already have lots of different formats in both places). -- 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: [HEADS UP] Jasper update with .so name update
On Tue, 2023-11-21 at 10:55 +0100, Josef Řídký wrote: > Hi, > > there is a new jasper version (4.1.0) that will be available in Fedora 40+. > As this version is bumping it's .so name, the rebuild of the dependent > package will be necessary. > > There is a side tag created for safe rebuild of those packages > (f40-build-side-77302) with a new jasper version available. > > I would like to ask maintainers of affected packages to rebuild their > packages using this tag, so I will be able to push the update to f40 once > all is done. > > List of affected packages is: > - eccodes-devel > - g2clib-devel > - grib_api-devel Somehow your list is far too short: [adamw@xps13a tmp]$ sudo dnf repoquery --whatrequires "libjasper.so.6()(64bit)" DevIL-0:1.7.8-42.fc39.x86_64 DevIL-ILUT-0:1.7.8-42.fc39.x86_64 GraphicsMagick-0:1.3.40-3.fc39.x86_64 LibRaw-0:0.21.1-6.fc40.x86_64 OpenSceneGraph-libs-0:3.6.5-19.fc40.x86_64 dcraw-0:9.28.0-20.fc39.x86_64 digikam-libs-0:8.1.0-3.fc39.x86_64 eccodes-0:2.32.1-1.fc40.x86_64 gegl04-0:0.4.46-1.fc40.x86_64 grib_api-0:1.27.0-19.fc39.x86_64 jasper-0:3.0.6-4.fc39.x86_64 jasper-devel-0:3.0.6-4.fc39.x86_64 jasper-utils-0:3.0.6-4.fc39.x86_64 kdelibs-6:4.14.38-40.fc40.x86_64 kdelibs3-0:3.5.10-123.fc40.x86_64 libicns-0:0.8.1-27.fc39.x86_64 ncl-0:6.6.2-38.fc40.x86_64 netpbm-progs-0:11.02.00-2.fc39.x86_64 qt5-qtimageformats-0:5.15.11-1.fc40.x86_64 qt6-qtimageformats-0:6.6.0-1.fc40.x86_64 wgrib2-0:3.1.3-1.fc40.x86_64 the update failed gating because of qt5-qtimageformats, but all the others also ought to be rebuilt onto the side tag before this is pushed. -- 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: Possible deprecation/removal of Initial Setup from Fedora
On Mon, 2023-11-27 at 14:12 +0100, mkol...@redhat.com wrote: > On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote: > > On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote: > > > Hello everyone, > > > > > > Is Anaconda Initial Setup important for your project or workflow? > > > What > > > functionality is absolutely necessary for you? Do you use the text > > > mode > > > or the graphical mode? Are you aware of any alternatives? Is there > > > anything that would prevent you from migrating to one of the > > > proposed > > > alternatives? Also please feel free to share this mail to any > > > relevant > > > groups. > > > > In addition to the other uses identified: if you do a KDE install and > > set the root password but do not create a user account, i-s will run > > on > > first boot and allow (not sure if it requires) user creation. This is > > probably the case for other non-GNOME desktops too (GNOME uses its > > own > > gnome-initial-setup). > Sure, but is this really necessary on those images ? If it only > triggers if no user account is present only only provides user > creation, what about enforcing user creation at installation time > instead ? > > That would simplify the whole thing, as there would be less scenarios > to test/debug/go wrong. The problem, as always, is different use cases. We want to very strongly encourage people to create a user before logging in on KDE installs, as we really don't want people using KDE as root. But for a small headless install, someone might want to operate as root without a user account. Workstation has sorted this out by disabling user/root spokes in the installer entirely and having its own g-i-s which requires creation of an admin user, but we don't have anything like that in place for KDE currently. So we have to try and manage both KDE and e.g. a minimal or Server install as best we can, using essentially the same workflows. If someone wants to do some customization for KDE, of course, that could help. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-11-27 @ ** 16:00 ** UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-11-27 # Time: ** 16:00 ** UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: ** #fedora-meeting on irc.libera.chat ** Greetings testers! It's time for another QA meeting. Note clocks have changed everywhere they change, by now. If you follow daylight savings time, the meeting should be at the same local time as usual. If you do not follow daylight savings time, the meeting will be one hour later than it was over the summer, in your local time. You can run `date -u` to see the current UTC time if you are unsure. As usual lately, please note this meeting will really be *on IRC*. Matrix may be ready for meeting purposes pretty soon, but I need to check on that before moving the meeting. So please use an IRC client or the web client - https://web.libera.chat/#fedora-meeting - to join. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. Note I have a partial conflict for the second half hour of the meeting slot, so might have to cut the meeting short or let someone take over. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in and Change review 3. Communications overhaul: Discourse and Matrix? 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How can I delete a rawhide Bodhi update?
On Fri, 2023-11-24 at 09:51 +, Mattia Verga via devel wrote: > I must say this is really a rare case when an automatic update which is > gated by failing tests and stuck in testing It's really not *that* rare any more, since we do quite extensive gating of critical path updates on openQA tests. I'd estimate about one update every two or three days fails tests for legit reasons. -- 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: Possible deprecation/removal of Initial Setup from Fedora
On Fri, 2023-11-24 at 13:38 +0100, Jiri Konecny wrote: > Hi, > > I wonder, I thought that the server images are usually using Anaconda to > create a user during installation. Am I missing something? No, I think you're right there. initial-setup is not part of the anaconda-deployed Server package set. anaconda - as it does for all other spins/editions except Workstation - requires you to create a root password or admin user, so you can always log in. I think if initial-setup was included in the package set, it would run on boot if you didn't *both* set the root password *and* create a user (as it does on spins where it is installed, e.g. KDE), but it isn't. I tested this with a Server DVD image I had lying around; doing an install with only root password (no user created) didn't run initial- setup on boot, and rpm shows initial-setup not installed. However, as dgilmore noted, the Server ARM disk images certainly do rely on initial-setup. > > Best Regards, > Jirka > > Dne 22. 11. 23 v 13:53 Gerd Hoffmann napsal(a): > > On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote: > > > On 2023-11-21 04:34, Jiri Konecny wrote: > > > > Is Anaconda Initial Setup important for your project or workflow? What > > > > functionality is absolutely necessary for you? Do you use the text > > > > mode or the graphical mode? Are you aware of any alternatives? Is > > > > there anything that would prevent you from migrating to one of the > > > > proposed alternatives? Also please feel free to share this mail to any > > > > relevant groups. > > > The Fedora Asahi Remix uses initial-setup (in text mode) for our Server > > > and > > > Minimal variants. > > I think this is used by *all* server images. It offers to set the root > > password and add users, so without that you simply can't login ... > > > > take care, > >Gerd > > -- > > ___ > > 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 > -- > ___ > 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 -- 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: Possible deprecation/removal of Initial Setup from Fedora
On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote: > Hello everyone, > > Is Anaconda Initial Setup important for your project or workflow? What > functionality is absolutely necessary for you? Do you use the text mode > or the graphical mode? Are you aware of any alternatives? Is there > anything that would prevent you from migrating to one of the proposed > alternatives? Also please feel free to share this mail to any relevant > groups. In addition to the other uses identified: if you do a KDE install and set the root password but do not create a user account, i-s will run on first boot and allow (not sure if it requires) user creation. This is probably the case for other non-GNOME desktops too (GNOME uses its own gnome-initial-setup). openQA tests this: https://openqa.fedoraproject.org/tests/2280185#step/_graphical_wait_login/1 -- 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: How can I delete a rawhide Bodhi update?
On Thu, 2023-11-23 at 20:40 +0100, Florian Weimer wrote: > * Mattia Verga via devel: > > > Il 23/11/23 16:40, Florian Weimer ha scritto: > > > I've got an update that I don't see pushed to stable. How do I make > > > sure that doesn't happen? > > > > > > As it's for rawhide, I didn't create the Bodhi update, and I don't see > > > an option to delete it. > > > > > There's no option to delete Bodhi updates. It can only be done by > > hacking the database directly, but it is usually never necessary. > > > > I assume you're referring to > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-13783978e8. That > > update will never be pushed to stable, since it is gated by failed > > tests. > > Half a dozen people can waive those tests, and there have been incorrect > waivers before. 8-/ > > I just want to make sure the update doesn't proceed because I'm not > entirely confident that the fix I have is logically correct. If we can get two more people to -1 it, Bodhi should obsolete/unpush it in response to that karma. As Mattia said, it's intentional that there's no option to *delete* an update. We don't want history to disappear. But it does seem like there's a workflow problem here. It would be useful for maintainers to have the ability to put an update in a state from which it cannot be pushed stable by karma or autopush (only by the maintainer or a provenpackager changing the state again). For regular release updates the maintainer can at least "unpush" them, though I'm not sure this fully achieves the goal. For Rawhide updates it looks like you can't even do that, which is awkward. I'd say it's probably worth filing a Bodhi issue for 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: Groff: Revert the mapping of special characters for UTF-8 devices introduced in 1.23.0 version
On Thu, 2023-11-16 at 23:41 +0100, Lukas Javorsky wrote: > > > > I think an upstream only wants to adhere to the language specification > > (groff_char(7)). These small differences became prominent with the advent > > of > > UTF-8 capable terminals. They have always been visible in a PostScript > > output. > > > > Imagine you are the upstream and a user sends you a bug report that groff > > does > > not behave according to the specification. While another user complains > > that > > his nonconforming input behaves weirdly. There is no solution which would > > satisfy both. > > > > I totally understand why they made the change, I just don't see the reason > for requesting them to put the mapping back. > > I think the right decision would be that upstreams of the packages that > have the man pages written with the wrong character, should be the ones to > fix their man pages. But they *don't* have their man pages written with the "wrong character". That's one reason why this is awkward and controversial. The man pages are written with the *right* character - an ASCII dash, the character that is actually used for arguments to console commands. groff is converting this to a Unicode dash based on the expectation that it's being used for something more "text-y", and the writer just used an ASCII dash because it's much more convenient to type, but they really want a more text-ish dash. This may be the case for a lot of text, but it's definitely not the case for CLI tool manpages. When they write an ASCII dash, they want it to stay as an ASCII dash. With the 'new' behaviour, you have to markup or escape your ASCII dashes somehow to prevent groff turning them into unicode dashes. -- 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: dnf conflict in rawhide Docker container in GitHub Action
On Mon, 2023-11-13 at 19:28 +0100, Thomas Haller wrote: > On Thu, 2023-08-10 at 12:37 -0700, Adam Williamson wrote: > > On Thu, 2023-08-10 at 19:07 +, Chris Kelley wrote: > > > Hello all, > > > > > > I have a GitHub Action > > > (https://github.com/dogtagpki/jss/actions/runs/5810230552/job/15794 > > > 978022) that fails due to a conflict between dnf and dnf5 when > > > using the rawhide docker image. I have been trying to keep up with > > > the dnf/dnf5 revert story, but I may have missed something about > > > the current state of affairs/expectations around it working without > > > issue. I am not sure to whom I should raise this issue, any > > > suggestions welcome - thanks! > > > > Not sure what the specific issue is here, but in general, we > > recommend > > against pulling from the Docker registry, as it is not updated very > > often. It's much better to pull from registry.fedoraproject.org or > > quay.io , as those are updated with every Rawhide compose. > > > Hi, > > It seems that https://registry.fedoraproject.org/repo/fedora/tags/ is > quite outdated (contrary to https://hub.docker.com/_/fedora ). > > This is quite bad, if I run > > podman run -ti fedora:39 > > it will get the image from registry.fedoraproject.org (due to > /etc/containers/registries.conf). The problem is, that this image is > from August and still points to Rawhide. So the first `dnf upgrade` > installs fc40 packages, which results in a broken installation. > > Workaround: > > podman run -ti docker.io/fedora:39 > > Is this a known issue? Am I doing something wrong? Where would I report > this? Neither I nor nirik can reproduce this as described. Note the web UI is basically just lies / incomplete info; I think it's telling you when the tag was created, not when the image behind it was last updated. This is what I get trying to reproduce: [adamw@xps13a Oneplus 9]$ podman run -ti fedora:39 Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf) Trying to pull registry.fedoraproject.org/fedora:39... Getting image source signatures Copying blob 6eb636413202 done | Copying config ec546109f8 done | Writing manifest to image destination [root@ee928f4eb27a /]# dnf update Fedora 39 - x86_64 31 MB/s | 89 MB 00:02 Fedora 39 openh264 (From Cisco) - x86_64 1.2 kB/s | 2.5 kB 00:02 Fedora 39 - x86_64 - Updates 393 kB/s | 12 MB 00:32 Last metadata expiration check: 0:00:01 ago on Mon Nov 13 19:00:36 2023. Dependencies resolved. = PackageArchitecture Version Repository Size = Upgrading: dnfnoarch 4.18.1-1.fc39 updates 508 k dnf-data noarch 4.18.1-1.fc39 updates 39 k elfutils-default-yama-scopenoarch 0.190-1.fc39 updates 14 k elfutils-libelfx86_64 0.190-1.fc39 updates 195 k elfutils-libs x86_64 0.190-1.fc39 updates 260 k gnupg2 x86_64 2.4.3-4.fc39 updates 2.6 M python3-dnf
[Test-Announce] 2023-11-13 @ ** 16:00 ** UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-11-13 # Time: ** 16:00 ** UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: ** #fedora-meeting on irc.libera.chat ** Greetings testers! It's time for another QA meeting. Note clocks have changed in North America, so the meeting time in UTC has also changed, as usual. If you follow daylight savings time and have already set your clock back, the meeting will be at the same local time as before. If you do not follow daylight savings time or have not yet set your clocks back, the meeting will be one hour later than before in your local time. You can run `date -u` to see the current UTC time if you are unsure. As usual lately, please note this meeting will really be *on IRC*. Matrix may be ready for meeting purposes pretty soon, but I need to check on that before moving the meeting. So please use an IRC client or the web client - https://web.libera.chat/#fedora-meeting - to join. 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 39 and Fedora 40 check-ins 3. Communications overhaul: Discourse and Matrix? 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Automatic check for bodhi updates not to break RPM dependencies
On Tue, 2023-11-07 at 15:20 +0100, Miro Hrončok wrote: > On 07. 11. 23 12:17, Sandro Mani wrote: > > Hi > > > > Due to an unfortunate oversight of an incorrect branch merge a couple of > > months > > ago, a recently backported security fix caused an unwanted gdal soname bump > > in > > F37, due to an update from the 3.5.x series to the 3.6.x series. > > > > I'm preparing a gdal-3.6.2-8.really3.5.3.fc37 to address this, please don't > > rebuild any dependencies in the meantime, as the new package will bring > > back > > the previous soname. > > > > Apologies for the troubles. > > Hello, > > this is not the first time I saw a bodhi update that breaks dozens of > dependencies, goes unnoticed for a week and is automatically pushed stable, > only to discover many packages fail to install. > > How come we don't have an automatic check for this? What can be done? This task (which we tend to call "reverse dependency checking") is actually one of the more difficult things to implement reliably, and has been ever since the AutoQA / taskotron days. Fedora CI does have the rpmdeplint test, which I believe attempts to do this: https://pagure.io/rpmdeplint/blob/master/f/rpmdeplint/__init__.py#_227 but it seems to only run that test on Rawhide: https://github.com/fedora-ci/rpmdeplint-trigger/blob/master/Jenkinsfile#L30 I am honestly not sure why. Additionally, Fedora CI triggering always (AIUI) runs tests in the context of a *package* not an *update*, which means it will produce quite a few 'false failures' in the case where the rebuilt dependencies are in fact bundled in an update with the bumped library. Additionally, rpmdeplint often 'false fails' for other reasons (commonly internal package conflicts which aren't really a big problem), and so it cannot be set as a gating test at present even on Rawhide. openQA will catch cases like this only when the update is a critical path one (so openQA actually tests it) and the broken dependency is in a package that's within the scope of one of openQA's tests. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Automatic check for bodhi updates not to break RPM dependencies
On Tue, 2023-11-07 at 15:20 +0100, Miro Hrončok wrote: > On 07. 11. 23 12:17, Sandro Mani wrote: > > Hi > > > > Due to an unfortunate oversight of an incorrect branch merge a couple of > > months > > ago, a recently backported security fix caused an unwanted gdal soname bump > > in > > F37, due to an update from the 3.5.x series to the 3.6.x series. > > > > I'm preparing a gdal-3.6.2-8.really3.5.3.fc37 to address this, please don't > > rebuild any dependencies in the meantime, as the new package will bring > > back > > the previous soname. > > > > Apologies for the troubles. > > Hello, > > this is not the first time I saw a bodhi update that breaks dozens of > dependencies, goes unnoticed for a week and is automatically pushed stable, > only to discover many packages fail to install. > > How come we don't have an automatic check for this? What can be done? This task (which we tend to call "reverse dependency checking") is actually one of the more difficult things to implement reliably, and has been ever since the AutoQA / taskotron days. Fedora CI does have the rpmdeplint test, which I believe attempts to do this: https://pagure.io/rpmdeplint/blob/master/f/rpmdeplint/__init__.py#_227 but it seems to only run that test on Rawhide: https://github.com/fedora-ci/rpmdeplint-trigger/blob/master/Jenkinsfile#L30 I am honestly not sure why. Additionally, Fedora CI triggering always (AIUI) runs tests in the context of a *package* not an *update*, which means it will produce quite a few 'false failures' in the case where the rebuilt dependencies are in fact bundled in an update with the bumped library. Additionally, rpmdeplint often 'false fails' for other reasons (commonly internal package conflicts which aren't really a big problem), and so it cannot be set as a gating test at present even on Rawhide. openQA will catch cases like this only when the update is a critical path one (so openQA actually tests it) and the broken dependency is in a package that's within the scope of one of openQA's tests. -- 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
PSA: Rawhide Server (and other xfs) installs broken
Hey folks! Just a heads up that Rawhide Server installs are broken in today's Rawhide compose (and any custom install using xfs). This is because a new version of xfsprogs went into Rawhide and grub2 cannot detect filesystems made with it: https://bugzilla.redhat.com/show_bug.cgi?id=2247926 I've identified the patches needed in grub2, but I can't patch it myself as I'm not on the list of people who can build packages that need to be Secure Boot signed, and anyway, working on the grub2 package is a bit of a nightmare for non-maintainers due to the whole "hundreds of patches that are pulled from an alternative upstream git repo" thing. I've requested xfsprogs be untagged for now: https://pagure.io/releng/issue/11763 so if that gets done, things should work again after the next compose. Unfortunately openQA didn't catch this because we don't test xfs installs on updates :( Maybe I'll have to add a test somehow. -- 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
Fedora Linux 39 Final Go/No-Go meeting tomorrow (Thursday)
The Fedora Linux 39 Final Go/No-Go[1] meeting is scheduled for Thursday 2 November at 1700 UTC in #fedora-meeting (on IRC, not Matrix). At this time, we will determine the status of F39 Final for the 7 November target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10627/?from_date=2023-10-30 [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora Linux 39 Final Go/No-Go meeting tomorrow (Thursday)
The Fedora Linux 39 Final Go/No-Go[1] meeting is scheduled for Thursday 2 November at 1700 UTC in #fedora-meeting (on IRC, not Matrix). At this time, we will determine the status of F39 Final for the 7 November target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10627/?from_date=2023-10-30 [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- 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] 2023-10-30 @ 16:00 UTC - Fedora 39 Blocker Review Meeting
# F39 Blocker Review meeting # Date: 2023-10-30 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.libera.chat (*NOT* Matrix) Hi folks! Currently there are two proposed Final freeze exception issues to review, so let's have a meeting on Monday (where we can also check on the state of accepted blockers). The meeting will on IRC only due to the ongoing lack of a Matrix <-> IRC bridge and a meeting bot on the Matrix side. If you no longer have an IRC setup you can join via webIRC: https://web.libera.chat/ , enter a nickname and put #fedora-blocker-review in the Channel box. 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 F39 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 39 Final is NO-GO (#3)
Due to outstanding blocker bugs[1], F39 Final RC-1.2 was declared NO-GO in today's Go/No-GO meeting[2]. The next Fedora Linux 39 Final Go/No-Go meeting[3] will be held at 1700 UTC on Thursday 2 November in #fedora-meeting. We will aim for the "target date #3" milestone of 7 November. The release schedule[4] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist [2] https://meetbot-raw.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_no_go-meeting.2023-10-26-17.00.html [3] https://calendar.fedoraproject.org/meeting/10627/?from_date=2023-10-30 [4] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora Linux 39 Final is NO-GO (#3)
Due to outstanding blocker bugs[1], F39 Final RC-1.2 was declared NO-GO in today's Go/No-GO meeting[2]. The next Fedora Linux 39 Final Go/No-Go meeting[3] will be held at 1700 UTC on Thursday 2 November in #fedora-meeting. We will aim for the "target date #3" milestone of 7 November. The release schedule[4] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist [2] https://meetbot-raw.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_no_go-meeting.2023-10-26-17.00.html [3] https://calendar.fedoraproject.org/meeting/10627/?from_date=2023-10-30 [4] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html -- 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
Fedora Linux 39 Final Go/No-Go meeting tomorrow (Thursday)
The Fedora Linux 39 Final Go/No-Go[1] meeting is scheduled for Thursday 26 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F39 Final for the 31 October target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10627/ [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 candidate composes coming - here's the plan
On Wed, 2023-10-25 at 11:23 -0700, Adam Williamson wrote: > Hey folks! Just to keep everyone in the loop regarding F39 plans. > > As you may have noticed, we've slipped once or twice already (depending > on whether you count the "early target date") and are in danger of > slipping again. The go/no-go meeting is scheduled for tomorrow (2023- > 10-26). The outstanding blockers are all Raspberry Pi-related, aside > from the shim one we've been waiving for several releases and intend to > waive again. > > Matthew Miller, Kevin Fenzi and I came up with this plan: we're going > to run a compose right now without fixes for the two outstanding Pi > blockers (2241252 and 2244305). If QA can get sufficient testing on > this done by the go/no-go meeting, we can discuss the possibility of > shipping it and noting that there are known issues with Raspberry Pi > that are taking time to resolve, and Pi users should not install or > upgrade to F39 until they're resolved (or something like that). > > If at any point a fix for 2241252 shows up, we'll run another compose > with the fix included. If that gets sufficient testing by the time of > the meeting, we can also consider that as a candidate to ship. If ARM > team decide to attempt a fix for 2244305 we'd also pull that in, but if > not, we think it's reasonable to consider revoting or waiving that bug, > as it seems not to happen very commonly or consistently and the > proposed "fix" apparently comes with tradeoffs of some kind. > > So, QA folks, please stand ready to test one or two candidate composes > soon. If we wind up with two, we will consider most test results to > apply to both, as the only difference should be uboot-tools; we would > want to run ARM hardware tests, at least, on both composes if possible. > The usual announcement mails will be sent for the completed composes. > > Thanks folks! Update on this: the first candidate without Pi fixes is done and currently available for testing - see https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.1_Summary . The second candidate is running, when it is done, https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.2_Summary will be live. Most tests of either candidate will be valid for both, but we especially would like testing of the second candidate (when it's done) on ARM hardware - obviously on Raspberry Pi, but also on any other ARM hardware folks have lying around. We ended up having to revert uboot- tools to an older version to try and address the Pi issues, so we need to check that hasn't broken anything else important. If you run into problems, please file a bug, propose it as a release blocker, and maybe reply here just to be sure :) 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
[Test-Announce] Fedora Linux 39 Final Go/No-Go meeting tomorrow (Thursday)
The Fedora Linux 39 Final Go/No-Go[1] meeting is scheduled for Thursday 26 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F39 Final for the 31 October target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10627/ [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- 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-arm] Re: Fedora Linux 39 Final blocker status summary #3
On Wed, 2023-10-25 at 20:51 -0400, Jeffrey Walton wrote: > On Wed, Oct 25, 2023 at 7:33 PM Adam Williamson > wrote: > > > > On Wed, 2023-10-25 at 22:02 +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Fri, Oct 20, 2023 at 04:55:57PM -0700, Adam Williamson wrote: > > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at > > > > all to come up with a genius fix, otherwise we'll likely have to > > > > document this > > > > > > Happy to oblige ;--] > > > > Genius located! Thanks, Zbigniew :) > > Be careful of this solution. Time functions were formerly returning an > error until the RTC was set to an accurate time. The new behavior is > to return a fake/incorrect time without an error. I don't think it's a > good idea to misreport something time system wide without error. > > You might want to consider other ways to get beyond signature checks > that are less intrusive, and not system wide. There isn't any new behaviour. We're just doing a new systemd build for F38 so the already-existing behaviour (set the clock to the time the package was built) will give a later time than previously. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Wed, 2023-10-25 at 22:02 +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 20, 2023 at 04:55:57PM -0700, Adam Williamson wrote: > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at > > all to come up with a genius fix, otherwise we'll likely have to > > document this > > Happy to oblige ;--] Genius located! Thanks, Zbigniew :) -- 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: F39 candidate composes coming - here's the plan
On Wed, 2023-10-25 at 20:46 +, Leslie Satenstein via devel wrote: > Hi Adam, are bugs related to Fedora gnome that I posted on the forum ignored? > I and a few others have smaller / older graphics cards. They are new enough > to work with the USB type cable. > On all my Fedora versions, (38-40), Wayland gnome, beginning around 5 > October, 2023, began locking up. > Bugzilla 2241955. > FYI, All three Fedora versions (38,39,40), prior to that date worked 100% > with Wayland.Since that date, only the x11 versions work. (I am unable to > test Rawhide 40, as it is Wayland only. I would like to see a comment in the > 2241955 that it will be handled during the second week following F39 go live. It's not being ignored, no. There are two GNOME developers trying to help you, but your reports are quite confusing and lacking in detail. It would help a lot if you could just describe in plain language - without your interpretations - exactly what you're trying and what the results are, on different kernel versions. At present I don't see any particular reason the bug should block the release, as it seems like only a few people are affected by the issue. Possibly it's specific to the NVIDIA 9800 GT graphics card, at least that's the best impression I can get from your posts. -- 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
F39 candidate composes coming - here's the plan
Hey folks! Just to keep everyone in the loop regarding F39 plans. As you may have noticed, we've slipped once or twice already (depending on whether you count the "early target date") and are in danger of slipping again. The go/no-go meeting is scheduled for tomorrow (2023- 10-26). The outstanding blockers are all Raspberry Pi-related, aside from the shim one we've been waiving for several releases and intend to waive again. Matthew Miller, Kevin Fenzi and I came up with this plan: we're going to run a compose right now without fixes for the two outstanding Pi blockers (2241252 and 2244305). If QA can get sufficient testing on this done by the go/no-go meeting, we can discuss the possibility of shipping it and noting that there are known issues with Raspberry Pi that are taking time to resolve, and Pi users should not install or upgrade to F39 until they're resolved (or something like that). If at any point a fix for 2241252 shows up, we'll run another compose with the fix included. If that gets sufficient testing by the time of the meeting, we can also consider that as a candidate to ship. If ARM team decide to attempt a fix for 2244305 we'd also pull that in, but if not, we think it's reasonable to consider revoting or waiving that bug, as it seems not to happen very commonly or consistently and the proposed "fix" apparently comes with tradeoffs of some kind. So, QA folks, please stand ready to test one or two candidate composes soon. If we wind up with two, we will consider most test results to apply to both, as the only difference should be uboot-tools; we would want to run ARM hardware tests, at least, on both composes if possible. The usual announcement mails will be sent for the completed composes. Thanks folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FEDORA-2023-ed0c57b4ba — unspecified update for libtirpc — Fedora Updates System
On Wed, 2023-10-25 at 12:03 -0400, Steve Dickson wrote: > Hello, > > This update failed [1] due to a system timeout [2] > not a test failure... Is there some way to override > or wave the failure. Failed tests are automatically retried one time. However, for...reasons[0]...this isn't shown immediately in Bodhi; the test will remain showing as 'failed' until the rerun completes (at which point the result will become whatever the rerun's result was). You can see the actual current status of testing on your update at https://openqa.fedoraproject.org/tests/overview?build=Update-FEDORA-2023-ed0c57b4ba=38=fedora=2 - all tests are either green (passed) or blue (running) currently. In general I monitor all openQA update test results and don't let flakey results stand - if a test flakes twice in a row I will restart it manually. Please check with me before waiving openQA results as it can have problematic consequences if the problem *does* reproduce for subsequent updates. [0] https://progress.opensuse.org/issues/123625 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-10-23 @ 16:00 UTC - Fedora 39 Blocker Review Meeting
# F39 Blocker Review meeting # Date: 2023-10-23 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.libera.chat (*NOT* Matrix) Hi folks! Currently there are no proposed blockers or FEs, but let's schedule a meeting on Monday just in case some show up today. If not, we can just quickly review the accepted blocker status and wind up. The meeting will on IRC only due to the ongoing lack of a Matrix <-> IRC bridge and a meeting bot on the Matrix side. If you no longer have an IRC setup you can join via webIRC: https://web.libera.chat/ , enter a nickname and put #fedora-blocker-review in the Channel box. If you have time today 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 F39 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > Once upon a time, Adam Williamson said: > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > > dates gpg key > > > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > > if push comes to shove, we'll wind up revoting or waiving it as not > > > practically fixable. > > > > Not adding to the ticket (because "me too" is not useful there), but... > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > systems with no RTC (make a systemd service depend on /dev/rtc not > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > a number of the small boards have no RTC. I do typically add an RTC to > > my Pis, but not always (for various reasons). > > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. There are several ways we could certainly address the bug going forward. Say, starting with a Fedora 40 Change. But it seems less clear how we could safely fix it for upgrades from F37 or F38 to F39, without pushing a level of change that is inappropriate for a stable 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
Fedora Linux 39 Final blocker status summary #3
Hi folks! We're still trying to get F39 done, so time for another status update... Action summary == Accepted blockers - 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED: releng to push the fix stable 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop team (and adamwill) to keep trying to come up with a fix 3. shim - https://bugzilla.redhat.com/2113005 - NEW: assume this will be waived 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM team (pbrobinson) to fix it 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED: ARM team to evaluate and fix if possible, ARM/QA to test on more systems if possible 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at all to come up with a genius fix, otherwise we'll likely have to document this Bug-by-bug detail = Accepted blockers - 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED kdump is enabled by default on desktops This is basically fixed, just waiting to be pushed stable. 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) Well, we kinda had a fix for this, but it turns out to break something even worse (now anaconda isn't visible on the Workstation live image). So we're still stuck trying to find a perfect fix, unfortunately. Desktop team plus me to keep cranking away on it. 3. shim - https://bugzilla.redhat.com/2113005 - NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards Let's just assume this is gonna be waived. 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 Peter says "So we've basically got to the bottom of the problem and worked out the issue, I now just need to come up with a fix.", so that's what we're waiting on. 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED Fedora Server 39 does not boot on Raspberry Pi 4 (RPi4) from microSD card slot This one's also waiting on ARM team (i.e. Peter), but seems somewhat less clear-cut of a blocker, so we're kinda waiting for his take on that, plus testing from other Raspberry Pi owners would be useful. 6. distribution - https://bugzilla.redhat.com/2242759 - NEW dnf system-upgrade fails on some RPi4 due to system boot date that pre- dates gpg key We're still kinda kicking around ideas for "fixing" this, but I think if push comes to shove, we'll wind up revoting or waiving it as not practically fixable. -- 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
Fedora Linux 39 Final is NO-GO (#2)
Due to outstanding blocker bugs[1], we do not have a release candidate for Fedora Linux 39 Final. Today's Go/No-Go meeting is cancelled. The next Fedora Linux 39 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 26 October in #fedora-meeting-1. We will aim for the "target date #2" milestone of 31 October. The release schedule[3] will be updated accordingly soon. [1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist [2] https://calendar.fedoraproject.org/meeting/10627 [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for a volunteer to automate the orphaned packages process
On Thu, 2023-10-19 at 18:43 +0200, Frantisek Zatloukal wrote:
> On Thu, Oct 19, 2023 at 6:24 PM Adam Williamson
> wrote:
>
> > I'm not sure I have time to take this, but glancing over it, I have a
> > suggestion on how to further automate the release stuff.
> >
> > You can use Bodhi release date to determine the extant EPEL releases
> > and the current Branched release. If you query
> > https://bodhi.fedoraproject.org/releases/ with content-type JSON, you
> > get a bunch of data on releases (paginated, so either handle the pages
> > or use https://bodhi.fedoraproject.org/releases/?rows_per_page=500
> > instead).
> >
> > To get all current EPEL releases you'd do something like this:
> >
> > epels = {int(rel['version']) for rel in releases if
> > rel['state'] == 'current' and rel['id_prefix'] ==
> > 'FEDORA-EPEL'}
> >
> > To find current Branched, you can do something like this:
> >
> > devrels = {int(rel['version']) for rel in releases if
> >rel['state'] == 'pending' and rel['id_prefix'] == 'FEDORA'}
> > if len(devrels) > 1:
> > branched = min(devrels)
> > else:
> > branched = None
> >
> > that logic should be safe as long as we don't change the release
> > process. There is always one "pending" Fedora release - Rawhide. If
> > there's more than one, there will be two, and the other one will be
> > Branched.
> >
>
> Or, the "lazier" to implement alternative for this would be
> https://packager-dashboard.fedoraproject.org/api/v1/releases :)
how/where is that data sourced?
if it's from fedfind, it ultimately relies on me manually updating a
JSON file, which isn't awesome. if it's from bodhi, great. :D
fedfind unfortunately can't use bodhi data because of the problem that
releases are marked stable too early in bodhi, but that shouldn't be a
problem for this script's use case.
--
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] Fedora Linux 39 Final is NO-GO (#2)
Due to outstanding blocker bugs[1], we do not have a release candidate for Fedora Linux 39 Final. Today's Go/No-Go meeting is cancelled. The next Fedora Linux 39 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 26 October in #fedora-meeting-1. We will aim for the "target date #2" milestone of 31 October. The release schedule[3] will be updated accordingly soon. [1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist [2] https://calendar.fedoraproject.org/meeting/10627 [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html -- 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 a volunteer to automate the orphaned packages process
On Thu, 2023-10-19 at 11:06 +0200, Miro Hrončok wrote:
> Hello folks,
>
> you might know I run a script that generates
>
> https://churchyard.fedorapeople.org/orphans.txt
> https://churchyard.fedorapeople.org/orphans.json
>
> The script is located at
> https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
>
> I try to monitor the output and whenever it is stuck, I restart it.
>
> Every 2 weeks I try to save a copy of the generated file and send it to the
> devel list, devel announce list and the affected maintainers.
>
> Every branching, the script needs (trivial) changes.
>
> When I see packages orphaned for 6+ weeks, I retire them.
>
>
> I took this task a coupe years back because I was not satisfied with the
> status
> quo at that time (packages orphaned for year+ lingering in the distro).
>
> The task is semi-automated but not fully. After almost 5 years, I think it's
> time to pass this to somebody else. Preferably to somebody who would enjoy
> automating it entirely.
>
> I can provide all the details about the operation if you want to become the
> reaper's apprentice.
>
> Please do let me know. I believe this process is essential for the health of
> Fedora but I'd like to be relieved of this task.
I'm not sure I have time to take this, but glancing over it, I have a
suggestion on how to further automate the release stuff.
You can use Bodhi release date to determine the extant EPEL releases
and the current Branched release. If you query
https://bodhi.fedoraproject.org/releases/ with content-type JSON, you
get a bunch of data on releases (paginated, so either handle the pages
or use https://bodhi.fedoraproject.org/releases/?rows_per_page=500
instead).
To get all current EPEL releases you'd do something like this:
epels = {int(rel['version']) for rel in releases if
rel['state'] == 'current' and rel['id_prefix'] == 'FEDORA-EPEL'}
To find current Branched, you can do something like this:
devrels = {int(rel['version']) for rel in releases if
rel['state'] == 'pending' and rel['id_prefix'] == 'FEDORA'}
if len(devrels) > 1:
branched = min(devrels)
else:
branched = None
that logic should be safe as long as we don't change the release
process. There is always one "pending" Fedora release - Rawhide. If
there's more than one, there will be two, and the other one will be
Branched.
--
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: F40 proposal: Fedora Atomic Desktops (Self-Contained Change proposal)
The discussion thread to provide feedback for this change proposal can be found here: https://discussion.fedoraproject.org/t/f40-change-proposal-fedora-atomic-desktops-self-contained/92893 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-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
F40 proposal: Fedora Atomic Desktops (Self-Contained Change proposal)
update the documentation and figure out a way to share more of the content between those variants. == Release Notes == To be done. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-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: F40 proposal: Fedora Atomic Desktops (Self-Contained Change proposal)
The discussion thread to provide feedback for this change proposal can be found here: https://discussion.fedoraproject.org/t/f40-change-proposal-fedora-atomic-desktops-self-contained/92893 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 proposal: Fedora Atomic Desktops (Self-Contained Change proposal)
update the documentation and figure out a way to share more of the content between those variants. == Release Notes == To be done. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re-triggering fedora CI tests
On Tue, 2023-10-17 at 11:41 +, Martin Cermak wrote: > Hello folks, > > based on my end user experience, users are only allowed to re-trigger Fedora > CI tests in case they are committers for the component in question. Would it > be possible to open it a little bit for certain other users? Specifically > Red Hat QE typically aren't even fedora packagers. But having a chance to > re-trigger ci tests would be very beneficial for them. we actually have work on this going on ATM: https://pagure.io/fedora-infrastructure/issue/11447 basically, the required support has been added to Bodhi but not deployed to prod yet, we will probably do that after F39 Final. Then we just need to add appropriate folks to a group called 'fedora-ci-users'. -- 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: Heads up: Rawhide builds currently failing openQA gating
On Mon, 2023-10-16 at 11:39 -0700, Adam Williamson wrote: > Hey, folks. If you have a Rawhide update stuck in openQA gating - we're > aware of the issue. A KDE package was prematurely rebuilt against kf6 > before https://pagure.io/fedora-kde/SIG/issue/399 was sorted out, and > this ultimately triggers file conflicts which prevents dnf update from > working in the KDE tests (and prevents the KDE live image build > working), which usually results in the tests failing in the > _advisory_post check that the update was actually installed (because it > wasn't). > > The KDE team is working on fixing this, there are several builds > pending which they hope should resolve all kf6 file conflicts and allow > tests to succeed again. If this doesn't work we'll just untag the > offending build (kde-partitionmanager) until the conflicts can be fully > sorted out. Once we have a resolution I will be re-running failed > tests. We apologize for the inconvenience. Update: I believe everything should be resolved now, and failed tests are being re-run. They should come up green over the next couple of hours, and updates will be unblocked. -- 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: Rawhide builds currently failing openQA gating
Hey, folks. If you have a Rawhide update stuck in openQA gating - we're aware of the issue. A KDE package was prematurely rebuilt against kf6 before https://pagure.io/fedora-kde/SIG/issue/399 was sorted out, and this ultimately triggers file conflicts which prevents dnf update from working in the KDE tests (and prevents the KDE live image build working), which usually results in the tests failing in the _advisory_post check that the update was actually installed (because it wasn't). The KDE team is working on fixing this, there are several builds pending which they hope should resolve all kf6 file conflicts and allow tests to succeed again. If this doesn't work we'll just untag the offending build (kde-partitionmanager) until the conflicts can be fully sorted out. Once we have a resolution I will be re-running failed tests. We apologize 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
[Test-Announce] 2023-10-16 @ 16:00 UTC - Fedora 39 Blocker Review Meeting
# F39 Blocker Review meeting # Date: 2023-10-16 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.libera.chat (*NOT* Matrix) Hi folks! We have 1 proposed Final blocker and 1 proposed Final freeze exception issue to review, so let's have a meeting on Monday. The meeting will on IRC only due to the ongoing lack of a Matrix <-> IRC bridge and a meeting bot on the Matrix side. If you no longer have an IRC setup you can join via webIRC: https://web.libera.chat/ , enter a nickname and put #fedora-blocker-review in the Channel box. 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 F39 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-10-16 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-10-16 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: ** #fedora-meeting on irc.libera.chat ** Greetings testers! It's time for another QA meeting. As usual lately, please note this meeting will really be *on IRC*. The Matrix bridge is still down and the meeting bot for Matrix is not quite done yet. So please use an IRC client or the web client - https://web.libera.chat/#fedora-meeting - to join. 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 39 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
https://pagure.io/fesco/issue/3082 - proposal to increase aarch64 netinst image size limit to 1G
Hey folks! I mentioned this in the blocker status summary email I just sent, but figured it also deserved its own thread just to make sure folks are aware of it. I've sent a ticket to FESCo: https://pagure.io/fesco/issue/3082 proposing we bump the max size of the aarch64 Server netinst image (which is release-blocking) from 700M to 1G. A detailed justification is in the ticket. If you have passionate opinions on this, please read the ticket and comment. 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
Fedora Linux 39 Final blocker status summary #2
com/2243206 - POST anaconda should allow installations on drives providing installation source This is at -3, +1 in voting currently. Needs more votes. If it happens to be accepted, anaconda team would have to decide on a fix. -- 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: Canceled: FESCo Meeting (2023-10-12)
On Thu, 2023-10-12 at 15:04 +0200, Fabio Valentini wrote: > On Thu, Oct 12, 2023, 14:58 Major Hayden wrote: > > > Hello there, > > > > I'm not able to find any items in the FESCo Pagure queue that need > > discussion today, so I'll cancel this week's meeting and we can regroup > > next week on October 19 at 1700 UTC. > > > > Unless anyone is super excited to be the chair for next week's meeting, I > > will do it. 晴 > > > > I hope everyone has a great rest of the week and weekend! > > > > Beware that there are some change proposals that are either pending > announcement / discussion / creation of fesco tickets. That also might be > the reason why our Ticket queue looks kind of empty. Well, AFAICS there are four awaiting announcement, but those wouldn't require any FESCo action immediately. There are only two that have been announced and not yet sent to FESCo - https://fedoraproject.org/wiki/Changes/Drop_Sshd_Socket and https://fedoraproject.org/wiki/Changes/KDE_Plasma_6 - and I believe we (Aoife and I) were kinda sitting on those for Reasons: the Plasma 6 one is a big one that still had active discussion ongoing till fairly recently, and it seems reasonably likely that the sshd socket one won't be needed once https://github.com/systemd/systemd/pull/29159#issuecomment-1714205320 lands in Fedora, so we were kind of intentionally leaving it in limbo, I think. -- 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: Python enable dependency generator problem
On Wed, 2023-10-11 at 09:31 -0300, Priscila Gutierres wrote: > Thank you, > It works removing -t from %pyproject_buildrequires, EXCEPT if I keep all > the pytest tests running > When running the test, it blames about the modules needed for the tests, as > you can see here: https://paste.centos.org/view/5f0e107a > Deleting line 61 here: https://paste.centos.org/view/c25fee49, everything > works as expected +_+ Well, yes, that's...expected. Removing -t means you're not generating automatic build dependencies for the test suite, so the things the test suite needs don't get installed. As I said in my mail, if you want to run the tests - which you should! - you either need to get upstream to make its dependency version specifiers looser, patch them downstream before the dependency generator runs, or don't use the dependency generator but specify the BuildRequires manually based on the text file. -- 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 Linux 39 Final is NO-GO
On Wed, 2023-10-11 at 15:45 +0200, Michael J Gruber wrote: > I was just wondering what the "anchor" is, say "right after final > freeze" or "7 days before GA". We could put "updates-testing disabled > in fedora-release GA version" as a remark in there, just like "xy plan > on this" and such. The anchor is "whenever someone remembers we have to do it". -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 39 Final is NO-GO
Due to outstanding blocker bugs[1], we do not have a release candidate for Fedora Linux 39 Final. Thursday's Go/No-Go meeting is cancelled. The next Fedora Linux 39 Final Go/No-Go meeting will be held at 1700 UTC on Thursday 19 October in #fedora-meeting-1. We will aim for the "target date #1" milestone of 24 October. The release schedule[2] will be updated accordingly soon. [1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Please help complete validation testing for current Fedora 39 candidate nightly!
Hey folks! You probably saw the mail "Fedora 39 Branched 20231010.n.0 nightly compose nominated for testing" today. Although we still don't have an RC for the Fedora 39 Final release, I want to ask folks to please help us fill out the matrices for this candidate as much as possible. It's best if we find any remaining blocker bugs *now*, not wait for an RC before doing the full testing. You can use testcase_stats to see what test cases probably need running - https://openqa.fedoraproject.org/testcase_stats/39/ . The pages there shows the execution history and last run date for each test on the corresponding matrix page, so you can see at a glance which tests haven't been run recently or at all. Please focus on tests marked Basic, Beta or Final that have not yet been run, or not been run for some time. And of course, if you find a significant bug, mark the test as a failure, file a bug, and nominate it as a release blocker. Thanks a lot 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
Re: Python enable dependency generator problem
On Tue, 2023-10-10 at 17:30 -0300, Priscila Gutierres wrote: > Hello, > > I'm trying to add python enable dependency generator on python-pymemcache, > but when adding it to the specfile, it asks for some old version of some > needed packages: > https://paste.centos.org/view/33623ed7 > > Fedora repos have a more updated version, but this dependency generator is > asking for an older version of those packages: > > https://src.fedoraproject.org/rpms/python-faker > https://src.fedoraproject.org/rpms/python-gevent > https://src.fedoraproject.org/rpms/python-pylibmc > > > How to fix this? Did you include the `-t` arg for the generator? `%pyproject_buildrequires -t`? If so, it'll be pulling these dependencies from tox.ini, which pulls them from https://github.com/pinterest/pymemcache/blob/master/test-requirements.txt , which pins very specific versions. If you *want* to auto-generate these requirements, your only options are to get upstream to loosen the version specifiers, or patch the requirements file in %prep before the build requirement generator runs (I think that ordering is possible). Alternatively of course you can omit `-t` so the dependency generator won't work out the requirements from tox.ini , but then you can't run the tests during %check unless you specify the requirements manually... -- 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: kdump enabled in F39
On Tue, 2023-10-10 at 12:15 -0400, Chris Murphy wrote: > Hi folks, > > I'm having some difficulty tracking down why it's being enabled on Fedora 39 > but not on Fedora 38. > > On both Fedora 38 and 39, /etc/kdump.conf contains > > auto_reset_crashkernel yes > > However, I've never seen the reported behavior until Fedora 39. > > While the crashkernel parameter is being set on the kernel command line, the > kdump.service unit is disabled. I don't know how these things interact, so I > don't know how big a deal the issue is. Maybe it's just wasted space on the > kernel command line? > > In any case, eventually it will clutter up the command line for everyone once > they update their kernel because this parameter will be added. And I don't > know how we fix it with an update because it means stepping on everyone's > /etc/kdump.conf - without a way of knowing if they want this or some other > setting applied. > > https://bugzilla.redhat.com/show_bug.cgi?id=2243068 Detailed follow-up in the bug report, but for anyone following along here, I think this was caused by changes to the set of scripts in kexec-tools between F38 and F39 which have the effect that a crashkernel= arg will almost always get added whenever a kernel is installed, or kexec-tools is updated. Previously that was not the case. -- 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] Fedora Linux 39 Final is NO-GO
Due to outstanding blocker bugs[1], we do not have a release candidate for Fedora Linux 39 Final. Thursday's Go/No-Go meeting is cancelled. The next Fedora Linux 39 Final Go/No-Go meeting will be held at 1700 UTC on Thursday 19 October in #fedora-meeting-1. We will aim for the "target date #1" milestone of 24 October. The release schedule[2] will be updated accordingly soon. [1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist [2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html -- 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] 2023-10-09 @ 16:00 UTC - Fedora 39 Blocker Review Meeting
# F39 Blocker Review meeting # Date: 2023-10-09 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.libera.chat (*NOT* Matrix) Hi folks! We have 4 proposed Final blockers and 3 proposed Final freeze exception issues to review, so let's have a meeting tomorrow. The meeting will on IRC only due to the ongoing lack of a Matrix <-> IRC bridge and a meeting bot on the Matrix side. If you no longer have an IRC setup you can join via webIRC: https://web.libera.chat/ , enter a nickname and put #fedora-blocker-review in the Channel box. 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 F39 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 39 Final blocker status summary
nel patches seem to finally be getting merged upstream, but it may be just too late for F39, unfortunately - if so, we'll have to waive it one more time. It'd be good if Gerd / Peter / Justin can clarify the outlook here. 11. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 We need the maintainers to work out a fix for this one, Peter says he's working on it. 12. xdg-desktop-portal - https://bugzilla.redhat.com/2240211 - VERIFIED Fonts, maximize buttons, cursor size settings not applied in "GTK" Flatpaks Update is in testing - https://bodhi.fedoraproject.org/updates/FEDORA-2023-a34ccfc45b . Just needs testing and karma. Proposed blockers - 1. blivet-gui - https://bugzilla.redhat.com/2241761 - MODIFIED cancelling partition editing by Esc doesn't cancel, but CONFIRMS the dialog We have a fix for this lined up and it's already accepted as an FE, so with testing and karma of https://bodhi.fedoraproject.org/updates/FEDORA-2023-e9198d932d this should go away. 2. kbd - https://bugzilla.redhat.com/2242287 - MODIFIED loadkeys from kbd 2.6.1 triggers all mounts in the cwd Similarly to #1, this is already accepted as FE and https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa617966c7 is ready for testing. 3. kernel - https://bugzilla.redhat.com/2239807 - NEW Fedora 39 Wayland experiences regular screen blackouts at increasing intervals after login on amdgpu with kernel 6.5+ We need votes on this one at https://pagure.io/fedora-qa/blocker-review/issue/1359 , and it'd be great if kernel team can come up with a fix, of course. It's basically a judgment call about how commonly we think this bug is likely to come up based on the feedback so far. There's an outside chance 6.5.6 might happen to fix it, will ask the reporter. 4. librepo - https://bugzilla.redhat.com/2242115 - POST Binary PGP keys cannot be imported since librepo v1.16.0 We need votes on this one at https://pagure.io/fedora-qa/blocker-review/issue/1375 . So far I can't see a clear blocker justification, but take a look for yourself. A fix has been posted as an upstream PR, it would be great if the maintainer can build an update with it. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Specify koji build machine mem req via. spec file
On Fri, 2023-10-06 at 14:17 -0400, Stephen Gallagher wrote: > On Thu, Oct 5, 2023 at 2:04 AM Adam Williamson > wrote: > > > > On Wed, 2023-10-04 at 12:19 +0200, Kalev Lember wrote: > > > On Wed, Oct 4, 2023 at 11:44 AM Martin Stransky > > > wrote: > > > > > > > Hello guys, > > > > > > > > Is there's a way how to set requested amount of ram for koji builders? > > > > > > > > I'd like to use it as Firefox builds fail recently due low memory, like > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2241690 > > > > > > > > > I looked at the first linked build log in the ticket and it looks like the > > > build failed in the debuginfo extraction step. In that log, find-debuginfo > > > is called with -j3, and it could be that it ran out of memory because it > > > was trying to do 3 debuginfo extractions in parallel. You could try to > > > stick something like this in the spec file to tune it down: > > > > > > # Require 32 GB of RAM per CPU core for debuginfo processing > > > %global _find_debuginfo_opts %limit_build -m 32768 > > > > Thanks for the idea, Kalev. I went ahead and applied this, and builds > > for F38 and F39 succeeded. Let's hope it really helps and this wasn't > > just luck! > > Looks like probably not, since the follow-up ELN build *also* > succeeded for the first time in quite a while! Unfortunately I still got several failed builds today while trying to do builds with the fixes for the .desktop file issues :( Most recent was a case of gdb-add-index getting killed, as Kevin says he found happens with 24G of RAM: https://bugzilla.redhat.com/show_bug.cgi?id=2241690#c7 https://koji.fedoraproject.org/koji/taskinfo?taskID=107145177 this was a build on buildvm-x86-11.iad2.fedoraproject.org . I guess I'll try fiddling with some of the other stuff discussed in this thread and firing more builds. :( -- 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: Live USB iso boot not working since Fedora 37, still broken in 39 Beta
On Thu, 2023-10-05 at 16:36 -0400, Neal Gompa wrote: > On Thu, Oct 5, 2023 at 4:03 AM Matthias Saou wrote: > > > > Hi, > > > > I continued digging some more, and it turns out there is a one liner > > fix for the issue that has been merged upstream: > > > > https://github.com/dracutdevs/dracut/pull/2196 > > > > Would there be any hope to get this backported to be included in Fedora > > 39? The scope of the change is ridiculously tiny, limited to this > > single modules.d/90dmsquash-live/iso-scan.sh file which is exclusively > > used for this broken feature. > > > > It would be really great to get the final Fedora 39 iso working again. > > > > An update has been proposed: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-f71507e281 The bug still needs to be accepted as an FE for this to make final, though. https://pagure.io/fedora-qa/blocker-review/issue/1382 -- 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: time is running: security issue BZ#2241470
On Thu, 2023-10-05 at 19:01 +0200, Tomasz Torcz wrote: > On Thu, Oct 05, 2023 at 11:23:35AM -0400, Stephen Smoogen wrote: > > On Sat, 30 Sept 2023 at 05:13, Marius Schwarz > > wrote: > > > > > > > > Hi, > > > > > > this is emerg ping for the security team, to take a look at this bz : > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2241470 > > > > > > The deadline for having a fix shipped is the afternoon of SUN, 1. of Oct > > > 2023 . On this date, the patches in upstream go public and exploits > > > will be developed for them. this impacts ALL of redhat based > > > installations which run as servers and are publically reachable. The > > > component in question is the default package for rh based installations. > > > > > So does anyone know which of this weeks major security problems this was > > about? Since it is supposedly past the release date, I figure it is ok to > > ask. If it isn't due to some other delay.. my apologies. > > My guess is on glibc's suid local root: https://lwn.net/Articles/946381/ That doesn't seem to really fit, though. You need to be able to at least set environment variables and execute processes to exploit that, right? That hardly covers "all publically reachable servers". I guess it's the closest candidate, but meh. In any case, the updates for that all went stable yesterday. -- 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: Specify koji build machine mem req via. spec file
On Wed, 2023-10-04 at 12:19 +0200, Kalev Lember wrote: > On Wed, Oct 4, 2023 at 11:44 AM Martin Stransky wrote: > > > Hello guys, > > > > Is there's a way how to set requested amount of ram for koji builders? > > > > I'd like to use it as Firefox builds fail recently due low memory, like > > https://bugzilla.redhat.com/show_bug.cgi?id=2241690 > > > I looked at the first linked build log in the ticket and it looks like the > build failed in the debuginfo extraction step. In that log, find-debuginfo > is called with -j3, and it could be that it ran out of memory because it > was trying to do 3 debuginfo extractions in parallel. You could try to > stick something like this in the spec file to tune it down: > > # Require 32 GB of RAM per CPU core for debuginfo processing > %global _find_debuginfo_opts %limit_build -m 32768 Thanks for the idea, Kalev. I went ahead and applied this, and builds for F38 and F39 succeeded. Let's hope it really helps and this wasn't just luck! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-10-02 @ 16:00 UTC - Fedora 39 Blocker Review Meeting
# F39 Blocker Review meeting # Date: 2023-10-02 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.libera.chat (*NOT* Matrix) Hi folks! We have 7 proposed Final blockers and 3 proposed Final freeze exception issues to review, so let's have a meeting on Monday. I will not be around to run the meeting, but I'm hoping somebody else will volunteer. lruzicka has said he'll do it if nobody else is available but he'd prefer somebody with native English to do it if possible. Don't be shy :) The SOP to run the meeting is https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting , it's not too hard. The meeting will on IRC only due to the ongoing lack of a Matrix <-> IRC bridge and a meeting bot on the Matrix side. If you no longer have an IRC setup you can join via webIRC: https://web.libera.chat/ , enter a nickname and put #fedora-blocker-review in the Channel box. 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 F39 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 someone will see you on Monday, I hope! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-10-02 @ 15:00 UTC - Fedora QA Meeting?
# Fedora Quality Assurance Meeting # Date: 2023-10-02 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: ** #fedora-meeting on irc.libera.chat ** Greetings testers! There is a meeting slot on Monday, but I won't be around (I'll be on my way back from a weekend trip). If anyone else is able to run a meeting, please do volunteer! If not, we'll do one next time. As usual lately, please note this meeting will really be *on IRC*. The Matrix bridge is still down and the meeting bot for Matrix is not quite done yet. So please use an IRC client or the web client - https://web.libera.chat/#fedora-meeting - to join. 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 39 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: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On Wed, 2023-09-27 at 09:48 -0500, Ian Pilcher wrote: > On 9/27/23 04:56, Miro Hrončok wrote: > > fail2ban > > > > https://bugzilla.redhat.com/2219991 > > https://github.com/fail2ban/fail2ban/issues/3487 > > Bugzilla ASSIGNED 2 months ago, no update since. > > Maintainers NEEDINFOed last week. > > With my system/network administrator hat on, this one is really > concerning. After reading the upstream issue, it doesn't seem that > there's much chance of this being fixed any time soon. > > Is there anything in Fedora that provides similar functionality? (I've > looked, but come up empty thus far.) Could we possibly just vendor the old async stuff into fail2ban for now to keep it usable until upstream manages to rewrite everything? I agree that we should really try to avoid this dying, it does seem to be fairly commonly used by enthusiast sysadmins. -- 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
