16:02:32 <adamw> #startmeeting F24-blocker-review
16:02:32 <zodbot> Meeting started Mon May  2 16:02:32 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:32 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:02:32 <adamw> #meetingname F24-blocker-review
16:02:32 <adamw> #topic Roll Call
16:02:32 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:02:37 <adamw> who's around for some blocker reviewin' fun?
16:02:44 * pschindl_ is here
16:02:45 * kparal is here
16:03:01 * satellit listening
16:03:18 <nb> .hello nb
16:03:21 <zodbot> nb: nb 'Nick Bebout' <nb@nb.zone>
16:03:57 * jkurik is partially here as he is in pallel making dinner for kids
16:04:45 * pwhalen is here
16:04:50 <adamw> woohoo time for fun
16:05:00 <adamw> jkurik: c'mon, you must be smp-capable
16:05:03 * coremodule is here
16:05:05 * tflink is somewhat here
16:05:15 <adamw> #chair pwhalen nb
16:05:15 <zodbot> Current chairs: adamw nb pwhalen
16:07:11 * cmurf here
16:07:13 <adamw> hi ahmad
16:07:14 <adamw> hi cmurf
16:07:23 <cmurf> hi adam
16:07:29 <adamw> #topic Introduction
16:07:29 <adamw> Why are we here?
16:07:29 <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:07:29 <adamw> #info We'll be following the process outlined at:
16:07:30 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:32 <adamw> #info The bugs up for review today are available at:
16:07:34 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:36 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:38 <danofsatx> meh
16:07:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:07:40 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:07:42 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:07:55 <adamw> so we still have no proposed beta blockers, which either means beta is awesome or we're all slacking
16:07:56 <adamw> :P
16:08:07 <adamw> we do have 3 proposed beta FEs, and some proposed final blockers to go through
16:08:14 <tflink> ha, we still have nice-to-have in the boilerplate
16:08:17 <adamw> let's hit up the beta FEs, just in case we wind up respinning this week for any reason
16:08:22 <adamw> tflink: ooh, nice spot.
16:08:24 <adamw> i'll fix it
16:08:46 <tflink> adamw: coremodule saw it, not me :)
16:08:50 <adamw> #info no Beta blockers, starting with proposed Beta FEs
16:08:59 * tflink doesn't know the last time he read that boilerplate
16:09:04 <adamw> #topic (1331107) The shutdown process on KDE takes ~2/3 minutes longer than usual
16:09:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331107
16:09:04 <adamw> #info Proposed Freeze Exceptions, plasma-workspace, NEW
16:09:31 <adamw> this seems fairly reproducible and I think I've seen it myself, I'm kinda OK with an FE in theory but i'd want it to be a small fix and not involve systemd, i think...
16:10:08 <cmurf> It's not fixable with an update?
16:10:26 <kparal> "Been tracking similar symptoms upstream for a couple of releases." -- that doesn't sound like something that's going to fixed this week
16:10:39 <kparal> *get fixed
16:10:49 * nb tends to think -1 since we don't know what the fix would be and what else it would afect
16:10:53 <jkurik> I see similar behavior on F23 as well
16:10:54 <adamw> cmurf: for installed systems sure, it affects the lives too
16:11:29 * satellit I see wait for 1:30 sec in shutdown
16:11:30 <cmurf> Well I'm +1FE for a contained fix.
16:11:47 * satellit 90 sec*
16:11:53 <cmurf> I'm -1FE if it touches anything else esp systemd
16:12:00 * nb agrees with cmurf
16:12:07 <cmurf> even if it touches dracut forget it
16:12:17 <kparal> we should require that bugs are reasonably close to being fixed when proposed for FEs
16:12:31 * adamw goes back and forth on that
16:12:32 <nb> yeah
16:12:33 <kparal> -1 now, and ask to repropose once fix is ready?
16:12:42 <cmurf> kparal makes a good point
16:12:44 <kparal> or at least somewhere in git
16:12:52 <cmurf> haha
16:12:52 <adamw> for me it tends to vary with the issue
16:12:57 * nb agrees with kparal's point
16:13:03 <adamw> sometimes we hit a proposed FE and everyone's all 'obviously +1' but it doesn't have a fix anywhere close
16:13:12 <adamw> so i don't think you can make it a principle
16:13:14 <cmurf> it does seem the problem isn't id'd yet, has no fix in play, or isn't a super high priority
16:13:32 <adamw> but i don't mind -1 or punt on this one.
16:13:52 <cmurf> adamw those tend to be cosmetic, and before we've already slipped
16:14:06 <cmurf> I think the tolerance for FE's after slipping is a lot lower
16:14:09 <kparal> my take is that a fix should be ready, almost ready, or a developer should ask for it, so that it's clear they want to work on it
16:14:18 <kparal> or at least the root cause should be known. something
16:15:08 <kparal> doesn't make sense to spend time on stuff that is not likely to get fixed before the deadline
16:15:09 <cmurf> *whew* "root cause should be known" then I'm off the hook for one of my upcoming FEs...
16:15:24 <adamw> alright, anyhow
16:15:27 <adamw> lemme count votes
16:15:29 <pwhalen> -1
16:15:34 <kparal> -1 for the moment
16:15:45 <cmurf> adam has to break the tie i love it
16:16:04 <adamw> ok, looks like -4 vs. +1ish
16:16:11 <jkurik> -1
16:16:19 <nb> -1
16:16:52 <adamw> proposed #agreed 1331107 - RejectedFreezeException (Beta) - as this could involve many core components and it seems the real cause is yet unknown and no-one has any idea what the fix will look like, we cannot approve a freeze exception at this time. It can be re-proposed with more info on the cause and/or a fix.
16:16:56 <cmurf> ack
16:17:04 <tflink> ack
16:17:05 <kparal> ack
16:17:12 <pwhalen> ack
16:17:16 <tflink> and a very late -1
16:17:18 <adamw> #agreed 1331107 - RejectedFreezeException (Beta) - as this could involve many core components and it seems the real cause is yet unknown and no-one has any idea what the fix will look like, we cannot approve a freeze exception at this time. It can be re-proposed with more info on the cause and/or a fix.
16:17:29 <kparal> btw, do we have a secretary?
16:17:33 <adamw> oh good point
16:17:37 <adamw> and well volunteered ;)
16:17:42 <adamw> #info kparal will secretarialize
16:17:43 * kparal can't do it today
16:17:46 <cmurf> snicker
16:17:47 <adamw> awww
16:17:48 <adamw> #undo
16:17:48 <zodbot> Removing item from minutes: INFO by adamw at 16:17:42 : kparal will secretarialize
16:17:58 <adamw> ok, who wants to be secretary? don't all jump at once
16:18:06 * cmurf has no idea how
16:18:07 <kparal> sorry, I know how you love to volunteer me
16:18:18 * tflink also volunteers kparal
16:18:23 <tflink> :)
16:18:35 <tflink> i can do it if pschindl_ doesn't
16:18:40 <kparal> tflink: and I thought you want me to work on taskotron
16:18:55 * tflink is feeling more troll-ish ATM
16:19:13 * kparal is juggling too many tasks atm
16:19:34 <adamw> ok, tim gets to take the refresher course
16:19:37 <adamw> cmurf: it's in the SOP
16:19:41 <kparal> cmurf: want to learn? https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Secretary_Duty
16:19:46 <cmurf> not today
16:19:52 <cmurf> juggling myself
16:20:03 <adamw> cmurf: and you follow the blocker bugs, right? everything the secretary does is shown there, that's all of the job - updating BZ post-meeting
16:20:12 <adamw> but for this week...
16:20:13 <kparal> let's continue, either pschindl_ wakes up or one of us can do it afterwards
16:20:16 <adamw> #info tflink will secretarialize
16:20:25 <adamw> and if he doesn't i guess me or kparal will backstop it
16:20:29 <adamw> alrighty
16:20:33 <adamw> #topic (1330318) rpm-ostree status error: Error calling StartServiceByName for org.projectatomic.rpmostree1: Timeout was reached
16:20:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1330318
16:20:33 <adamw> #info Proposed Freeze Exceptions, selinux-policy, MODIFIED
16:21:10 <cmurf> it's gonna be an selinux-policy fix
16:21:30 <cmurf> without it atomic host can't be updated
16:21:38 <adamw> the referenced selinux-policy update doesn't exist yet...
16:21:45 <cmurf> yup
16:21:53 <kparal> they can't compose new atomic without this?
16:22:01 <adamw> kparal: we can build atomic, but you can't update it.
16:22:02 <cmurf> they can it's just not updatable
16:22:08 <adamw> (well, i guess with enforcing=0 or something?)
16:22:13 <kparal> oh that's bad
16:22:18 <kparal> +1 FE
16:22:22 <adamw> so until a fix for this goes stable all the atomic images are non-updatable
16:22:28 <adamw> yeah, +1 here too
16:22:31 <adamw> at least AIUI
16:22:37 <cmurf> i'm +1FE as selinux stuff tends to be contained 8-)
16:22:42 <pwhalen> +1 FE
16:22:51 <Southern_Gentlem> +1 FE
16:22:57 <tflink> +1 FE
16:23:07 <jkurik> +1 FE
16:23:34 <satellit> +1 FE
16:23:44 <cmurf> yeah in fact 'rpm-ostree status' doesn't even work, so you can't even get basic info about the running system
16:23:44 <garretraziel> +1 FE for me also
16:23:47 <nb> +1
16:24:26 <adamw> alrighty
16:25:05 <adamw> proposed #agreed 1330318 - AcceptedFreezeException (Beta) - this causes a significant problem in the Atomic images and we must push the fix stable to remedy that; fix should be safe per selinux-policy update policies, so this is accepted as a freeze exception
16:25:17 <kparal> ack
16:25:22 <cmurf> ack
16:25:23 <pwhalen> ack
16:25:38 <garretraziel> ack
16:25:39 <adamw> on that last bit - selinux folks have a rule that they only push relaxations of policy after a given point in the cycle (no tightenings), though *occasionally* there's a mistake (hi, gdm)
16:25:40 <jkurik> ack
16:25:47 <adamw> #agreed 1330318 - AcceptedFreezeException (Beta) - this causes a significant problem in the Atomic images and we must push the fix stable to remedy that; fix should be safe per selinux-policy update policies, so this is accepted as a freeze exception
16:26:15 <adamw> #topic (1331834) initramfs are no longer hostonly by default
16:26:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331834
16:26:15 <adamw> #info Proposed Freeze Exceptions, spin-kickstarts, NEW
16:26:19 <adamw> CLOSED FEATURE?
16:26:20 <adamw> :P
16:26:36 <cmurf> haha
16:26:50 <cmurf> sadly not a feature
16:27:42 <adamw> hmm, tricky one
16:27:45 <cmurf> i'm honestly neutral, I think +1FE is sane because it's not a great bug for i686 folks and requires manual work around, not directly fixable with an update
16:28:11 <cmurf> on the other hand I don't know the risk to modifying spin-kickstarts
16:28:12 <adamw> i guess i'd be willing to pull it in up to, say, the monday before release (i.e. today)
16:28:17 <adamw> but not on tuesday or wednesday :P
16:28:23 <kparal> if somebody installs Beta with this unfixed, and then fix it, will it be applied to future kernels?
16:28:26 <adamw> it "s"hould be fine
16:28:39 <cmurf> yeah if it blows up something now then there's another few days to unwind it
16:28:56 <cmurf> so i guess I'm +1FE
16:29:04 <adamw> kparal: aiui it would certainly be possible to document a permanent fix
16:29:24 <cmurf> yeah remove the offending package
16:29:37 <kparal> so people have to manually remove the dracut-config-generic package?
16:29:47 <kparal> maybe it will get autoremoved by dnf?
16:29:54 <cmurf> they'd have to do more than one thing
16:30:22 <cmurf> 'dnf remove dracut-config-generic' and then also remove a kernel package or delete an initramfs
16:30:36 <adamw> cmurf: well, no, that's just if they want to deal with existing ones
16:30:39 <cmurf> I say that because they almost certainly won't know of the problem until they hit it.
16:30:43 <kparal> well once they update kernel, the initrd is regenerated
16:30:50 <adamw> if you just want to make sure future ones are hostonly you don't need to remove existing ones...
16:30:59 <kparal> right
16:31:14 <adamw> anyhow
16:31:16 <cmurf> I mean to have space to install that 4th kernel package
16:31:31 <adamw> i'm kinda a very weak +1 in the sense that i'd only wanna fix it if we happen to respin today or if we slip again
16:31:39 <cmurf> yeah
16:31:42 <cmurf> agreed
16:31:55 <adamw> cmurf: ok, iswym, you're thinking of the practical case where someone's likely to actually notice it.
16:31:56 <tflink> +1 FE so long as it happens soon or if we slip again
16:31:58 <kparal> adamw: same opinion
16:32:06 <cmurf> adamw yes
16:32:14 <adamw> ok
16:32:19 <cmurf> they actually hit the wall, then go wtf and have to figure out how to back out
16:32:29 <nb> +1 if we happen to respin, but i hope we don't respin/slip :)
16:33:03 <adamw> proposed #agreed 1331834 - AcceptedFreezeException - we're willing to run a compose with this change but *only* if there's sufficient time before the go/no-go date to test it and unwind if things go bad, i.e. on a Monday or earlier. we acknowledge the likely inconvenience for i686 installs
16:33:14 <cmurf> ack
16:33:17 <nb> ack
16:33:22 <kparal> ack
16:33:24 <Southern_Gentlem> ack
16:33:26 <jkurik> ack
16:33:39 <tflink> ack
16:33:40 <garretraziel> ack
16:33:44 <adamw> #agreed 1331834 - AcceptedFreezeException - we're willing to run a compose with this change but *only* if there's sufficient time before the go/no-go date to test it and unwind if things go bad, i.e. on a Monday or earlier. we acknowledge the likely inconvenience for i686 installs
16:34:30 <adamw> ok, that's the proposed FEs
16:34:39 <adamw> all accepted Beta blockers are in VERIFIED, so doesn't look like there's anything to review there
16:34:53 <adamw> kpar, you're the updates sync master - are we OK with update metadata for the 0day/prevrel fixes?
16:35:01 <cmurf> \o/
16:35:29 <kparal> do we still have any open?
16:35:33 <kparal> I closed the luc ones
16:35:36 <kparal> they were ok
16:35:57 <kparal> I don't see any other
16:36:32 <adamw> nope, i was just checking
16:36:35 <adamw> awesome then
16:36:46 <adamw> we just need another stable push and to complete the 1.4 matrices
16:36:56 <adamw> so, who's ready for some fun fun final blocker review?
16:37:04 <kparal> hmm
16:37:10 * tflink is not prepared for the fun
16:37:14 <adamw> we have 8 proposed final blockers so it'd be good to cut that down a bit...
16:37:16 <cmurf> i have been looking forward to this all weekend
16:37:33 * kparal is not looking forward the hibernate one
16:37:37 <cmurf> haha *crickets8
16:37:55 <cmurf> kparal: won't be that hard
16:38:14 <adamw> welp, i'm gonna start the ball rolling
16:38:27 <kparal> it would be much easier if some developer stepped up and said he's going to fix it before Final
16:38:28 <adamw> at this point feel free to visualize the one from Indiana Jones
16:38:42 <adamw> and if everyone runs away screaming and we don't have enough voters, we'll just wind things up
16:38:42 * kparal is about to get crushed
16:38:43 <adamw> deal?
16:38:54 <kparal> sure
16:39:01 <kparal> as always :)
16:39:05 <tflink> is there a guy with a gun at the end of running from the boulder?
16:39:05 <adamw> #info all Beta blockers are in VERIFIED state, so moving on to proposed Final blockers
16:39:18 <adamw> tflink: of course. and the light at the end of the tunnel is always an oncoming train.
16:39:35 <cmurf> adamw: ritualistic execution with a burning heart offered up for the pleasure of Kali?
16:39:52 <adamw> so let's bite the bullet and take the hibernate one first, since we have a pretty good attendance today from various groups
16:39:54 <adamw> #topic (1206936) Laptop does not resume from hibernate, boots instead
16:39:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1206936
16:39:55 <adamw> #info Proposed Blocker, anaconda, NEW
16:40:56 <Southern_Gentlem> how is this a anaconda bug?
16:41:04 <kparal> the discussion in dupe https://bugzilla.redhat.com/show_bug.cgi?id=1224151 is also interesting
16:41:52 <adamw> Southern_Gentlem: basically resume from hibernate doesn't work because a kernel parameter pointing to the device where the hibernate data is stored is required and anaconda doesn't write one
16:41:53 <kparal> the ongoing investigation is great, but I'm not sure we have all needed info to get a clear picture of what is needed to be changed
16:42:03 <adamw> dracut's contention is it's anaconda team's job to write that
16:42:09 <kparal> if this is just about anaconda adding resume= or more
16:42:15 <adamw> anaconda team's contention is that they never did before and they disagree with dracut's belief that there must be an explicit pointer
16:42:38 <adamw> kparal: the problem seems to be that different developers have different opinions on what "ought to be changed"
16:42:40 <adamw> =)
16:42:50 <cmurf> which isn't something I think we can resolve
16:42:56 <adamw> dracut think the way they work (requiring the parameter) is just fine, and anaconda must change to write the param
16:43:06 <adamw> anaconda think the way dracut works is stupid, they shouldn't have to write the param, and dracut should get 'fixed'
16:43:10 <adamw> cue much heat, little light
16:43:13 <cmurf> same for systemd, they do not like non-generic initramfs's either
16:43:17 <kparal> adamw: I would not say anaconda devs disagree, they just asked for clarifications and pointed out it worked differently
16:43:30 <adamw> kparal: i have the uncensored versions from irc :P
16:43:30 <kparal> I'm not sure there is a strong disagreement
16:43:34 <kparal> oh
16:43:43 <kparal> in that case, I take it back :)
16:44:22 <cmurf> well, with --reproducible initramfs almost inevitable with the TPM work, it's untenable, anaconda will have to eventually add resume=
16:44:32 <cmurf> *if* hibernation is ever going to work out of the box
16:44:49 <cmurf> anyway -1 blocker
16:45:20 <kparal> it's true that we offer hibernation in some very remote parts of GNOME UI
16:45:32 <adamw> yeah, i'm still -1 on this fundamentally
16:45:34 <kparal> and it seems to be the default action for critical battery for all desktops
16:45:35 <cmurf> kparal yes and that's what I think it blocker worthy
16:45:40 <adamw> it's never been reliable and we explicitly don't include it in the criteria
16:45:49 <cmurf> misleading UI's are viscious and need to be removed
16:46:01 <Southern_Gentlem> -1 blocker
16:46:05 <kparal> I never wanted to block on resume not working, but I'd consider blocking on resume not even attempted
16:46:14 <adamw> i would perhaps be interested in a 'critical action should be shutdown' bug, but this isn't that bug
16:47:27 <kparal> I'd love to do something in this area, but it seems there needs to be more user pressure, and we can't use blocker process for this
16:47:43 <kparal> so I guess -1 at this moment
16:48:03 <cmurf> yeah, the WG is just not interested in power management right now which is sad because Fedora is way behind literally everything else except, I don't know, maybe Arch
16:48:12 <tflink> -1
16:48:29 <pwhalen> -1
16:48:42 <cmurf> openSUSE, Ubuntu, OS X, Windows, they all do better in this area (the era of laptops, not desktops)
16:49:05 <garretraziel> I'm -1 also
16:49:11 <cmurf> it's a craptastic bug but not a blocker
16:49:26 <tflink> -1
16:50:10 <kparal> I agree, we're not doing well here, but probably Workstation WG need to put pressure on this, not us
16:50:10 <cmurf> I would change my mind if both mdadm and LVM maintainers say resuming from swap on LVM is safe
16:50:17 <cmurf> including if LVM thinp is present
16:50:30 <nb> -1
16:50:59 <adamw> ok
16:51:10 <cmurf> kparal: yep, there needs to be political capital to get this done, QA can only hold our noses and wave our hands in futility
16:51:27 <cmurf> this is one of those stinker bugs
16:51:30 <adamw> proposed #agreed 1206936 - RejectedBlocker (Final) - this is a worrying issue, but we do not find that it meets the release criteria, which have always been held specifically not to cover hibernation, thus it is rejected as a release blocker
16:51:39 <kparal> ack
16:51:43 <cmurf> ack
16:52:12 <tflink> ack
16:52:23 <cmurf> see not hard :)
16:52:42 <kparal> hrmpf
16:52:46 <cmurf> haha
16:52:51 <cmurf> well now we've swallowed that frog...
16:52:58 <pwhalen> ack
16:54:59 <nb> ack
16:55:30 <adamw> #agreed 1206936 - RejectedBlocker (Final) - this is a worrying issue, but we do not find that it meets the release criteria, which have always been held specifically not to cover hibernation, thus it is rejected as a release blocker
16:55:41 <adamw> #topic (1329908) [comps] LXQt group description is the same as for LXDE, may confuse users to see two list entries for LXDE
16:55:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1329908
16:55:42 <adamw> #info Proposed Blocker, comps, ASSIGNED
16:55:50 <adamw> this is a pretty obvious -1 blocker for me
16:56:33 <garretraziel> yup, -1 blocker
16:56:52 <cmurf> -1 blocker
16:56:52 <garretraziel> aren't LXDE and LXQt related somehow? one is newer version of the other
16:57:13 <nb> -1
16:57:29 <pwhalen> -1
16:57:56 <adamw> garretraziel: yes
16:58:11 <adamw> the problem is that in the french translation they just took the LXDE text and cloned it to lxqt without changes
16:58:20 <adamw> which obviously needs fixing but equally obviously isn't a release blocker...
16:58:57 <adamw> proposed #agreed 1329908 - RejectedBlocker (Final) - it seems clear that this does not meet any of the release criteria
16:59:03 <adamw> er
16:59:05 <adamw> patch
16:59:11 <adamw> proposed #agreed 1329908 - RejectedBlocker (Final) - it seems clear that this does not violate any of the release criteria
16:59:34 <RaphGro> orly? - hi, by the way.
17:01:14 <cmurf> ack
17:01:23 <RaphGro> garretraziel, LXDE is Gtk based, LXQt is Qt based
17:01:25 <nb> ack
17:02:12 <pwhalen> ack
17:02:16 <RaphGro> although, it would be nice to see it fixed in final
17:02:33 <RaphGro> LXQt is no official desktop (yet)
17:02:44 <adamw> #agreed 1329908 - RejectedBlocker (Final) - it seems clear that this does not violate any of the release criteria
17:02:51 <adamw> sure, it'd be nice for it to be fixed, but not a blocker :)
17:02:58 <adamw> #topic (1317275) [abrt] gnome-software: gs_plugin_loader_get_updates_async(): gnome-software killed by SIGSEGV
17:02:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1317275
17:02:58 <adamw> #info Proposed Blocker, gnome-software, NEW
17:03:07 <RaphGro> it may confuse users of the netinstall media, they get two LXDE entries in ananconda.
17:03:27 <cmurf> +1 blocker
17:03:50 * kparal on a call
17:04:10 <cmurf> but seems like this is old and needs newer testing
17:05:06 <cmurf> and no reproduce steps
17:05:24 <cmurf> strike my +1, punt with needinfo
17:05:46 <adamw> i think i had a similar bug
17:06:03 <adamw> when i did alpha testing, shortly after booting the installed system you'd get a crash in gnome-software, and you'd get no update notifications
17:06:14 <adamw> i took a reasonable guess that the one was related to the other...
17:06:17 <adamw> not sure if it's still happening
17:06:50 <cmurf> oh that's this bug/
17:06:57 <cmurf> yeah i have one of those also from early on
17:07:28 <adamw> well, i'm guessing it's the same
17:07:30 <adamw> lemme find mine
17:08:28 <adamw> hmm, mine is https://bugzilla.redhat.com/show_bug.cgi?id=1320396 , which doesn't look quite the same
17:08:35 <adamw> so i'm OK with punt on this one
17:09:25 <adamw> see if reporter is still hitting it with a beta compose
17:10:29 <pwhalen> +1 punt
17:12:15 <cmurf> i'll commit to nominating mine as blocker if i hit it again
17:12:21 <cmurf> after beta 1.4 ships
17:14:50 <adamw> proposed #agreed 1320396 - punt (delay decision) - there is no info on how to reproduce this or if it is still currently a problem, we will ask the reporter for more details and discuss again next time
17:15:04 <cmurf> ack
17:15:45 <adamw> np
17:15:49 <adamw> grr, wrong channel :)
17:16:22 <kparal> ack
17:16:57 <adamw> #agreed 1320396 - punt (delay decision) - there is no info on how to reproduce this or if it is still currently a problem, we will ask the reporter for more details and discuss again next time
17:17:07 <adamw> #topic (1329342) 1.8.0.91-1.b14.fc25 (OpenJDK April CPU) breaks EC ciphers
17:17:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1329342
17:17:08 <adamw> #info Proposed Blocker, java-1.8.0-openjdk, MODIFIED
17:17:17 <cmurf> +1 blocker
17:17:24 * cmurf already read it :D
17:17:45 <kparal> shouldn't this have been pushed already? due to accepted FE?
17:17:58 <cmurf> maybe, no change though
17:18:27 <kparal> let's wait a week to get it pushed and we can skip discussing it
17:18:32 <adamw> it's in beta composes
17:18:35 <adamw> but not pushed stable yet
17:18:49 <adamw> i'll do a stable push request today and get it pushed
17:18:53 <adamw> so yeah, likely no need to discuss
17:19:03 <kparal> ok, great
17:19:12 * kparal loves skipping blockers
17:19:33 <adamw> proposed #agreed 1329342 - punt (delay decision) - we expect this to be closed soon as it was included in Beta composes and has sufficient karma to get a stable push in the next day or two, so we delay the decision expecting it to be closed by next week
17:19:38 <cmurf> ack
17:19:40 <kparal> ack
17:19:53 <garretraziel> ack
17:20:04 <adamw> #agreed 1329342 - punt (delay decision) - we expect this to be closed soon as it was included in Beta composes and has sufficient karma to get a stable push in the next day or two, so we delay the decision expecting it to be closed by next week
17:20:38 <adamw> #topic (1318470) failure to mount persistent overlay when booting live USB
17:20:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318470
17:20:38 <adamw> #info Proposed Blocker, livecd-tools, NEW
17:21:15 <satellit> I see this in LUC
17:21:15 <cmurf> +1 blocker on the criterion although I wonder if the criterion needs updating if we don't care about persistent overlays
17:21:27 * kparal would love to see FMW and other dd-based tools as the only blocking type of usb writers
17:21:28 <cmurf> LUC doesn't support it anymore aFAIK
17:21:44 <cmurf> kparal agreed
17:21:47 <satellit> sorry li-t-d with persistence
17:21:52 <kparal> currently, the criterion is clear, though
17:21:52 <cmurf> and litd/livecd-tools are on the way out
17:22:01 <adamw> well, the criterion was actually written with a very sneaky escape clause
17:22:03 <kparal> cmurf: what do you mean?
17:22:05 <adamw> it says "the media must support"
17:22:24 <adamw> which means that technically if the bits on the media are correct but the writing tools are broken, we don't have to block
17:22:33 <adamw> however, i don't know if we know which is the case right now
17:22:39 <cmurf> livecd-tools replaced by livemedia-tools
17:22:51 <adamw> um
17:22:59 <adamw> livecd-creator is replaced by livemedia-creator
17:23:06 <adamw> which is part of lorax
17:23:09 <kparal> "as that stage is likely to be done using a stable released Fedora or other operating system and hence irrelevant to the release validation process" - I don't completely understand that
17:23:17 <satellit> some items are stored in /temp  but not all remain after reboot
17:23:18 <kparal> we block on FMR in F23
17:23:21 <adamw> i don't think livecd-iso-to-disk is actually intended to be deprecated, though we should check with bcl
17:23:32 <adamw> kparal: yes, but that's for the 'images must boot' criterion, not this one
17:23:58 <adamw> kparal: it was written before we had AcceptedPreviousRelease and were more blase about fixing things in previous releases =)
17:24:03 <cmurf> livecd-tools replaced by livemedia-creator (in lorax)
17:24:05 <cmurf> so complicated
17:24:10 <kparal> ok
17:24:15 <adamw> cmurf: livecd-creator is replaced by livemedia-creator
17:24:19 <adamw> livecd-tools is not
17:24:27 <adamw> livecd-tools is greater than just livecd-creator =)
17:24:31 <cmurf> ok a search for livecd-creator pops up nothing
17:24:37 <cmurf> and litd is in livecd-tools
17:24:40 <adamw> yes
17:24:43 <adamw> right
17:24:44 <adamw> the poitn is
17:24:50 <satellit> persistent USB of Soas is used
17:24:52 <adamw> livemedia-creator replaces *one* of the things that's in livecd-tools
17:24:57 <adamw> it doesn't replace all the others
17:25:18 <adamw> i don't know what bcl's plans are re dropping livecd-creator from livecd-tools or declaring livecd-iso-to-disk deprecated or anything
17:25:22 <cmurf> satellit brings up a good point though even though it's not a release blocking thing
17:25:27 <adamw> but i think all we know for sure is that livemedia-creator is the new thing for creating images
17:25:38 <adamw> anyhow
17:25:45 <cmurf> adamw ok i defer to you now and my understanding for later
17:25:57 <adamw> i can either go '+1 but we need to ask bcl his plans here and may need to unblock it and perhaps change the criteria'
17:26:05 <adamw> or i can go punt and ask bcl first
17:26:07 <cmurf> right that's reasonable
17:26:12 <cmurf> whichever
17:26:33 <cmurf> for all I know this is actually a dracut bug or a livemedia-creator problem changing the name of the directory
17:26:52 <cmurf> I think that's what's going on here, because dracut wants to find things in a particular place and they aren't there anymore
17:27:00 <cmurf> litd seems to make the media correctly
17:27:10 <cmurf> so i suspect this ultimately will be a lorax bug fix
17:27:19 <cmurf> or dracut
17:27:36 <adamw> basically it definitely hits the current criterion as written if the fix requires the *images* to be changed somehow
17:27:44 <adamw> if we can't just fix it in the tool for writing them to sticks
17:27:45 <cmurf> right
17:27:57 <adamw> if it can be fixed in the tools we have slight wiggle room even under the current criterion
17:28:02 <adamw> so, votes?
17:28:04 <cmurf> the path changed between livecd-creator and livemedia-creator
17:28:22 <cmurf> AFAIK can't be fixed in litd
17:28:26 <adamw> i guess i'm punt just on the basis this whole area changed completely and it makes sense to check in with the devs what we actually plan to support now
17:28:37 <cmurf> absolutely reasonable
17:28:39 <adamw> but i'll note for the record that i definitely agree it hits the criterion as it exists
17:28:54 <cmurf> right
17:29:11 <cmurf> actually i'd be more sad for soas if we have no persistent overlay option, than probably any other use case
17:29:12 <adamw> kparal?
17:29:15 <adamw> anyone else still alive?
17:29:34 <cmurf> success all of our enemies are vanquished
17:29:39 <kparal> I am, but I have no idea, I defer to the superior knowledge of all of you
17:30:05 <cmurf> haha superior knowledge... clearly that's not a factor we have to appeal to higher authorities in any case
17:30:37 <pwhalen> +1
17:31:14 <kparal> where's pschindl_, anyway? he surely fell asleep again, right after roll call :)
17:31:20 <adamw> pwhalen: is that +1 blocker or +1 punt?
17:31:29 <adamw> kparal: go check the gutters behind the bars
17:31:31 <kparal> I'm either punt or +1, whichever. we'll need to resolve it either way
17:31:53 * satellit hope we can fix it
17:31:55 * cmurf same page as kparal
17:32:03 <cmurf> in principle block for now, but needinfo/punt
17:32:05 <pwhalen> +1 blocker, check with the devs
17:32:17 <cmurf> yeah we're all there
17:32:39 <adamw> okay, well, let's pick somethin'
17:32:42 <kparal> adamw: he has a habit of going 10 miles into a random direction and not remember any part of it, instead of lying somewhere. that would be too easy
17:33:09 <garretraziel> but then again, who hasn't
17:33:13 <cmurf> punt/needinfo
17:33:19 <adamw> proposed #agreed 1318470 - AcceptedBlocker (Final) - this is accepted per the current criterion which it definitely seems to violate, but we note that this whole area has changed a lot with F24 and it may be that persistence is no longer supported: we will check with the developers for clarification
17:33:26 <cmurf> ack
17:33:31 <satellit> ack
17:33:35 <garretraziel> ack
17:33:39 <kparal> garretraziel: I didn't, or at least I don't remember it ;)
17:33:43 <pwhalen> ack
17:33:44 <kparal> ack
17:34:09 <adamw> #agreed 1318470 - AcceptedBlocker (Final) - this is accepted per the current criterion which it definitely seems to violate, but we note that this whole area has changed a lot with F24 and it may be that persistence is no longer supported: we will check with the developers for clarification
17:34:33 <adamw> #topic (1331107) The shutdown process on KDE takes ~2/3 minutes longer than usual
17:34:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331107
17:34:34 <adamw> #info Proposed Blocker, plasma-workspace, NEW
17:34:47 <adamw> we already discussed this as beta FE but I forgot it was also nominated as final blocker, mea culpa
17:34:55 <cmurf> oh and i thought
17:34:59 <adamw> i suspect this wouldn't pass the 'last blocker' smell test...
17:35:04 <cmurf> no
17:35:20 <cmurf> if it survives that long... it's a feature
17:35:27 <cmurf> not a blocker
17:35:36 <kparal> this sucks, but actually has been happening to me in a sense for the last several years. so it's kind of "fedora feature"
17:35:41 <adamw> hehe
17:35:54 <kparal> mostly cased by luks+lvm in my case
17:35:59 <kparal> *caused
17:36:05 <cmurf> kparal really? hmmm
17:36:19 <kparal> I think
17:36:22 <adamw> well
17:36:25 * satellit I see wait for 1min 30 sec in shutdown
17:36:26 <adamw> we have to be careful with this
17:36:31 <adamw> there can be *many* reasons for shutdown delays
17:36:46 * kparal powers down his laptop with sysrq more often than not
17:36:47 <adamw> and they will often involve a 'stop job for user session' message (or whatever the precise text is)
17:36:51 <adamw> that does *not* mean they are the same bug
17:37:00 <adamw> kparal: remote mounts can often screw up laptop shutdown, fwiw...
17:37:01 <cmurf> i wonder if our lovely umount+e2fsck bug that hits composes is related to DE specific delays in "shutdown" or whatever they do, and that inhibits umount from happening...
17:37:03 <cmurf> anyway
17:37:09 <kparal> adamw: that's also possible
17:37:17 <adamw> so i want to be careful we don't wind up with another 'stop job' megabug which is actually 15 different bugs
17:37:32 <cmurf> yes the stop job red cylon eye
17:37:34 <adamw> since that didn't help anyone
17:38:02 <kparal> anyway, I guess -1, we're sadly not there yet and can't block for "just annoyances"
17:38:04 <cmurf> is it a cylon eye or is it K.I.T.T.
17:39:05 <adamw> yeah, especially since the worst cases here we can fix with an update
17:39:13 <adamw> slowness shutting down a live image is annoying but not really blocking
17:39:14 <adamw> so -1
17:40:04 <adamw> i'd definitely like to find time to debug this, though...
17:40:07 <garretraziel> I agree with adamw, -1
17:40:14 <satellit> -1
17:40:14 <cmurf> -1
17:40:32 <nb> -1
17:40:51 <cmurf> kparal: does it happen with opensuse?
17:41:10 <cmurf> they're slightly more KDE oriented if I recall correctly
17:41:10 <pwhalen> -1
17:41:29 <adamw> proposed #agreed 1331107 - RejectedBlocker (Final) - this is definitely an annoyance, but a delay in shutdown isn't severe enough to meet the criteria, especially as it can be fixed with an update for installed systems
17:41:46 <cmurf> ackchoo!
17:43:11 <kparal> cmurf: didn't happen yet. haven't used it yet either, though...
17:43:18 <kparal> ack
17:43:28 <adamw> one more ack?
17:43:32 <nb> ack\
17:43:48 <satellit> ack
17:43:57 <pwhalen> ack
17:44:22 <garretraziel> ack
17:44:29 <adamw> #agreed 1331107 - RejectedBlocker (Final) - this is definitely an annoyance, but a delay in shutdown isn't severe enough to meet the criteria, especially as it can be fixed with an update for installed systems
17:44:32 <adamw> wow, it's an ack flood
17:44:34 * adamw drowns in the acks
17:44:43 <adamw> ok, just two to go!
17:44:43 <adamw> #topic (1330766) [abrt] realmd: g_cancellable_is_cancelled(): realmd killed by SIGSEGV
17:44:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1330766
17:44:44 <adamw> #info Proposed Blocker, realmd, NEW
17:44:46 <cmurf> kparal: might be a useful point of reference, see if it happens with Tumbleweed, should be sufficiently new to be a valid comparison to Fedora KDE
17:45:12 <kparal> see, and now I have a business reason to run on opensuse :)
17:45:26 <adamw> haha
17:46:11 <adamw> so i hit this in freeipa testing
17:46:17 <cmurf> yep
17:46:26 <adamw> basically if an enrolment requires packages to be installed, it fails
17:46:28 <cmurf> so why is it or is it not conditional?
17:46:43 <cmurf> seems fairly reliably blocker worthy?
17:46:51 <adamw> well, the thing is, you can just re-try immediately and it should work
17:46:59 <cmurf> uh huh
17:47:02 <cmurf> interesting
17:47:08 <kparal> why does it fail only once? by then the packages are installed?
17:47:08 <adamw> but...dunno if that's enough to reject it
17:47:11 <adamw> kparal: yes
17:47:16 <adamw> at least, that's what it seems like.
17:47:18 <kparal> ok, so deterministic
17:47:33 <cmurf> bad initialization or something?
17:47:38 <adamw> kparal: well, there's a few assumptions in there - we could test with very short package install times and stuff
17:47:44 <adamw> but the basic behaviour seems reproducible, i hit it 3 times
17:47:51 <kparal> seems +1
17:48:12 <cmurf> i still think it's more +1 than not, even that it works on 2nd attempt
17:48:23 <cmurf> consistently on all systems it doesn't work on 1st attempt, right?
17:48:27 <kparal> not sure if this would hold the last blocker test
17:48:44 <adamw> cmurf: well, if you happen to have the packages already installed it may work, though again i didn't explicitly test that yet
17:48:57 <adamw> so if say you have a kickstart for deploying your clients, which installs the packages
17:49:01 <cmurf> shouldn't they already be installed?
17:49:14 <cmurf> if it's supposed to work OOTB, seems like they should be there
17:49:14 <adamw> they're not all installed in an ootb server install
17:49:24 <adamw> nah, it's expected that they'll be downloaded
17:49:40 <cmurf> but there's a release blocking criterion for optional packages?
17:49:59 <adamw> what do you mean, 'optional'?
17:50:09 <cmurf> well it's not included by default, it's an option to install it
17:50:27 <adamw> the enrolment tool itself is installed by default
17:50:38 <adamw> the specific packages for operating as a client are not because they're different for different domains
17:50:48 <adamw> you need a different set of packages to be an AD client vs. a FreeIPA client
17:50:52 <adamw> so we don't install all the packages for both
17:50:55 <cmurf> okay
17:51:08 <adamw> this bug is likely in the enrolment tool itself, not the client packages
17:51:12 <cmurf> well there's a criterion and it seems to apply so I'm still +1
17:51:21 <danofsatx> +1
17:51:27 <garretraziel> +1
17:51:31 <cmurf> and if it really doesn't pass the last blocker smell test then the criterion needs to be re-evaluated
17:51:39 * danofsatx sneaks in like he was always here
17:51:46 <adamw> hi dan =)
17:52:14 <cmurf> danofsatx: blues beat the stars last night, neener
17:52:35 <danofsatx> ya, but Spurs are beating everyone ;)
17:52:37 <adamw> proposed #agreed 1330766 - AcceptedBlocker (Final) - this does seem like a violation of "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install" in the case that the client packages are not yet installed, which is the case for a default Server install
17:53:15 <danofsatx> ackish
17:53:25 <cmurf> ackathon
17:54:05 <adamw> you crazy rebels
17:54:24 <cmurf> danofsatx: basketball, scores are too high, you keep having to sharpen pencils to keep track of the score
17:54:31 <kparal> ack
17:54:51 <nb> ack
17:54:53 <adamw> #agreed 1330766 - AcceptedBlocker (Final) - this does seem like a violation of "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install" in the case that the client packages are not yet installed, which is the case for a default Server install
17:54:56 <adamw> ok, just one more!
17:54:59 <adamw> #topic (1247797) [abrt] WARNING: CPU: 0 PID: 1101 at drivers/gpu/drm/i915/intel_display.c:11098 intel_check_page_flip+0xea/0x100 [i915]() [i915]
17:54:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1247797
17:54:59 <adamw> #info Proposed Blocker, xorg-x11-drv-intel, NEW
17:55:02 <cmurf> mercy
17:56:16 <kparal> well the last comment sounds optimistic
17:56:26 <cmurf> seems like a -1 on the basis it's not clear what the problem is, therefore not clear how to fix, and seems maybe fixed already
17:56:35 <adamw> hmm, recent comment that this is fixed
17:56:43 <adamw> punt again for more info from other reporters?
17:56:51 <cmurf> -1 blocker, upgrade and repropose if you still hit it
17:57:04 <cmurf> update rather
17:57:17 <cmurf> gonna guess it was a kernel update
17:57:27 <pwhalen> agreed, punt for more info on the bz
17:57:37 <kparal> punt a week and see
17:59:11 <adamw> proposed #agreed 1247797 - punt (delay decision) - it seems this may have been fixed recently, we will ask other reporters if they are still seeing the problem and re-consider this next week
17:59:17 <kparal> ack
17:59:23 <nb> ack
17:59:24 <cmurf> ack
17:59:33 <danofsatx> ack
17:59:42 <adamw> #agreed 1247797 - punt (delay decision) - it seems this may have been fixed recently, we will ask other reporters if they are still seeing the problem and re-consider this next week
17:59:48 <adamw> alrighty, right on time!
17:59:50 <adamw> #topic Open floor
17:59:53 <adamw> so, any other business, folks?
17:59:55 <danofsatx> yay me
17:59:59 <cmurf> zip
18:00:05 <adamw> i haven't looked at the matrices yet today but we should fill in any remaining gaps for 1.4
18:00:18 <adamw> i will get a stable push request in today which should clear the beta blocker lists for now
18:00:31 <danofsatx> I don't feel like reading back log, are there beta blockers, or not?
18:00:37 <adamw> none outstanding atm
18:00:51 <danofsatx> cool
18:01:03 <cmurf> neat
18:01:14 <adamw> allllrighty
18:01:19 <adamw> let's let the brno folks get to the bar
18:01:22 <adamw> thanks for coming everyone
18:01:25 * RaphGro wonders if the comps lxqt l10n bug is also in f23, propably yes. nobody claimed till now.
18:01:26 <adamw> who am i kidding, they've been there for hours
18:01:32 <danofsatx> what makes you think they're not already there?
18:01:32 <kparal> pschindl_: wake up, we're going to a bar!
18:01:38 <adamw> RaphGro: I think the group may be new in f24? not sure though
18:01:53 <cmurf> could look at https://bugzilla.redhat.com/show_bug.cgi?id=1331382 which was asked about on fedora-qa channel
18:01:58 <RaphGro> will look deeper into it
18:02:57 <adamw> well, that may be 'intended'
18:03:04 <adamw> in that the desktop controls the keyboard layout when you're running live
18:03:15 <cmurf> that makes sense
18:03:15 <adamw> perhaps the indicator could have different modes to show when it's just an indicator and when it's a switcher...
18:03:36 <cmurf> ok but not a blocker
18:04:14 <adamw> yeah, well, i'll keep an eye on it
18:04:17 <adamw> ok, thanks everyone!
18:04:20 * adamw sets the fuse
18:06:31 <adamw> #endmeeting