16:05:11 <adamw> #startmeeting F24-blocker-review
16:05:11 <zodbot> Meeting started Mon Apr  4 16:05:11 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:11 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:05:11 <adamw> #meetingname F24-blocker-review
16:05:11 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:05:12 <adamw> #topic Roll Call
16:05:14 <adamw> ahoyhoy folks, who's around?
16:05:16 * kparal is here
16:05:27 <adamw> i'll leave roll call open for a few mins so people coming out of QA meeting can grab a coffee
16:05:38 * satellit_e listening
16:05:59 * handsome_pirate is here
16:06:13 <handsome_pirate> will be distracted for the first fifteen minutes or so
16:07:10 * kparal pokes pschindl
16:07:22 * pschindl is here
16:09:17 * adamw looks for other usual suspects
16:09:22 <adamw> dgilmore: pwhalen: ping?
16:09:52 <dgilmore> adamw: in releng meeting
16:11:07 <adamw> kk
16:11:37 <adamw> alrighty, let's get rolling
16:11:40 <adamw> we only have a couple of blockers
16:11:55 <adamw> #chair handsome_pirate kparal
16:11:55 <zodbot> Current chairs: adamw handsome_pirate kparal
16:12:02 <adamw> #topic Introduction
16:12:02 <adamw> Why are we here?
16:12:02 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:12:02 <adamw> #info We'll be following the process outlined at:
16:12:04 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:12:04 <adamw> #info The bugs up for review today are available at:
16:12:06 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:09 <adamw> #info The criteria for release blocking bugs can be found at:
16:12:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:12:13 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:12:16 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:12:17 <adamw> who wants to secretarialize?
16:13:05 <pschindl> I will do it.
16:13:37 <kparal> thanks, I was afraid it will be me again :)
16:15:06 <adamw> thanks pschindl
16:15:11 <adamw> #info pschindl to secretarialize
16:15:16 <adamw> okey dokey, let's get goin'
16:16:08 <adamw> oh hey look, we grew two extra proposed blockers overnight
16:16:10 <adamw> how exciting
16:16:13 <adamw> #topic (1318067) [anaconda] non-bootable system after fresh install of current F24 on bare metal
16:16:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318067
16:16:13 <adamw> #info Proposed Blocker, grub2, NEW
16:17:08 <adamw> so thanks to some awesome work by Robert Knight and some help from Matthew Garrett we're pretty sure we know what's going on here now
16:17:59 <kparal> is there some tldr to read?
16:18:02 <adamw> basically we synced to a slightly unfortunate point upstream (note: apparently the coreos grub build is our upstream now) where boot won't work on systems with some particular state of TPM support
16:18:10 <adamw> per mjg59: "Ah yes that version of the patchset will be broken on any systems that export TPM support in the BIOS but don't have an enabled TPM."
16:18:55 <adamw> i don't really know how many systems that is, but from talking to matthew i'm +1 blocker on this, it's clearly going to be some noticeable number of systems and it's definitely a regression (systems that booted before won't now)
16:19:35 <kparal> +1
16:19:45 * pwhalen is here
16:19:47 <kparal> lbrabec also hit this on his laptop
16:19:57 <kparal> I think most latest thinkpads have a tpm
16:21:52 <adamw> hi pwhalen
16:22:06 <handsome_pirate> +1 blocker
16:22:32 <Southern_Gentlem> +1 blocker
16:22:33 <pschindl> +1
16:22:49 <pwhalen> +1 blocker, we hit issues with grub2 on aarch64 as well
16:23:02 <handsome_pirate> pwhalen:  with tpm boxen?
16:23:25 * handsome_pirate didn't know of any aarch64 boxes with tpm
16:23:37 <handsome_pirate> but, aarch64 is non-release-blocking
16:24:53 <adamw> proposed #agreed 1318067 - AcceptedBlocker - this is a conditional violation of "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles." and from the info gathered it seems significant enough of a violation to accept as a blocker
16:24:56 <adamw> er, patch
16:25:01 <adamw> proposed #agreed 1318067 - AcceptedBlocker (Beta) - this is a conditional violation of "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles." and from the info gathered it seems significant enough of a violation to accept as a blocker
16:25:20 <kparal> ack
16:25:37 <Southern_Gentlem> ack
16:25:40 <pschindl> ack
16:25:41 <pwhalen> handsome_pirate, no
16:25:48 <pwhalen> ack
16:26:55 <handsome_pirate> ack
16:27:22 <adamw> #agreed 1318067 - AcceptedBlocker (Beta) - this is a conditional violation of "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles." and from the info gathered it seems significant enough of a violation to accept as a blocker
16:27:28 <adamw> #topic (1323511) hibernate action results in a shutdown
16:27:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1323511
16:27:28 <adamw> #info Proposed Blocker, kernel, NEW
16:27:52 <adamw> as i wrote on-list i'm kinda generally minded to reject hibernate bugs as blockers just because it doesn't seem like that's ever worked well.
16:27:59 <adamw> i dunno if we have this written down anywhere, though.
16:28:17 <adamw> at least i'm pretty sure the power management criteria don't cover hibernate (or, in fact, suspend)
16:28:38 <adamw> and i think that's intentional and not an oversight
16:28:42 * handsome_pirate recalls past hibernate bugs being non-blocker
16:28:43 <adamw> hey giulio! perfect timing
16:29:01 <jpigface> hi folks
16:29:04 <kparal> I'd say hibernating a VM is not a serious enough use case to block release
16:29:16 <kparal> it's far easier to create a snapshot
16:29:26 <jpigface> kparal: has anybody tested it on bare metal yet?
16:29:45 <kparal> I don't think so, hibernate never worked for me on bare metal
16:30:50 <kparal> also I remember that some vm actions were actually intentional, I think acpi signal -> poweroff, instead of showing the power menu or suspending
16:30:55 <kparal> but I don't know about hibernate
16:31:03 <kparal> just saying it might be more complicated than it seems
16:31:35 <handsome_pirate> always is
16:32:04 <jpigface> I noted another thing worth saying... Gnome hides the menu's actions, related to hibernate and suspend, while running a vm
16:32:33 <kparal> jpigface: because the system indicates it does not support those actions
16:32:42 <kparal> I think it's affected by the vm guest agents
16:33:31 * kparal would reject the proposal and re-evaluate it if it turns out of affect bare metal (large-scale)
16:33:40 <Southern_Gentlem> -1
16:34:04 <jpigface> Actually, I agree with kparal.
16:34:32 <Southern_Gentlem> my bare metal doesnt have time to hibernate
16:34:42 <pwhalen> heh
16:34:55 <pwhalen> -1 blocker, until we know about bare metal
16:35:14 <pschindl> -1 too.
16:35:27 <jpigface> (When in doubt, I tend to propose bug as blockers, even if they don't explictly violate the release criteria. This is the case here.)
16:35:46 <adamw> sure, no problem
16:35:53 <adamw> getting a blocker rejected is no shame :)
16:36:02 <adamw> keep doing it, we prefer to err on the side of caution
16:36:15 <Southern_Gentlem> jpigface, np better to be open about an issue than cover it up
16:36:31 <handsome_pirate> -1 blocker based on past recollection
16:36:36 <jpigface> So, I'm -1 actually... But if the issue is widespread on bare metal, we'd better discuss it (With more datas/logs, if possible)
16:36:55 <adamw> proposed #agreed 1323511 - RejectedBlocker (Beta) - the criteria do not cover hibernation and this is intentional, it's not considered release-blocking functionality (due to the difficulty of making it work reliably). it's also not really supported in VMs anyhow.
16:37:00 <handsome_pirate> ack
16:37:01 <pwhalen> ack
16:37:05 <Southern_Gentlem> ack
16:37:06 <jpigface> ack
16:37:08 <adamw> jpigface: the other thing to check with bare metal is whether it worked *before* :)
16:37:09 <pschindl> ack
16:37:11 <kparal> ack
16:37:11 <adamw> #agreed 1323511 - RejectedBlocker (Beta) - the criteria do not cover hibernation and this is intentional, it's not considered release-blocking functionality (due to the difficulty of making it work reliably). it's also not really supported in VMs anyhow.
16:37:19 <adamw> #topic (1293167) [abrt] kf5-kinit: qt_message_fatal(): kdeinit5 killed by SIGABRT
16:37:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1293167
16:37:20 <adamw> #info Proposed Blocker, kf5-kinit, NEW
16:37:57 <Southern_Gentlem> my issue here is to hibernate a vm your are going to have to have a huge ( i mean huge ) swap
16:38:39 <kparal> seems +1 per criteria
16:38:46 * handsome_pirate is thinking +1
16:38:51 <adamw> nice catch
16:38:52 <kparal> after logout, log in does not work (when multiple users are logged in)
16:38:59 <adamw> well, it's not a slam dunk +1, it's a conditional violation
16:39:05 <adamw> but seems like a pretty significant one for me
16:39:10 <kparal> and does violate criterion about default desktop elements working correctly
16:39:15 <handsome_pirate> Semms pretty nasty
16:39:16 <Southern_Gentlem> +1
16:39:22 <jpigface> So... The issue related to kf5-init seems 100% reproducible (see #14). The question is: do the steps violate the criterion? It's not a typical logout
16:39:33 <adamw> so i'm +1 to this at least initially, i'm willing to listen to KDE feedback if they disagree though.
16:39:52 <adamw> jpigface: i'd say it's a conditional violation - violates in the case of this particular scenario (two simultaneous logins)
16:39:58 <kparal> I'd say this might fit more: "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional. "
16:40:02 <kparal> https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Desktop_panel
16:40:14 <adamw> i like this criterion more, personally.
16:40:23 <adamw> but either way, doesn't matter too much.
16:40:30 <kparal> which is "this"? :)
16:40:33 * handsome_pirate can see it either way, and is still +1
16:40:46 <pschindl> +1
16:40:50 <kparal> ah, and we also have this Final one: All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.
16:41:00 <kparal> which would put it into Final
16:41:09 <pwhalen> +1
16:41:22 <kparal> as a conditional violation with multiple users logged in, I think Final would fit more than Beta
16:41:38 <Southern_Gentlem> ???
16:42:00 <kparal> Southern_Gentlem: can you elaborate? :)
16:42:26 <Southern_Gentlem> i like the beta one because we know  its borked lets fix it now than waiting on the fianl
16:42:29 <Southern_Gentlem> final
16:42:43 <kparal> if only the fixes were magical and happened instantly
16:42:59 <adamw> hmm, that's actually a point kparal
16:43:08 <adamw> i'm kinda inclined to agree
16:43:10 * handsome_pirate honestly thinks the beta criteria fit a little better
16:43:10 <kparal> we're not deciding when to fix, but how long to wait
16:43:12 * adamw changes vote to +1 final
16:43:19 <Southern_Gentlem> correct so there is a beta  No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional. "
16:43:25 <adamw> handsome_pirate: we can take a conditional violation of a Beta criterion as a Final blocker
16:43:36 <handsome_pirate> all right
16:43:41 <handsome_pirate> +1 conditional beta
16:43:42 <Southern_Gentlem> ok +1
16:43:49 <adamw> (he says confidently)
16:43:59 * handsome_pirate hears trumpets
16:44:03 * kparal is -1 Beta +1 Final, whichever criterion
16:44:10 <handsome_pirate> (actually, listening to Tchaikovsky)
16:44:24 <adamw> and yeah, as kparal says, just because it's a Final blocker doesn't mean we can't fix it for Beta
16:44:34 <adamw> oh - +1 Final blocker / +1 Beta FE
16:45:02 <Southern_Gentlem> yes i think it should be +1 beta and +1 final
16:45:04 <pwhalen> sounds reasonable. +1 Final blocker / +1 Beta FE
16:45:11 * kparal nods
16:45:30 <adamw> it's pretty simple really...i think people would be OK with this kinda breakage in a beta, not in a final.
16:45:32 <Southern_Gentlem> yes i think it should be +1 beta FE and +1 final
16:45:37 * jpigface is +1 Final blocker / +1 Beta FE too. It's not a "typical logout", it's more like a corner case.
16:45:50 <adamw> right
16:45:50 <pschindl> +1 Final Bl./+1 Beta FE. That looks better.
16:47:07 <adamw> proposed #agreed 1293167 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - we count this as a conditional violation of "...logging out...must work using...the mechanisms offered (if any) by all release-blocking desktops." As it's conditional and affects a more advanced use case we accept it as a Final blocker rather than Beta, but also as a Beta freeze exception issue.
16:47:15 <handsome_pirate> asck
16:47:15 <pwhalen> ack
16:47:16 <jpigface> ack
16:47:18 <pschindl> ack
16:47:31 <kparal> ack
16:47:31 <adamw> i know it's not your favourite criterion kparal, sorry =)
16:47:46 <Southern_Gentlem> fyi from my seed i am seeing 3.6 to 1 kde to workstation dowloads of the alpha
16:47:47 * kparal will survive
16:47:55 <adamw> #agreed 1293167 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - we count this as a conditional violation of "...logging out...must work using...the mechanisms offered (if any) by all release-blocking desktops." As it's conditional and affects a more advanced use case we accept it as a Final blocker rather than Beta, but also as a Beta freeze exception issue.
16:47:59 <Southern_Gentlem> ack
16:48:18 <adamw> #topic (1321393) blivet.errors.DeviceTreeError: no slaves found for device md127
16:48:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1321393
16:48:18 <adamw> #info Proposed Blocker, python-blivet, NEW
16:49:10 <adamw> i'd be +1 if there was a *complete* RAID set attached
16:49:23 <adamw> if it was some random disks with RAID metadata, i think anaconda have historically been against taking those as blockers
16:49:30 * adamw pings dlehman
16:51:12 <kparal> I still dislike the fact that anaconda just crashes and gives no user-understandable explanation for incomplete raids, but otherwise I have the same opinion as adamw
16:52:45 <handsome_pirate> yeah
16:52:59 * handsome_pirate is not liking the idea of leaving this as a non-blocker
16:53:04 <handsome_pirate> Maybe Final
16:53:40 <dgilmore> I think anacanonda can ignore disks it does not know about, but it should not crash
16:53:48 <dgilmore> I am +1 blocker
16:53:56 <adamw> dgilmore: ignoring incomplete RAID sets is apparently difficult
16:54:48 <adamw> <dlehman> adamw: all I know about it is that mdadm can put things in a state where there's a /sys/class/block/mdXXX but is has nothing in slaves/
16:54:48 <adamw> adamw: which, I think, sort of suggests it shouldn't be in /sys/class/block at all
16:54:49 <adamw> <dlehman> but I'm sure they'll have a reason why it's not a bug
16:54:57 <adamw> so...i'm gonna propose we punt this for a bit more info
16:55:11 <dgilmore> adamw: I can go with this
16:55:18 <adamw> i) info from reporters on exactly what they had attached (was it a complete RAID set or some random drives which happened to have stale RAID metadata?)
16:55:20 <kparal> I'm not talking about ignoring, just showing a dialog and a link to a wiki page with most common raid issues, and preventing further installation, would be enough.
16:55:27 <dgilmore> but I think if anaconda can not deal with a disk it needs to do so gracefully
16:55:33 <adamw> ii) info from blivet/mdadm folks on what the heck the bug is technically and how bad it seems to them
16:55:43 <adamw> kparal: dgilmore was talking about ignoring :)
16:55:53 <kparal> yeah I knowm
16:55:59 <dgilmore> adamw: only in that it is one way to deal with it
16:56:07 <adamw> just sayin', that's why I replied to that.
16:56:08 <dgilmore> I do not really care how its done
16:56:16 * handsome_pirate is +1 punt
16:56:18 <dgilmore> just that it is graceful and does not crash
16:56:19 <handsome_pirate> still
16:56:31 <kparal> +1 to punt
16:56:31 <handsome_pirate> I think we do ought to block on this
16:56:39 <handsome_pirate> but, more info is needed
16:57:48 <kparal> handsome_pirate: we've head an issue with incomplete raid a 100 times and we've never blocked on it, so we would need a strong reason to change the attitude. for complete arrays, yes, that's in our criteria
16:58:27 <adamw> proposed #agreed 1321393 - punt (delay decision) - this looks worrying, but we need more information: from the reporters on whether they had an actual valid RAID set or just disks with stale RAID metadata, and from blivet and/or mdadm developers on what the problem looks like from their end
16:58:40 <handsome_pirate> hrm
16:58:42 <handsome_pirate> ack
16:58:43 <pschindl> ack
16:58:44 <jpigface> ack
16:59:20 <adamw> pschindl: after writing the standard comment, can you add another asking for info from the reporters and set needinfo?>
16:59:36 <adamw> dgilmore: kparal: ack/nack/patch?
16:59:41 <kparal> ack
16:59:50 <pschindl> adamw: ok
17:00:25 <adamw> #agreed 1321393 - punt (delay decision) - this looks worrying, but we need more information: from the reporters on whether they had an actual valid RAID set or just disks with stale RAID metadata, and from blivet and/or mdadm developers on what the problem looks like from their end
17:00:40 <adamw> #info we have no proposed Final blockers at this point
17:01:18 <adamw> looking at the accepted blockers, there's one i'm worried about
17:01:22 <adamw> #info moving onto accepted Beta blockers
17:01:37 <adamw> for the record we're not voting +1/-1 here, we're checking in to make sure the process of fixes is moving along
17:01:46 <adamw> sometimes we re-vote accepted blockers but i'll note specifically when that's happening
17:01:53 <adamw> #topic (1259865) call `dnf mark install <pkgs...>`on packages installed from PK
17:01:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1259865
17:01:53 <adamw> #info Accepted Blocker, PackageKit, NEW
17:01:57 * jpigface goes afk, sry.
17:02:02 <adamw> so we accepted this one way back in February and it looks like nothing at all has happened
17:02:05 <adamw> thanks jpigface!
17:02:28 <adamw> #info this was accepted back in February and no progress seems to have been made
17:02:44 <adamw> kparal: are you OK with an action item to try and get some progress on this?
17:03:29 <handsome_pirate> As an aside, I think this also exists on F23
17:03:32 <kparal> I'm afraid rhughes hates me already
17:03:36 <kparal> which means it can't get worse :)
17:03:55 <kparal> adamw: sure
17:03:57 <handsome_pirate> that's the spirit!
17:04:00 <adamw> =)
17:04:05 <adamw> that's how you know you're a good QA person
17:04:45 <adamw> check the developer hate-o-meter
17:04:58 <adamw> #action kparal to poke GNOME Software / PK folks and try to get some movement on this bug
17:05:47 <adamw> #topic (1306808) blivet.errors.FSError: mount failed: 32
17:05:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1306808
17:05:48 <adamw> #info Accepted Blocker, anaconda, NEW
17:05:53 <adamw> now i look at it, this one is similar
17:06:04 <adamw> it's an existing-btrfs-reuse bug, which i'm sure the anaconda devs will just *love*
17:06:08 <adamw> so i guess i'll take the bullet
17:06:17 <adamw> #action adamw to very diplomatically raise this bug with anaconda team,
17:06:20 <adamw> #undo
17:06:20 <zodbot> Removing item from minutes: ACTION by adamw at 17:06:17 : adamw to very diplomatically raise this bug with anaconda team,
17:06:23 <adamw> #action adamw to very diplomatically raise this bug with anaconda team
17:06:41 <kparal> thumbs up
17:08:28 <adamw> hmm, one more
17:08:29 <adamw> #topic (1262556) AttributeError: 'NoneType' object has no attribute 'get_data'
17:08:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1262556
17:08:29 <adamw> #info Accepted Blocker, NetworkManager, NEW
17:08:36 <adamw> #info this one has a needinfo from a dev, so we should get on that
17:09:01 <adamw> satellit and I are both on the bug so one of us can take that bullet i guess...
17:10:09 <adamw> i think that's all i got
17:10:13 <adamw> #topic Open floor
17:10:20 <adamw> any other business, folks? other bugs we should look at?
17:10:38 <kparal> nothing here
17:11:05 <handsome_pirate> .moar "vegan bacon" adamw
17:11:05 <zodbot> here adamw, have some more vegan bacon
17:11:26 <handsome_pirate> (stuff is actually pretty tasty, though it tastes nothing like actual bacon)
17:12:01 * adamw mostly eats giant sausages of chinese fake ham
17:12:45 <adamw> alrighty, thanks a lot for coming folks
17:12:53 <kparal> thanks
17:13:01 <handsome_pirate> wooohoo
17:13:05 <adamw> brno folks can now use both hands for drinking
17:13:30 <adamw> same time next week!
17:13:32 <adamw> #endmeeting