Re: Fedora Linux 34 Final blocker status update #3
On Thu, 2021-04-01 at 14:56 -0400, Ben Cotton wrote: > > 1. gdm — https://bugzilla.redhat.com/show_bug.cgi?id=1942443 — NEW > Login using password failed after upgrade to Fedora 34 > > When a device has a fingerprint reader, but no fingerprints are > enrolled, login fails on the default terminal. Switching to a > different virtual console allows login. Removing fprintd-pam resolves > the problem, but is probably not the solution we want. It may be that > modifications of nsswitch.conf outside of authselect cause fprintd to > get unexpected failures from authselect. Just to clarify this one a bit: AIUI, this is the same bug we fixed earlier in the cycle, but it's still a problem after update to the 'fixed' package for some people. It seems to affect two scenarios: 1. Very old installs, from a release where we had authconfig not authselect, that have been upgraded all the way to F34 2. Installs where /etc/nsswitch.conf has been modified in any way except via authselect, so authselect won't apply changes to it any more I believe benzea is planning to try and solve this by having the package make the specific change to the configuration that's necessary, in affected cases. We think that just making this specific change in a package scriptlet should be pretty safe, it shouldn't be able to break any odd configuration we can think of. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On Tue, 2021-03-30 at 19:11 +0200, Robert-André Mauchin wrote:
> Hello,
>
> Following a change in the config file of a program, I'd like to display
> a message to my users to indicate they need to update the config file
> with the new one. I try "echo" in the update scriptlet:
>
> %postun
> if [ "$1" -ge "1" ] ; then # Upgrade
> dnscrypt-proxy -service install --config
> %{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
> echo 'Since version 2.0.45, some of the configuration files have been
> renamed.
> Please merge your config to
> /etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then
> replace dnscrypt-proxy.toml with that file.
> Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files accordingly.'
> fi
>
> But it doesn't work as expected. Is there a way to transmit that message
> to my users?
Besides putting it in the update description, no.
You cannot assume that updates are done attended, or done from a
console. What if they're using dnf-automatic? What if they're using a
graphical application which doesn't display console output?
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: ask to test latest systemd build for systemd-resolved problems
On Sat, 2021-03-27 at 09:06 +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Mar 26, 2021 at 09:06:14PM -0700, Adam Williamson wrote: > > On Fri, 2021-03-26 at 17:39 +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Fri, Mar 26, 2021 at 08:42:51AM -0700, Adam Williamson wrote: > > > > Can you do a Koji scratch build? This is easier for me to test in > > > > openQA (I already have the tooling set up to schedule tests on scratch > > > > builds, it cannot do it for COPR builds). Thanks! > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=64648010 > > > Should be done in about half an hour. > > > > D'oh, sorry, should've been more specific - a scratch build for F34 (or > > F33) would be better. I can't easily run tests on a Rawhide scratch > > build (as we don't run the update tests on Rawhide). > > https://koji.fedoraproject.org/koji/taskinfo?taskID=64671982 (f34) > https://koji.fedoraproject.org/koji/taskinfo?taskID=64672016 (f33) Tested and looks OK: https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=34&build=Kojitask-64671982-NOREPORT&groupid=2 one test failed for unrelated reasons, I'm re-running it now. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-03-29 @ **16:00** UTC - Fedora 34 Blocker Review Meeting
# F34 Blocker Review meeting # Date: 2021-03-29 # Time: **16:00** UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 4 proposed Final blockers and 1 proposed Final freeze exception issue to review (as of now), so we'll have a Fedora 34 blocker review meeting tomorrow. 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 F34 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 Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-03-29 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomorrow. I don't have anything urgent this week, and we'll be doing a blocker meeting for F34. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ask to test latest systemd build for systemd-resolved problems
On Fri, 2021-03-26 at 17:39 +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Mar 26, 2021 at 08:42:51AM -0700, Adam Williamson wrote: > > Can you do a Koji scratch build? This is easier for me to test in > > openQA (I already have the tooling set up to schedule tests on scratch > > builds, it cannot do it for COPR builds). Thanks! > > https://koji.fedoraproject.org/koji/taskinfo?taskID=64648010 > Should be done in about half an hour. D'oh, sorry, should've been more specific - a scratch build for F34 (or F33) would be better. I can't easily run tests on a Rawhide scratch build (as we don't run the update tests on Rawhide). -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: ask to test latest systemd build for systemd-resolved problems
On Fri, 2021-03-26 at 09:16 +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > we have been trying to figure out the issue where resolved sometimes > does not resolve certain names [1], e.g. 'google.com'. Unfortunately, > the issue is only reproducible for some people (most likely it depends > on the dns server or other network topology details…). > > One of the patches that seem problematic [2] was included in F33 and > then reverted. But it is still present in the systemd main branch. > Before tagging the next release and pushing it to F34 and rawhide, we > would like to solve this issue (or verify that it does not occur anymore). > > I prepared a copr build of latest system git [3,4] to make this easy > to test. > > The ask: if you could reproduce the issue before, please test if it > still occurs with the copr build. Just "yes"/"no" is already useful. Can you do a Koji scratch build? This is easier for me to test in openQA (I already have the tooling set up to schedule tests on scratch builds, it cannot do it for COPR builds). Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-03-22 @ **15:00** UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2021-03-22 # Time: **15:00** UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet for a couple of weeks, and Beta is signed off now, so let's check in on that and make sure we're all ready for Beta release. Note that daylight savings time started in most of North America recently, so the meeting time in UTC has been changed. If your clocks went forward recently, the meeting time in your local time will be the same as it was before. If your area does not observe daylight savings, or starts later, the meeting will be an hour *earlier* in your local time than it was before. You can use 'date -u' to check the current UTC time and make sure you head to the meeting at the right 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 34 Beta prep and status 3. Test Day / community event status 4. Open floor -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-03-15 @ **16:00** UTC - Fedora 34 Blocker Review Meeting
# F34 Blocker Review meeting # Date: 2021-03-15 # Time: **16:00** UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 3 proposed Beta freeze exception issues, and 5 proposed Final blockers to review (as of now), so we'll have a Fedora 34 blocker review meeting tomorrow. Note that daylight savings time started in most places that observe it today, so the meeting time in UTC has been changed. If your clocks went forward this weekend, the meeting time in your local time will be the same as it was before. If your area does not observe daylight savings, or starts later, the meeting will be an hour *earlier* in your local time than it was before. You can use 'date -u' to check the current UTC time and make sure you head to the meeting at the right time. 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 F34 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 Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-03-15 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomorrow. I don't have anything urgent this week, and we'll be doing a blocker meeting for F34. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-03-08 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2021-03-08 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet for a couple of weeks, so let's meet up tomorrow and check in on F34 progress and community events. 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 34 status 3. Test Day / community event status 4. Open floor -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-03-08 @ 17:00 UTC - Fedora 34 Blocker Review Meeting
# F34 Blocker Review meeting # Date: 2021-03-08 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 1 proposed Beta blocker, 8 proposed freeze exception issues, and 2 proposed Final blockers to review (as of now), so we'll have a Fedora 34 blocker review meeting tomorrow. 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 F34 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 Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Plymouth, themes and console clearing: https://bugzilla.redhat.com/show_bug.cgi?id=1933378
On Fri, 2021-03-05 at 01:51 +0100, David Kaufmann wrote: > On Thu, Mar 04, 2021 at 02:45:29PM -0800, Adam Williamson wrote: > > Well, you could still argue it's prettier than a wall-o-text boot. And > > it *does* hide the wall-o-text. > > On the first boot after install that's maybe nice, but usually when I > look at the machine booting I either do need to see why the initramfs > does not boot, which one is the first service failing or why the > shutdown/reboot progress is hanging - in all of those cases I prefer the > wall-o-text ;) > > But yes, doesn't look as nice as plymouth. xD Well, you get the wall-o-text just by pressing Esc... But anyhoo, since opinion so far seems to favor no-plymouth-in-core, I've sent a PR for that: https://pagure.io/fedora-comps/pull-request/631 -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Plymouth, themes and console clearing: https://bugzilla.redhat.com/show_bug.cgi?id=1933378
On Thu, 2021-03-04 at 22:40 +0100, Hans de Goede wrote: > > > Starting from a minimal install with plymouth omitted, adding just > > plymouth itself pulls in 3 packages (plymouth, plymouth-core-libs, > > plymouth-scripts) with an installed size of 621K. Adding plymouth- > > system-theme pulls in 32 packages with an installed size of 24M. So > > putting plymouth-system-theme in @core would substantially inflate the > > size of @core in terms of both number of packages and overall installed > > size. Removing plymouth from @core would not save a lot in terms of > > packages or space. > > > > So, I guess the question here is, what do we do? > > > > 1) Remove plymouth from @core > > 2) Add plymouth-system-theme to @core > > 3) Make Hans/Ray/someone fix the plymouth bug > > 1) clearly gets my vote, not just because I don't have time to work on 3) > but also because to me it seems like the right thing to do. Plymouth is > a boot splash, its goal is to make the boot look pretty / hide all the > scary log messages in use-cases where we want this. The text fallback > splash is not pretty. In general if it shows instead of the graphical > splash the fact that the text fallback shows is considered a bug. Well, you could still argue it's prettier than a wall-o-text boot. And it *does* hide the wall-o-text. > So either the server spin wants a pretty boot and then they should fix the > bug of the text splash showing by installing plymouth-system-theme, or the > server spin does not want a pretty boot and then there should be no > plymouth at all. What if we want something arguably-prettier than wall-o-text, but don't want an extra 32 packages and 24M of storage used up? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Plymouth, themes and console clearing: https://bugzilla.redhat.com/show_bug.cgi?id=1933378
Hey folks! So I've filed a bug recently which may need wider discussion about the resolution. The bug report is: https://bugzilla.redhat.com/show_bug.cgi?id=1933378 The problem is this. If plymouth is installed but no graphical theme is installed/configured - which is currently the case for at least Server and minimal installs - plymouth uses a 'fallback' text theme, which Hans says is under-maintained. Since around Fedora-Rawhide- 20210122.n.0, openQA has been encountering an intermittent problem where this theme does not clear properly when boot is complete and the console login is shown, it looks like this: https://openqa.fedoraproject.org/tests/799388#step/_console_wait_login/6 It gets worse once you actually try and log in - bits of the grey background get wiped and replaced with black in ugly patterns, this both looks dumb and makes working around the bug in openQA by adding more screenshots impractical (because the pattern of the background just keeps changing). This bug does not seem to happen if a Plymouth graphical theme is installed and configured, only if the fallback text theme is used. In the bug report, we did a bit of looking into what bits of Plymouth are installed when. In comps, 'plymouth' itself is listed as 'mandatory' in @core. This seems to ultimately date back to https://pagure.io/fedora-comps/c/0dca8c2b3f04624873918e6dfef12f27bf1a6d75 by Bill, which was in response to https://bugzilla.redhat.com/show_bug.cgi?id=801087 (the bug number in the commit is a typo). The commit claims "Add plymouth to core, to match prior releases", but it was *not* in @core in "previous releases" so far as I can tell; it may have been pulled into minimal installs via dependencies (I can check an F16 minimal install later). 'plymouth-system-theme' - which installs the default graphical theme - is in the 'base-x' group. So only package sets that include base-x will install a graphical theme for Plymouth. This includes all major desktops, but does *not* include at least Server or minimal installs (and probably some other subsets I'm not thinking of). Anything that includes @core but *not* @base-x will hit the broken configuration. Obviously one option here is just to fix the bug in Plymouth, but Hans suggested that we should fix it by not installing Plymouth in this configuration - i.e. we should only ever install plymouth and plymouth- system-theme or no plymouth at all. If you don't have plymouth installed, you get a very old-school "wall of text" boot process; if there are encrypted system partitions, you get a plain text prompt for the encryption passphrase, with no keyboard layout indicator (I'm not sure if the text theme indicates the keyboard layout either). Starting from a minimal install with plymouth omitted, adding just plymouth itself pulls in 3 packages (plymouth, plymouth-core-libs, plymouth-scripts) with an installed size of 621K. Adding plymouth- system-theme pulls in 32 packages with an installed size of 24M. So putting plymouth-system-theme in @core would substantially inflate the size of @core in terms of both number of packages and overall installed size. Removing plymouth from @core would not save a lot in terms of packages or space. So, I guess the question here is, what do we do? 1) Remove plymouth from @core 2) Add plymouth-system-theme to @core 3) Make Hans/Ray/someone fix the plymouth bug Opinions? :) Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Update gating test is "failed" with no useful information
On Tue, 2021-03-02 at 13:59 +, Richard W.M. Jones wrote: > > Other tests are kind of random. I mean, what does this mean? > > https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/12861/testReport/(root)/tests/ > > Stuff like: > > 1) File /usr/lib64/ocaml/cmdliner/cmdliner.a changed content on x86_64. > > Amazing! The package was rebuilt, what did you expect? The test description does explain this to some extent: "Report changed files from the before build to the after build. Certain file changes will raise additional warnings if the concern is more critical than just reporting changes (e.g., a suspected security impact)." I suspect the types of files that changed here are flagged as being "critical" on the basis that they are effectively ABI, so this is telling you more or less the same thing as the abidiff failure: the update changes the ABI. Note that many other files in the package will have changed, but they're not *all* shown in the test results, just these specific ones. The question here is more "should ABI change-type issues be counted as failures on Rawhide 'updates'?", I think. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-03-01 @ 17:00 UTC - Fedora 34 Blocker Review Meeting
# F34 Blocker Review meeting # Date: 2021-03-01 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 5 proposed Beta blockers, 7 proposed freeze exception issues, and 3 proposed Final blockers to review (as of now), so we'll have a Fedora 34 blocker review meeting tomorrow. 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. 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 F34 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 Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Re: Proposal to CANCEL: 2021-02-29 Fedora QA Meeting
On Sat, 2021-02-27 at 23:01 -0800, Adam Williamson wrote: > Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have > anything urgent this week, and we'll be doing a blocker meeting for F34. > > If you're aware of anything important we have to discuss this week, > please do reply to this mail and we can go ahead and run the meeting. I was, of course, thinking of the 2021-02-29 that is more correctly known as 2021-03-01. :D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-02-29 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have anything urgent this week, and we'll be doing a blocker meeting for F34. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-02-22 @ 17:00 UTC - Fedora 34 Blocker Review Meeting
# F34 Blocker Review meeting # Date: 2021-02-22 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 3 proposed Beta blockers and 2 proposed Final blockers to review (as of now), so we'll have a Fedora 34 blocker review meeting tomorrow. 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. 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 F34 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 Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] 2021-02-22 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2021-02-22 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet for a couple of weeks, and we're getting to F34 Beta release time, so let's meet up tomorrow. 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 34 status and Changes 3. Test Day / community event status 4. Open floor -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-02-15 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have anything urgent this week. We did just branch and there are things we could kick around, but Monday's a public holiday in Canada so I won't be around to run a meeting. If someone else wants to run a meeting, please do reply to this mail with an agenda and go ahead and run the meeting on Monday. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 33 Beta blocker status email #1
On Fri, 2021-02-12 at 20:50 -0500, Matthew Miller wrote: > On Sat, Feb 13, 2021 at 02:02:16AM +0100, Kevin Kofler via devel wrote: > > Ben Cotton wrote: > > > 2. kde-settings — KDE needs to pick up F34 backgrounds — NEW > > > ACTION: kde-settings maintainers to adopt F34 backgrounds > > > > Oh, it's Groundhog Day, again? > > > > Can we PLEASE find a process for the backgrounds which does NOT include > > having this beta blocker open at each and every beta freeze? > > The Fedora 34 background just went in, but the Fedora 35 background should > land soon. The goal is to shift forward so the new backgrounds to actually > land in Rawhide at around the time that Rawhide "becomes" the next release > — so around August 10th this year for Fedora 36. > > However, there still needs to be an update in KDE, right? And it'd still be > a blocker, although ideally never get to the point where it _matters_ that > it's a blocker. Or, maybe there is something that can be done in KDE to > automatically pick up the latest? It being a blocker isn't necessarily a problem. This happening *late* is a problem. This cycle it's actually going better, I'd say - we're not at freeze yet, remember. We've only just branched. Freeze isn't for over a week. And the kde-settings build happened today. If that does the job, then I'm fine with the timing. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream
On Thu, 2021-02-11 at 09:55 +0100, Clement Verna wrote: > > > > So, what do folks think? Does this seem like a good idea? Should I go > > ahead with trying to get it deployed and onboard things to it? Any > > comments, ideas, potential problems? Thanks! > > > > > I am pretty sure you did :-) but have you looked at adding the missing > information to Bodhi ? Now that we have rawhide in Bodhi we should be able > to expose most the information needed. I didn't look at that in any technical detail but conceptually it seems kinda wrong to me. The problem with using any existing system is that all existing systems are *for* something. Bodhi is for dealing with updates. There's no reason why Bodhi would track, for instance, whether 34 is under a string freeze, right? Because Bodhi doesn't have anything to do with translations. There are a zillion other 'states' that it would be useful to have info on which aren't relevant to any *one* existing system, and that's why to me it makes sense to have a separate thing for that. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream
On Thu, 2021-02-11 at 08:16 +0100, Frantisek Zatloukal wrote: > On Wed, Feb 10, 2021 at 11:27 PM Debarshi Ray wrote: > > > Hey, > > > > I wanted to respond earlier, but it totally slipped my mind. > > > > We'd totally use releasestream in Toolbox for mapping the string > > "rawhide" to a numeric version: > > https://github.com/containers/toolbox/issues/646 > > > > Cheers, > > Rishi > > > > You (and anybody else, ofc :) ) can take a look at the packager dashboard > before Adam deploys releasestream. It exposes Fedora release information on > https://packager-dashboard.fedoraproject.org/api/v1/releases . It's based > on fedfind, with some more logic and information processing in the > background. In the end, though, fedfind is just getting its info from a JSON file I hand edit, which winds up getting reprocessed into that...:D https://fedorapeople.org/groups/qa/metadata/release.json -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Mon, 2021-02-08 at 17:00 +, José Abílio Matos wrote: > On Monday, February 8, 2021 3:54:29 PM WET Miro Hrončok wrote: > > python-blinker orphan, pjp, sundaram 0 weeks > > ago > > I took python-blinker that is required by nikola. In particular it means that > the following users/groups are covered: For the record it's also required by fedora-messaging, which is why just about everything else in the world needed it :) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
[Test-Announce] Proposal to CANCEL: 2021-02-08 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomorrow. I don't have anything urgent this week. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mesa 21.0.0-rc3 making rawhide really unstable?
On Tue, 2021-02-02 at 09:56 -0800, Kevin Fenzi wrote: > On Tue, Feb 02, 2021 at 04:15:56PM +0100, Fabio Valentini wrote: > > Hi everybody, > > > > After updating my rawhide VMs today, it looks like > > mesa-21.0.0~rc3-1.fc34 is making all sessions really unstable. > > gnome-shell (wayland) repeatedly crashes after opening any windows, > > and Xorg based LightDM or Pantheon session crashes at launch with > > compositor segfaults. One system was fine until I updated mesa, so > > this issue should really be caused by the mesa 20 → 21 update ... > > > > Can somebody shine light on whether this is limited to my systems or > > if this is a general problem with mesa 21? > > Seems fine here... I'm using gdm/gnome-shell at the moment. What kernels are you guys on? It's a little hard to tell as everything seems a bit shaky right now, but I think openQA was seeing repeated Shell crashes up until today's compose - with debug kernels - but with today's compose (with a non-debug kernel) that doesn't seem to be happening. We *do* get a crash during g-i-s right after first boot of the installed system, though. I'm about to look into that and file a bug. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
[Test-Announce] 2021-02-01 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2021-02-01 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet for a couple of weeks, and there are interesting goings- on, so let's meet up tomorrow. 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 34 status and Changes 3. Criteria proposals, etc. 4. Test Day / community event status 5. Open floor -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, 2021-01-28 at 13:46 -0700, Chris Murphy wrote: > > OK I'm seeing this problem in a VM with > Fedora-Workstation-Live-x86_64-Rawhide-20210128.n.0.iso but I'm not > sure how consistent it is yet. MemTotal is ~3G for a VM that has 4G > allocated. Something's wrong... > > VM 5.11.0-0.rc5.20210127git2ab38c17aac1.136.fc34.x86_64 > [0.701792] Memory: 3016992K/4190656K available (43019K kernel > code, 11036K rwdata, 27184K rodata, 5036K init, 31780K bss, 1173408K > reserved, 0K cma-reserved) > > Baremetal 5.10.11-200.fc33.x86_64 > [0.125875] Memory: 12059084K/12493424K available (14345K kernel > code, 3465K rwdata, 9704K rodata, 2536K init, 5504K bss, 434080K > reserved, 0K cma-reserved) > > Why is reserved so much higher in the VM case? It clearly sees the 4G > but is delimiting it to 3G for some reason I don't understand. This is > well before the zram module is loaded, by the way. I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1921923 for this. zdzichu suggests https://lkml.org/lkml/2021/1/25/701 may be related. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, 2021-01-28 at 10:18 -0800, Adam Williamson wrote:
> On Thu, 2021-01-28 at 14:16 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
> > > With today's OpenQA tests I can point out that using zram on 2048MB RAM
> > > VMs actually breaks FreeIPA deployment:
> > > https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
> > >
> > > OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> > > FreeIPA deployment with integrated CA and DNS server. Not anymore with
> > > zram activated:
> > >
> > > Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
> > > dev-zram0.swap (/dev/zram0 with 1384MB)
> > >
> > > which ends up eating 2/3rds of the whole memory budget and FreeIPA
> > > installer fails:
> > >
> > > 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments
> > > [] and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
> > > 'test.openqa.fedoraproject.org', 'realm_name':
> > > 'TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> > > 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> > > 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> > > 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> > > Prerelease)
> > > 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> > > ...
> > > 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
> > > exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
> > > 0.77GB available
> > > 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is
> > > available, 0.77GB available
> > > 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
> > > /var/log/ipaserver-install.log for more information
> >
> > Enabling zram doesn't really "take away memory", because no pre-allocation
> > happens.
> > If there is no physical swap, then adding zram0 should just shown additional
> > swap space, so I don't think it could cause the check to fail.
> > But if there is physical swap, the zram device is used with higher
> > preference
> > than the physical swap. So I think the explanation could be that the VM has
> > a swap partition.
>
> The openQA test in question runs after, and uses the hard disk from, a
> test that runs a default Fedora Server install:
> https://openqa.fedoraproject.org/tests/763650
> which, AIUI, should not be creating a swap partition. The logs from the test -
> https://openqa.fedoraproject.org/tests/763657/file/role_deploy_domain_controller-var_log.tar.gz
> -
> do not show any swaps being activated other than zram ones. So no, I
> don't think there is a swap partition.
Probably relevant - we log the output of `free` shortly after system
install. Up to and including Fedora-Rawhide-20210124.n.0 , it looked
approximately like this:
totalusedfree shared buff/cache available
Mem:2024132 189668 16094484104 225016 1684936
Swap: 1011708 0 1011708
Particularly, "total" memory was reported as around 200 bytes. In
Fedora-Rawhide-20210127.n.1 and Fedora-Rawhide-20210128.n.0, though -
the two most recent composes - it looks like this:
totalusedfree shared buff/cache available
Mem:1417856 311908 8528324104 253116 944752
Swap: 1417212 0 1417212
"total" memory is now reported as around 140 bytes. Not sure what
caused this to change.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, 2021-01-28 at 14:16 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
> > With today's OpenQA tests I can point out that using zram on 2048MB RAM
> > VMs actually breaks FreeIPA deployment:
> > https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
> >
> > OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> > FreeIPA deployment with integrated CA and DNS server. Not anymore with
> > zram activated:
> >
> > Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
> > dev-zram0.swap (/dev/zram0 with 1384MB)
> >
> > which ends up eating 2/3rds of the whole memory budget and FreeIPA
> > installer fails:
> >
> > 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments []
> > and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
> > 'test.openqa.fedoraproject.org', 'realm_name':
> > 'TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> > 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> > 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> > 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> > Prerelease)
> > 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> > ...
> > 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
> > exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
> > 0.77GB available
> > 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is available,
> > 0.77GB available
> > 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
> > /var/log/ipaserver-install.log for more information
>
> Enabling zram doesn't really "take away memory", because no pre-allocation
> happens.
> If there is no physical swap, then adding zram0 should just shown additional
> swap space, so I don't think it could cause the check to fail.
> But if there is physical swap, the zram device is used with higher preference
> than the physical swap. So I think the explanation could be that the VM has
> a swap partition.
The openQA test in question runs after, and uses the hard disk from, a
test that runs a default Fedora Server install:
https://openqa.fedoraproject.org/tests/763650
which, AIUI, should not be creating a swap partition. The logs from the test -
https://openqa.fedoraproject.org/tests/763657/file/role_deploy_domain_controller-var_log.tar.gz
-
do not show any swaps being activated other than zram ones. So no, I
don't think there is a swap partition.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-07 at 09:25 -0800, Adam Williamson wrote: > Hey folks! > > So here's an idea I was thinking about over the RH shutdown: I propose > we gate stable release critical path updates on the openQA tests. A further update on this: FESCo has voted on it and approved it: https://pagure.io/fesco/issue/2548 the Greenwave policy has been updated, and a bug in greenwave which was affecting the decisions has been fixed. I'm now proposing we merge and deploy the Bodhi PR which would make this gating start happening: https://github.com/fedora-infra/bodhi/pull/4180 The contingency plan would be to change the Greenwave policy to drop the requirements for the `_critpath` decision contexts, so they're the same as the non-critpath ones; if this goes badly, that can be done very quickly (it just needs someone with the authority to run the greenwave playbook, like nirik). Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
[Test-Announce] Proposal to CANCEL: 2021-01-25 Fedora QA Meeting
Hi folks! Sorry for the late notice - I'm proposing we cancel the QA meeting tomorrow. I don't have anything urgent this week. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Backwards-incompatible RPM format change in Fedora 34?
On Fri, 2021-01-22 at 09:57 +0200, Panu Matilainen wrote: > On 1/21/21 8:37 PM, Adam Williamson wrote: > > On Thu, 2021-01-21 at 10:53 +0100, Kevin Kofler via devel wrote: > > > Florian Weimer wrote: > > > > With rpm-4.15.1-3.fc32.1.x86_64, I get this error: > > > > > > > > $ rpm -qip > > > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm > > > > error: /var/tmp/rpm-tmp.6iU66n: signature hdr data: BAD, no. of > > > > bytes(88084) out of range error: > > > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm: > > > > not an rpm package (or package manifest) > > > > > > > > Is this expected? > > > > > > > > It seems that rpm-4.16.1.2-1.fc33.x86_64 can parse the RPM just fine. > > > > But rpm-4.14.3-4.el8.x86_64 does not like it, either. > > > > > > Considering that direct upgrades from F32 to F34 (n to n+2) are supposed > > > to > > > be supported, this sounds like a blocker to me. > > > > openQA N+2 upgrade tests have indeed been running into this for a few > > days: > > > > https://openqa.fedoraproject.org/tests/759545#step/upgrade_run/20 > > > > I had been meaning to dig into it a bit more before filing a bug. > > > > Folks, when rpm starts spitting errors like that, don't think, just file > a bug. It's very, very very very unlikely that it's "ok" in any > imaginable meaning. It's not that I thought it was "OK", it's just that these days I tend to like filing a bug report with detailed cause analysis and stuff all wrapped up :) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Backwards-incompatible RPM format change in Fedora 34?
On Thu, 2021-01-21 at 10:53 +0100, Kevin Kofler via devel wrote: > Florian Weimer wrote: > > With rpm-4.15.1-3.fc32.1.x86_64, I get this error: > > > > $ rpm -qip > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm > > error: /var/tmp/rpm-tmp.6iU66n: signature hdr data: BAD, no. of > > bytes(88084) out of range error: > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm: > > not an rpm package (or package manifest) > > > > Is this expected? > > > > It seems that rpm-4.16.1.2-1.fc33.x86_64 can parse the RPM just fine. > > But rpm-4.14.3-4.el8.x86_64 does not like it, either. > > Considering that direct upgrades from F32 to F34 (n to n+2) are supposed to > be supported, this sounds like a blocker to me. openQA N+2 upgrade tests have indeed been running into this for a few days: https://openqa.fedoraproject.org/tests/759545#step/upgrade_run/20 I had been meaning to dig into it a bit more before filing a bug. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
[Test-Announce] 2021-01-18 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2021-01-18 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet for a couple of weeks, and there are interesting goings- on, so let's meet up on Monday. 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 34 status (inc. GNOME 40) 3. Gating proposals/ideas 4. Test Day / community event status 5. Open floor -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-14 at 13:21 +0100, Miro Hrončok wrote: > On 14. 01. 21 13:15, Kevin Kofler via devel wrote: > > Adam Williamson wrote: > > > As feedback on this was mostly positive, I went ahead and did the work. > > > The PR for the Greenwave policy has been merged already, as that does > > > not in itself cause any actual behaviour change: > > > https://pagure.io/fedora-infra/ansible/pull-request/349 > > > > > > The PR for Bodhi is here: > > > https://github.com/fedora-infra/bodhi/pull/4180 > > > > > > merging that *would* cause the proposal to be implemented, and start > > > gating updates. Please yell if you think this isn't ready yet and you > > > didn't yell already, or you see any issues in the practical > > > implementation. Thanks! > > > > Shouldn't such a policy change go through a FESCo vote first? > > > > (I guess they will just wave it through, sadly, but still, I think it ought > > to go through a democratic vote.) > > Or even a change proposal ;) Honestly, I don't really know. To me it doesn't really fit the Change process. If you'd like to have FESCo vote on it I can file a ticket for sure. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-07 at 09:25 -0800, Adam Williamson wrote: > Hey folks! > > So here's an idea I was thinking about over the RH shutdown: I propose > we gate stable release critical path updates on the openQA tests. As feedback on this was mostly positive, I went ahead and did the work. The PR for the Greenwave policy has been merged already, as that does not in itself cause any actual behaviour change: https://pagure.io/fedora-infra/ansible/pull-request/349 The PR for Bodhi is here: https://github.com/fedora-infra/bodhi/pull/4180 merging that *would* cause the proposal to be implemented, and start gating updates. Please yell if you think this isn't ready yet and you didn't yell already, or you see any issues in the practical implementation. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream
On Wed, 2021-01-13 at 13:42 -0800, Kevin Fenzi wrote: > I'm definitely in favor of this effort. ;) > > A few questions inline... > > On Wed, Jan 13, 2021 at 09:53:36AM -0800, Adam Williamson wrote: > ...snip... > > > > that is all it does. The "releases" and "events" are entirely > > arbitrary; a "release" can be any string, and so can the "state" for a > > given "event". An "event" is defined as a state being either reached or > > left; any number of events for the same state can be present for a > > release. > > Might it be good to standardize these? I mean we don't want to have: > > state: "Fedora 34 Beta Released to mirrors" > and then in f35 cycle: > state: "f35b released/mirrors" > > Or at least record somewhere in a doc what we want to use after the > first cycle in use? I was following the lessons we learned with taskotron: make the tool simple and flexible, standardize the usage by convention. (This also means the tool is flexible: if it works out for Fedora, it could be used for...pretty much any other software project that has this issue). Typically submissions should be done by code or at least scripted, and there shouldn't be *too* many systems submitting events, so it should be relatively easy to make sure they follow the same names. But yes, we definitely want everything that submits to call the same release the same thing :) We *could* write a "fedora helper" for submitting events that enforces a house style, but for something this simple I'm not sure it's worthwhile. We could use one of the name formats Bodhi has, or we could use the 'dist' / 'short' names from productmd compose metadata, I guess. > ...snip... > > > > My idea for using this is basically that we deploy an 'official' > > releasestream instance in infra, and then find things that do the > > actual work of moving Fedora releases into and out of given "states" > > and tack on a bit at the end to tell releasestream about it. So when > > e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a > > "submit 'enter freeze' event to releasestream" to that process somehow > > - ideally something that has to be run as part of the process anyway > > would send the POST, but in a pinch a human could do it too. When > > Fedora 34 is being 'released', we tweak that process to include sending > > a releasestream event POST. And so on. > > I see right now this keeps the state/messages in a file store? > I think this is a great app to just run in openshift, but if we do that > I wouldn't want to loose state, so perhaps we store things in a > database? I know thats overkill for this simple stuff, but it would mean > we have everything easily stored/backed up, etc. I guess we could also > just make a persistent volume and make sure to back it up. Yeah, it could be a database too, I guess, I just used a text file because it was easy, honestly, and it also means you can hand edit stuff quite easily (this would allow fixups for incorrect names, and it'd also make it easy to 'reconstruct' historical schedules, which I might do at some point). If you file a ticket for adding db support I'll look at it. > ...snip... > > > > > So, what do folks think? Does this seem like a good idea? Should I go > > ahead with trying to get it deployed and onboard things to it? Any > > comments, ideas, potential problems? Thanks! > > Yeah, I like it and definitely think it's worth a try! > > Thanks for implementing it. Thanks for the feedback! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Attempting to allow for a source of truth for Fedora release cycle information: releasestream
Hi folks!
Before the RH holiday shutdown, I started a new project designed to
address a long-standing pain point in Fedora: we don't really have a
good source of truth for release cycle information. I'm thinking of
situations where something:
* Needs to know what the "current stable" Fedora release(s) are
* Needs to know if Fedora X is Branched
* Needs to know whether Fedora X Beta happened yet
* Needs to know whether Fedora X is frozen
...etc etc etc. Some of this information is available...sort of...from
various different systems, with various awkward caveats that I won't
dive into unless someone asks. But there isn't really a single source
of truth for it, and some of it just isn't really available in any
easily machine-consumable way.
So I wrote releasestream:
https://pagure.io/fedora-qa/releasestream
releasestream is intended to be a system that will let us do this. It
is a very very simple webapp with three capabilities:
* It can read a simple record ("stream") of "release events" for a
"release" and produce several static JSON representations of the
information
* It can write an entry to one of these streams in response to a
properly-formatted POST request
* It can publish a message when a new entry is received
that is all it does. The "releases" and "events" are entirely
arbitrary; a "release" can be any string, and so can the "state" for a
given "event". An "event" is defined as a state being either reached or
left; any number of events for the same state can be present for a
release.
The JSON outputs are basically "states by release" and "releases by
state", as you might want either depending on what you're doing. You
can conveniently look up "what releases are currently in state X?" or
"what states is release X currently in?".
This all works right now; the main thing that isn't implemented yet is
any form of authentication. Right now if you can talk to the server you
can submit events. I wanted to check if there is interest in moving
forward with this, and discuss various options, before working on that.
There is a ticket where I sketched out various possible approaches:
https://pagure.io/fedora-qa/releasestream/issue/2
My idea for using this is basically that we deploy an 'official'
releasestream instance in infra, and then find things that do the
actual work of moving Fedora releases into and out of given "states"
and tack on a bit at the end to tell releasestream about it. So when
e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a
"submit 'enter freeze' event to releasestream" to that process somehow
- ideally something that has to be run as part of the process anyway
would send the POST, but in a pinch a human could do it too. When
Fedora 34 is being 'released', we tweak that process to include sending
a releasestream event POST. And so on.
The thing I like about this design is that there's a low barrier to
entry, and can easily be adopted piecemeal but still be immediately
useful for some things - as long as the event your code needs to watch
for has been "onboarded", you're good. It also allows for the
implementation details of a state change to change radically - it can
go from being done by a human to being done by system X to being done
by system Y, and all that needs to happen is to ensure the same dead
simple POST request is sent to the same server.
So, what do folks think? Does this seem like a good idea? Should I go
ahead with trying to get it deployed and onboard things to it? Any
comments, ideas, potential problems? Thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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
Re: Proposal: gate stable release critical path updates on openQA test results
On Mon, 2021-01-11 at 12:09 -0500, Stephen Gallagher wrote: > To rephrase their statements in my own words (and correct me if I get > them wrong): > Kevin is suggesting that he believes that maintainers should be the > sole arbiters of when a package is pushed, not that maintainers are > infallible. > Adam is saying that we have tried Kevin's approach previously and > found it to be less successful on the whole than what we are doing > right now. Not quite, no. What I'm saying is that Kevin suggests that if we just make the process require manual action at each step and remove things like autopush, maintainers will get it right (AIUI). I'm saying that IMHO the evidence suggests this is not true, for two reasons: i) As I recall, before we had autopush or enabled it by default, maintainers still did things wrong sometimes. ii) even with autopush, maintainers *can* be more careful, in three possible ways. They can disable autopush, or they can include the dependencies in the library update, or they can wait for the library update to go stable before pushing the dependent update even to testing. As I understand Kevin's argument, he's saying that some maintainers might not bother to do any of those three things, *but* if we disabled autopush, they *would* check that the updates their update depends on have gone stable before pushing it stable manually. I'm sceptical that that is the case. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Mon, 2021-01-11 at 15:41 +0100, Kevin Kofler via devel wrote: > Matthew Miller wrote: > > And, also hopefully also a rare occasion, but if this were enabled (and > > the definitions up to date), problems like > > > https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/CAS6KHTZLR6LUNWEVK3BOIO6HVNQDETZ/#N5HJDKMTGOTL44BT2HZ43LE6Q23345IQ > > would be caught before they hit users. > > This issue was a result of using autopush. See also: > https://bodhi.fedoraproject.org/updates/FEDORA-2021-5da509fd8e#comment-1807700 > A maintainer would normally not manually push an update before the library > update it depends on, the autopush logic was what made that accident happen. Well, but maintainers *did*, back before we had autopush. You might just as well say "a maintainer would not normally enable autopush if they're submitting an update that depends on another update that is not yet stable", because they shouldn't. But they do. All the time. Maintainers get stuff wrong sometimes. We've tweaked the mechanisms in various ways for more than a decade and that hasn't stopped happening yet. Even if we changed Bodhi to precisely your preferred configuration, I'm gonna posit that maintainers would still manage to get stuff wrong sometimes. :) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Mon, 2021-01-11 at 00:46 +0100, Miro Hrončok wrote: > On 10. 01. 21 23:25, Matthew Miller wrote: > > On Sun, Jan 10, 2021 at 02:20:04PM -0800, Adam Williamson wrote: > > > > All this does is making it again harder to issue bug fixes for the very > > > > packages where it matters the most. > > > > > > But...if the tests pass it doesn't, and I already said that the tests > > > pretty much always pass and I actively work to resolve any case where a > > > test fails when it shouldn't. > > > > > > You're not going to be waiving results for every update, here. It would > > > be a pretty rare occurrence. > > > > And, also hopefully also a rare occasion, but if this were enabled (and the > > definitions up to date), problems like > > https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/CAS6KHTZLR6LUNWEVK3BOIO6HVNQDETZ/#N5HJDKMTGOTL44BT2HZ43LE6Q23345IQ > > would be caught before they hit users. > > I believe we should gate on installability first. > > See https://pagure.io/fesco/issue/2343 If the package is actually part of the test scenario, openQA effectively does this. There is a check wired into all the update tests at the end. It checks whether any package that's in one of the updates is installed, but is *not* the version from the update, and fails if so - because this usually means the package was not installable, so when the test updated the system with the packages from the update available, dnf did not update it. openQA won't catch a package not being installable if it is not actually part of the system-under-test in any of the tests, but most critical path packages ought to be. Is there any reason you think these need to go in a particular order? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Sun, 2021-01-10 at 19:25 +0100, Kevin Kofler via devel wrote: > Pierre-Yves Chibon wrote: > > This is basically what this thread is asking. If we make a test mandatory, > > no updates will be pushed when this test fails unless the failure is > > waived. > > > > So it seems we are all in agreement! > > Not all. I am still opposed to this. We already have too many mandatory > requirements for manual update pushes (IMHO, ANY mandatory requirement is a > mandatory requirement too many), we do not need yet another one. > > All this does is making it again harder to issue bug fixes for the very > packages where it matters the most. But...if the tests pass it doesn't, and I already said that the tests pretty much always pass and I actively work to resolve any case where a test fails when it shouldn't. You're not going to be waiving results for every update, here. It would be a pretty rare occurrence. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Sun, 2021-01-10 at 12:44 -0500, Neal Gompa wrote: > On Sun, Jan 10, 2021 at 12:32 PM Adam Williamson > wrote: > > > > On Sat, 2021-01-09 at 12:27 +0100, Vitaly Zaitsev via devel wrote: > > > On 08.01.2021 23:24, Matthew Miller wrote: > > > > I think we should get to the point where it blocks manual pushes > > > > (without > > > > the failure being waved). If the test is broken, fix the test. > > > > > > Some tests are permanently broken. For example rpminspect-pipeline - > > > filesize. > > > > > > It's okay when the size of the files in the package changes, but it > > > always fails. > > > > That's not an openQA test, so not in the scope of this proposal. > > Sure, but perhaps we should establish a means to evaluate the > usefulness of tests on a regular cadence. Tests *can* provide value, > let's not kid ourselves, but if we just turn them on and train people > to ignore and waive them, then they're worse than a burden, they're a > waste. > > As part of enabling openQA tests, we should also establish a means to > evaluate the usefulness of *all* distro-wide checks. Is "I look at all the results every day" a means? :) I mean, I do. And I'll continue to. Even if a result is 'waived' for Bodhi purposes, I'll still see it as a failure in openQA. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
[Test-Announce] Proposal to CANCEL: 2021-01-11 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomorrow. I don't have anything urgent this week. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: gate stable release critical path updates on openQA test results
On Sat, 2021-01-09 at 12:27 +0100, Vitaly Zaitsev via devel wrote: > On 08.01.2021 23:24, Matthew Miller wrote: > > I think we should get to the point where it blocks manual pushes (without > > the failure being waved). If the test is broken, fix the test. > > Some tests are permanently broken. For example rpminspect-pipeline - > filesize. > > It's okay when the size of the files in the package changes, but it > always fails. That's not an openQA test, so not in the scope of this proposal. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Fri, 2021-01-08 at 23:26 +0100, Miro Hrončok wrote: > On 08. 01. 21 23:24, Matthew Miller wrote: > > On Fri, Jan 08, 2021 at 09:34:29PM +0100, Kevin Kofler via devel wrote: > > > > So if anything, I think this change is in line with your views here. > > > > > > Well, if (and as long as) the gating only blocks the autopush and does not > > > prevent a manual push (as yet another requirement), I withdraw my > > > objection. > > > > I think we should get to the point where it blocks manual pushes (without > > the failure being waved). If the test is broken, fix the test. > > That is easier said than done. What if the failure is unrelated to my update? I'm essentially committing us to making sure it won't be. As I explained in the initial email, I already do this quite conscientiously. The only way this can be the case is if an update which causes a test failure gets pushed stable. Either the update is tested but the failure is disregarded and the update pushed (which this proposal will make *less* likely, but not impossible, since failures can be waived) or the problem is introduced by an update that isn't tested (this is unusual but does sometimes happen). Neither of these things happens terribly often. When one does happen, I treat it as a high priority to get it fixed or worked around and re-run all non-related tests that were affected by it. And, of course, we *can* waive failures if all else fails. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Fri, 2021-01-08 at 21:34 +0100, Kevin Kofler via devel wrote: > Stephen Gallagher wrote: > > I think you've got this backwards, Kevin. This is about disabling the > > autopush if any of those tests fail. So the result would be that > > critical path packages would get 1) more testing before the existing > > autopush occurs and 2) if any of those tests fail, it won't get pushed > > stable unless a conscious decision is made by the maintainer. > > > > So if anything, I think this change is in line with your views here. > > Well, if (and as long as) the gating only blocks the autopush and does not > prevent a manual push (as yet another requirement), I withdraw my objection. It's not quite that. You can't just hit the 'push' button in Bodhi if one of the tests has failed, but you *can* push the update. You have to waive the failed test first, then push it. See https://docs.fedoraproject.org/en-US/ci/gating/#_waive . -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Fri, 2021-01-08 at 03:08 +0100, Kevin Kofler via devel wrote: > Adam Williamson wrote: > > So here's an idea I was thinking about over the RH shutdown: I propose > > we gate stable release critical path updates on the openQA tests. > > -1 > > We already enforce too strict requirements on updates, *especially* those > that deliberately or accidentally end up in the "critical path", instead of > trusting the maintainer to do the right thing. This only makes it worse. > > Pushing to stable should be a concious decision made by a person, the > maintainer, not by automated rules of any kind. It already often isn't, because people use the autopush mechanisms. Which are the default. I know you don't agree with that either, but they're already there and are used on almost all updates. There have been multiple occasions where an update that had a bug which openQA caught got autopushed stable because they got sufficient positive karma before I could notice the failure and -1 the update to disable autopush. That's the specific case I'm trying to address with this. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-07 at 22:35 +0100, Miro Hrončok wrote: > On 07. 01. 21 18:25, Adam Williamson wrote: > > What do people think of this idea? Any questions? Thanks! > > I'd like to see the critpath definition up to date before we do this. > > https://pagure.io/releng/issue/8948 It doesn't really matter that much, I don't think. I mean, ideally I'd want to gate *all* updates, we only don't do that because of capacity issues. As long as the gating and the testing are lined up (as they would be), I don't think that's really worth waiting for tbh. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-07 at 20:58 +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 07, 2021 at 09:25:44AM -0800, Adam Williamson wrote: > > Hey folks! > > > > So here's an idea I was thinking about over the RH shutdown: I propose > > we gate stable release critical path updates on the openQA tests. > > +1 > > > The result of this would be that critpath updates could not go stable > > if any of the openQA tests failed, unless a waiver was issued. I think > > this should be viable and not cause any major issues. > > Just to confirm: the packager who issues the update is allowed to > create the waiver? At least that, yeah. I think it's the same permission as editing an update - if you can edit the update, you can issue a waiver for it. That's a whole *other* can of worms I'm going to get into later ;) > When I initially read the proposal, I was immediately worried about > false positives. But the fp rate seems low, so it looks alright to > start gating. Right, we basically aim to resolve *all* false failures one way or another, rapidly, and I think we've got a fairly good record there. > > There's the related issue that the critpath list is outdated: > https://pagure.io/releng/issue/8948. > It's not really required to have it up-to-date, but if we don't we'll > be gating on some packages we shouldn't gate on, and not gating on > some we should. Yup. It's not as bad as I thought, though - best as I can tell there's actually only one unapplied change, plus the PR I have open. Of course, it really should be re-generated regularly to take changes in dependencies into account. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-07 at 11:23 -0800, Adam Williamson wrote: > On Thu, 2021-01-07 at 18:48 +, Mattia Verga via devel wrote: > > Il 07/01/21 18:25, Adam Williamson ha scritto: > > > ...snip... > > > > > > Implementing this would be relatively simple, and would involve two > > > things: adding some new bits to Fedora's greenwave policy definition, > > > and patching Bodhi to use a different decision_context for greenwave > > > queries for non-critpath updates and critpath updates. I could have > > > both those changes ready for review in a day, probably. It would be > > > equally simple to revert the change if it turned out to be a bad idea. > > > > > > ...snip... > > > > I thought it would just require to add a gating.yaml file to src.fpo > > package repository listing the required tests to pass for gating be > > effective. Isn't that so? > > Well yes, but that wouldn't be a sensible way to do this, as we'd have > to do it for *every single package* we wanted to gate. Which is > hundreds, I think. > > That mechanism is intended for tests applicable to single packages or > small groups of packages. At this scale it makes more sense to amend > the project-wide policy, as I proposed. That file is: > https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/greenwave/templates/fedora.yaml > if you're interested. ...oh and actually there's another very in-the-weeds reason that wouldn't work, which is commented in that file: # The "remoterule" policy applies policies configured in individual # package repositories. See Greenwave docs/policies.rst and # https://docs.fedoraproject.org/en-US/ci/gating/ for details. Note # we don't have a remoterule policy for bodhi_update subject type # because Greenwave doesn't consider it to support remote rules. those in-repo policies can actually only be used for tests that run at the *package* level (the 'koji_build' 'subject_type', in Greenwave's terms). In practice, that means tests than run in Fedora CI. As the system currently works, you actually can't use a per-repo policy to gate on tests that run at the *update* level (in practice, openQA tests). It would be possible but not *entirely* trivial to change this. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-07 at 18:48 +, Mattia Verga via devel wrote: > Il 07/01/21 18:25, Adam Williamson ha scritto: > > ...snip... > > > > Implementing this would be relatively simple, and would involve two > > things: adding some new bits to Fedora's greenwave policy definition, > > and patching Bodhi to use a different decision_context for greenwave > > queries for non-critpath updates and critpath updates. I could have > > both those changes ready for review in a day, probably. It would be > > equally simple to revert the change if it turned out to be a bad idea. > > > > ...snip... > > I thought it would just require to add a gating.yaml file to src.fpo > package repository listing the required tests to pass for gating be > effective. Isn't that so? Well yes, but that wouldn't be a sensible way to do this, as we'd have to do it for *every single package* we wanted to gate. Which is hundreds, I think. That mechanism is intended for tests applicable to single packages or small groups of packages. At this scale it makes more sense to amend the project-wide policy, as I proposed. That file is: https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/greenwave/templates/fedora.yaml if you're interested. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, 2021-01-07 at 09:48 -0800, Kevin Fenzi wrote: > On Thu, Jan 07, 2021 at 09:25:44AM -0800, Adam Williamson wrote: > > Hey folks! > > > > So here's an idea I was thinking about over the RH shutdown: I propose > > we gate stable release critical path updates on the openQA tests. > ...snip... > > +1 from me. Lets do it! > > So, this would only be updates to stable branches right? > > Or would it also include critical path updates in rawhide? For now, yes. Well, it would be either stable branches only, or stable plus Branched - we can choose, but both are possible as we already test both. I think doing Branched would probably be viable. This is #1 in a series of 3 AdamW Shutdown Thoughts proposals, in fact :) #3 is "do update testing on Rawhide". But that one is the most thorny and complicated and comes with a ton of awkward implications, which is why it's #3. tl;dr preview summary - eventually I'd like to get there (testing Rawhide updates and gating on the results). But there's a lot of stuff we'd have to work through first. Stay tuned. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Proposal: gate stable release critical path updates on openQA test results
Hey folks! So here's an idea I was thinking about over the RH shutdown: I propose we gate stable release critical path updates on the openQA tests. Currently we run a set of ~50 tests on every critpath update. For an F33 update this is the set: https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=33&build=Update-FEDORA-2021-4634e99fa0&groupid=2 The results are reported to Bodhi - you can see them on the "Automated Tests" tab - but don't automatically affect whether you can push the update...yet. :) I'm proposing we start gating these updates on those test results. We've actually discussed this before but always thought it was difficult or impossible because these tests aren't run on all updates, only critical path updates (and a small hand-tended list of additional packages to test updates for that's maintained in the scheduler). Greenwave doesn't have a "require this test to be passed or not present" feature, and it would actually be hard/not a good idea to do so, so we sort of thought we were stuck. But recently I was editing the Fedora greenwave config and realized there's actually a simple solution: Bodhi can just make *different greenwave queries* for critpath and non-critpath updates. We can have alternate greenwave "decision contexts" for critpath and non-critpath updates, and have the critpath one require passes for the openQA tests. That solves the problem neatly, AFAICS. The result of this would be that critpath updates could not go stable if any of the openQA tests failed, unless a waiver was issued. I think this should be viable and not cause any major issues. Implementing this would be relatively simple, and would involve two things: adding some new bits to Fedora's greenwave policy definition, and patching Bodhi to use a different decision_context for greenwave queries for non-critpath updates and critpath updates. I could have both those changes ready for review in a day, probably. It would be equally simple to revert the change if it turned out to be a bad idea. I've been monitoring the update test results ever since we started doing update testing, and I check *every* update test failure. Sometimes there's a test system issue or a non-bug change that makes the tests fail, and when that happens, I fix the problem and re-run the tests. Where the failure is a real bug, I investigate it and file a report to the appropriate place, then add a comment on the update explaining the issue, usually with negative karma. So we've been doing something similar to "gating" for years, just implemented manually :) I would like to make it real gating to avoid cases where an update with a bug gets pushed stable before I manage to file a comment; this has happened a few times to packages which tend to get feedback very fast, or if an update comes out over a weekend or something and I don't see the failure for a few days. There are a few other folks already with sufficient knowledge of the openQA system that they could investigate a failure if necessary - lruzicka and pwhalen, for instance - and we're happy to help others learn the process if they'd be interested. You can see the recent history of update tests here: https://openqa.fedoraproject.org/group_overview/2?limit_builds=100 there are more with a failure than would usually be the case. This is because of a bug in fwupd which causes GNOME Software to hang sometimes. I've spent this week investigating exactly that bug with hughsie. As part of that process we did find a workaround a couple of days ago; if we had gating enabled, I would have put that workaround into production to make the test pass reliably and not cause updates to be gated, and/or just restarted failed tests until they passed. There's also a change in how Cockpit renders a page that caused the recent Cockpit updates to get a failure each, so after I write this email I'll be updating that test and re-running it. That should give you a flavor of how things go in general. What do people think of this idea? Any questions? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
[Test-Announce] 2021-01-04 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2021-01-04 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers, and happy new solar year! We didn't meet since the holiday break, so let's meet on Monday and see where we're at. 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 34 status and Changes 3. Matrix, redux 4. Test Day / community event status 5. Open floor -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Wed, 2020-12-30 at 14:53 -0500, Ben Cotton wrote: > == Benefit to Fedora == > > This change will not only simplify and make less confusing the GRUB > configuration but also allow the following improvements: > > * To have a consistent configuration across all the architectures using GRUB. > * Allow the same installation to be booted with either EFI or legacy BIOS. > * Use the same documentation and commands for all architectures > instead of having EFI as a special case. > * Make GRUB configuration tools more robust by not relying on symbolic > links to be created and not having to handle platform specific cases. > * Align with images generated by COSA and OSBuild on how the GRUB > configuration files are used. > * Align with other Linux distributions on how the GRUB configuration > files are used. But: > == Upgrade/compatibility impact == > > The changes will only be for new installations, existing systems will > not be impacted and will continue using the grub.cfg and grubenv files > that are located in the ESP. To me several of the benefits seem to not really be true, so long as this is the plan for upgrades. * We wouldn't have a "consistent configuration" across everybody, really, because anyone who upgraded from pre-F34 would still have the old config; every bootloader debugging session ever would start by figuring out which case this was. * We can't really use the same "documentation and commands" for the same reason. We either have to document both possibilities forever, or accept that our docs will be incorrect for anyone who upgraded from pre-F34. * We can't really make the tools "more robust" in the way cited because they'll still have to handle both cases as long as both cases exist. If anything this makes them more fragile: the more divergent paths a tool has to support, the more likely it is something will break. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, 2020-12-29 at 18:54 +, Gary Buhrmaster wrote: > On Tue, Dec 15, 2020 at 11:45 PM Adam Williamson > wrote: > > > I wrote in the update that in my opinion the solution for this bug > > can't involve expecting add-ons to suddenly get re-signed en masse, or > > users to change their local configuration. It needs to keep working as > > it did before. If the policy is ahead of the real world, the policy > > needs to be loosened. > > It was my (possibly failing) recollection that Mozilla > has been signing add-ons with SHA2 (and SHA1 > for compatibility) for a few years now. Is this just > an issue because Mozilla has not re-signed existing > add-ons (which while is obviously not something to > be taken lightly, because they do control the primary > distribution point(*) should be at least theoretically > possible to do a bulk re-signing, and probably a > good thing to do to avoid needing to downgrade > their security stance), or is Mozilla not signing > with SHA2 as I thought? Well, installing uBlock Origin (which is a pretty frequently updated addon) on a fresh VM fails, with the change. So I suspect it's the latter. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Mon, 2020-12-28 at 15:36 -0800, Kevin Fenzi wrote: > On Mon, Dec 28, 2020 at 10:58:49PM +0100, Marius Schwarz wrote: > > Am 18.12.20 um 15:33 schrieb James Szinger: > > > On Tue, 15 Dec 2020 11:17:21 -0800 > > > Kevin Fenzi wrote: > > > > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > > > will stop working. Worse they will appear corrupted, so you will have > > > > to remove them and re-install them (after downgrading nss). > > > > > > > > For now, downgrade nss or avoid updating to it until things can get > > > > sorted out. > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1908018 > > > > > > > > kevin > > > I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or > > > are there going to be a lot of unhappy Firefox users? The bug is > > > still open. > > > > > > > nss 3.59.0-3 did not reach Rawhide AARCH64 repos and therefore firefox > > addons can't be installed atm. > > Yeah, workaround for now: > > sudo update-crypto-policies --set FEDORA:32 > > PS: no need to cc me on posts to the list. :) It's not that something "didn't reach" Rawhide, either. The NSS maintainer intends nss in Rawhide to respect the system-wide policy by default. We need mstransky to patch Firefox to use the system-wide NSS *but* allow SHA-1 signatures for add-ons. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Stale proven packagers
On Wed, 2020-12-23 at 18:04 +0100, Florian Weimer wrote: > * Gary Buhrmaster: > > > It does support it, but AFAIK does not require it. > > > > Arguably those with elevated access (provenpackagers(*)) > > should be required to use a hardware token such > > as a FIDO2 authenticators with biometrics and/or > > PIN required (some phones with biometrics are > > are equivalent to external tokens) where passwords > > themselves can away. That may be a bridge too > > far at this point, but I would like to see that as a goal > > to work towards (2021 should be the year passwords > > die according to Microsoft). > > Is there even meaningful two-factor authentication support for Git > pushes, anywhere? (Not just in the Fedora infrastructure.) I mean, they *kinda* are 2FA already: we use certs and hopefully packagers all have a passphrase, so you need the cert and the passphrase. The weakest point in the current system is really the FAS password. If you have a packager's FAS password you can change the ssh key associated with the account to another that you control, and the FAS password is also all you need to run a build and submit it to Bodhi. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Stale proven packagers
On Wed, 2020-12-23 at 15:05 +, Gary Buhrmaster wrote: > On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel > wrote: > > > > > Maybe Fedora should add 2FA support and require it for the most powerful > > groups? > > > > It does support it, but AFAIK does not require it. old-FAS (the current one) has 2FA support and requires it for things like root access on infra hosts. There's at least one bug in the old-FAS 2FA implementation which makes it close to useless, so it probably wouldn't be worth extending the requirements for 2FA until new-FAS (based on AAA) is deployed. At that point I think it would make sense to require packager accounts to have a second factor, and require that second factor when getting a Kerberos ticket and when changing the ssh keys on the account. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora CoreOS rawhide stream
On Tue, 2020-12-22 at 15:22 -0800, Adam Williamson wrote: > On Mon, 2020-12-21 at 17:34 -0500, Jonathan Lebon wrote: > > We've recently started a rawhide "mechanical" stream of Fedora CoreOS > > (mechanical streams are streams that are meant for developers and that > > don't use RPM lockfiles). You can see the first build here: > > > > https://builds.coreos.fedoraproject.org/browser?stream=rawhide > > > > This will allow us to more easily track breaking changes in rawhide > > and work with maintainers and upstreams to resolve them earlier in the > > process. (Yes, this is long overdue -- better late than never!) > > Cool, I'll set openQA up to test this stream too. ...well, I will as soon as https://builds.coreos.fedoraproject.org/streams/rawhide.json isn't 403 any more :D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora CoreOS rawhide stream
On Mon, 2020-12-21 at 17:34 -0500, Jonathan Lebon wrote: > We've recently started a rawhide "mechanical" stream of Fedora CoreOS > (mechanical streams are streams that are meant for developers and that > don't use RPM lockfiles). You can see the first build here: > > https://builds.coreos.fedoraproject.org/browser?stream=rawhide > > This will allow us to more easily track breaking changes in rawhide > and work with maintainers and upstreams to resolve them earlier in the > process. (Yes, this is long overdue -- better late than never!) Cool, I'll set openQA up to test this stream too. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Stale proven packagers
On Tue, 2020-12-22 at 13:23 -0800, Kevin Fenzi wrote: > > > Perhaps we need a process for cleaning up membership of this extremely > > powerful group? If the FAS password of *any one* of those user accounts > > were somehow compromised (or if just one of them decided they had a > > grudge against Fedora now and were going to have some fun), the results > > could be...unfortunate. > > Oh look, flashback 13 years: > > https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal > > Anyhow, I was in favor of something then, but it got shouted down, and I > am still in favor now of some kind of checkin process. I think it should > be light weight tho... always being bothered is bad. On the other hand > it's hard to know how to notify people. If you send email once a week > for 4 weeks and get no answer does that mean they are missing? Or that > your email is going to the spam folder? Or that they are on a long > vacation not checking email? It's hard to balance. So that proposal was just for all packagers. I think it should at least be reasonable to set a relatively high bar for being a provenpackager. Proven packagers really should be people who are deeply involved in Fedora work on a daily basis, I think, and so should be able to respond to a regular check-in process like this or the one bcotton proposed. And the result would only be that they'd lose provenpackager privileges, which could quite easily be restored if it turned out they'd just gone on a yak farming retreat for a bit or something. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Stale proven packagers
A propos of some discussion of the Solarwinds news, it occurred to me
to check how many proven packager accounts there are in FAS. There are
251, which seems like a lot. Then it occurred to me to check how many
of them are inactive, so I wrote a little script:
===
#!/usr/bin/python3
import getpass
from fedora.client.fas2 import AccountSystem
from koji import ClientSession
username = input("FAS user name: ")
password = getpass.getpass("FAS password: ")
acc = AccountSystem(username=username, password=password)
pps = acc.group_members("provenpackager")
ks = ClientSession("https://koji.fedoraproject.org/kojihub";)
for pp in pps:
user = ks.getUser(pp["username"])
if not user:
print(f"{pp['username']} NON-EXISTENT IN KOJI")
continue
uid = user["id"]
if ks.listBuilds(userID=uid, createdAfter="2019-01-01 00:00:00"):
continue
print(pp["username"])
===
Here is the list it produced:
alexl
alexlan
arg
athimm
atkac
bernie
bkabrda
bpepple
caillon
cebbert
chitlesh
cweyl
cwickert
davej
dbhole
dcbw
denis
dgregor
dsd
ecik
ensc
epienbro
fitzsim
gdk NON-EXISTENT IN KOJI
gemi
ianweller
iarnell
ilianaw
ishcherb
ivazquez
ixs
jcapik
jkeating
johnp
jpo
jreznik
jspaleta
jstanley
jsteffan
jwilson
kasal
katzj
kay
ke4qqq
kengert
kyle
kylev
laxathom
lennart
lmacken
lutter
markmc
mbarnes
mef
mjakubicek
mjg59
mmahut
mmaslano
mmcgrath
msrb
mstuchli
npmccallum
overholt
paragn
patches
pertusus
pjp
praveenp
pravins
rakesh
rkuska
rvokal
s4504kr
scop
sdake
sdz
skvidal
stahnma
steve
sundaram
thomasvs
toshio
tradej
tremble
tstclair
tuxbrewr
vakwetu
vicodan
willb
wolfy
that's 90 of the 251 who still have provenpackager privileges, but
haven't run any kind of Koji build since at least 2019-01-01 (if you
check, it turns out many of them haven't run a build since long before
then). Many of them, to my knowledge, don't work on Fedora at all any
more and haven't for years. At least one of them, to my and everyone
else's knowledge, is sadly dead and has been for some time. One account
- it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't
exist in koji (any more?)
Perhaps we need a process for cleaning up membership of this extremely
powerful group? If the FAS password of *any one* of those user accounts
were somehow compromised (or if just one of them decided they had a
grudge against Fedora now and were going to have some fun), the results
could be...unfortunate.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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
Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
On Sat, 2020-12-19 at 20:07 +0100, Dan Čermák wrote: > clime writes: > > > On Thu, 17 Dec 2020 at 22:04, James Szinger wrote: > > > > > > On Thu, 17 Dec 2020 14:05:40 -0500 > > > Ben Cotton wrote: > > > > > > 1. How does this affect users who download, maybe modify, and rebuild > > > the SRPM? Can they continue to use rpmbuid and mock as they have > > > been? Does the SRPM contain the pre-processed or post-processed spec > > > file? > > > > They can use mock if the preprocessing will be enabled for the > > respective chroots where it is enabled in Koji/Fedora. > > They can't directly use rpmbuild for those packages that contain the > > macros. But they can use rpkg/fedpkg to do the work. > > Or preprocess spec first and then use rpmbuild. I am aware this is a > > negative point of this change. > > This is a pretty big downside imho, as that means that building Fedora > packages that use these new kinds of macros in other build systems will > become impossible or at the very least, very, very difficult. There is > quite some development going on in OBS (afaik e.g. Igor exported all > Fedora Rust rpms to OBS for automated rebuilds) and enabling this > preprocessing will make these packages FTBFS in OBS. I mean, only if you're sourcing from dist-git? The .src.rpm will have the post-processed spec file and should rebuild anywhere without issues, presumably. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Unannounced soname bump libldns.so.2() -> libldns.so.3()
On Sat, 2020-12-19 at 18:23 +0100, Miro Hrončok wrote: > > I suspect a compose might fail because of this as well. Shall we untag the > build? I rebuilt libreswan (which did fail the compose) already. I'll try the others shortly. Note libreswan had similarly been bumped to a newer version in git but not built; I bumped it back down to the last version that was actually built then did the rebuild on top of that, as I don't know if the newer version (it was an RC) was actually meant to go out yet, and pemensik's mail is auto-responding as OOO. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Unannounced soname bump: ldns
A new build of ldns was done for Rawhide yesterday by law/pemensik: https://koji.fedoraproject.org/koji/buildinfo?buildID=1660180 This build changes the soname of libreport from libldns.so.2 to libldns.so.3. This bump was not announced AFAICS, and none of its several dependencies appear to have been rebuilt: dnsperf-0:2.4.0-2.fc34.x86_64 dnssec-trigger-0:0.17-1.fc34.x86_64 flamethrower-0:0.11.0-1.fc34.x86_64 ldns-devel-0:1.7.0-32.fc33.x86_64 ldns-utils-0:1.7.0-32.fc33.x86_64 libreswan-0:4.1-3.fc34.x86_64 netresolve-backends-aresdns-0:0.0.1-0.28.20160317git.fc33.x86_64 netresolve-backends-avahi-0:0.0.1-0.28.20160317git.fc33.x86_64 netresolve-backends-compat-0:0.0.1-0.28.20160317git.fc33.x86_64 netresolve-backends-ubdns-0:0.0.1-0.28.20160317git.fc33.x86_64 netresolve-compat-0:0.0.1-0.28.20160317git.fc33.x86_64 netresolve-core-0:0.0.1-0.28.20160317git.fc33.x86_64 netresolve-tools-0:0.0.1-0.28.20160317git.fc33.x86_64 nordugrid-arc-plugins-needed-0:6.9.0-1.fc34.x86_64 opendnssec-0:2.1.7-1.fc34.x86_64 python3-ldns-0:1.7.0-32.fc33.x86_64 This broke today's Rawhide compose due to a KDE dependency chain that involves libreswan: https://koji.fedoraproject.org/koji/taskinfo?taskID=57780927 Please remember to announce soname bumps ahead of time and arrange rebuilds of dependencies so this kind of problem can be avoided. Thanks. I will try and rebuild things, at least compose-critical things, now, but if straight rebuilds don't work might need people to help out. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Fri, 2020-12-18 at 07:33 -0700, James Szinger wrote: > On Tue, 15 Dec 2020 11:17:21 -0800 > Kevin Fenzi wrote: > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > will stop working. Worse they will appear corrupted, so you will have > > to remove them and re-install them (after downgrading nss). > > > > For now, downgrade nss or avoid updating to it until things can get > > sorted out. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1908018 > > > > kevin > > I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or > are there going to be a lot of unhappy Firefox users? It's fixed. > The bug is still open. Because we still need to do something (or, rather, get Mozilla to do something) about the underlying situation. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: What is the most time consuming task for you as packager?
On Wed, 2020-12-16 at 11:18 -0800, Kevin Fenzi wrote: > On Wed, Dec 16, 2020 at 11:06:45AM -0800, Adam Williamson wrote: > > > > See I thought that too at first, and was going to cite it, but then I > > thought, wait. The problem isn't that the update *actually broke the > > ABI*, right? The problem is that it *unnecessarily bumped the soname*. > > I think abidiff's job is to catch the *opposite* problem, isn't it? > > Where the ABI changes but the soname isn't bumped. > > > > I would need to check, but I suspect possibly in this case abidiff just > > wouldn't do anything at all, because what it would seem to make sense > > to do is run it only on pairs of shared libraries with identical > > sonames from the two package builds. When the soname is bumped, it > > wouldn't make sense to run abidiff, because you'd *expect* the ABI to > > change in that case. > > Ah, indeed. That could well be the case. > > I wonder if we shouldn't setup a 'soname bump test', make it gating for > everything and require waiving it. It would be a extra step and more > hassle, but it would prevent unintended soname bumps from landing, it > would make it a deliberate choice. What I would prefer to do is get a reliable reverse dep check (we may have one already, I haven't looked) and gate updates on it. This would require soname bumps for Rawhide to be sent out as multi-package updates containing rebuilds of all dependent packages. This would be a big change, but I think we're at the point where we should really think about making it happen. We basically have all the necessary pieces to do it at this point, and the experience. We just need to piece through all the work and communication required. We might need to re-examine some permissions issues as part of it, too (including Bodhi's rather strict permission rules for editing updates). As a preview, after the RH shutdown - in the New Year - I'm considering seriously pushing some proposals for heavier gating across Fedora. I'm at least wanting to look at gating Rawhide composes (initially on a smaller set of required tests than the one we've been prototyping for a while), gating critpath updates on at least some of the openQA tests, and getting a subset of openQA update tests running on Rawhide critpath updates and considering if we can start doing some Rawhide update gating as per above. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: What is the most time consuming task for you as packager?
On Wed, 2020-12-16 at 10:48 -0800, Kevin Fenzi wrote: > On Wed, Dec 16, 2020 at 10:01:19AM -0800, Adam Williamson wrote: > > On Wed, 2020-12-16 at 12:37 +0100, Vitaly Zaitsev via devel wrote: > > > On 15.12.2020 23:29, Miroslav Suchý wrote: > > > > What you - as Fedora packager - find most time consuming on packaging? > > > > > > ABI check between shared libraries updates. > > > > > > Bodhi used to run abidiff automated tests, but after Fedora Infra moved > > > to the new datacenter, they disappeared. > > > > Bodhi doesn't run any tests, it only shows results from other systems. > > > > abi check was run by Taskotron, which has been retired. The approximate > > replacement is Fedora CI, which should run rpminspect (among other > > tests). rpminspect runs abidiff. So there should still be abidiff > > results, if Fedora CI is doing what it says it should. > > > > For instance, here is the most recent Rawhide update from you: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-af9f093288 > > > > If we click on "Automated Tests", we see a result for > > "fedora-ci.koji-build.rpminspect.static-analysis". Clicking on it takes > > us to: > > https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/2629/testReport/(root)/tests/ > > > > where we can see the "/abidiff" results: > > https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/2629/testReport/(root)/tests/_abidiff/ > > > > are OK. I don't know of a known failure case to check it's failing when > > it should, though. > > Well, rpm broke the buildroot eariler today so it should have failed > this right? > > https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/2840/testReport/(root)/tests/_abidiff/ > > but... no? > > "Comparing rpm-4.16.1.1-1.fc34 with older rpm-4.16.1-1.fc34 found in the > "f34-updates" Koji tag." > > it's not checking the actual previous build? See I thought that too at first, and was going to cite it, but then I thought, wait. The problem isn't that the update *actually broke the ABI*, right? The problem is that it *unnecessarily bumped the soname*. I think abidiff's job is to catch the *opposite* problem, isn't it? Where the ABI changes but the soname isn't bumped. I would need to check, but I suspect possibly in this case abidiff just wouldn't do anything at all, because what it would seem to make sense to do is run it only on pairs of shared libraries with identical sonames from the two package builds. When the soname is bumped, it wouldn't make sense to run abidiff, because you'd *expect* the ABI to change in that case. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: What is the most time consuming task for you as packager?
On Wed, 2020-12-16 at 12:37 +0100, Vitaly Zaitsev via devel wrote: > On 15.12.2020 23:29, Miroslav Suchý wrote: > > What you - as Fedora packager - find most time consuming on packaging? > > ABI check between shared libraries updates. > > Bodhi used to run abidiff automated tests, but after Fedora Infra moved > to the new datacenter, they disappeared. Bodhi doesn't run any tests, it only shows results from other systems. abi check was run by Taskotron, which has been retired. The approximate replacement is Fedora CI, which should run rpminspect (among other tests). rpminspect runs abidiff. So there should still be abidiff results, if Fedora CI is doing what it says it should. For instance, here is the most recent Rawhide update from you: https://bodhi.fedoraproject.org/updates/FEDORA-2020-af9f093288 If we click on "Automated Tests", we see a result for "fedora-ci.koji-build.rpminspect.static-analysis". Clicking on it takes us to: https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/2629/testReport/(root)/tests/ where we can see the "/abidiff" results: https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/2629/testReport/(root)/tests/_abidiff/ are OK. I don't know of a known failure case to check it's failing when it should, though. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Wed, 2020-12-16 at 02:40 +0100, Alexander Ploumistos wrote: > Sorry to be a bother, but is there another side effect from having > this update installed on a server? As far as I could tell from the > discussion on the update page, only the sha1 signed firefox add-ons > are concerned, but I could be missing something. From the comments on the update I'm not sure *precisely* what the scope of the change is, but it's at least possible that the behaviour of anything that uses NSS for cryptography could have changed with this update. Things that don't use NSS won't be affected of course. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: What is the most time consuming task for you as packager?
On Tue, 2020-12-15 at 18:29 -0500, Matthew Miller wrote: > On Tue, Dec 15, 2020 at 04:44:49PM -0600, Michael Cronenworth wrote: > > Can we make the Bodhi update notes part of the git repo? Ex. ChangeLog.md > > I would definitely like to see a consolidated changelog. I don't know if it > should be part of the git repo, or just a changelog convention. (Like: > any lines starting with > get put into the notes for the next bodhi update?) My traditional note that anything along these lines should be optional. I frequently submit multi-package updates, and want to write the update text directly, separate from package commit messages and changelogs. For me, the description of "this update containing five new package builds" is completely different from the package-level description of any one of those new builds. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, 2020-12-15 at 17:59 -0500, Steven A. Falco wrote: > On 12/15/20 5:09 PM, Adam Williamson wrote: > > On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote: > > > On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos > > > wrote: > > > > > > > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: > > > > > > > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > > > > will stop working. Worse they will appear corrupted, so you will have > > > > > to > > > > > remove them and re-install them (after downgrading nss). > > > > > > > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 > > > > installed since it hit my local updates-testing mirror and all my > > > > add-ons are looking good. > > > > > > So, I spoke too soon. I just got notified that one of my add-ons is > > > misbehaving and it has been disabled. I'm still on the same session I > > > was when I sent the previous message, nothing was installed or updated > > > in the meantime. Is this bug time-based or something? > > > > You didn't answer the question whether you had restarted Firefox since > > installing the new nss. > > > > Either way, probably Firefox is doing a periodic check of installed > > add-ons and that fails whenever it happens now. The issue is they're > > signed with SHA-1 certs, but nss is now not accepting SHA-1 per the > > current system-wide policy. > > Since there is no great way for end-users to motivate the various add-on > creators to update their certs, this sounds like a serious problem. > > For now I've put an exclude in my dnf.conf to prevent any nss upgrades, but > that is also not a great solution, for obvious reasons. Perhaps there will > have to be a way for end-users to override the check for critical add-ons. > Hopefully the add-on creators will eventually switch certs, but that could > take a very long time. To be clear, the update is not stable for F33 and should not go stable. It's only in updates-testing. I wrote in the update that in my opinion the solution for this bug can't involve expecting add-ons to suddenly get re-signed en masse, or users to change their local configuration. It needs to keep working as it did before. If the policy is ahead of the real world, the policy needs to be loosened. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: heads up: nss 3.59 breaks firefox add-ons
On Tue, 2020-12-15 at 22:38 +0100, Alexander Ploumistos wrote: > On Tue, Dec 15, 2020 at 9:04 PM Alexander Ploumistos > wrote: > > > > On Tue, Dec 15, 2020 at 8:17 PM Kevin Fenzi wrote: > > > > > > If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons > > > will stop working. Worse they will appear corrupted, so you will have to > > > remove them and re-install them (after downgrading nss). > > > > I'm running firefox 83.0-13.fc33.x86_64 with nss 3.59.0-2.fc33 > > installed since it hit my local updates-testing mirror and all my > > add-ons are looking good. > > So, I spoke too soon. I just got notified that one of my add-ons is > misbehaving and it has been disabled. I'm still on the same session I > was when I sent the previous message, nothing was installed or updated > in the meantime. Is this bug time-based or something? You didn't answer the question whether you had restarted Firefox since installing the new nss. Either way, probably Firefox is doing a periodic check of installed add-ons and that fails whenever it happens now. The issue is they're signed with SHA-1 certs, but nss is now not accepting SHA-1 per the current system-wide policy. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Reducing noise on devel list
On Tue, 2020-12-15 at 13:07 -0500, Robbie Harwood wrote: > Mauricio Tavares writes: > > > On Tue, Dec 15, 2020 at 12:18 PM Robbie Harwood wrote: > > > > > > Vít Ondruch writes: > > > > > > > I have setup filter ages ago and it moves such emails into subfolder. I > > > > still think this is preferable to moving them into different ML. > > > > > > I would like to disagree with the idea that everyone needing to create > > > their own filtration is preferable to putting them on a separate list. > > > > So giving people the option to decide what to do with their > > emails is less preferable than having 4-5 people decide for every > > single subscriber? > > Subscribing to two mailing lists instead of one isn't preventing you > from deciding what to do with your email. Well, the potential problem I see is that you have to *know* the other list exists. For a new Fedora user this isn't trivial. I've no idea how people find out about devel@ but I imagine it's linked all over the intarwebs, having existed for literal decades at this point. Right now if you sign up for devel@ for *whatever* reason, you find out about these report emails because they start showing up in your mailbox. If we move them to a separate list which *won't* be linked all over the intarwebs, how will people know the reports exist? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Rawhide users: don't update to 20201208.n.0 packages (fprintd 1.90.6), console login and su are broken
On Sun, 2020-12-13 at 07:43 +0100, Onyeibo Oku wrote: > Greetings. > > Looking to run an installation (and update perhaps). Is it now safe? > > Maybe: > sudo dnf update --exclude=fprintd > > Regards and thanks for the early warning. Hi Onyeibo! We had trouble getting a successful compose with the fixes for a bit, but one just got through today. openQA testing shows 20201212.n.0 has the glibc and fprintd bugs fixed and looks generally OK, there are some test failures that will need looking into but nothing super-critical. So as long as your mirror has synced to that compose you should be OK to install/update. If you want to be sure, wait another few hours first. The fixed versions are glibc-2.32.9000- 20.fc34 and fprintd-1.90.7-1.fc34 or higher (I think the compose got 8- 1.fc34). Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Pre-made live image with actual functioning persistent storage?
On Fri, 2020-12-11 at 13:48 -0500, Matthew Miller wrote: > We're going to spend some of our remaining budget on a swag refresh, and as > part of that, we're getting some shiny new USB sticks, and partly > considering the recent discussion about making it easy for new users to try > without committing, we're getting ones with decent speed and quality and > room for a persistent overlay. > > It has been approximately a decade since I made such an image. Does anyone > have a recipe for creating one with persistent storage (and possibly a > separate home filesystem, or however that should be set up on btrfs?) AFAIK it *should* still work as documented on the old wiki page: https://fedoraproject.org/w/index.php?title=How_to_create_and_use_Live_USB&oldid=504045#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29 "To include a persistent filesystem for /home, use the --home-size-mb parameter. For example: su -c "livecd-iso-to-disk --home-size-mb 2048 Fedora-Workstation-Live-x86_64-34-1.1.iso /dev/sdX" This will create a 2 GiB filesystem that will be mounted as /home each time the stick is booted, allowing you to preserve data in /home across boots. To enable 'data persistence' support - so changes you make to the entire live environment will persist across boots - add the --overlay- size-mb parameter to add a persistent data storage area to the target stick. For example: su -c "livecd-iso-to-disk --overlay-size-mb 2048 Fedora-Workstation-Live-x86_64-34-1.1.iso /dev/sdX" where 2048 is the desired size (in megabytes) of the overlay. The livecd-iso-to-disk tool will not accept an overlay size value greater than 4095 for VFAT, but for ext[234] filesystems it is only limited by the available space." I have no idea when is the last time anyone tested this. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Proposal: drop "Test installation media" from live media
On Fri, 2020-12-11 at 13:07 -0500, Matthew Miller wrote: > Right now, when you start Fedora live media to install Workstation or KDE or > etc., you get an ugly text prompt which defaults to doing a media test > (although it's not actually even clear from the highlighting that that's the > default). > > I think since burning spinning optical media is no longer the normal way to > do this, we should drop this and just go straight to booting (unless of > course a key is hit to stop things and enter boot parameters). > > In my experience with USB sticks (and i've probably made over 500 of 'em in > the last few years), the most likely failure modes are like this: > > 1) Doesn't even write properly. > 2) Doesn't boot after you created it. > 3) Fails hard and it's definitely done > 4) Random transient errors > > The test media option doesn't actually help with any of these except maybe > making #3 happen slightly sooner. With #4, it actually means that in some > cases you'd be fine just doing the install and the test fails. > > Let's just go ahead and get people started faster. Could we maybe just bump it down to the 'troubleshooting' menu or whatever it's labelled there and have it not be the default, rather than remove it entirely? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: End of CentOS Linux: What about Fedora?
On Thu, 2020-12-10 at 03:59 +0100, Kevin Kofler via devel wrote: > Jaroslav Prokop wrote: > > But apparently some already took on this task [0]. > > [0] https://github.com/hpcng/rocky > > The official website is: > https://rockylinux.org/ > (Still somewhat under construction, of course.) > > It was started by the original founder of CentOS with the aim of going back > to the roots of CentOS, the way it worked before Red Hat started their > Embrace, Extend, Extinguish scheme. Off the record...there really wasn't one. It was an Embrace, Equivocate, Evacuate policy... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Rawhide users: don't update to 20201208.n.0 packages (fprintd 1.90.6), console login and su are broken
On Wed, 2020-12-09 at 12:02 -0800, Adam Williamson wrote: > On Wed, 2020-12-09 at 10:34 -0800, Adam Williamson wrote: > > Hey folks! > > > > Just a heads up that the most recent Rawhide compose (20201208.n.0) > > seems badly broken; console login doesn't work and 'su' segfaults. I > > think the most likely cause of these issues is the new glibc 2.32.9000- > > 19.fc34 build. > > > > So if you're running Rawhide I'd recommend holding off on updating, and > > especially on updating glibc, if you didn't do it already. If you've > > updated glibc you may want to downgrade it (if you still have a root > > shell somewhere :>) > > Still looking into this, but it seems kinda complex. Downgrading glibc > on my test VM didn't fix the issues. I thought sssd might be the > culprit, but downgrading that didn't help either. > > It seems like the console login bug at least doesn't happen with a > minimal package install: > https://openqa.fedoraproject.org/tests/737305 > passed, including console login as user and root, and I verified that > it used the packages from the 1208.n.0 compose. But it seems to > reliably happen on Server, Workstation and KDE installs. So it's > apparently caused by something present in those installs but not in > minimal... > > Still looking into this, my advice for now is still not to upgrade past > the 1207.n.0 package state until it's figured out :) OK, further update: culprit seems to be fprintd. fprintd 1.90.6 is the bad version. A 1.90.7 build is done which should fix it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1656747 A libfprint 1.90.6 is also done, not sure if that's also needed: https://koji.fedoraproject.org/koji/buildinfo?buildID=1656771 There were bug reports already that I hadn't found as I was looking for glibc bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1905667 https://bugzilla.redhat.com/show_bug.cgi?id=1905964 so, skip fprintd 1.90.6! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Rawhide users: don't update to 20201208.n.0 packages (likely glibc), console login and su are broken
On Wed, 2020-12-09 at 10:34 -0800, Adam Williamson wrote: > Hey folks! > > Just a heads up that the most recent Rawhide compose (20201208.n.0) > seems badly broken; console login doesn't work and 'su' segfaults. I > think the most likely cause of these issues is the new glibc 2.32.9000- > 19.fc34 build. > > So if you're running Rawhide I'd recommend holding off on updating, and > especially on updating glibc, if you didn't do it already. If you've > updated glibc you may want to downgrade it (if you still have a root > shell somewhere :>) Still looking into this, but it seems kinda complex. Downgrading glibc on my test VM didn't fix the issues. I thought sssd might be the culprit, but downgrading that didn't help either. It seems like the console login bug at least doesn't happen with a minimal package install: https://openqa.fedoraproject.org/tests/737305 passed, including console login as user and root, and I verified that it used the packages from the 1208.n.0 compose. But it seems to reliably happen on Server, Workstation and KDE installs. So it's apparently caused by something present in those installs but not in minimal... Still looking into this, my advice for now is still not to upgrade past the 1207.n.0 package state until it's figured out :) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Rawhide users: don't update to 20201208.n.0 packages (likely glibc), console login and su are broken
Hey folks! Just a heads up that the most recent Rawhide compose (20201208.n.0) seems badly broken; console login doesn't work and 'su' segfaults. I think the most likely cause of these issues is the new glibc 2.32.9000- 19.fc34 build. So if you're running Rawhide I'd recommend holding off on updating, and especially on updating glibc, if you didn't do it already. If you've updated glibc you may want to downgrade it (if you still have a root shell somewhere :>) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: End of CentOS Linux: What about Fedora?
On Wed, 2020-12-09 at 14:07 +0100, Jaroslav Prokop wrote: > > If I understood the announcement, it would be a kind of CentOS streams > is rolling release or a release with short > release interval. That does not make my job much easier as someone who > just sets up services and leaves it running. It's a rolling release *of a stable RHEL branch*. You're not getting radical new changes if you run CentOS Stream; you're just getting the changes you'd usually get in RHEL stable point releases (e.g. 8.1, 8.2 etc) but getting them early and as they are produced, rather than in periodic lumps). For some folks / maintenance styles this might still be an issue, but it should work OK in quite a lot of cases. It's not like you're running Rawhide. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Reducing noise on devel list
On Sat, 2020-12-05 at 10:23 -0800, Kevin Fenzi wrote: > On Fri, Dec 04, 2020 at 03:43:04PM -0600, Dennis Gilmore wrote: > > Hi all, > > > > I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all > > automated emails to a separate list where people who want to follow > > can, while I was part of the proliferation of compose reports coming > > here, there is now a great deal of them, and they no longer seem to > > trigger any conversation. I think that devel list would benefit from > > having all automated reports sent to a reports-list and letting people > > bring reports over when there is something to discuss. I was asked to > > bring the request to the list for people to weigh in. > > I'm a bit torn by this. The rawhide report has actually triggered > conversation (less than 3 weeks ago) and I find it usefull to point out > things. > > Perhaps we could keep the traditional rawhide report, but send the > qa/compose test reports to another list? I quite like the Rawhide compose and compose check reports going together, because it's sort of logical: here's what changed, and here's what it broke/fixed. What about keeping those two on devel@ but I could fiddle with check- compose again and have it send the IoT and Cloud reports to iot and cloud lists (if they want them) or not send them (if they don't)? I've actually twice before written mechanisms for sending the reports for different things to different places, but they keep breaking because we keep changing what things we build, what we call them, and how we build them :/ -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Reducing noise on devel list
On Sat, 2020-12-05 at 10:23 -0800, Kevin Fenzi wrote: > On Fri, Dec 04, 2020 at 03:43:04PM -0600, Dennis Gilmore wrote: > > Hi all, > > > > I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all > > automated emails to a separate list where people who want to follow > > can, while I was part of the proliferation of compose reports coming > > here, there is now a great deal of them, and they no longer seem to > > trigger any conversation. I think that devel list would benefit from > > having all automated reports sent to a reports-list and letting people > > bring reports over when there is something to discuss. I was asked to > > bring the request to the list for people to weigh in. > > I'm a bit torn by this. The rawhide report has actually triggered > conversation (less than 3 weeks ago) and I find it usefull to point out > things. > > Perhaps we could keep the traditional rawhide report, but send the > qa/compose test reports to another list? BTW, people do actually follow those reports even if they don't reply to them, because I get pings when they stop working :) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34(m.p. all): root-auth Impossibilitybug found
On Sat, 2020-12-05 at 18:49 +0100, Marius Schwarz wrote: > > BTW: whats the actual gnome bugzilla? gitlab.gnome.org . -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34(m.p. all): root-auth Impossibilitybug found
On Sat, 2020-12-05 at 09:40 -0600, Michael Catanzaro wrote: > On Sat, Dec 5, 2020 at 4:21 pm, Marius Schwarz > wrote: > > Does anyone have an idea? > > I tested this in Fedora 33 by enabling the Screen Keyboard > accessibility setting. The screen keyboard works fine for me: it can > receive mouse input just fine. > > So maybe this is fixed in Fedora 33? I am using a mouse rather than a > touchscreen, so perhaps that is to blame for the difference, but more > likely I guess it's fixed in F33? > > P.S. That's not caribou anymore. The screen keyboard is actually built > into gnome-shell nowadays. The subject says "Fedora 34". So if it's different because of that, it's not that 33 fixed it compared to what Marius is seeing, but current Rawhide GNOME has it broken compared to what you're seeing... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Reducing noise on devel list
On Fri, 2020-12-04 at 15:43 -0600, Dennis Gilmore wrote: > Hi all, > > I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all > automated emails to a separate list where people who want to follow > can, while I was part of the proliferation of compose reports coming > here, there is now a great deal of them, and they no longer seem to > trigger any conversation. I think that devel list would benefit from > having all automated reports sent to a reports-list and letting people > bring reports over when there is something to discuss. I was asked to > bring the request to the list for people to weigh in. As someone who generates half these reports, I'd be fine with that, though it does make them somewhat less discoverable. I'd suggest we should look for places people find devel@ and link to the new reports@ or whatever from those places too. If anyone winds up trying to find out where we decide where to mail "compose check reports", this is it: https://pagure.io/fedora-infra/ansible/blob/master/f/inventory/group_vars/checkcompose checkcompose_emailto would be the thing to change. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Rawhide Repo needs downgradeable packages
On Fri, 2020-12-04 at 16:11 +0100, Marius Schwarz wrote: > Hi, > > as you may have heared, Fedora is now running on Pinephone and other > devices, that need bleeding edge versions to function. > > Status of Fedora Pine as of 15:15 CET > > Cams now working, but app needs rework > Mobile INET working > WIFI working > Touch working > SMS working > GPS working > Calls partly, "calls app" does not connect to pulseaudio. > Headphones ( sort of ) > Mali400 GPU support working ( MPV rulez ) > > and with Gnome(38) instead of Phosh.. no window problems! Big Thanks to > nikhiljha <https://github.com/nikhiljha>and his copr repo. > > O== my request > > In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell > 40~alpha ) caused a lot of bugs and needed to be downgraded directly > from koji, > by first finding & downloading them with wget ( because of the slow wifi > and dependency checks, direct http links work ofcourse ), and later > downgraded with > dnf, which is so to speak, a pain in the ass. Of course, the best way to > handle it would be, if the os compenents came from stable repos, so that > these problems do not happen. But as i said, bleeding edge is needed atm. > > Is it possible to keep at least the last version of a package around in > rawhide repo, to make dnf downgrade work? That would ease a lot of this > pain. > > I know that there is a native koji tool to handle rawhide, but i must > say, that won't work in most cases. Let me explain: > > Pine has announced to open stores in the US and Canada, because of the > huge amount of requests for a pinephone. As it looks, this phone, as > cheap as it compontants are, fills a gap of some kind. Therefor we will > have much more user using it, and (i hope i can help with it) will use > Fedora with Gnome-Shell. > Phosh is more like Android, it has it charm, but tbh I, and people I > showned it to, love they way gnome-shell handles stuff. > > We "may" get them to downgrade stuff with dnf, but that needs to be as > simple as it could. I don't think there's an easy way to do this, because of how we build stuff. The Rawhide and Branched trees are rsynced over top of the previous content from the most recent successful compose, with metadata pre-built at the compose level. The old thing is thrown away and replaced with the new thing, which is a very simple process. If you want to keep old stuff around it suddenly gets a ton more complex, because now you have to keep track of what is "old stuff" and when to get rid of it, and you have to add a step to the process that (re-)generates the repo metadata after the new stuff has been added to the old stuff. Limited downgrading possibilities exist for stable releases because we freeze those and add updates repos alongside the frozen stable release, but that's not how we build development releases. I don't really think it makes sense to do a ton of engineering to support an explicitly non-recommended use case. Rawhide is not for running on your phone. Having said that, there are more efficient ways to do what you're doing. You don't need to download with wget; you can use the 'koji' CLI tool directly (koji download-build --arch=XX --arch=noarch NVR). You can also find the older Rawhide content in older composes, at https://kojipkgs.fedoraproject.org/compose/rawhide/ - you can configure the Everything repo from any of those as a local repo and its content will be available for downgrading. Of course, that server doesn't expect heavy traffic, so if lots of pinephone people start trying to do it at once, it might start choking. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 15:22 -0500, Colin Walters wrote: > > On Thu, Dec 3, 2020, at 2:48 PM, Adam Williamson wrote: > > > I dunno when's the last time anyone tried without it, tbh. > > For CoreOS we spent a *lot* of time ensuring that Ignition has first class > SELinux support, and actually making it work on the Live ISO in a > not-horribly-hacky way required a kernel patch: > https://lore.kernel.org/selinux/20190912133007.27545-1-jle...@redhat.com/T/#u I meant for the anaconda-based liveinst, not for ignition... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 14:43 -0500, Matthew Miller wrote: > On Thu, Dec 03, 2020 at 11:36:32AM -0800, Adam Williamson wrote: > > > > (Personally I'm really proud that for example our Live ISO ships with > > > > SELinux enforcing) > > > This is true of Fedora Workstation and other desktop spin live ISOs as > > > well. > > Yes, but the live installer runs 'setenforce 0' at the start then sets > > it back on exit. As long as the live installer is running, you're in > > permissive. > > Huh. Well, then, that's cool that CoreOS doesn't need to do that. > > Does the live installer really? I dunno when's the last time anyone tried without it, tbh. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 14:14 -0500, Josh Boyer wrote: > > > > Beyond the pungi-vs-bodhi thing of course, to me it is also very > > fundamental that our OS build and test process runs natively via podman and > > Kubernetes (unprivileged). We're telling people to use containers; > > building the operating system shouldn't require you to `yum install` (or > > even `rpm-ostree` install stuff directly on a host system. Our current > > build pipeline is Jenkins-running-in-OpenShift; we're actively working on > > removing Jenkins from the equation in some circumstances and making the > > whole thing even more Kubernetes-native. This is not at all true of the > > Koji/pungi stack. > > Is that difference really split along tooling lines? I'm not sure it > is. You could use pungi to build updated installation media every > time there's a push of updates. We just... don't. Right. It's a choice, not a capability thing. At this point I think there are two reasons for the choice: 1) It *does* take a long time to produce a full compose, and doing that for every update push for every stable release might overwhelm capacity, I think 2) We don't have the capacity to test full composes very frequently to the level we test "stable releases" 2 is really the awkward one. It's not really a showstopper, but it comes with awkward questions. We could respin every month and go through a full validation process, but that would be a huge lift and eat up basically the whole of QA's time (and probably a lot of releng's, and various other people) and we'd probably still miss stuff. We could produce respins on some sort of schedule and run them through automated testing and maybe some light manual validation and put them out on some kind of "use at your own risk" basis, but there the devil is in the details, particularly of communication. How exactly do you sell the message "these images are PROBABLY actually a bit better than the release ones, and they're almost certainly more secure, but we can't really entirely stand behind them and if you have some problem with them we're going to tell you to use the official release image instead"? It's a tricky bit of communication to do successfully. Even still, we might want to try it. I dunno. But at that point we've gone a bit off the original topic, and there I think Colin hit the nail on the head with "for FCOS we made a massive simplification". Which is a nice thing to be able to do ;) For the thing called "Fedora", we can't really make all those simplifications, because of existing expectations and commitments. So this goes back to my big point: when we make "Fedora CoreOS" a key part of the thing called "Fedora", we have impedance mismatches, and here's another. The thing called "Fedora CoreOS" has made these simplifications in deployment: it's massively restricted what "deployment" means, in terms of what gets deployed where and how. That gives it quite a big payoff in various ways in terms of how development and testing and release can be done. But we really don't have those options for the whole of the thing called "Fedora", not on any sensible timescale at least. Unless Josh wants to start getting really radical about RHEL 9...:D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 14:06 -0500, Matthew Miller wrote: > On Thu, Dec 03, 2020 at 01:58:56PM -0500, Colin Walters wrote: > > (Personally I'm really proud that for example our Live ISO ships with > > SELinux enforcing) > > This is true of Fedora Workstation and other desktop spin live ISOs as well. Yes, but the live installer runs 'setenforce 0' at the start then sets it back on exit. As long as the live installer is running, you're in permissive. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote: > > > I think if we don't want to accept a different > > > philosophy about release schedule and release engineering we can > just > > close > > > that Change proposal. > > > > That's not the outcome I intended, but rather that if we want > CoreOS to > > be an "Edition" but we don't want to require it to conform to the > > existing "philosophy", as you put it, we need the scope of this > Change > > to include thinking through all the consequences of that and > deciding > > what to do about them. > > > > Happy to do that, is your main concern about communication and the > story of > what is "Fedora" ? or what are the other consequences ? For me personally it's mainly about validation and release engineering. Specifically, making sure the processes we have in place for deciding when to cut a CoreOS release in a stream and when to bump streams between releases align with the Fedora-wide release criteria etc, and making sure the release criteria express all the requirements we actually intend to have for making those choices as regards CoreOS. Making sure there's a clear vertically-integrated process, like there is for "Fedora", from Edition PRDs to release criteria to validation tests to release decisions, and there are all the necessary bits of glue in between those layers, so you can pretty easily trace back and forth between them. But I suspect there are various consequences for other teams and other parts of the process, if you think about it. If you just look at a Fedora release schedule: https://fedorapeople.org/groups/schedule/f-34/f-34-all-tasks.html there are a zillion things on there, and they're all aligned to our big every-six-month-release-machine somehow. At minimum, it'd be a good idea to look through all those and think about whether and how each entry would be affected by having an Edition with a completely different release process. > > More or less, yes - but with a key addition: "...and if so, how?" > > > > I feel that we already have the how, Fedora CoreOS has been releasing > fortnightly for more than a year now. > So it is a matter of making more widely known how this is done ? It's a matter of "how" from the perspective of the Fedora project. I just meant it as an expression of all the other stuff above. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote: [big snip] > To the outside > > world, there is a strong impression that the thing called "Fedora" is a > > product or set of products with a release number that gets released > > every six months. The concept of "Fedora 33 release" or "Fedora 34 > > release" is a strong concept with all these sort of institutional > > ripples. > > > > And why cannot we make this evolve ? Is it bad to have a Fedora that has > streams instead of versions ? We can. Can I ask that you please read my *whole* emails before writing your replies? Or at least if you must reply in-line while reading, please after you finish, go back and see if what you wrote earlier still applies? All of this stuff up top is irrelevant because it's all based on an assumption that I was saying FCOS must at all costs align with existing processes and schedules, when I was not saying that at all. I was just trying to outline the situation and the factors that need to be considered. I'll reply to the stuff from lower down, where you actually engaged with what I was actually saying, in a separate mail. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, 2020-12-02 at 21:25 -0500, Dusty Mabe wrote: > > Ideally we update our stable stream closer to Fedora's actual release date > but I think it's > important to maybe release Fedora CoreOS from the notion that it's tightly > coupled with the > Fedora major release date for a few reasons: I'm pretty sure I covered this in my original mail. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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
