On Tue, 2016-04-19 at 07:43 -0400, Stephen Gallagher wrote: > On 04/18/2016 05:05 PM, Adam Williamson wrote: > > > > 3. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
