Hi folks! Time for a first F24 Beta blocker bug status mail. Today is the Beta freeze date, so we need to be really focusing on getting Beta into shape now.
tl;dr work summary ------------------
QA folks: * test fix for #1325085 (ARM-y): https://bodhi.fedoraproject.org/updates/FEDORA-2016-9efb51303d * test fixes for #1262556 and #1306808 with pending anaconda/blivet update * Improve Beta validation test coverage (new nightly nomination soon)
developers: * kernel / ARM folks: fix #1321330 * PackageKit / GNOME folks: fix #1259865
detailed per-bug info ---------------------
1. https://bugzilla.redhat.com/show_bug.cgi?id=1321330%C2%A0- kernel - NEW on i.mx6 systems the console does not start correctly
This is some kinda ARM kernel bug that we need the relevant devs to fix, there's really not a lot anyone else can do here yet.
2. https://bugzilla.redhat.com/show_bug.cgi?id=1325085%C2%A0- libvirt - ON_QA libvirt doesn't recognize arm/aarch64 versioned virt-* machinetypes as capable of multiple PCI buses, names them all "pci"
This is another ARM issue it seems like. There appears to be a fix available, so it'd be great if folks with ARM devices could test it. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9efb51303d%C2%A0has a couple of +1s so far, but no specific ARM testing feedback I don't think.
3. https://bugzilla.redhat.com/show_bug.cgi?id=1262556%C2%A0- anaconda - MODIFIED AttributeError: 'NoneType' object has no attribute 'get_data' (when wifi scan run and AP which does not broadcast SSID is in range)
This ought to be fixed in the new anaconda build which sbueno is just now sending out as an update. We still have the anaconda updates testing chicken/egg problem, but this one should be susceptible to testing by updating anaconda on a live image before running the installer, happily. You need to have a system with wifi and a wireless AP nearby which does not broadcast its SSID: boot a live image, update anaconda, disconnect any wired connection, do `virsh net-destroy default`, then run the installer and see if you can make it through the hub without a crash.
4. https://bugzilla.redhat.com/show_bug.cgi?id=1259865%C2%A0- PackageKit - NEW call `dnf mark install <pkgs...>`on packages installed from PK
We are waiting for the GNOME / PackageKit folks to come up with something here.
5. https://bugzilla.redhat.com/show_bug.cgi?id=1306808%C2%A0- python-blivet - MODIFIED "blivet.errors.FSError: mount failed: 32"
This issue should be resolved with the pending anaconda/python-blivet update and again should be testable from an updated live image; do an F23 install to btrfs, boot an F24 live, update anaconda and python- blivet, then try and install over the F23 install, re-using one or more of the btrfs subvolumes (rather than blowing them all away).
Beta validation testing -----------------------
We are still missing quite a lot of Beta validation testing coverage. For now the 'current' validation event is still the 20160407.n.2 nightly, but I'm planning either to request a candidate 1 compose with the anaconda/blivet update, or get it pushed stable, which would cause the first nightly that contains it to be nominated for validation testing. Still, please do run tests with 20160407.n.2 for now, we really need to hit some of the spots that aren't covered.
Remember, https://www.happyassassin.net/testcase_stats/24/%C2%A0helps you see which tests need running! Focus on Beta tests which have not been run recently or at all.
On Mon, Apr 18, 2016 at 10:05 PM, Adam Williamson adamwill@fedoraproject.org wrote:
Hi folks! Time for a first F24 Beta blocker bug status mail. Today is the Beta freeze date, so we need to be really focusing on getting Beta into shape now.
Sorry about the delayed response, I'd already gone to bed with manflu.
tl;dr work summary
QA folks:
- test fix for #1325085 (ARM-y): https://bodhi.fedoraproject.org/updates/FEDORA-2016-9efb51303d
- test fixes for #1262556 and #1306808 with pending anaconda/blivet update
- Improve Beta validation test coverage (new nightly nomination soon)
developers:
- kernel / ARM folks: fix #1321330
- PackageKit / GNOME folks: fix #1259865
detailed per-bug info
- https://bugzilla.redhat.com/show_bug.cgi?id=1321330 - kernel - NEW on i.mx6 systems the console does not start correctly
This is some kinda ARM kernel bug that we need the relevant devs to fix, there's really not a lot anyone else can do here yet.
Almost there, it's been triaged, I think I have the fix, just building a kernel to test.
- https://bugzilla.redhat.com/show_bug.cgi?id=1325085 - libvirt - ON_QA libvirt doesn't recognize arm/aarch64 versioned virt-* machinetypes as capable of multiple PCI buses, names them all "pci"
This is another ARM issue it seems like. There appears to be a fix available, so it'd be great if folks with ARM devices could test it. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9efb51303d has a couple of +1s so far, but no specific ARM testing feedback I don't think.
Will test, it looks like in the BZ there's been some ARM specific testing, I wasn't even aware of it as it wasn't on our tracker BZ.
- https://bugzilla.redhat.com/show_bug.cgi?id=1262556 - anaconda - MODIFIED AttributeError: 'NoneType' object has no attribute 'get_data' (when wifi scan run and AP which does not broadcast SSID is in range)
This ought to be fixed in the new anaconda build which sbueno is just now sending out as an update. We still have the anaconda updates testing chicken/egg problem, but this one should be susceptible to testing by updating anaconda on a live image before running the installer, happily. You need to have a system with wifi and a wireless AP nearby which does not broadcast its SSID: boot a live image, update anaconda, disconnect any wired connection, do `virsh net-destroy default`, then run the installer and see if you can make it through the hub without a crash.
- https://bugzilla.redhat.com/show_bug.cgi?id=1259865 - PackageKit - NEW call `dnf mark install <pkgs...>`on packages installed from PK
We are waiting for the GNOME / PackageKit folks to come up with something here.
- https://bugzilla.redhat.com/show_bug.cgi?id=1306808 - python-blivet - MODIFIED "blivet.errors.FSError: mount failed: 32"
This issue should be resolved with the pending anaconda/python-blivet update and again should be testable from an updated live image; do an F23 install to btrfs, boot an F24 live, update anaconda and python- blivet, then try and install over the F23 install, re-using one or more of the btrfs subvolumes (rather than blowing them all away).
Beta validation testing
We are still missing quite a lot of Beta validation testing coverage. For now the 'current' validation event is still the 20160407.n.2 nightly, but I'm planning either to request a candidate 1 compose with the anaconda/blivet update, or get it pushed stable, which would cause the first nightly that contains it to be nominated for validation testing. Still, please do run tests with 20160407.n.2 for now, we really need to hit some of the spots that aren't covered.
Remember, https://www.happyassassin.net/testcase_stats/24/ helps you see which tests need running! Focus on Beta tests which have not been run recently or at all.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
On 04/18/2016 05:05 PM, Adam Williamson wrote:
- https://bugzilla.redhat.com/show_bug.cgi?id=1262556 - anaconda - MODIFIED AttributeError: 'NoneType' object has no attribute 'get_data' (when wifi scan run and AP which does not broadcast SSID is in range)
This ought to be fixed in the new anaconda build which sbueno is just now sending out as an update. We still have the anaconda updates testing chicken/egg problem, but this one should be susceptible to testing by updating anaconda on a live image before running the installer, happily. You need to have a system with wifi and a wireless AP nearby which does not broadcast its SSID: boot a live image, update anaconda, disconnect any wired connection, do `virsh net-destroy default`, then run the installer and see if you can make it through the hub without a crash.
Given that Anaconda has a built-in mechanism for addressing exactly this (the updates.img), shouldn't we perhaps consider doing testing by providing updates.img shortlinks on the BZ (with the diff being from the last-known-good compose)?
Then testers can just boot with inst.updates=http://short.link/blah on the kernel command-line and test that way.
The process for generating an updates.img isn't very onerous, IIRC; there's a `make updates` target in the anaconda repo. So probably we could put together a SOP for generating them (to avoid dumping this requirement perpetually on the anaconda folks, though I hope they would be willing to help produce that document).
On Tue, 2016-04-19 at 07:43 -0400, Stephen Gallagher wrote:
On 04/18/2016 05:05 PM, Adam Williamson wrote:
- https://bugzilla.redhat.com/show_bug.cgi?id=1262556 - anaconda - MODIFIED
AttributeError: 'NoneType' object has no attribute 'get_data' (when wifi scan run and AP which does not broadcast SSID is in range)
This ought to be fixed in the new anaconda build which sbueno is just now sending out as an update. We still have the anaconda updates testing chicken/egg problem, but this one should be susceptible to testing by updating anaconda on a live image before running the installer, happily. You need to have a system with wifi and a wireless AP nearby which does not broadcast its SSID: boot a live image, update anaconda, disconnect any wired connection, do `virsh net-destroy default`, then run the installer and see if you can make it through the hub without a crash.
Given that Anaconda has a built-in mechanism for addressing exactly this (the updates.img), shouldn't we perhaps consider doing testing by providing updates.img shortlinks on the BZ (with the diff being from the last-known-good compose)?
updates.img testing is useful for some things, not for everything. For instance, my reproducer for this involves a system with no wired connection, so the standard way to load the updates.img is not so useful ;) You can load them from local media but it's a bit more work. For this specific case I figured using the 'update packages on a live image' approach would be a better test.
Also note that for karma purposes - as opposed to testing the fix before commit - we should really test the *entire* update, not just the specific change for the bug in question. Testing an entire Bodhi update via updates.img is not usually really possible because it's just not quite the same thing: you can't change *everything* with an updates.img.
The process for generating an updates.img isn't very onerous, IIRC; there's a `make updates` target in the anaconda repo. So probably we could put together a SOP for generating them (to avoid dumping this requirement perpetually on the anaconda folks, though I hope they would be willing to help produce that document).
Generally speaking we use updates.img to test the individual fixes before rolling an update, where necessary/appropriate. For testing the update we really should be testing the updated packages themselves.