16:02:52 <adamw> #startmeeting F24-blocker-review
16:02:52 <zodbot> Meeting started Mon Apr 18 16:02:52 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:52 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:02:52 <adamw> #meetingname F24-blocker-review
16:02:52 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:02:53 <adamw> #topic Roll Call
16:03:00 <adamw> ahoyhoy, who's around for blocker review meeting fun?
16:03:36 * kparal is here
16:03:44 <kparal> I'm afraid we will be low on people
16:03:53 <kparal> most people excused themselves
16:05:33 <adamw> sigh
16:05:37 <adamw> we need to do FE review too
16:05:58 <adamw> let's give it a few and if we don't have people we can retry tomorrow i guess...
16:06:01 <adamw> brunowolff: ahoy?
16:06:19 <adamw> nirik: dgilmore: halfline: danofsatx: tflink: ahoy ahoy ahoy ahoy?
16:06:35 * nirik is in the releng meeting with dgilmore also
16:07:33 <brunowolff> I'm probably going to have to leave soon.
16:08:03 <rdieter> I can participate if you need another warm body
16:08:22 <kparal> we accept zombies too
16:08:24 <dgilmore> adamw: give me 20 minutes
16:09:49 <brunowolff> It looks like I can stay.
16:11:43 * pwhalen is here
16:12:06 * adamw does some countin'
16:12:18 <adamw> so we have...me, kparal, rdieter, bruno, pwhalen, apparently
16:12:24 <adamw> that seems like enough to give it a shot.
16:12:37 <adamw> #chair brunowolff kparal
16:12:37 <zodbot> Current chairs: adamw brunowolff kparal
16:12:45 <adamw> #topic Introduction
16:12:45 <adamw> Why are we here?
16:12:45 <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:45 <adamw> #info We'll be following the process outlined at:
16:12:47 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:12:47 <adamw> #info The bugs up for review today are available at:
16:12:49 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:50 <adamw> #info The criteria for release blocking bugs can be found at:
16:12:52 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:12:54 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:12:56 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:13:47 <adamw> #topic (1325085) libvirt assigns same address to two PCI devices
16:13:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1325085
16:13:48 <adamw> #info Proposed Blocker, libvirt, ON_QA
16:13:54 <adamw> oh, who's gonna secretarialize?
16:14:01 * adamw looks at no-one in particular, particularly not kparal
16:14:13 <kparal> sure, sure
16:14:56 <adamw> =)
16:15:03 <adamw> #info kparal has kindly 'volunteered' to secretarialize
16:15:51 <adamw> so, uh...sounds plausible?
16:16:09 <adamw> seems like maybe ARM only?
16:16:17 <adamw> still, ARM's a primary arch, sooo
16:16:50 <pwhalen> +1 of course
16:18:43 <adamw> pwhalen is +1 on anything with 'arm' in it
16:18:49 <adamw> votes, ppl
16:19:00 <kparal> I don't know if it happens always or not
16:19:05 <kparal> but +1 I guess
16:19:34 <brunowolff> +1 blocker
16:19:43 <rdieter> +1
16:20:22 <adamw> woohoo, everyone wave yer rubber stamp in the air like you just don't care
16:21:07 <adamw> proposed #agreed 1325085 - AcceptedBlocker (Beta) - as described, the bug is a violation of "The release must be able host virtual guest instances of the same release." on ARM (a primary arch)
16:21:29 <pwhalen> ack
16:21:38 <brunowolff> If I didn't care I'd vote no blocker as the only arm machine I have doesn't run normal Fedroa.
16:22:10 <brunowolff> ack
16:22:25 <kparal> ack
16:22:38 <adamw> #agreed 1325085 - AcceptedBlocker (Beta) - as described, the bug is a violation of "The release must be able host virtual guest instances of the same release." on ARM (a primary arch)
16:22:46 <adamw> #topic (1321393) blivet.errors.DeviceTreeError: no slaves found for device md127
16:22:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1321393
16:22:46 <adamw> #info Proposed Blocker, python-blivet, ASSIGNED
16:24:16 <adamw> oh man, what were we doing with this one
16:24:24 <rdieter> looks like the NEEDINFO query hasn't been satisfied (yet)
16:24:41 <adamw> oh, right, we had some ideas and none of the reporters responded
16:24:45 <adamw> welp on that basis i'm fine with a -1
16:25:08 <rdieter> ditto, -1
16:25:11 * kparal is fine with -1 until more info is presented
16:26:38 <brunowolff> -1 if we can't reproduce and reporters aren't helping.
16:27:15 <pwhalen> -1 until more info
16:28:15 <adamw> proposed #agreed 1321393 - RejectedBlocker (Beta) - no-one has responded to the information requests on this, so for now it is rejected as a blocker on the basis it was likely caused by multiple installer launches and no data is available to indicate otherwise. the bug can be re-proposed as a blocker with the requested information if appropriate
16:28:26 <pwhalen> ack
16:28:52 <brunowolff> ack
16:29:24 <kparal> ack
16:30:44 <rdieter> ack
16:32:12 * kparal pokes adamw
16:32:16 <cmurf> well that extra hour (and 30 minutes) flew by quickly
16:32:21 <adamw> sorry
16:32:25 <adamw> #agreed 1321393 - RejectedBlocker (Beta) - no-one has responded to the information requests on this, so for now it is rejected as a blocker on the basis it was likely caused by multiple installer launches and no data is available to indicate otherwise. the bug can be re-proposed as a blocker with the requested information if appropriate
16:32:51 <adamw> #topic (1327360) qt > 4.8.7-6.fc24 fails to load any plugins (including styles)
16:32:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1327360
16:32:51 <adamw> #info Proposed Blocker, qt, MODIFIED
16:33:13 <kparal> rdieter: this breaks default apps on KDE Live, right?
16:33:19 <kparal> at least some default apps
16:33:28 <rdieter> kparal: a few, yes
16:33:43 <kparal> so we can use that criterion
16:33:53 <adamw> the 'default apps must work' criterion is final, though
16:34:05 <adamw> for beta there's only a few specific features of the desktop that must work
16:34:09 <kparal> hmm, right
16:34:43 <kparal> rdieter: is something from this broken as a consequence of that bug?  https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Post-install_requirements
16:34:43 <adamw> i'm fine with FE for this but at least on current info it's not a blocker
16:35:06 <rdieter> I knew that too, sorry.  +1 beta FE
16:35:11 <rdieter> -1 blocker
16:35:55 <kparal> ok, -1/+1
16:36:05 <cmurf> -1 blocker +1 FE
16:36:07 <adamw> we can vote +1 Final blocker too i guess
16:36:11 <cmurf> maybe +1 blocker final
16:36:12 <adamw> not sure if necessary
16:36:33 <pwhalen> +1 beta FE , +1 final blocker
16:36:39 <kparal> +1 final
16:36:41 <rdieter> adamw: naw, I'm confident fixed rebuilds will land relatively quickly, no need for the beaurocracy
16:37:21 <brunowolff> Looks like +1 FE +1 final blocker according to criteria
16:39:22 <adamw> ok'
16:40:30 <adamw> proposed #agreed 1327360 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this does not violate any of the Beta criteria so far as we can tell, but does violate "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" in the case of a few qt4 apps instal
16:40:30 <adamw> led by default with the KDE spin. It as accepted as a Beta FE for this same reason.
16:40:33 <adamw> grr
16:40:57 <kparal> (we can drop the final blocker)
16:41:13 <adamw> proposed #agreed 1327360 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - does not violate any of the Beta criteria, but does violate "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully..." in the case of qt4 apps installed with the KDE spin. It as accepted as a Beta FE for this reason
16:41:29 <kparal> ack
16:41:31 <rdieter> ack
16:41:33 <pwhalen> ack
16:41:35 <brunowolff> ack
16:41:46 <cmurf> ack
16:43:57 <adamw> #agreed 1327360 - RejectedBlocker (Beta) AcceptedBlocker (Final) AcceptedFreezeException (Beta) - does not violate any of the Beta criteria, but does violate "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully..." in the case of qt4 apps installed with the KDE spin. It as accepted as a Beta FE for this reason
16:44:06 <adamw> alrighty, that's all the Beta blockers
16:44:15 <adamw> since we're freezing tomorrow, let's do proposed Beta FEs too
16:44:16 <adamw> sound good?
16:44:23 <pwhalen> sure
16:44:35 <adamw> #info moving on to proposed Beta freeze exceptions
16:44:36 <adamw> #topic (1323193) FTBFS on secondary arches due liblfds
16:44:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1323193
16:44:36 <adamw> #info Proposed Freeze Exceptions, 389-ds-base, ON_QA
16:45:56 <adamw> #c1 seems like a reasonable justification
16:46:02 <adamw> important bits missing from secondary arch Server images
16:46:08 <adamw> so, +1 FE for me i guess
16:46:16 <rdieter> +1 FE
16:46:20 <pwhalen> +1 FE
16:46:45 <cmurf> sure +1
16:47:49 <kparal> +1
16:48:21 <adamw> proposed #agreed 1323193 - AcceptedFreezeException (Beta) - FreeIPA is a core part of the Server flavor, and this bug prevents its inclusion in secondary-arch images. issues that seriously affect the compose of secondary arch deliverables generally qualify for FE status.
16:48:36 <pwhalen> ack
16:48:37 <kparal> ack
16:48:40 <brunowolff> ack
16:48:44 <adamw> #agreed 1323193 - AcceptedFreezeException (Beta) - FreeIPA is a core part of the Server flavor, and this bug prevents its inclusion in secondary-arch images. issues that seriously affect the compose of secondary arch deliverables generally qualify for FE status.
16:48:55 <adamw> #topic (1315225) firefox build failure on ppc64le/arm64
16:48:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1315225
16:48:55 <adamw> #info Proposed Freeze Exceptions, firefox, NEW
16:49:02 <adamw> seems like a similar case
16:49:30 <adamw> +1 FE
16:49:34 <pwhalen> +1 FE
16:49:41 <adamw> (i mean similar in terms of FE status, not technically similar)
16:49:48 <rdieter> +1 FE
16:49:50 <kparal> +1
16:50:41 <brunowolff> +1 FE
16:51:59 <adamw> proposed #agreed 1315225 - AcceptedFreezeException (Beta) - Firefox is the default browser for most desktops, and this bug prevents its inclusion in secondary-arch images. issues that seriously affect the compose of secondary arch deliverables generally qualify for FE status.
16:52:12 <pwhalen> ack
16:52:35 <brunowolff> ack
16:52:45 <kparal> ack
16:52:50 <rdieter> ack
16:52:53 <adamw> #agreed 1315225 - AcceptedFreezeException (Beta) - Firefox is the default browser for most desktops, and this bug prevents its inclusion in secondary-arch images. issues that seriously affect the compose of secondary arch deliverables generally qualify for FE status.
16:52:59 <adamw> #topic (1323511) hibernate action results in a shutdown
16:52:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1323511
16:52:59 <adamw> #info Proposed Freeze Exceptions, kernel, NEW
16:53:01 <adamw> oh, man
16:53:07 <cmurf> just say no
16:53:11 <adamw> when I see the word 'hibernate' I reach for my revolver
16:53:14 <cmurf> haha
16:53:18 <pwhalen> heh
16:53:36 <cmurf> because you have a revolver so handy at all times
16:53:40 <brunowolff> Given we are on a stable kernel right now, I don't think a freeze exception would be overly risky.
16:53:59 <kparal> adamw: why is that?
16:54:10 <cmurf> I think all hibernation stuff is best let up to upstreams, I know that  it *ought* to work in a VM but...
16:54:31 <kparal> I think this might actually be a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1206936 which is proposed for a final blocker
16:54:37 <adamw> kparal: i can't recall a time when it's actually really worked reliably at all.
16:54:38 <kparal> and has a reasonable justification
16:54:48 <cmurf> I think its kinda outta scope for us because it's so complicated to sort out kernel vs systemd vs dracut vs all the proper settings from the installer have been made (or not)
16:55:03 <kparal> adamw: you might be surprised to read the one proposed for the final blocker then :)
16:55:25 <cmurf> the installer team doesn't support it so i don't see how we block on it
16:55:28 <adamw> anyone who claims it worked at any point there is either a) lying or b) lucky
16:55:29 <adamw> :P
16:55:34 <kparal> -1 for Beta FE, in any case. and we can discuss the one for Final afterwards
16:55:38 <cmurf> lying and lucky?
16:55:57 <cmurf> -1 FE, there's no admission by any party whose problem this even is
16:56:02 <cmurf> where would the fix go?
16:56:15 <adamw> let's say i'm -1 FE without at least some kind of clear agreement on what actually is going to get fixed
16:56:18 <adamw> 'fixed'
16:56:51 <pwhalen> -1
16:56:53 <rdieter> -1 too
16:56:53 <cmurf> i think hibernation is in the category of experimental surgery, if it works, great, but we're not guaranteeing anything
16:57:09 <adamw> cmurf: that's always been my take, yeah.
16:58:00 <cmurf> cmurf's experimental surgery vs adamw's revolver
16:58:13 <adamw> revolver-based experimental surgery
16:58:21 <cmurf> haha now that's funny
16:58:31 <cmurf> that's got me laughing
16:58:46 <adamw> proposed #agreed 1323511 - RejectedFreezeException (Beta) - there does not appear to be any agreement even on who should be fixing what here, which makes it hard to grant this an FE. we would re-consider it if some specific development team would at least accept responsibility so it's clear roughly what will be fixed and how.
16:58:53 <cmurf> RBES
16:58:56 <kparal> ack
16:59:01 <cmurf> ack
16:59:09 <rdieter> kparal: the symptoms appear the same, I'd say dup 'em (1323511 and 1206936 )
16:59:10 <rdieter> ack
16:59:32 <kparal> I'll put See Also in there and mention it
16:59:35 <pwhalen> ack
16:59:41 <kparal> the original issue is reported against VMs
16:59:52 <kparal> which is likely to be a different scenario
17:00:19 <cmurf> The DE's are really well advised to not expose hibernation unless they know it works and they will support it. GNOME on Fedora at least has hidden all of that stuff from the user.
17:00:47 <brunowolff> ack
17:01:00 <rdieter> cmurf: imo, let systemd do it
17:01:15 <kparal> cmurf: the official response was that they don't know how to put it into UI to "look nice", not that it is not working well. at least speaking about suspend.
17:01:34 <cmurf> rdieter, it's more complicated, it takes something like 14 things to go right for both hibernation and the resume to work out
17:01:37 <rdieter> cmurf: or enforce it via policykit
17:01:58 <cmurf> suspend to ram should work, :-P
17:01:59 <rdieter> so CanHibernate returns false by default
17:02:37 <rdieter> so users would have to opt in via custom policykit or permissions or something to enable it
17:02:50 <cmurf> that'd be nice
17:02:51 * kparal has his finger on the rejection notice trigger and waits for adamw to give a signal to fire it
17:02:56 <adamw> #agreed 1323511 - RejectedFreezeException (Beta) - there does not appear to be any agreement even on who should be fixing what here, which makes it hard to grant this an FE. we would re-consider it if some specific development team would at least accept responsibility so it's clear roughly what will be fixed and how.
17:02:59 <adamw> okey dokey
17:03:00 <kparal> bam!
17:03:02 <rdieter> ack
17:03:13 <adamw> we already voted on 1327360 , so that's good
17:03:29 <adamw> alright, we have a couple of final blockers so let's blow through those quickly
17:03:35 <adamw> #info moving onto Final blockers
17:03:37 <cmurf> super
17:03:38 <adamw> since we're on the topic already:
17:03:43 <adamw> #topic (1206936) Laptop does not resume from hibernate, boots instead
17:03:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1206936
17:03:44 <adamw> #info Proposed Blocker, systemd, NEW
17:04:10 <kparal> jhogarth is not here, a pity
17:04:24 <adamw> i'm gonna be -1 on this. i have sympathy for the rationale from #c32, but ultimately i'm not buying it. 'hybrid suspend' is an extremely experimental thing and I don't think we've ever provided any kind of guarantee that it's gonna work.
17:04:34 <kparal> he pinged me on irc and debugged this
17:04:45 <kparal> his argument is not about specific hardware issues etc
17:04:55 <adamw> so unless we actually stand behind hybrid suspend as some sort of guaranteed feature, you would lose open data in apps when you run out of battery *anyway*. thus i'm not gonna buy that as a criteria violation.
17:04:58 <kparal> but about this functionality being completely broken on all hardware
17:05:06 <cmurf> the problem is anything that permits hibernation to happen not knowing if it can resume, will result in data loss
17:05:16 <cmurf> so i'm on the side of making sure it can't easily be used
17:05:23 <rdieter> good point
17:05:27 <kparal> cmurf: not really, you sync data beforehand
17:05:28 <adamw> cmurf: but the only thing that does it is this 'hybrid suspend' thing
17:05:31 <adamw> which kicks in when battery is low
17:05:36 <kparal> so it's like a broken suspend-resume
17:05:42 <kparal> which happens to me once a week
17:05:42 <adamw> so if we turn that off, what do we get instead? the system just stays suspended and the battery dies
17:05:44 <adamw> ...and you lose your data anyway
17:05:53 <cmurf> kparal: should be true
17:06:17 <adamw> so, basically, we have two ways we can lose your data when your battery dies. switching from one to the other doesn't seem like a thing we should block the release for.
17:06:33 <adamw> unless the 'hybrid suspend' thing kicks in with like 20% battery left or something, i dunno what the cutoff is exactly.
17:06:47 <cmurf> the only thing I know that works, hybrid wise, is Intel Rapid Start, where it's entirely managed by the firmware
17:07:14 <cmurf> but it requires its own unique partition, and we don't have support for it in the installer, even though there is such support for that in the  kernel
17:07:22 <kparal> to be fair, I don't see "hybrid suspend" or "hibernation" option anywhere in gnome, so this is not likely to be a default functionality
17:07:37 <cmurf> kparal: right
17:07:49 <kparal> (I think this bug is not just about hybrid suspend, but also about normal hibernation )
17:08:03 <cmurf> it's actually about it not resuming correctly right?
17:08:16 <adamw> so yeah, if we have some kind of easily user visible interactive way to trigger hibernate on a release blocking desktop, i could buy a blocker bug to turn it off. if 'hybrid suspend' kicks in with a decent chunk of battery life available, I could *maaaaaybe* buy a blocker to change that. those are about the only hibernate-related blockers I'd buy.
17:08:32 <kparal> but otoh, if we can't do hibernation at all, on any hardware, just because our software is broken, we are pretty uncompetitive in the OS scene
17:08:36 <cmurf> and it doesn't resume because there's no resume= on the command line, and systemd is assuming a resume= for dracut to then go find out what actual kernel device to tell the kernel to resume from
17:08:43 <adamw> kparal: jhogarth claims "Hibernation is commonly required in laptop scenarios and indeed the default power management on critical battery is to HybridSleep"
17:08:47 <adamw> but i dunno any details on that
17:09:06 <kparal> in the gnome control center, the default action on low battery seems to be suspend
17:09:21 <cmurf> i thought it was poweroff
17:09:43 <kparal> hmm, off by default, but can be enabled
17:09:50 <kparal> it's called "suspend & power off"
17:09:51 <cmurf> it should be suspend to ram on a timer only, and if the power is getting low then it does a poweroff
17:09:57 <kparal> is it hybrid sleep?
17:10:17 <cmurf> yeah maybe
17:10:31 <kparal> we can ask at #fedora-desktop
17:10:45 <cmurf> suspend to ram with low power is risky, there can be data loss in that case for sure
17:11:46 * kparal asked at #fedora-desktop
17:11:51 <adamw> i'm still inclined -1 on this, but i can live with a punt if necessary.
17:12:39 <cmurf> I'm -1, we have no criterion
17:13:10 <cmurf> hibernation is like the rules of hockey, exceptions everywhere
17:13:24 <kparal> I agree it would be best to have a separate criterion for this, that would exclude hardware specific issues, even broad ones, and only talk about the software side doing the right thing (like not forgetting the resume= line)
17:13:37 <cmurf> kparal +1
17:14:12 <adamw> i'd only want to do that if the developers actually want to stand behind it. but that's a separate discussion i guess
17:14:51 <cmurf> adamw: i think the discussion definitely requires developer support backing it up or it's a noop discussion
17:14:51 <kparal> give me one more minute
17:16:07 <kparal> also see https://fedoraproject.org/wiki/Common_F24_bugs#Hibernation_doesn.27t_work_from_a_standard_install
17:16:16 <cmurf> AFAIK modern hardware running windows 8/10 expect firmware hibernation, they've given up on software hibernation over there; macs, well they do a hybrid firmware+bootloader hibernation because the hibernation file can be encrypted
17:16:38 <kparal> James Hogarth told me that by doing that quite simple workaround, hibernation starts working for him
17:16:57 <kparal> so it's really a tiny bug that breaks it completely
17:17:08 <cmurf> You mean resume= as a boot parameter?
17:17:51 <kparal> yes, it seems so
17:18:18 <cmurf> Ok well then it's an anaconda bug? That's what writes resume= into /etc/default/grub so that the grub.cfg gets it added.
17:18:47 <adamw> except anaconda devs say it's stupid that they should have to do it, and they have a reasonable point there
17:18:51 <adamw> but again not really our question.
17:18:59 <cmurf> Right.
17:19:02 <adamw> our question isn't whether this is a bug or who should fix it, but whether it's a release blocker.
17:19:11 <cmurf> No criterion we have no way to make it a blocker we can't even say whose bug it is.
17:19:24 <kparal> mclasen says there's a hibernation action somewhere in the UI, but I can't find it
17:19:27 <adamw> there is a criterion justification attempt in the bug, i just don't buy it. :P
17:19:37 <kparal> we can punt and I can add more information to it
17:19:43 <cmurf> +1 punt
17:19:44 <adamw> i guess i can live with that.
17:19:44 <mclasen> kparal: I think we only show it if it has a chance of working, maybe ?
17:20:01 <kparal> mclasen: ok, I have swap disabled, so I might not see it
17:20:01 <cmurf> mclasen for sure only if it has a GOOD chance of working ;-)
17:20:20 <kparal> please see http://i.imgur.com/lpF7DX7.png
17:20:25 <kparal> so yes, it's in the UI
17:20:36 <kparal> at least on some machines
17:20:51 <mclasen> yeah, we call into logind to see if it thinks we can hibernate
17:21:20 <adamw> ehh, that's still pretty hidden. i was thinking more 'right there on the power menu'.
17:21:24 <adamw> aaanyhoo
17:21:46 <cmurf> Right but the test needs to be, can it hibernate *and* resume. If it can't do both it doesn't really support hibernation.
17:22:11 <mclasen> kparal: gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanHibernate  to find out
17:22:13 <adamw> proposed #agreed 1206936 - punt (delay decision) - we're inclined to reject this as we explicitly don't cover hibernation in the criteria and have always considered it too unreliable to block release, but we will delay the decision for a week for more discussion and input from all parties
17:22:14 <cmurf> I've never seen than in a VM either... I'll have to check. My hardware doesn't have that drop down menu.
17:22:20 <cmurf> ack
17:22:34 <pwhalen> ack
17:22:46 * kparal would not mind a new criterion is he described
17:23:08 <brunowolff> ack
17:23:22 <kparal> we need to push this stuff forward, because we suck in this area. we don't need to suck even more than bad drivers go
17:23:25 <adamw> kparal: well you get a week to propose one =)
17:23:25 <kparal> ack
17:23:30 <cmurf> kparal, that criterion will link to a which way book and diagram to help us determin which of 46 parties to pin the tail on the donkey
17:23:44 <adamw> #agreed 1206936 - punt (delay decision) - we're inclined to reject this as we explicitly don't cover hibernation in the criteria and have always considered it too unreliable to block release, but we will delay the decision for a week for more discussion and input from all parties
17:23:47 <kparal> cmurf: details!
17:23:54 <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:23:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1247797
17:23:54 <adamw> #info Proposed Blocker, xorg-x11-drv-intel, NEW
17:24:48 <cmurf> I thought this was fixed....
17:25:35 <cmurf> oh i see
17:25:41 <adamw> there've been a few similar ones...
17:25:48 <adamw> i'd probably wanna run this by ajax, i guess.
17:25:51 <cmurf> so it happens with wayland, uncertain if it happens with x
17:26:59 <cmurf> +1 FE, -1 block, contingent on getting an opinion from ajax
17:27:22 <mclasen> cmurf: we don't show power button configuration for tablets or vm's, it appears
17:27:24 <kparal> 40 users in CC
17:27:25 <cmurf> since we're not anywhere near final freeze, might as well punt and ask for info from ajax
17:27:45 <adamw> be worth checking the dates on the CCs
17:27:51 <adamw> see if most came in while we were on wayland-by-default
17:28:02 <cmurf> definitely most of those are older kernels
17:28:11 <cmurf> many are 4.2 series
17:28:15 <kparal> https://bugzilla.redhat.com/show_activity.cgi?id=1247797
17:28:36 <kparal> seems evenly distributed
17:28:42 <adamw> proposed #agreed 1247797 - punt (delay decision) - if this affects common hardware in a default configuration it's potential blocker material, but we want to check for non-Wayland cases and discuss with the relevant developers before making a decision
17:28:45 <cmurf> weren't we wayland by default for 10 minutes?
17:28:50 <kparal> too bad FAF doesn't respond
17:28:53 <pwhalen> ack
17:28:54 <cmurf> i mean in actual composes
17:29:04 <kparal> ack
17:29:06 <cmurf> ack
17:29:36 <adamw> i thought it was longer
17:29:39 <adamw> #agreed 1247797 - punt (delay decision) - if this affects common hardware in a default configuration it's potential blocker material, but we want to check for non-Wayland cases and discuss with the relevant developers before making a decision
17:29:43 <mclasen> cmurf: more like 5 months, believe (unless you don't count rawhide) rawhide)
17:29:45 <adamw> alright, that's all the proposals
17:30:42 <cmurf> \o/
17:31:22 <cmurf> re 1247797
17:31:28 <cmurf> i'm not seeing any newer kernels tested
17:31:32 <cmurf> it's 4.2 and 4.3
17:31:36 <cmurf> no 4.4 or even 4.5 kernels
17:32:12 <adamw> #topic Accepted Beta blocker roundup
17:32:16 <adamw> I'm a little worried on https://bugzilla.redhat.com/show_bug.cgi?id=1259865
17:32:22 <adamw> mclasen, can you kick that along at all?
17:32:45 <mclasen> I've sent mail about it earlier today
17:33:05 <brunowolff> I ran into some i915 issues several months ago, but it got fixed. So this should probably get retested on a 4.5 kernel.
17:33:10 <adamw> mclasen: thanks
17:33:19 <adamw> #info mclasen has poked #1259865
17:33:29 <adamw> #info adamw posted needinfo on #1321330
17:33:41 <adamw> other accepted blockers seem to be in hand
17:33:56 <adamw> any other notes on accepted beta blockers?
17:33:57 <cmurf> mclasen hughsie is @ lgm today if that's who you poked
17:34:11 <cmurf> lgm=libregraphicsmeeting
17:34:20 <mclasen> I wanted to mention that hughsie was working on making graphical upgrades testable with the beta before the weekend
17:34:31 <kparal> cmurf: I found only Last Glacial Maximum
17:35:00 <mclasen> haven't seen any results yet, but it shouldn't affect the freeze anyway (change goes in the copr/f23)
17:35:05 <cmurf> kparal: yes well sometimes it does seem like things move at a snails pace but...
17:35:54 <adamw> mclasen: that would be good. but freeze is tomorrow
17:35:59 <adamw> is there some bug we should grant an FE?
17:36:05 <adamw> oh i see
17:36:07 <adamw> missed your followup
17:36:08 <kparal> adamw: that's f23
17:36:58 <adamw> alrighty
17:37:02 <adamw> #topic Open floor
17:37:05 <adamw> any other topics?
17:37:13 <adamw> i don't see any huge looming bear traps for beta
17:37:20 <cmurf> what'd i miss about Fedora Media Writer testing tomorrow?
17:37:26 <adamw> we have the new-liveusb-creator test day tomorrow, it'd be good for people to come out and help
17:37:29 <cmurf> I NVM i'll just read th elogs
17:38:05 <cmurf> i've got it on my todo baring some other fire
17:38:29 <cmurf> I'm mainly concerned about the lack of Windows test coverage
17:38:45 <cmurf> The Windows tool just appeared a bit over a week ago.
17:39:17 <cmurf> https://mbriza.fedorapeople.org/liveusb-creator.zip
17:39:51 <cmurf> I'd really like it if we had our own tool for this than Rawriter32 or whatever is in our current installation docs.
17:40:39 <adamw> there is already a windows build of the old luc, we just don't recommend it terribly hard because the dd-style tools are more reliable
17:40:45 <adamw> if this rewrite works out well i'll adjust the docs
17:41:45 <cmurf> yeah this? https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
17:42:03 <cmurf> Or https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/sect-preparing-boot-media.html
17:42:18 <cmurf> The first one made me nearly reach for a bottle of scotch.
17:42:38 * satellit LUC new interface works in f23 - f24 for me
17:42:44 * kparal offers a shot of home-made slivovice
17:43:14 <adamw> cmurf: the first one. i would love if it could be simpler, but the tools suck. there's only so much you can do with the docs.
17:43:38 <adamw> any time i tried to make it simpler, people kept adding all the other choices back. badly.
17:43:46 <cmurf> adamw: I noticed that.
17:43:56 <adamw> so now i try to keep the least bad choices at the top and all the others at the bottom with information on exactly how much they all suck.
17:44:04 <cmurf> Haha
17:44:35 <adamw> it would be nice if luc was the best choice for everyone. the current tool doesn't cut it, though, as it's not available for non-linux distros and it's less reliable than either dd or litd writing
17:44:36 <cmurf> Or encourage the concise version for the official docs which can't be added to by just anyone like the wiki.
17:44:41 <adamw> for a long time it wouldn't create a stick that booted on UEFI at all
17:44:55 <adamw> yeah, that too. i haven't checked in on that page for a while
17:44:56 <adamw> anyhoo
17:45:06 <adamw> er, non-fedora linux distros, i mean
17:45:11 <cmurf> dd
17:45:27 <cmurf> dd is not friendly but it's bullet proof, even on a mac
17:45:58 <adamw> well, yes, you'll notice the three methods at the top of the page are the best dd-style methods i could find for each OS.
17:46:01 <cmurf> and there is a dd for windows, just not included by default
17:46:35 <adamw> i'm not telling windows users to use a CLI tool that could destroy their disks, i'm just not. i'd rather not do it for OS X, except I couldn't find any decent GUI dd tool for OS X.
17:46:36 <cmurf> something Rawrite32 is doing is it makes the media test fail, so it is either not block copying or it's mounting after the block copy.
17:46:41 <kparal> now that we have ubuntu on windows... ;)
17:46:59 <cmurf> Same thing happens on OS X. It mounts the stick rw after completion, which changes the contents, and that causes media check to fail.
17:47:03 <adamw> cmurf: note the SUSE tool is the first one in the instructions.
17:47:11 <cmurf> adamw; yep haven't tried it
17:47:15 <kparal> let's bundle whole ubuntu stack into FMR and distribute that :P
17:47:36 <cmurf> kparal: 3GiB?
17:48:11 <kparal> I know
17:48:40 <cmurf> pretty sure using litd causes media check to fail; for sure creating an overlay does.
17:48:43 <cmurf> OH!
17:49:01 <cmurf> BTW, persistent overlay in litd isn't working. Does anyone care? I'll find the bug.
17:49:10 <adamw> care level: 0
17:49:19 <adamw> at a guess i'd blame livemedia-creator, though
17:49:22 <cmurf> Is that almost infinite?
17:49:27 <adamw> no. no it is not.
17:49:30 <cmurf> Haha
17:49:36 <cmurf> I filed a bug against livecd-tools
17:50:02 <adamw> livemedia-creator is in lorax.
17:50:04 <cmurf> But the failure looks like it happens in dracut so you're probably right, it's livemedia-creator naming things differently in the ISO
17:50:14 <adamw> okay, anyhow
17:50:20 <adamw> anything else blocker/f24 beta related?
17:50:25 <cmurf> no
17:51:32 <adamw> alrighty then, thanks for coming, folks
17:51:38 <adamw> let's get beta testing done :)
17:52:05 <cmurf> it's done, ship it!
17:53:07 <adamw> +1
17:53:26 <adamw> if i was running things we'd just redirect getfedora.org to https://www.happyassassin.net/nightlies.html and all go get our damn pina coladas
17:53:49 <adamw> #endmeeting