Re: heads up: nss 3.59 breaks firefox add-ons
Is this still active? My Firefox plugins are getting disabled and I cannot install new ones (they are reported as corrupt). Is there a new instance of this bug? Regards Onyeibo On Fri Dec 18, 2020 at 5:30 PM WAT, Adam Williamson wrote: > 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 > > > ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.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@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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@lists.fedoraproject.org
Re: proposal: move Data Corruption criterion from Final to Beta
On Thu, Jan 7, 2021 at 5:44 AM Kamil Paral wrote: > The reason for this proposal is this bugzilla [1] and this blocker ticket [2] > where we discussed whether we should ship an older Firefox on F33 Beta media, > which was known to completely wipe the whole user profile on upgraded > systems. We didn't (and still don't) have any release criterion which says > that this situation should not occur. Fortunately, in the F33 Beta case, we > managed to ship a fixed version of Firefox in time, and so we didn't really > need to make a decision back then. My recollection is the older Firefox did ship on beta media. There wasn't a newer successfully built Firefox still. But yeah, I support moving the criterion to beta. The language says "must be fixed or documented" - who decides which? It reads like there are up to three decisions to make for this criterion: 1) is it a blocker? 2) should it be documented or fixed for beta? 3) should it be documented or fixed for final? -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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@lists.fedoraproject.org
Fedora 32 updates-testing report
The following Fedora 32 Security updates need testing: Age URL 68 https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f643c272c libntlm-1.6-1.fc32 21 https://bodhi.fedoraproject.org/updates/FEDORA-2020-d32853a28d mingw-openjpeg2-2.3.1-11.fc32 openjpeg2-2.3.1-10.fc32 20 https://bodhi.fedoraproject.org/updates/FEDORA-2020-307946cfb6 python-lxml-4.4.1-5.fc32 6 https://bodhi.fedoraproject.org/updates/FEDORA-2021-ccb8a9c403 golang-github-containernetworking-plugins-0.9.0-1.fc32 3 https://bodhi.fedoraproject.org/updates/FEDORA-2021-a5570c5281 sympa-6.2.60-1.fc32 3 https://bodhi.fedoraproject.org/updates/FEDORA-2021-2cb0643316 roundcubemail-1.4.10-1.fc32 2 https://bodhi.fedoraproject.org/updates/FEDORA-2021-ca0e53d310 php-7.4.14-1.fc32 2 https://bodhi.fedoraproject.org/updates/FEDORA-2021-03bcfa3491 golang-github-docker-credential-helpers-0.6.3-2.fc32 2 https://bodhi.fedoraproject.org/updates/FEDORA-2021-9316ee2948 golang-github-russellhaering-goxmldsig-1.1.0-1.fc32 2 https://bodhi.fedoraproject.org/updates/FEDORA-2021-24ef21134b adplug-2.3.3-1.fc32 audacious-plugins-3.10.1-7.fc32 ocp-0.1.22-0.28.git849cc42.fc32 0 https://bodhi.fedoraproject.org/updates/FEDORA-2021-d5b2c18fe6 nodejs-12.20.1-1.fc32 0 https://bodhi.fedoraproject.org/updates/FEDORA-2021-154a1b4c19 dovecot-2.3.13-1.fc32 The following Fedora 32 Critical Path updates have yet to be approved: Age URL 188 https://bodhi.fedoraproject.org/updates/FEDORA-2020-ebbe0f7b25 cpio-2.13-6.fc32 41 https://bodhi.fedoraproject.org/updates/FEDORA-2020-e49210967b dnf-4.4.2-1.fc32 libdnf-0.55.0-3.fc32 microdnf-3.5.1-1.fc32 36 https://bodhi.fedoraproject.org/updates/FEDORA-2020-e3cff2530e koji-1.23.0-2.fc32 28 https://bodhi.fedoraproject.org/updates/FEDORA-2020-345d2fd2aa iproute-5.9.0-1.fc32 21 https://bodhi.fedoraproject.org/updates/FEDORA-2020-d32853a28d mingw-openjpeg2-2.3.1-11.fc32 openjpeg2-2.3.1-10.fc32 16 https://bodhi.fedoraproject.org/updates/FEDORA-2020-d4c4f04447 ethtool-5.10-1.fc32 12 https://bodhi.fedoraproject.org/updates/FEDORA-2020-66d135ac1f python3-3.8.7-1.fc32 python3-docs-3.8.7-1.fc32 10 https://bodhi.fedoraproject.org/updates/FEDORA-2020-726021f11f libburn-1.5.2-4.fc32 8 https://bodhi.fedoraproject.org/updates/FEDORA-2020-43e9e3abbe tzdata-2020f-1.fc32 4 https://bodhi.fedoraproject.org/updates/FEDORA-2021-50c22ae8fd lua-socket-3.0-0.27.rc1.fc32 3 https://bodhi.fedoraproject.org/updates/FEDORA-2021-6aba9c3436 perl-libnet-3.13-1.fc32 3 https://bodhi.fedoraproject.org/updates/FEDORA-2021-f36298d6e0 libtiff-4.1.0-3.fc32 3 https://bodhi.fedoraproject.org/updates/FEDORA-2021-8907efd76e switcheroo-control-2.4-1.fc32 2 https://bodhi.fedoraproject.org/updates/FEDORA-2021-616abd3e65 keyutils-1.6.1-1.fc32 0 https://bodhi.fedoraproject.org/updates/FEDORA-2021-c737118abd perl-Socket-2.031-1.fc32 0 https://bodhi.fedoraproject.org/updates/FEDORA-2021-3a21976a89 libguestfs-1.44.0-1.fc32 0 https://bodhi.fedoraproject.org/updates/FEDORA-2021-2297dddc0f hwdata-0.343-1.fc32 The following builds have been pushed to Fedora 32 updates-testing bottles-2.0.9.7-1.fc32 cockpit-235-1.fc32 cockpit-podman-27.1-1.fc32 dovecot-2.3.13-2.fc32 egl-wayland-1.1.6-1.fc32 lollypop-1.4.8-1.fc32 minigalaxy-1.0.1-1.fc32 perl-Gtk2-GladeXML-1.008-1.fc32 perl-Gtk2-Spell-1.05-1.fc32 php-laminas-validator-2.13.5-1.fc32 polybar-3.5.4-1.fc32 python-cairosvg-2.4.2-4.fc32 python-ogr-0.19.0-1.fc32 standard-test-roles-4.10-1.fc32 switchboard-plug-bluetooth-2.3.4-1.fc32 switchboard-plug-sound-2.2.6-1.fc32 wingpanel-indicator-bluetooth-2.1.6-1.fc32 wingpanel-indicator-keyboard-2.3.0-1.fc32 wingpanel-indicator-sound-2.1.8-1.fc32 zimg-3.0.1-2.fc32 Details about builds: bottles-2.0.9.7-1.fc32 (FEDORA-2021-0c8295842d) Easily manage Wine prefix in a new way Update Information: Initial package ChangeLog: References: [ 1 ] Bug #1913786 - Review Request: bottles - Easily manage Wine prefix in a new way https://bugzilla.redhat.com/show_bug.cgi?id=1913786 cockpit-235-1.fc32 (FEDORA-2021-ef799c5b6b) Web Console for Linux servers Update Information: - Login: Improved handling of SSH host keys - Overview: Editable motd
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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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@lists.fedoraproject.org
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, Jan 07, 2021 at 09:25:44AM -0800, 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. YES. > 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. Nice! > 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 :) Yeah, that's not a _great_ use of your time. Let's make the computer do it! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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@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=33=Update-FEDORA-2021-4634e99fa0=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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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@lists.fedoraproject.org
proposal: move Data Corruption criterion from Final to Beta
I propose we move the existing Data Corruption criterion from Final to Beta. The criterion sounds like this: "All known bugs that can cause corruption of user data must be fixed or documented at Common F34 bugs." https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Data_corruption (see footnotes for some additional details) The reason for this proposal is this bugzilla [1] and this blocker ticket [2] where we discussed whether we should ship an older Firefox on F33 Beta media, which was known to completely wipe the whole user profile on upgraded systems. We didn't (and still don't) have any release criterion which says that this situation should not occur. Fortunately, in the F33 Beta case, we managed to ship a fixed version of Firefox in time, and so we didn't really need to make a decision back then. I talked about this problem in general in [2], and I said: "I support moving the Data Corruption criterion to Beta, with the rationale that we also require system upgrades to be fully working at Beta, and that puts testers into a tough place where they are recommended to upgrade but might lose personal data. It seems to me that those two things should be coupled together, for important cases (like this one, IMO). The corruption criterion allows us to decide when we want to demand the fix and when it's enough to have it documented. If e.g. all my history+bookmarks+passwords get purged from Firefox or if e.g. my ~/Documents folder gets removed on Beta upgrade, I believe we should have an option to block the Beta release. At the same time, we don't need to apply it if you only lose e.g. your color profiles in gnome-terminal. Currently your whole home can get purged and we don't have a way to stop it in Beta, I find that a problem." The criterion as currently written is flexible enough that it doesn't force us to fix the issue, if we consider it low-risk or low-impact, but it *enables us* to have that conversation and accept the high-risk or high-impact issues as blockers. That's why I believe moving it to Beta doesn't bring any downsides, just advantages. Please comment, thank you. Kamil [1] https://bugzilla.redhat.com/show_bug.cgi?id=1881495 [2] https://pagure.io/fedora-qa/blocker-review/issue/118 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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@lists.fedoraproject.org
Re: [Test Week] Fedora Kernel 5.10
13:20 < jforbes> The 5.10.5 kernel is now available in koji. https://koji.fedoraproject.org/koji/buildinfo?buildID=1665895 Worked good in Virtualbox here :) On Tue, Jan 5, 2021 at 10:10 AM Luna Jernberg wrote: > Got help from zdzichu, alciregi & kwizart > > and it works great in my test VM in Virtualbox > > On Tue, Jan 5, 2021 at 9:43 AM Luna Jernberg > wrote: > >> Any way to help testing with this in Rawhide? >> >> On Sun, Jan 3, 2021 at 4:07 AM Sumantro Mukherjee >> wrote: >> >>> Hey All, >>> >>> I would like to invite all of you to participate in the Kernel 5.10 >>> Test week which is happening from 2021-01-04 to 2021-01-11. It's >>> fairly simple, head over to the wiki [0] and read in details about the >>> test week and simply run the test case mentioned in[1] and enter your >>> results. >>> >>> As usual, the Fedora QA team will hangout at #fedora-test-day@freenode >>> for question and >>> discussion. >>> >>> >>> [0] >>> http://fedoraproject.org/wiki/Test_Day:2021-01-04_Kernel_5.10_Test_Week >>> [1] https://testdays.fedorainfracloud.org/events/99 >>> >>> Happy New Year! && Happy Testing! >>> >>> -- >>> //sumantro >>> Fedora QE >>> TRIED AND PERSONALLY TESTED, ERGO TRUSTED >>> ___ >>> test mailing list -- test@lists.fedoraproject.org >>> To unsubscribe send an email to test-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.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@lists.fedoraproject.org >>> >> ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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@lists.fedoraproject.org
Re: criteria clarification: change HTTP to HTTP(S) and drop FTP in select criteria
On Mon, Jan 4, 2021 at 2:40 PM Kamil Paral wrote:
> This has been already discussed before [1], but the discussion died down.
> Here's an updated proposal.
>
> Change the following:
>
> 1.
> https://fedoraproject.org/wiki/Basic_Release_Criteria#Remote_package_sources
> From: "When using a release-blocking dedicated installer image, the
> installer must be able to use either HTTP or FTP repositories (or both) as
> package sources. Release-blocking network install images must default to a
> valid publicly-accessible package source."
> To: "...must be able to use HTTP(S) repositories as package sources..."
> Also add a new footnote:
> "Covered repository types
> This criterion only covers direct repository URLs ("baseurl"), and doesn't
> cover mirrorlist or metalink URLs."
>
> 2. https://fedoraproject.org/wiki/Basic_Release_Criteria#Update_image
> From: "The installer must be able to download and use an installer update
> image from an HTTP server."
> To: "...from an HTTP(S) server."
>
> 3.
> https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Remote_package_sources
> From: "When using the dedicated installer images, the installer must be
> able to use HTTP, FTP and NFS repositories as package sources."
> To: "...must be able to use HTTP(S) and NFS repositories..."
> Also update its footnotes in the same spirit.
> Also add a new footnote:
> "Covered repository types
> This criterion only covers direct repository URLs ("baseurl"), and doesn't
> cover mirrorlist or metalink URLs."
>
> It will also have an effect on our test cases:
>
> 4.
> https://fedoraproject.org/wiki/QA:Testcase_install_repository_HTTP/FTP_graphical
> Rename to QA:Testcase_install_repository_HTTP_graphical
> Update the contents by replacing HTTP with HTTP(S) and dropping FTP
> mentions.
>
> 5.
> https://fedoraproject.org/wiki/QA:Testcase_install_repository_HTTP/FTP_variation
> Rename to QA:Testcase_install_repository_HTTP_variation
> Update the contents by replacing HTTP with HTTP(S) and dropping FTP
> mentions.
>
> 6. https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL
> Update the contents by replacing HTTP with HTTP(S).
>
>
> Please approve or comment, thanks.
>
> [1]
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/A3AQMNHXT5GADPIO4DJ5PTUGOBKJIB2L/
>
Since there were no further concerns following Matthew's and Adam's emails,
I implemented the changes today:
https://fedoraproject.org/w/index.php?title=Basic_Release_Criteria=revision=599785=590210
https://fedoraproject.org/w/index.php?title=Fedora_34_Beta_Release_Criteria=revision=599786=592374
https://fedoraproject.org/w/index.php?title=QA%3ATestcase_install_repository_HTTP_graphical=revision=599789=599787
https://fedoraproject.org/w/index.php?title=QA%3ATestcase_install_repository_HTTP_variation=revision=599796=599790
https://fedoraproject.org/w/index.php?title=QA%3ATestcase_Anaconda_updates.img_via_URL=revision=599797=441859
https://fedoraproject.org/w/index.php?title=Template%3AInstallation_test_matrix=revision=599799=596984
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.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@lists.fedoraproject.org
