Re: Off Topic -- "X-BeenThere: " missing from list message headers.
On Mon, 23 Nov 2015 19:50:00 -0500 Stephen Gallagher wrote: > A similar and more annoying problem is that mailman 3 lost the > X-List-Administrivia header (and didn't replace it with anything at > all), so all list administrators have no simple way to filter out the > moderation queue messages. Thankfully you filed an issue on this: https://gitlab.com/mailman/mailman/issues/164 :) kevin pgp_6CCurt4Rz.pgp Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Off Topic -- "X-BeenThere: " missing from list message headers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/23/2015 04:08 PM, Kevin Fenzi wrote: > On Mon, 23 Nov 2015 12:42:53 -0800 Adam Williamson > wrote: > >> On Mon, 2015-11-23 at 11:35 -0800, Joshua Andrews wrote: >>> Suddenly my message filters stopped working. I've been using >>> "X-BeenThere:" in the message headers to filter list emails. Do >>> I need to create new filters, has X-BeenThere been obsoleted? >>> >> >> This is probably to do with the mailman3 update. I'd recommend >> using the 'List-id' header for mailing list identification >> purposes; that header is actually defined in an RFC - RFC2919 - >> so all mailing list software should produce it. > > Yep. X-BeenThere has been deprecated since 2007. ;( > > http://fedoraproject.org/wiki/Mailman3_Migration#Email_filters > A similar and more annoying problem is that mailman 3 lost the X-List-Administrivia header (and didn't replace it with anything at all), so all list administrators have no simple way to filter out the moderation queue messages. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlZTtDUACgkQeiVVYja6o6N7vgCgiQm2jodEaXbibLWYth1eocf+ jq8AoJC5mjQj4pw+HQjR5qMbDSEKuutJ =OplR -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Fedora 21 updates-testing report
The following Fedora 21 Security updates need testing: Age URL 297 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1467 openstack-glance-2014.1.3-4.fc21 177 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9141 ceph-deploy-1.5.25-1.fc21 166 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9744 squid-3.4.13-1.fc21 110 https://bodhi.fedoraproject.org/updates/FEDORA-2015-12773 python-kdcproxy-0.3.2-1.fc21 93 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1fed73bab8 conntrack-tools-1.4.2-9.fc21 89 https://bodhi.fedoraproject.org/updates/FEDORA-2015-14179 libreswan-3.15-1.fc21 89 https://bodhi.fedoraproject.org/updates/FEDORA-2015-14200 sblim-sfcb-1.4.8-5.fc21 81 https://bodhi.fedoraproject.org/updates/FEDORA-2015-14852 libwmf-0.2.8.4-46.fc21 64 https://bodhi.fedoraproject.org/updates/FEDORA-2015-16238 nagios-4.0.8-1.fc21 50 https://bodhi.fedoraproject.org/updates/FEDORA-2015-af1b712fce python-pymongo-3.0.3-1.fc21 50 https://bodhi.fedoraproject.org/updates/FEDORA-2015-048e95ac1d thunderbird-38.3.0-1.fc21 45 https://bodhi.fedoraproject.org/updates/FEDORA-2015-d683ebb786 postgresql-9.3.10-1.fc21 43 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1f9e79df21 audiofile-0.3.6-9.fc21 37 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6542ab6d3a libreport-2.3.0-10.fc21 abrt-2.3.0-12.fc21 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-47cf97f125 git-2.1.0-6.fc21 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-fed35dffd7 perl-HTML-Scrubber-0.15-1.fc21 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-69e6c3607f miniupnpc-1.9-6.fc21 18 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0080239274 sudo-1.8.15-1.fc21 14 https://bodhi.fedoraproject.org/updates/FEDORA-2015-f92fd549f1 libreoffice-4.3.7.2-13.fc21 13 https://bodhi.fedoraproject.org/updates/FEDORA-2015-e75992a62a putty-0.65-2.fc21 10 https://bodhi.fedoraproject.org/updates/FEDORA-2015-501493d853 libpng10-1.0.64-1.fc21 8 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5a9d60c28e potrace-1.13-2.fc21 7 https://bodhi.fedoraproject.org/updates/FEDORA-2015-bee38cd15f monitorix-3.8.1-1.fc21 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-8f34820159 seamonkey-2.39-1.fc21 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1932919218 imapsync-1.644-2.fc21 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-8a1243db75 mingw-libpng-1.6.19-1.fc21 0 https://bodhi.fedoraproject.org/updates/FEDORA-2015-aceb4313a9 keepass-2.30-2.fc21 0 https://bodhi.fedoraproject.org/updates/FEDORA-2015-bd5b55f4d6 ca-certificates-2015.2.6-1.0.fc21 The following Fedora 21 Critical Path updates have yet to be approved: Age URL 115 https://bodhi.fedoraproject.org/updates/FEDORA-2015-12402 gstreamer1-plugins-good-1.4.5-3.fc21 103 https://bodhi.fedoraproject.org/updates/FEDORA-2015-13239 yum-3.4.3-154.fc21 93 https://bodhi.fedoraproject.org/updates/FEDORA-2015-13877 libteam-1.18-1.fc21 93 https://bodhi.fedoraproject.org/updates/FEDORA-2015-90d3a9ce48 dracut-038-40.git20150819.fc21 93 https://bodhi.fedoraproject.org/updates/FEDORA-2015-37e78bb9af btrfs-progs-4.1.2-1.fc21 50 https://bodhi.fedoraproject.org/updates/FEDORA-2015-048e95ac1d thunderbird-38.3.0-1.fc21 50 https://bodhi.fedoraproject.org/updates/FEDORA-2015-ff9eaa3e01 device-mapper-multipath-0.4.9-68.fc21.6 38 https://bodhi.fedoraproject.org/updates/FEDORA-2015-f01da0e4b8 spatialite-tools-4.2.0-15.fc21 sqlite-3.9.0-1.fc21 37 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6542ab6d3a libreport-2.3.0-10.fc21 abrt-2.3.0-12.fc21 28 https://bodhi.fedoraproject.org/updates/FEDORA-2015-311e897518 dnsmasq-2.75-2.fc21 28 https://bodhi.fedoraproject.org/updates/FEDORA-2015-830a68baaa createrepo_c-0.9.1-1.fc21 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-38c68e7875 linux-firmware-20151030-58.git66d3d8d7.fc21 19 https://bodhi.fedoraproject.org/updates/FEDORA-2015-315b5f87f0 vim-7.4.909-1.fc21 19 https://bodhi.fedoraproject.org/updates/FEDORA-2015-64068a1f08 crda-3.18_2015.10.22-1.fc21 18 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0080239274 sudo-1.8.15-1.fc21 15 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0cef72c8c6 livecd-tools-21.7-1.fc21 12 https://bodhi.fedoraproject.org/updates/FEDORA-2015-bef3629320 perl-Carp-1.38-1.fc21 7 https://bodhi.fedoraproject.org/updates/FEDORA-2015-b60333a0f1 perl-Time-HiRes-1.9728-1.fc21 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-e75f593a13 perl-Socket-2.021-1.fc21 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-dac22b777a pcre-8.35-16.fc21 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-416af98b59 hwdata-0.284-1.fc21 0 https://bodhi.fedoraproject.org/updates/FEDORA-2015-bd5b55f4d6 ca-certificates-2015.2.6-1
Re: criterion proposal: upgrading across 2 releases
I believe a failure to upgrade from N-2 to N should not block the N release. The reason is limited resources, both for tests and for changes to fix problems. These resources are more valuable applied to the N release than to something two releases in the past. If someone wants to test a release-skipping upgrade, fine. Report problems? Sure. If someone wants to fix these problems, OK; if not, the policy should be "Upgrade one release at a time. Release-skipping upgrades may work, but are not guaranteed." If "upgrade N-2 -> N-1" works, and "upgrade N-1 -> N" works, then "upgrade N-2 -> N" also works, right? Maybe not, and I think it profligate to insist we fix a broken two-release upgrade when two single-release upgrades successfully reach the desired target. Document, do not block. I may hold a minority opinion, but this seems like another call for QA to do somebody else's job. Who should decide that release-skip upgrade is a Fedora imperative? -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Off Topic -- "X-BeenThere: " missing from list message headers.
On Mon, 23 Nov 2015 12:42:53 -0800 Adam Williamson wrote: > On Mon, 2015-11-23 at 11:35 -0800, Joshua Andrews wrote: > > Suddenly my message filters stopped working. I've been using > > "X-BeenThere:" in the message headers to filter list emails. Do I > > need to create new filters, has X-BeenThere been obsoleted? > > This is probably to do with the mailman3 update. I'd recommend using > the 'List-id' header for mailing list identification purposes; that > header is actually defined in an RFC - RFC2919 - so all mailing list > software should produce it. Yep. X-BeenThere has been deprecated since 2007. ;( http://fedoraproject.org/wiki/Mailman3_Migration#Email_filters kevin pgpvHBoE4ANzi.pgp Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: testcase proposal: joining bios+uefi in system upgrade section
On Mon, 2015-11-23 at 10:36 -0500, Kamil Paral wrote: > Oh, one more thing - similarly to _bios and _uefi test cases, I'd > like to change existing _workstation_encrypted test case to just > _encrypted test case - it shouldn't matter which package set is > installed to verify that there's no issue with unlocking your drives. > This way you can easily fill 3 test cases with just a single test > (e.g. minimal + encrypted + bios). Just be aware that the upgrade test cases are based on templates, please don't break that setup as it saves a lot of work in duplicating content between all the various upgrade tests. I understand why you want to make the changes in the way you do, but I do think it'd be nice if possible to always treat UEFI vs. BIOS as an 'environment' difference, i.e. in the result columns, not in the test case name. As an alternative perhaps we could have workstation_encrypted (or 'any package set encrypted', if I can tweak the template a bit) with BIOS and UEFI columns, and other tests with just x86 and ARM columns? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Off Topic -- "X-BeenThere: " missing from list message headers.
On Mon, 2015-11-23 at 11:35 -0800, Joshua Andrews wrote: > Suddenly my message filters stopped working. I've been using "X-BeenThere:" > in the message headers to filter list emails. Do I need to create new > filters, has X-BeenThere been obsoleted? This is probably to do with the mailman3 update. I'd recommend using the 'List-id' header for mailing list identification purposes; that header is actually defined in an RFC - RFC2919 - so all mailing list software should produce it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
On Mon, 2015-11-23 at 13:26 -0500, Kamil Paral wrote: > > I feel that for something as important as system upgrade, we should provide > > a > > better level of quality and assurance for upgrading across 2 releases. > > Currently we have no criterion and testing it is just an afterthought, not > > even tracked anywhere. I'd like to amend the existing criterion to include > > N-2 release as well, i.e.: > > > > "For each one of the release-blocking package sets, it must be possible to > > successfully complete an upgrade from a fully updated installation of any of > > the two previous stable Fedora releases with that package set installed." > > (language corrections very welcome) > > During QA meeting, people were generally in favor of this idea. I was > asked to check with Will Woods, system-upgrade maintainer. I did > that, and he has no objections. He says it's no extra work for him > and that the most work is needed from package maintainers when > designing dependencies, scriptlets, etc. This is something to > consider as well, but I think we implicitly want all packages to be > upgradable forward (even when skipping a release). And I don't > remember any issues with this lately. > > Does someone have some additional concerns about this? Nope - as I said in the meeting, if tools folks are OK, so am I. It may be worth floating on devel@, though, to see if any packagers are concerned about maintaining upgradability on that level. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
2015-11-23 @ 16:00 UTC - Fedora QA Meeting - Minutes
== #fedora-meeting: Fedora QA meeting == Meeting started by adamw at 16:00:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-11-23/fedora-qa.2015-11-23-16.00.log.html . Meeting summary --- * Roll call (adamw, 16:00:13) * Previous meeting follow-up (adamw, 16:03:21) * "adamw to draft up proposal for better handling of 'special blockers'" - yep, did that, and we'll be discussing the draft later in the meeting (adamw, 16:04:13) * "adamw to finish off the 'installer help' criteria / test case changes" - did that: can't find the link in new hyperkitty mailing list archive, but trust me, I did it (adamw, 16:06:18) * "adamw to work with releng to get rawhide nightly boot.iso compose working and create an initial f24 nightly validation event" - did that too, nirik fixed all the things stopping nightly composes and we have nightly validation events going now (adamw, 16:07:03) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151120_Installation (satellit, 16:13:41) * satellit reports ongoing problems with Rawhide image compose and install (adamw, 16:14:08) * Non-media blocker process (adamw, 16:14:28) * AGREED: QA is generally in favour of changing the process to include some kind of check on the status of blocker-fixing updates as an input to go/no-go (adamw, 16:44:49) * ACTION: kparal to look further into the details of go/no-go process and propose a practical policy for changing it to cover blockers fixed by updates (adamw, 16:47:16) * Open floor (adamw, 16:48:01) * ACTION: kparal to check with dnf-system-upgrade maintainers if they're OK with blocking on N+2 upgrades (adamw, 16:55:51) Meeting ended at 17:00:04 UTC. Action Items * kparal to look further into the details of go/no-go process and propose a practical policy for changing it to cover blockers fixed by updates * kparal to check with dnf-system-upgrade maintainers if they're OK with blocking on N+2 upgrades Action Items, by person --- * kparal * kparal to look further into the details of go/no-go process and propose a practical policy for changing it to cover blockers fixed by updates * kparal to check with dnf-system-upgrade maintainers if they're OK with blocking on N+2 upgrades * **UNASSIGNED** * (none) People Present (lines said) --- * adamw (86) * kparal (60) * dgilmore (16) * roshi (11) * sgallagh (10) * linuxmodder (10) * satellit_e (10) * tflink (5) * zodbot (4) * garretraziel (4) * pschindl (3) * nirik (1) * satellit (1) * danofsatx (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Off Topic -- "X-BeenThere: " missing from list message headers.
Suddenly my message filters stopped working. I've been using "X-BeenThere:" in the message headers to filter list emails. Do I need to create new filters, has X-BeenThere been obsoleted? -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
> I feel that for something as important as system upgrade, we should provide a > better level of quality and assurance for upgrading across 2 releases. > Currently we have no criterion and testing it is just an afterthought, not > even tracked anywhere. I'd like to amend the existing criterion to include > N-2 release as well, i.e.: > > "For each one of the release-blocking package sets, it must be possible to > successfully complete an upgrade from a fully updated installation of any of > the two previous stable Fedora releases with that package set installed." > (language corrections very welcome) During QA meeting, people were generally in favor of this idea. I was asked to check with Will Woods, system-upgrade maintainer. I did that, and he has no objections. He says it's no extra work for him and that the most work is needed from package maintainers when designing dependencies, scriptlets, etc. This is something to consider as well, but I think we implicitly want all packages to be upgradable forward (even when skipping a release). And I don't remember any issues with this lately. Does someone have some additional concerns about this? Thanks, Kamil -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Fedora Rawhide 20151123 compose check report
Missing expected images: Cloud disk raw i386 Cloud_atomic disk raw x86_64 Workstation live x86_64 Workstation live i386 Cloud disk raw x86_64 Kde live x86_64 No images in this compose but not Rawhide 20151122 Images in Rawhide 20151122 but not this: Kde live x86_64 Failed openQA tests: 26 of 48 ID: 8887Test: x86_64 universal server_lvmthin ID: 8885Test: i386 universal upgrade_desktop_32bit ID: 8883Test: x86_64 universal upgrade_desktop_64bit ID: 8880Test: x86_64 universal server_no_swap ID: 8874Test: x86_64 universal server_software_raid@uefi ID: 8873Test: x86_64 universal server_software_raid ID: 8872Test: x86_64 universal server_delete_pata ID: 8871Test: i386 kde_live default_install ID: 8870Test: i386 generic_boot default_install ID: 8869Test: x86_64 generic_boot default_install@uefi ID: 8868Test: x86_64 generic_boot default_install ID: 8866Test: i386 universal server_lvmthin ID: 8862Test: i386 universal server_simple_encrypted ID: 8861Test: i386 universal server_repository_http_graphical ID: 8860Test: i386 universal server_scsi_updates_img ID: 8852Test: x86_64 universal server_simple_free_space@uefi ID: 8848Test: x86_64 universal server_sata_multi@uefi ID: 8847Test: x86_64 universal european_language_install ID: 8846Test: x86_64 universal server_shrink_ntfs ID: 8845Test: x86_64 universal server_shrink_ext4 ID: 8838Test: x86_64 universal server_ext3 ID: 8833Test: x86_64 universal server_simple_encrypted ID: 8831Test: x86_64 universal server_repository_http_variation ID: 8830Test: x86_64 universal server_repository_http_graphical ID: 8829Test: x86_64 universal server_mirrorlist_graphical ID: 8826Test: x86_64 universal server_scsi_updates_img Passed openQA tests: 22 of 48 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
2015-11-25 @ 21:00 UTC - Taskotron Outage and Upgrade
# Taskotron Outage and Upgrade # Date: 2015-11-25 # Time: 21:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Length: Approximately 4 hours There is a larger infra outage scheduled for Wednesday and we're going to take advantage of that to do an upgrade to production Taskotron. The big changes are: 1. Upgrade to F22 2. fedmsg emission dev and stg will also be down during the larger outage but no major changes are planned. Tim pgpLlJYW6JotS.pgp Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Non-image blocker process change proposal
On Wed, 18 Nov 2015 16:36:16 -0800 Adam Williamson wrote: > #2 MOAR METADATA > > > The alternative is to make the existing Blocker trackers do more work. > In this model we wouldn't add any new tracker bugs; we'd just add new > 'magic words' in the Whiteboard field. Right now, an accepted blocker > is identified by the string 'AcceptedBlocker' appearing in the > whiteboard field. We could simply add some more magical strings like > that: 'Accepted0Day' and 'AcceptedStable', say (better suggestions > welcome). > > I kind of like this idea as it's less change and involves creating > fewer new bugs. We'd have to make some changes to blockerbugs either > way - tflink can say if either approach would be more work in > blockerbugs, but I'm gonna guess they'd be fairly similar. Yeah, I think that either approach would involve a similar amount of effort to change blockerbugs. #2 would be slightly less effort but it's not much. Once the approach is decided, we can file RFEs for blockerbugs and get that work landed before F24 alpha. Tim pgpVrKU_SAWn9.pgp Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
criterion proposal: upgrading across 2 releases
Our current upgrade criterion says: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed." https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Upgrade_requirements Currently we have no criterion that would cover upgrading across 2 releases, e.g. from F21 to F23 (directly, not one by one). But in the real world this very often happens. It's even one of the reasons we support our releases until N+2 release is available + 1 month (i.e. F21 is supported until F23 is out + 1 month). The often cited reason is for people to be upgrading just once per year (and have one month to do that). And of course many (probably most) of them don't upgrade one by one, but skip a release. I feel that for something as important as system upgrade, we should provide a better level of quality and assurance for upgrading across 2 releases. Currently we have no criterion and testing it is just an afterthought, not even tracked anywhere. I'd like to amend the existing criterion to include N-2 release as well, i.e.: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of any of the two previous stable Fedora releases with that package set installed." (language corrections very welcome) We can discuss whether N+2 upgrading should be a separate Final criterion, not joined with the Beta one. I don't feel strongly either way. I'd also set up a new test case in our installation matrix in the upgrade section: https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade Something like QA:Testcase_upgrade_dnf_skip_release. The question is whether to have just a single test case and let people choose which package set they test, or whether to pick some particular package set. We probably don't want to test all combinations, at least not manually. Just a single "please test something" test case would be satisfactory here, I think. Something will get tested, and we will block on important bugs we discover, that's the important change. If we decide to not go this route for some reason, I think we should adjust our tools (system-upgrade) and documentation (wiki, fedora docs) and provide very clear and visible warning that the only officially supported means of upgrading is to go up releases one by one. And that skipping releases might be dangerous (considerably more than doing it the recommended way). Because I feel we would be doing our users a disservice if we neither tested skipping releases nor warned them against doing that. Thoughts? Kamil -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: testcase proposal: joining bios+uefi in system upgrade section
> Now that we have system-upgrade instead of fedup, I don't think we need to > split every single upgrade test case between bios and uefi, as we have it > right now: > https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade > > The difference is that fedup created its own upgrade environment, a new boot > menu, a special initrd, contained a lot of systemd-related hacks. > System-upgrade uses the standard "offline upgrade" environment, so if > offline upgrades ever worked for you, there should be no difference. It > doesn't create its own boot menu, it doesn't have a separate initrd. It uses > the standard way of booting your system - if your system boots, the upgrade > process should boot as well :) Likewise for adding a new boot entries during > the upgrade - if kernel updates work well for you, there should be no > problem adding a new kernel entry during upgrade, it's the same operation. > > So, I'd like to save some unnecessary work and merge "x86_64 BIOS" and > "x86_64 UEFI" columns into "x86_64" column in that wiki matrix. > > I'd also like to add two new test cases: > QA:Testcase_upgrade_dnf_previous_bios > QA:Testcase_upgrade_dnf_previous_uefi > > This will only serve as a way to track that we have tested both environments, > but it no longer matters which product was used to perform the testing, and > also we no longer need to test all combinations. So, if you tested > workstation on bios, you can fill out two test cases immediately > (_workstation and _bios). If you tested minimal on uefi, the same applies. > > I think it's valuable to keep bios vs uefi differentiation in the table at > least in the form of these two additional test cases, because it's still a > system upgrade, and there are some critical components which can break (like > a new major release of efibootmgr or grub). We should make sure we've tested > both variants. But this way, it adds virtually no extra work (compared to > testing all combinations of it) and still gives us almost the same test > value. Oh, one more thing - similarly to _bios and _uefi test cases, I'd like to change existing _workstation_encrypted test case to just _encrypted test case - it shouldn't matter which package set is installed to verify that there's no issue with unlocking your drives. This way you can easily fill 3 test cases with just a single test (e.g. minimal + encrypted + bios). -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
rawhide report: 20151123 changes
Compose started at Mon Nov 23 05:15:03 UTC 2015 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [devassistant] devassistant-cli-0.11.2-1.fc24.noarch requires python(abi) = 0:3.4 devassistant-core-0.11.2-1.fc24.noarch requires python(abi) = 0:3.4 devassistant-gui-0.11.2-1.fc24.noarch requires python(abi) = 0:3.4 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [fcitx-libpinyin] fcitx-libpinyin-0.3.2-1.fc23.i686 requires libpinyin.so.6(LIBPINYIN) fcitx-libpinyin-0.3.2-1.fc23.i686 requires libpinyin.so.6 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/schema) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/registry) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/pkg) golang-github-kubernetes-heapster-devel-0.16.1
Fedora 22 updates-testing report
The following Fedora 22 Security updates need testing: Age URL 227 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5878 echoping-6.1-0.beta.r434svn.1.fc22 176 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9185 ceph-deploy-1.5.25-1.fc22 109 https://bodhi.fedoraproject.org/updates/FEDORA-2015-12781 python-kdcproxy-0.3.2-1.fc22 94 https://bodhi.fedoraproject.org/updates/FEDORA-2015-13823 python-django-1.8.4-1.fc22 93 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1aee5e6f0b conntrack-tools-1.4.2-9.fc22 88 https://bodhi.fedoraproject.org/updates/FEDORA-2015-14199 sblim-sfcb-1.4.9-2.fc22 63 https://bodhi.fedoraproject.org/updates/FEDORA-2015-16239 nagios-4.0.8-1.fc22 57 https://bodhi.fedoraproject.org/updates/FEDORA-2015-05490fc42d squid-3.4.13-3.fc22 57 https://bodhi.fedoraproject.org/updates/FEDORA-2015-be2c11d456 subversion-1.8.14-1.fc22 52 https://bodhi.fedoraproject.org/updates/FEDORA-2015-2d37e7dacf openstack-swift-2.2.0-6.fc22 50 https://bodhi.fedoraproject.org/updates/FEDORA-2015-3e4043f088 python-pymongo-3.0.3-1.fc22 42 https://bodhi.fedoraproject.org/updates/FEDORA-2015-4bc7688b3e audiofile-0.3.6-9.fc22 27 https://bodhi.fedoraproject.org/updates/FEDORA-2015-de44abca87 ntp-4.2.6p5-34.fc22 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0552500cd7 python-pygments-2.0.2-3.fc22 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-95f5ff8d44 perl-HTML-Scrubber-0.15-1.fc22 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9039c25f1d miniupnpc-1.9-6.fc22 19 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0de8163795 python-pycurl-7.19.5.1-3.fc22 15 https://bodhi.fedoraproject.org/updates/FEDORA-2015-56be43eae6 libsndfile-1.0.25-17.fc22 12 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5ad4a1f151 putty-0.66-1.fc22 10 https://bodhi.fedoraproject.org/updates/FEDORA-2015-ec2ddd15d7 libpng10-1.0.64-1.fc22 8 https://bodhi.fedoraproject.org/updates/FEDORA-2015-89ee6b7f82 potrace-1.13-2.fc22 7 https://bodhi.fedoraproject.org/updates/FEDORA-2015-a433d8ba72 jenkins-remoting-2.53-1.fc22 jenkins-1.609.3-3.fc22 4 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178 wpa_supplicant-2.4-7.fc22 4 https://bodhi.fedoraproject.org/updates/FEDORA-2015-c7b1be8823 seamonkey-2.39-1.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-7dfbe09bb4 libpng-1.6.16-4.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6c07ab1fa6 libpng-1.6.16-5.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-e5e4ecf80d libpng15-1.5.21-2.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6691fc09b2 imapsync-1.644-2.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-97fc1797fa mingw-libpng-1.6.19-1.fc22 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0772f3f93b rpm-4.12.0.1-14.fc22 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-037f844d3e libxml2-2.9.3-1.fc22 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-2c155d7632 grub2-2.02-0.17.fc22 The following Fedora 22 Critical Path updates have yet to be approved: Age URL 103 https://bodhi.fedoraproject.org/updates/FEDORA-2015-13210 yum-3.4.3-508.fc22 88 https://bodhi.fedoraproject.org/updates/FEDORA-2015-14218 xulrunner-40.0-1.fc22 25 https://bodhi.fedoraproject.org/updates/FEDORA-2015-7517bd0bc5 libtiff-4.0.3-21.fc22 21 https://bodhi.fedoraproject.org/updates/FEDORA-2015-2123de044f libgphoto2-2.5.8-1.fc22 19 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0de8163795 python-pycurl-7.19.5.1-3.fc22 17 https://bodhi.fedoraproject.org/updates/FEDORA-2015-48f718ed1b vim-7.4.909-1.fc22 15 https://bodhi.fedoraproject.org/updates/FEDORA-2015-56be43eae6 libsndfile-1.0.25-17.fc22 15 https://bodhi.fedoraproject.org/updates/FEDORA-2015-069fea7e6b livecd-tools-22.3-1.fc22 12 https://bodhi.fedoraproject.org/updates/FEDORA-2015-ff8dec36c1 perl-Carp-1.38-1.fc22 10 https://bodhi.fedoraproject.org/updates/FEDORA-2015-fee72c84ae kde-runtime-15.08.3-1.fc22 kdelibs-4.14.14-1.fc22 9 https://bodhi.fedoraproject.org/updates/FEDORA-2015-600c5627e8 libdvdread-5.0.3-1.fc22 9 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5aaff55f5c vte3-0.36.5-1.fc22 8 https://bodhi.fedoraproject.org/updates/FEDORA-2015-14488dbea4 libbluray-0.9.1-1.fc22 4 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178 wpa_supplicant-2.4-7.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9274339b62 libpng-1.6.19-1.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-d96e31cecd perl-Socket-2.021-1.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-bb63ed333d pcre-8.37-6.fc22 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6c07ab1fa6 libpng-1.6.16-5.fc22 3 https://bodhi.fedoraproject.org/updates/FED
testcase proposal: joining bios+uefi in system upgrade section
Now that we have system-upgrade instead of fedup, I don't think we need to split every single upgrade test case between bios and uefi, as we have it right now: https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade The difference is that fedup created its own upgrade environment, a new boot menu, a special initrd, contained a lot of systemd-related hacks. System-upgrade uses the standard "offline upgrade" environment, so if offline upgrades ever worked for you, there should be no difference. It doesn't create its own boot menu, it doesn't have a separate initrd. It uses the standard way of booting your system - if your system boots, the upgrade process should boot as well :) Likewise for adding a new boot entries during the upgrade - if kernel updates work well for you, there should be no problem adding a new kernel entry during upgrade, it's the same operation. So, I'd like to save some unnecessary work and merge "x86_64 BIOS" and "x86_64 UEFI" columns into "x86_64" column in that wiki matrix. I'd also like to add two new test cases: QA:Testcase_upgrade_dnf_previous_bios QA:Testcase_upgrade_dnf_previous_uefi This will only serve as a way to track that we have tested both environments, but it no longer matters which product was used to perform the testing, and also we no longer need to test all combinations. So, if you tested workstation on bios, you can fill out two test cases immediately (_workstation and _bios). If you tested minimal on uefi, the same applies. I think it's valuable to keep bios vs uefi differentiation in the table at least in the form of these two additional test cases, because it's still a system upgrade, and there are some critical components which can break (like a new major release of efibootmgr or grub). We should make sure we've tested both variants. But this way, it adds virtually no extra work (compared to testing all combinations of it) and still gives us almost the same test value. Thoughts? Kamil -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Non-image blocker process change proposal
> >> Well, here's our latest mess-up: > >> https://bodhi.fedoraproject.org/updates/FEDORA-2015-e00b75e39f > >> dnf-plugin-system-upgrade-0.7.0-1.fc22 had enough karma for stable > >> on > > Oct 29, which was Go/No-Go day. Therefore it was considered "resolved". > > > > "Had enough karma" != queued for stable. When I say "queued for > > stable", I mean that it needs to be "submitted for stable" and > > awaiting a push (if not already pushed). According to the history on > > that bug, it was not actually submitted for stable until November 2nd. > > That would have failed my criterion above, since that was after Go/No-Go. Hmm, however, that update had karma autopush set, and its threshold was reached. So what exactly is the difference between maintainer asking to push and bodhi autokarma asking to push? I assume they should behave exactly the same. Maybe autokarma push was not triggered, or delayed for some reason? We need to find the difference and define that condition more precisely, or fix a bug somewhere, else it's quite likely we'll have a similar problem in the future. > > Yup, I think "queued for stable" is the right thing to require here. > Releng always does a 0 day push; we just need to ensure during the > blocker review process that things that need to be included in that push > are actually queued for stable. > > That should be enough for all practical purposes. I mean, releng's 0 day > push may fail of course or take longer than expected, but I don't think > that needs to be tracked with the blocker review process. Releng is > going to be painfully aware if their pushes are failing anyway and > working as fast as they can to fix them. OK. I was just trying to point out that there needs to be about 1-2 day period (releng knows best) between the 0 day push and the actual announcement. Maybe that's why we usually have 4 days between Go and the announcement? I don't know whether there's a releng process for it or not, but since QA wants to track 0 day updates more reliably, it would make sense to also have a similar process in releng space to ensure the updates are ready for everyone when the announcement goes out. I'd like to avoid the system-upgrade sad story next time. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
