16:02:52 #startmeeting F24-blocker-review 16:02:52 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:52 The meeting name has been set to 'f24-blocker-review' 16:02:52 #meetingname F24-blocker-review 16:02:52 The meeting name has been set to 'f24-blocker-review' 16:02:53 #topic Roll Call 16:03:00 ahoyhoy, who's around for blocker review meeting fun? 16:03:36 * kparal is here 16:03:44 I'm afraid we will be low on people 16:03:53 most people excused themselves 16:05:33 sigh 16:05:37 we need to do FE review too 16:05:58 let's give it a few and if we don't have people we can retry tomorrow i guess... 16:06:01 brunowolff: ahoy? 16:06:19 nirik: dgilmore: halfline: danofsatx: tflink: ahoy ahoy ahoy ahoy? 16:06:35 * nirik is in the releng meeting with dgilmore also 16:07:33 I'm probably going to have to leave soon. 16:08:03 I can participate if you need another warm body 16:08:22 we accept zombies too 16:08:24 adamw: give me 20 minutes 16:09:49 It looks like I can stay. 16:11:43 * pwhalen is here 16:12:06 * adamw does some countin' 16:12:18 so we have...me, kparal, rdieter, bruno, pwhalen, apparently 16:12:24 that seems like enough to give it a shot. 16:12:37 #chair brunowolff kparal 16:12:37 Current chairs: adamw brunowolff kparal 16:12:45 #topic Introduction 16:12:45 Why are we here? 16:12:45 #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 #info We'll be following the process outlined at: 16:12:47 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:12:47 #info The bugs up for review today are available at: 16:12:49 #link http://qa.fedoraproject.org/blockerbugs/current 16:12:50 #info The criteria for release blocking bugs can be found at: 16:12:52 #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria 16:12:54 #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria 16:12:56 #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria 16:13:47 #topic (1325085) libvirt assigns same address to two PCI devices 16:13:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1325085 16:13:48 #info Proposed Blocker, libvirt, ON_QA 16:13:54 oh, who's gonna secretarialize? 16:14:01 * adamw looks at no-one in particular, particularly not kparal 16:14:13 sure, sure 16:14:56 =) 16:15:03 #info kparal has kindly 'volunteered' to secretarialize 16:15:51 so, uh...sounds plausible? 16:16:09 seems like maybe ARM only? 16:16:17 still, ARM's a primary arch, sooo 16:16:50 +1 of course 16:18:43 pwhalen is +1 on anything with 'arm' in it 16:18:49 votes, ppl 16:19:00 I don't know if it happens always or not 16:19:05 but +1 I guess 16:19:34 +1 blocker 16:19:43 +1 16:20:22 woohoo, everyone wave yer rubber stamp in the air like you just don't care 16:21:07 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 ack 16:21:38 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 ack 16:22:25 ack 16:22:38 #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 #topic (1321393) blivet.errors.DeviceTreeError: no slaves found for device md127 16:22:46 #link https://bugzilla.redhat.com/show_bug.cgi?id=1321393 16:22:46 #info Proposed Blocker, python-blivet, ASSIGNED 16:24:16 oh man, what were we doing with this one 16:24:24 looks like the NEEDINFO query hasn't been satisfied (yet) 16:24:41 oh, right, we had some ideas and none of the reporters responded 16:24:45 welp on that basis i'm fine with a -1 16:25:08 ditto, -1 16:25:11 * kparal is fine with -1 until more info is presented 16:26:38 -1 if we can't reproduce and reporters aren't helping. 16:27:15 -1 until more info 16:28:15 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 ack 16:28:52 ack 16:29:24 ack 16:30:44 ack 16:32:12 * kparal pokes adamw 16:32:16 well that extra hour (and 30 minutes) flew by quickly 16:32:21 sorry 16:32:25 #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 #topic (1327360) qt > 4.8.7-6.fc24 fails to load any plugins (including styles) 16:32:51 #link https://bugzilla.redhat.com/show_bug.cgi?id=1327360 16:32:51 #info Proposed Blocker, qt, MODIFIED 16:33:13 rdieter: this breaks default apps on KDE Live, right? 16:33:19 at least some default apps 16:33:28 kparal: a few, yes 16:33:43 so we can use that criterion 16:33:53 the 'default apps must work' criterion is final, though 16:34:05 for beta there's only a few specific features of the desktop that must work 16:34:09 hmm, right 16:34:43 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 i'm fine with FE for this but at least on current info it's not a blocker 16:35:06 I knew that too, sorry. +1 beta FE 16:35:11 -1 blocker 16:35:55 ok, -1/+1 16:36:05 -1 blocker +1 FE 16:36:07 we can vote +1 Final blocker too i guess 16:36:11 maybe +1 blocker final 16:36:12 not sure if necessary 16:36:33 +1 beta FE , +1 final blocker 16:36:39 +1 final 16:36:41 adamw: naw, I'm confident fixed rebuilds will land relatively quickly, no need for the beaurocracy 16:37:21 Looks like +1 FE +1 final blocker according to criteria 16:39:22 ok' 16:40:30 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 led by default with the KDE spin. It as accepted as a Beta FE for this same reason. 16:40:33 grr 16:40:57 (we can drop the final blocker) 16:41:13 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 ack 16:41:31 ack 16:41:33 ack 16:41:35 ack 16:41:46 ack 16:43:57 #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 alrighty, that's all the Beta blockers 16:44:15 since we're freezing tomorrow, let's do proposed Beta FEs too 16:44:16 sound good? 16:44:23 sure 16:44:35 #info moving on to proposed Beta freeze exceptions 16:44:36 #topic (1323193) FTBFS on secondary arches due liblfds 16:44:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1323193 16:44:36 #info Proposed Freeze Exceptions, 389-ds-base, ON_QA 16:45:56 #c1 seems like a reasonable justification 16:46:02 important bits missing from secondary arch Server images 16:46:08 so, +1 FE for me i guess 16:46:16 +1 FE 16:46:20 +1 FE 16:46:45 sure +1 16:47:49 +1 16:48:21 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 ack 16:48:37 ack 16:48:40 ack 16:48:44 #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 #topic (1315225) firefox build failure on ppc64le/arm64 16:48:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1315225 16:48:55 #info Proposed Freeze Exceptions, firefox, NEW 16:49:02 seems like a similar case 16:49:30 +1 FE 16:49:34 +1 FE 16:49:41 (i mean similar in terms of FE status, not technically similar) 16:49:48 +1 FE 16:49:50 +1 16:50:41 +1 FE 16:51:59 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 ack 16:52:35 ack 16:52:45 ack 16:52:50 ack 16:52:53 #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 #topic (1323511) hibernate action results in a shutdown 16:52:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=1323511 16:52:59 #info Proposed Freeze Exceptions, kernel, NEW 16:53:01 oh, man 16:53:07 just say no 16:53:11 when I see the word 'hibernate' I reach for my revolver 16:53:14 haha 16:53:18 heh 16:53:36 because you have a revolver so handy at all times 16:53:40 Given we are on a stable kernel right now, I don't think a freeze exception would be overly risky. 16:53:59 adamw: why is that? 16:54:10 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 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 kparal: i can't recall a time when it's actually really worked reliably at all. 16:54:38 and has a reasonable justification 16:54:48 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 adamw: you might be surprised to read the one proposed for the final blocker then :) 16:55:25 the installer team doesn't support it so i don't see how we block on it 16:55:28 anyone who claims it worked at any point there is either a) lying or b) lucky 16:55:29 :P 16:55:34 -1 for Beta FE, in any case. and we can discuss the one for Final afterwards 16:55:38 lying and lucky? 16:55:57 -1 FE, there's no admission by any party whose problem this even is 16:56:02 where would the fix go? 16:56:15 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 'fixed' 16:56:51 -1 16:56:53 -1 too 16:56:53 i think hibernation is in the category of experimental surgery, if it works, great, but we're not guaranteeing anything 16:57:09 cmurf: that's always been my take, yeah. 16:58:00 cmurf's experimental surgery vs adamw's revolver 16:58:13 revolver-based experimental surgery 16:58:21 haha now that's funny 16:58:31 that's got me laughing 16:58:46 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 RBES 16:58:56 ack 16:59:01 ack 16:59:09 kparal: the symptoms appear the same, I'd say dup 'em (1323511 and 1206936 ) 16:59:10 ack 16:59:32 I'll put See Also in there and mention it 16:59:35 ack 16:59:41 the original issue is reported against VMs 16:59:52 which is likely to be a different scenario 17:00:19 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 ack 17:01:00 cmurf: imo, let systemd do it 17:01:15 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 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 cmurf: or enforce it via policykit 17:01:58 suspend to ram should work, :-P 17:01:59 so CanHibernate returns false by default 17:02:37 so users would have to opt in via custom policykit or permissions or something to enable it 17:02:50 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 #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 okey dokey 17:03:00 bam! 17:03:02 ack 17:03:13 we already voted on 1327360 , so that's good 17:03:29 alright, we have a couple of final blockers so let's blow through those quickly 17:03:35 #info moving onto Final blockers 17:03:37 super 17:03:38 since we're on the topic already: 17:03:43 #topic (1206936) Laptop does not resume from hibernate, boots instead 17:03:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=1206936 17:03:44 #info Proposed Blocker, systemd, NEW 17:04:10 jhogarth is not here, a pity 17:04:24 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 he pinged me on irc and debugged this 17:04:45 his argument is not about specific hardware issues etc 17:04:55 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 but about this functionality being completely broken on all hardware 17:05:06 the problem is anything that permits hibernation to happen not knowing if it can resume, will result in data loss 17:05:16 so i'm on the side of making sure it can't easily be used 17:05:23 good point 17:05:27 cmurf: not really, you sync data beforehand 17:05:28 cmurf: but the only thing that does it is this 'hybrid suspend' thing 17:05:31 which kicks in when battery is low 17:05:36 so it's like a broken suspend-resume 17:05:42 which happens to me once a week 17:05:42 so if we turn that off, what do we get instead? the system just stays suspended and the battery dies 17:05:44 ...and you lose your data anyway 17:05:53 kparal: should be true 17:06:17 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 unless the 'hybrid suspend' thing kicks in with like 20% battery left or something, i dunno what the cutoff is exactly. 17:06:47 the only thing I know that works, hybrid wise, is Intel Rapid Start, where it's entirely managed by the firmware 17:07:14 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 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 kparal: right 17:07:49 (I think this bug is not just about hybrid suspend, but also about normal hibernation ) 17:08:03 it's actually about it not resuming correctly right? 17:08:16 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 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 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 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 but i dunno any details on that 17:09:06 in the gnome control center, the default action on low battery seems to be suspend 17:09:21 i thought it was poweroff 17:09:43 hmm, off by default, but can be enabled 17:09:50 it's called "suspend & power off" 17:09:51 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 is it hybrid sleep? 17:10:17 yeah maybe 17:10:31 we can ask at #fedora-desktop 17:10:45 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 i'm still inclined -1 on this, but i can live with a punt if necessary. 17:12:39 I'm -1, we have no criterion 17:13:10 hibernation is like the rules of hockey, exceptions everywhere 17:13:24 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 kparal +1 17:14:12 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 adamw: i think the discussion definitely requires developer support backing it up or it's a noop discussion 17:14:51 give me one more minute 17:16:07 also see https://fedoraproject.org/wiki/Common_F24_bugs#Hibernation_doesn.27t_work_from_a_standard_install 17:16:16 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 James Hogarth told me that by doing that quite simple workaround, hibernation starts working for him 17:16:57 so it's really a tiny bug that breaks it completely 17:17:08 You mean resume= as a boot parameter? 17:17:51 yes, it seems so 17:18:18 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 except anaconda devs say it's stupid that they should have to do it, and they have a reasonable point there 17:18:51 but again not really our question. 17:18:59 Right. 17:19:02 our question isn't whether this is a bug or who should fix it, but whether it's a release blocker. 17:19:11 No criterion we have no way to make it a blocker we can't even say whose bug it is. 17:19:24 mclasen says there's a hibernation action somewhere in the UI, but I can't find it 17:19:27 there is a criterion justification attempt in the bug, i just don't buy it. :P 17:19:37 we can punt and I can add more information to it 17:19:43 +1 punt 17:19:44 i guess i can live with that. 17:19:44 kparal: I think we only show it if it has a chance of working, maybe ? 17:20:01 mclasen: ok, I have swap disabled, so I might not see it 17:20:01 mclasen for sure only if it has a GOOD chance of working ;-) 17:20:20 please see http://i.imgur.com/lpF7DX7.png 17:20:25 so yes, it's in the UI 17:20:36 at least on some machines 17:20:51 yeah, we call into logind to see if it thinks we can hibernate 17:21:20 ehh, that's still pretty hidden. i was thinking more 'right there on the power menu'. 17:21:24 aaanyhoo 17:21:46 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 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 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 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 ack 17:22:34 ack 17:22:46 * kparal would not mind a new criterion is he described 17:23:08 ack 17:23:22 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 kparal: well you get a week to propose one =) 17:23:25 ack 17:23:30 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 #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 cmurf: details! 17:23:54 #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 #link https://bugzilla.redhat.com/show_bug.cgi?id=1247797 17:23:54 #info Proposed Blocker, xorg-x11-drv-intel, NEW 17:24:48 I thought this was fixed.... 17:25:35 oh i see 17:25:41 there've been a few similar ones... 17:25:48 i'd probably wanna run this by ajax, i guess. 17:25:51 so it happens with wayland, uncertain if it happens with x 17:26:59 +1 FE, -1 block, contingent on getting an opinion from ajax 17:27:22 cmurf: we don't show power button configuration for tablets or vm's, it appears 17:27:24 40 users in CC 17:27:25 since we're not anywhere near final freeze, might as well punt and ask for info from ajax 17:27:45 be worth checking the dates on the CCs 17:27:51 see if most came in while we were on wayland-by-default 17:28:02 definitely most of those are older kernels 17:28:11 many are 4.2 series 17:28:15 https://bugzilla.redhat.com/show_activity.cgi?id=1247797 17:28:36 seems evenly distributed 17:28:42 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 weren't we wayland by default for 10 minutes? 17:28:50 too bad FAF doesn't respond 17:28:53 ack 17:28:54 i mean in actual composes 17:29:04 ack 17:29:06 ack 17:29:36 i thought it was longer 17:29:39 #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 cmurf: more like 5 months, believe (unless you don't count rawhide) rawhide) 17:29:45 alright, that's all the proposals 17:30:42 \o/ 17:31:22 re 1247797 17:31:28 i'm not seeing any newer kernels tested 17:31:32 it's 4.2 and 4.3 17:31:36 no 4.4 or even 4.5 kernels 17:32:12 #topic Accepted Beta blocker roundup 17:32:16 I'm a little worried on https://bugzilla.redhat.com/show_bug.cgi?id=1259865 17:32:22 mclasen, can you kick that along at all? 17:32:45 I've sent mail about it earlier today 17:33:05 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 mclasen: thanks 17:33:19 #info mclasen has poked #1259865 17:33:29 #info adamw posted needinfo on #1321330 17:33:41 other accepted blockers seem to be in hand 17:33:56 any other notes on accepted beta blockers? 17:33:57 mclasen hughsie is @ lgm today if that's who you poked 17:34:11 lgm=libregraphicsmeeting 17:34:20 I wanted to mention that hughsie was working on making graphical upgrades testable with the beta before the weekend 17:34:31 cmurf: I found only Last Glacial Maximum 17:35:00 haven't seen any results yet, but it shouldn't affect the freeze anyway (change goes in the copr/f23) 17:35:05 kparal: yes well sometimes it does seem like things move at a snails pace but... 17:35:54 mclasen: that would be good. but freeze is tomorrow 17:35:59 is there some bug we should grant an FE? 17:36:05 oh i see 17:36:07 missed your followup 17:36:08 adamw: that's f23 17:36:58 alrighty 17:37:02 #topic Open floor 17:37:05 any other topics? 17:37:13 i don't see any huge looming bear traps for beta 17:37:20 what'd i miss about Fedora Media Writer testing tomorrow? 17:37:26 we have the new-liveusb-creator test day tomorrow, it'd be good for people to come out and help 17:37:29 I NVM i'll just read th elogs 17:38:05 i've got it on my todo baring some other fire 17:38:29 I'm mainly concerned about the lack of Windows test coverage 17:38:45 The Windows tool just appeared a bit over a week ago. 17:39:17 https://mbriza.fedorapeople.org/liveusb-creator.zip 17:39:51 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 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 if this rewrite works out well i'll adjust the docs 17:41:45 yeah this? https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB 17:42:03 Or https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/sect-preparing-boot-media.html 17:42:18 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 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 any time i tried to make it simpler, people kept adding all the other choices back. badly. 17:43:46 adamw: I noticed that. 17:43:56 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 Haha 17:44:35 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 Or encourage the concise version for the official docs which can't be added to by just anyone like the wiki. 17:44:41 for a long time it wouldn't create a stick that booted on UEFI at all 17:44:55 yeah, that too. i haven't checked in on that page for a while 17:44:56 anyhoo 17:45:06 er, non-fedora linux distros, i mean 17:45:11 dd 17:45:27 dd is not friendly but it's bullet proof, even on a mac 17:45:58 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 and there is a dd for windows, just not included by default 17:46:35 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 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 now that we have ubuntu on windows... ;) 17:46:59 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 cmurf: note the SUSE tool is the first one in the instructions. 17:47:11 adamw; yep haven't tried it 17:47:15 let's bundle whole ubuntu stack into FMR and distribute that :P 17:47:36 kparal: 3GiB? 17:48:11 I know 17:48:40 pretty sure using litd causes media check to fail; for sure creating an overlay does. 17:48:43 OH! 17:49:01 BTW, persistent overlay in litd isn't working. Does anyone care? I'll find the bug. 17:49:10 care level: 0 17:49:19 at a guess i'd blame livemedia-creator, though 17:49:22 Is that almost infinite? 17:49:27 no. no it is not. 17:49:30 Haha 17:49:36 I filed a bug against livecd-tools 17:50:02 livemedia-creator is in lorax. 17:50:04 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 okay, anyhow 17:50:20 anything else blocker/f24 beta related? 17:50:25 no 17:51:32 alrighty then, thanks for coming, folks 17:51:38 let's get beta testing done :) 17:52:05 it's done, ship it! 17:53:07 +1 17:53:26 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 #endmeeting