16:04:59 <adamw> #startmeeting F25-blocker-review 16:04:59 <zodbot> Meeting started Mon Sep 26 16:04:59 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:04:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:04:59 <zodbot> The meeting name has been set to 'f25-blocker-review' 16:04:59 <adamw> #meetingname F25-blocker-review 16:04:59 <zodbot> The meeting name has been set to 'f25-blocker-review' 16:04:59 <adamw> #topic Roll Call 16:05:03 <Southern_Gentlem> np but had to pick on you 16:05:08 <adamw> who's around for some blocker review fun? 16:05:15 <Southern_Gentlem> .hello jbwillia 16:05:16 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@yahoo.com> 16:05:22 * satellit listening 16:05:23 * coremodule is here! 16:05:30 * kparal is here 16:05:34 * tenk is here 16:05:40 <coremodule> And glad to act as secretary if needed! 16:05:46 <kparal> pschindl will arrive a bit later 16:06:29 <adamw> #info coremodule will secretarialize 16:06:32 <adamw> thanks coremodule 16:06:35 <adamw> #chair coremodule kparal 16:06:35 <zodbot> Current chairs: adamw coremodule kparal 16:06:43 <coremodule> adamw, No problemo! 16:08:13 * adamw will leave registration open for a couple of minutes for people to take a break after qa meeting 16:09:48 * cmurf monitoring while steeping 16:10:22 <adamw> also, call of nature 16:10:23 <adamw> :P 16:10:24 * adamw brb 16:15:00 <adamw> #topic Introduction 16:15:00 <adamw> Why are we here? 16:15:01 <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:15:01 <adamw> #info We'll be following the process outlined at: 16:15:02 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:15:02 <adamw> #info The bugs up for review today are available at: 16:15:04 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 16:15:06 <adamw> #info The criteria for release blocking bugs can be found at: 16:15:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria 16:15:10 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria 16:15:12 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria 16:16:39 <adamw> for Beta, we have: 16:16:42 <adamw> #info 1 Proposed Blockers 16:16:43 <adamw> #info 4 Accepted Blockers 16:16:47 <adamw> #info 2 Accepted Freeze Exceptions 16:16:53 <adamw> also for Final: 16:17:03 <adamw> #info 6 Proposed Blockers (Final) 16:17:15 <adamw> so let's move along to the proposed Beta blocker... 16:17:23 <adamw> #topic (1378162) blivet.errors.DeviceFormatError: device path does not exist or is not writable 16:17:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1378162 16:17:23 <adamw> #info Proposed Blocker, python-blivet, POST 16:18:21 <cmurf> seems straightforward 16:18:45 <cmurf> +1 blocker 16:18:47 <adamw> well, i'm not totally sure of the scenario that triggers it, but it at least seems fairly reproducible - i also hit it one time incidentally while i was doing a live install to test something else 16:19:29 <Southern_Gentlem> +1 16:19:39 <tenk> https://bugzilla.redhat.com/show_bug.cgi?id=1374973 lloks like the one i have few week ago 16:19:41 <tenk> +1 16:19:46 <adamw> oh, hmm, except wait a second 16:19:55 <adamw> maybe i should've proposed this for F26 not F25 16:20:05 <adamw> let me check if it's actually happening on 25... 16:20:21 <tenk> yes rawhide for me 16:20:51 * satellit do we test from DVD vs USB anymore? (liveinst) 16:21:41 <adamw> hmm, yeah, this seems to be rawhide only 16:21:44 <adamw> my bad! sorry folks 16:21:53 <Southern_Gentlem> _1 16:21:56 <Southern_Gentlem> -1 16:22:00 <adamw> #info this bug is affecting Rawhide, not F25, proposal for F25 was incorrect; will adjust the bug 16:22:12 <coremodule> I can do that. 16:22:16 <coremodule> ^^ 16:22:33 <adamw> i did it 16:22:36 <adamw> since it was my mistake :) 16:22:46 <tenk> -1 F25 Beta +1 F26 Alpha 16:22:48 <coremodule> Alright, cool. 16:23:12 <adamw> so that was easy 16:23:32 <adamw> hmm, since we're getting near to Beta doomsday, should we check through the Beta accepted blockers before moving onto Final proposed? 16:24:40 <coremodule> Probably a good idea... 16:24:59 <tenk> ok for me (probably going to sleep after beta review (already 1:24 am) 16:25:25 <adamw> tenk: thanks for sticking around! sorry for the unfortunate hours :( 16:25:25 * satellit does li-t-d test have to be run in f25? on a f25 .iso 16:25:50 <adamw> satellit: no, actually it's as interesting or more interesting to get results for burning a 25 ISO from 23 or 24 16:25:55 <adamw> since that's going to be a more common real-world use case 16:26:01 <satellit> k 16:26:10 <adamw> #info moving onto accepted Beta blockers 16:26:26 <adamw> so here we're not voting +1/-1, we're looking at the issues to make sure they're being worked on, and deciding what to do if not 16:26:31 <adamw> topic (1369786) Autopart fails on installation from live usb created by l-i-t-d 16:26:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1369786 16:26:31 <adamw> #info Accepted Blocker, anaconda, NEW 16:27:01 <adamw> seems like nothing much is happening here 16:27:21 <cmurf> might be the wrong component? 16:27:23 <cmurf> blivet? 16:27:43 <cmurf> i looked at this and all the confusion is happening in blivet 16:27:44 <adamw> anaconda should be OK...even if it's actually blivet, anaconda devs should at least take care of that 16:28:20 <adamw> it would be nice to get a completely clean set of logs with a recent 25 image though, i guess 16:28:23 <adamw> could you do that, cmurf? 16:28:34 <cmurf> yeah 16:28:46 <cmurf> 20160924? 16:28:48 <adamw> yeah 16:28:55 <adamw> #action cmurf to get clean logs for https://bugzilla.redhat.com/show_bug.cgi?id=1369786 16:29:10 <adamw> coremodule: could you post a poke asking the anaconda devs for status on the bug? 16:29:33 <coremodule> adamw, Sure! 16:29:37 <adamw> thanks 16:29:47 <adamw> oh fer pete's sake 16:29:54 <adamw> same damn copy/paste error as last week 16:29:56 <adamw> #undo 16:29:56 <zodbot> Removing item from minutes: ACTION by adamw at 16:28:55 : cmurf to get clean logs for https://bugzilla.redhat.com/show_bug.cgi?id=1369786 16:30:00 <adamw> #undo 16:30:00 <zodbot> Removing item from minutes: INFO by adamw at 16:26:31 : Accepted Blocker, anaconda, NEW 16:30:03 * pschindl is here 16:30:05 <adamw> #undo 16:30:05 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x3795b890> 16:30:11 <adamw> #topic (1369786) Autopart fails on installation from live usb created by l-i-t-d 16:30:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1369786 16:30:11 <adamw> #info Accepted Blocker, anaconda, NEW 16:30:20 <adamw> #action cmurf to get clean logs for https://bugzilla.redhat.com/show_bug.cgi?id=1369786 16:30:26 <adamw> alrighty, there we go 16:30:31 <adamw> #topic (1374810) initial-setup fails - TypeError: unhashable type: 'list' 16:30:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374810 16:30:32 <adamw> #info Accepted Blocker, anaconda, ON_QA 16:30:39 <adamw> so, ON_QA is always a good sign 16:31:15 <adamw> there's also a new initial-setup build: http://koji.fedoraproject.org/koji/buildinfo?buildID=803053 16:31:51 <adamw> https://bodhi.fedoraproject.org/updates/FEDORA-2016-66457e9af1 16:31:55 <adamw> and pwhalen says it works on ARM 16:32:25 <adamw> #info anaconda update and initial-setup update are pending stable, we're expecting this to be resolved when they go stable 16:33:04 <adamw> #topic (1374864) initial-setup is not completable when there's no network link 16:33:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374864 16:33:04 <adamw> #info Accepted Blocker, initial-setup, NEW 16:34:16 <adamw> so i'm not totally sure, but it sounds like this one isn't fixed yet... 16:34:21 <mkolman> when was this last tried ? 16:34:37 <adamw> it sounds like they've been having trouble testing because of the previous bug (1374810) causing it to crash 16:34:48 <adamw> so we should probably ask for a re-test with the new anaconda and i-s to find out where we are 16:35:06 <adamw> coremodule, could you add a comment to that effect, asking peter and dennis to re-test? 16:35:18 <coremodule> adamw, Sure thing, on it now. 16:35:36 <mkolman> I have this on my TODO list 16:35:48 <mkolman> but I'm just getting started setup for it 16:35:52 <adamw> ok, cool 16:36:11 <mkolman> eq. updated a test VM & will try if I can reproduce it if I remove the network adapters from the 16:36:12 * satellit in testing of f25 Plasma live I see a 4-5 min wait if only wifi is available on liveinst 16:36:14 <mkolman> *from it 16:36:18 <adamw> #info we will ask pbrobinson and dgilmore to re-test this with the newest anaconda and initial-setup to see what the current status is, mkolman will take it from there 16:36:40 <adamw> satellit: 4-5 min wait for anaconda to start up? or for the image to boot? 16:36:57 <satellit> to get past first timbuktu screen 16:37:19 <adamw> satellit: hmm, ok, that's not great...did you file a bug? i kinda remember having a bug report about that already? 16:37:29 <satellit> no bug yet 16:37:42 <satellit> time out? 16:37:59 <mkolman> in any case the network spoke should not be required in Initial Setup 16:38:06 <satellit> k 16:38:13 <mkolman> at least unless there is something else that is required and needs network 16:38:22 <mkolman> and I don't think we have anything like this 16:38:23 <adamw> satellit: probably something's waiting for a timeout of some sorts, yeah. if you can file a bug that'd be great. 16:38:37 <satellit> will test...: ) 16:38:47 <adamw> mkolman: sure - as I read the bug the issue is that *all* of i-s doesn't work without a network, but we can just wait for the testing and see where we are 16:38:54 <adamw> so, moving on... 16:38:54 <adamw> #topic (1225184) anaconda does not detect RAID devices 16:38:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1225184 16:38:55 <adamw> #info Accepted Blocker, python-blivet, ASSIGNED 16:39:06 * satellit afk bye 16:39:14 <mkolman> really ? 16:39:39 <mkolman> I read it as "you can't finish IS if the network spoke is not done" 16:40:26 <mkolman> "initial-setup can not be completed as the network spoke is not complete" 16:41:12 <cmurf> this is the WTF RAID bug 16:41:29 <adamw> mkolman: yeah, i think you're right. 16:41:33 <adamw> yeah, this bug is awful 16:41:43 <adamw> do you have any idea where we are with it, cmurf? 16:41:46 * adamw 's eyes are glazing over 16:41:54 <cmurf> i know, almost 100 comments 16:42:04 <cmurf> no idea, it's still reproducible 16:42:23 <mkolman> 100+ comments on a Fedora bug 16:42:23 <adamw> cmurf: it seems like there's at least a clear cut case you and dlehman were discussing, and then it got left off with the ball in dlehman's court... 16:42:24 <mkolman> WOW 16:43:46 <cmurf> i think this needs another coremodule poke 16:43:56 <cmurf> and see if there's more info we can provide 16:44:25 <cmurf> s/another/a 16:44:32 <adamw> it seems like what we're basically debugging here is 'RAID sets don't show up in the live installer'... 16:44:38 <cmurf> that's right 16:44:42 <cmurf> bug in the logs, it sees them 16:45:01 <cmurf> they're just not being sorted out within anaconda/blivet logic for whatever reason 16:45:06 <coremodule> I can send something asking for a status report. 16:45:19 <cmurf> s/bug/but 16:46:35 <adamw> so i'm going to ask the two more recent commenters (Paul and Hawzy) who look to be reporting different bugs to file separately 16:46:49 <cmurf> yes good, keep the scope narrow 16:46:55 <adamw> coremodule, can you set a needinfo on dlehman and ask what his understanding of the current status is> 16:46:56 <adamw> ? 16:47:15 <cmurf> it could be that the new lvm raid support is contributing to confusion within the installer 16:47:57 <coremodule> adamw, Gotcha, will do! 16:48:19 <adamw> alright, that's all the accepted blockers 16:48:27 <adamw> #info moving onto proposed Final blockers 16:49:02 <adamw> and just as a reminder - Beta freeze is in effect in a few hours, so if there's a fix you want to get into the Beta and it's not yet proposed as a freeze exception issue or a blocker...propose it! 16:49:13 <adamw> #topic (1375712) [abrt] anaconda: TypeError: __new__() takes 3 positional arguments but 5 were given 16:49:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1375712 16:49:14 <adamw> #info Proposed Blocker, anaconda, ON_QA 16:50:54 <adamw> so this was affecting Rawhide at the time but it was expected to affect F25 too when the affected lorax hit f25 16:51:02 <adamw> there are so many damn iscsi bugs ATM i'm losing track 16:51:23 <cmurf> i guess people still use iscsi... *sigh* 16:51:25 <Southern_Gentlem> and another blivet? 16:51:40 <cmurf> a literal blivet 16:51:56 <Southern_Gentlem> +1 +1 FE 16:52:40 <cmurf> if the problem is still going to hit f25, or has hit it, then +1 16:52:46 <adamw> so the affected lorax is pending stable for F25 atm 16:52:51 <adamw> so i'll go +1 on that basis 16:52:52 <cmurf> ok so +1 16:53:03 <adamw> the blivet fix should land soon anyway (that update is also pending stable) 16:53:11 <cmurf> ok good 16:53:50 <adamw> proposed #agreed 1375712 - AcceptedBlocker (Final) - the affected lorax build is currently pending stable for F25, so we're accepting this as a blocker as we expect it will affect F25 with that lorax, and violates "The installer must be able to detect (if possible) and install to supported network-attached storage devices." 16:54:37 <coremodule> ack 16:55:02 <tenk> ack 16:55:07 <Southern_Gentlem> ack 16:55:27 <adamw> #agreed 1375712 - AcceptedBlocker (Final) - the affected lorax build is currently pending stable for F25, so we're accepting this as a blocker as we expect it will affect F25 with that lorax, and violates "The installer must be able to detect (if possible) and install to supported network-attached storage devices." 16:55:30 <adamw> #topic (1378159) iSCSI install crashes with 'The name org.freedesktop.UDisks2 was not provided by any .service files' 16:55:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1378159 16:55:30 <adamw> #info Proposed Blocker, anaconda, NEW 16:55:42 <adamw> so this is the bug F25 iscsi installs are *actually* running into atm 16:55:50 <adamw> pretty straightforward violation i think, +1 16:56:00 <cmurf> i think i've been to shorting wedding ceremonies 16:56:07 <cmurf> oops 16:56:16 <cmurf> this could be due to the storaged feature change 16:56:19 <cmurf> +1 blocker 16:56:48 <Kevin_Kofler> "The name org.freedesktop.UDisks2 was not provided by any .service files" have also been sighted in Plasma by at least one user, there was a post on the kde@l.fp.o ML about it. 16:57:11 <cmurf> right so, storaged may not have that service file 16:57:19 <cmurf> where udisks2 package did 16:57:25 <Southern_Gentlem> +1 16:57:49 <cmurf> but I'm not sure what the solution is, so +1 on anaconda and they can move it to storaged folks if that's the proper fix 16:58:03 <cmurf> the installer still shouldn't crash 16:58:46 <adamw> Kevin_Kofler: i don't think fixing this bug in anaconda is going to fix a similar issue in KDE, basically this is a porting issue for things that used udisks, i think 16:58:52 <adamw> unless storaged decides to be backwards compatible 16:59:11 <cmurf> supposed to be 16:59:12 <adamw> proposed #agreed 1378159 - AcceptedBlocker (Final) - this is a clear violation of "The installer must be able to detect (if possible) and install to supported network-attached storage devices." 16:59:23 <cmurf> ack 16:59:43 <Kevin_Kofler> Storaged is supposed to be a drop-in replacement for UDisks2, at least that's what the feature advertised. 16:59:52 <coremodule> ack 17:00:30 <adamw> i guess we can CC someone from storaged on the bug. 17:00:51 <adamw> ack/nack/patch? (got 2 acks) 17:01:02 <Southern_Gentlem> ack 17:01:52 <adamw> #agreed 1378159 - AcceptedBlocker (Final) - this is a clear violation of "The installer must be able to detect (if possible) and install to supported network-attached storage devices." 17:02:00 * adamw will dig up a storaged folk to poke 17:02:13 <adamw> #topic (1366897) GNOME session doesn't wait for apps to cleanly exit 17:02:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366897 17:02:13 <adamw> #info Proposed Blocker, gnome-session, NEW 17:02:25 <cmurf> this could be a can of worms 17:02:54 <cmurf> i'm -1 17:03:25 <kparal> I tried this quickly and some apps are listed in the logout dialog, like gedit 17:03:27 <cmurf> actually comment 7 has good points 17:03:33 <kparal> some other apps like libreoffice writer are not 17:04:22 <cmurf> i'm still -1 17:04:39 <kparal> where's the data loss criterion? can't find it 17:04:49 <cmurf> data corruption 17:04:50 <adamw> kparal: final 17:04:50 <cmurf> final 17:04:57 <kparal> this one? https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria#Data_corruption 17:05:06 <cmurf> yes 17:05:16 <kparal> it's corruption, not loss 17:05:23 <adamw> it does say 'document or fix', or words to that effect 17:05:33 <cmurf> document it 17:05:42 <adamw> so we could take this as one to be documented 17:05:45 <cmurf> i think corruption = loss 17:06:15 * kparal adding CommonBugs tag 17:06:20 <cmurf> what's corrupt? 17:06:46 <kparal> e.g. your document can't be opened anymore 17:06:52 <cmurf> apps should be writing out their own tmp files for open documents, delete them on clean exit, and recover them on next launch from dirty exit 17:06:55 <adamw> yeah, i'd kinda go with that (we could amend the criterion to state 'loss or corruption' if we want to be clear i guess) 17:07:41 <pschindl> +1 for documenting 17:07:43 <cmurf> the document can't be opened anymore? that's worthy of a separate bug, it's 2016 we shouldn't have corrupt documents behaving that way 17:07:45 <kparal> even though I dislike it, I'd probably go with -1 here. it has never really worked properly, seems to me 17:07:50 <Southern_Gentlem> writer will try to recover the doc when it is next restarted but the user should never assume the doc is autosaved 17:07:57 <kparal> I don't think people rely on that too much 17:08:13 <kparal> bug "crashed" firefox on each startup annoys me as hell, that's true 17:08:45 <cmurf> this is why this bug is a can of worms 17:08:56 <adamw> i could sort of go either way on 'blocker' status, but if the resolution is just going to be to document it anyway, it seems a bit academic 17:09:05 <cmurf> between the DE, systemd session behavior, and apps not closing when informed, *shrug* 17:09:06 <adamw> i mean, we're gonna put it in commonbugs whether we call it a 'blocker' or not 17:09:16 <cmurf> right 17:10:52 <adamw> i guess i'll vote -1 on the basis of mcatanzaro's comment... 17:11:57 <Southern_Gentlem> -1 17:12:39 <cmurf> i think users are now used to apps saving user data automatically, reliably, if desktops can't keep up with that... poof. 17:13:08 <adamw> proposed #agreed 1366897 - RejectedBlocker (Final) - it's a close call on this one, but even if it was accepted as a blocker the resolution would be to document it on Common Bugs, which we're going to do anyway, so the decision isn't super important; we went with -1 17:13:12 <cmurf> ack 17:13:23 <coremodule> ack 17:13:46 <pschindl> ack 17:13:49 <adamw> #agreed 1366897 - RejectedBlocker (Final) - it's a close call on this one, but even if it was accepted as a blocker the resolution would be to document it on Common Bugs, which we're going to do anyway, so the decision isn't super important; we went with -1 17:14:00 <adamw> #topic (1377741) maximized video is shifted in totem after gtk3 update 17:14:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1377741 17:14:00 <adamw> #info Proposed Blocker, gtk3, NEW 17:14:37 <adamw> hmm, interesting call 17:14:56 <adamw> watching a full screen video *is* kind of a basic thing to do in a video player. and a basic desktop function generally speaking. 17:15:17 <cmurf> yes 17:15:20 <cmurf> +1 blocker 17:15:24 <pschindl> +1 17:15:34 <kparal> btw this can be easily fixed with GDK_BACKEND=x11 17:15:42 <kparal> +1 17:17:12 <adamw> proposed #agreed 1377741 - AcceptedBlocker (Final) - watching a fullscreen video is considered to be 'basic functionality' of totem and so violates "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" 17:17:26 <cmurf> ack 17:17:56 <pschindl> ack 17:18:22 <kparal> ack 17:18:31 <adamw> #agreed 1377741 - AcceptedBlocker (Final) - watching a fullscreen video is considered to be 'basic functionality' of totem and so violates "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" 17:18:38 <adamw> #topic (1377616) When the 'Select Live ISO' button is pressed the mediawriter segfaults 17:18:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1377616 17:18:38 <adamw> #info Proposed Blocker, mediawriter, VERIFIED 17:19:04 <cmurf> +1 straightforward 17:19:43 <Southern_Gentlem> yes nice to fix but is it really worth holding up release 17:19:49 <adamw> so this happens if you're on wayland and don't have qgnomeplatform installed? 17:19:55 <cmurf> it wouldn't hold up release 17:20:05 <cmurf> it would just mean mediawriter doesn't become primary downloadable 17:20:12 <cmurf> if it's not fixed 17:20:15 <adamw> cmurf: no, it wouldn't 17:20:16 <cmurf> bug it'll get fixed 17:20:25 <adamw> cmurf: we have requirements for luc/fmw outside of the 'primary deliverable' thing 17:20:34 <adamw> it is one of the 'supported methods' for writing USB media, meaning it can block release 17:20:38 <Southern_Gentlem> cmurf, at this point it we are voting if its a blocker the way i understand 17:20:39 <cmurf> oh hell 17:20:59 <cmurf> well it doesn't matter, it doesn't work and has to work so it's still +1 17:21:17 <adamw> if this was a really hard thing to fix i might be -1 on the basis we could document it and it probably wouldn't break f23/f24 as wayland isn't default there, but since we've got a fix anyway, let's just get on the +1 train... 17:21:19 <kparal> adamw: yes, for your question 17:21:45 <Southern_Gentlem> +1 17:21:51 <kparal> I believe the release should be able to run and write itself, so +1 from me 17:21:55 <pschindl> +1 17:22:06 <kparal> (the same issue with boxes) 17:22:31 <cmurf> how many ways to create fedora install media... 17:22:34 <cmurf> do I have enough fingers? 17:22:37 <kparal> however, I'd be ok with delay to Final, since it only affect the branched release 17:22:49 <kparal> (but it's fixed now anyway) 17:22:54 <adamw> cmurf: we have three 'supported' USB mechanisms, which is two too many, but oh well 17:23:05 <adamw> kparal: this is Final :) 17:23:11 <kparal> right! 17:23:22 <kparal> so I wasn't technically wrong 17:23:37 <adamw> proposed #agreed 1377616 - AcceptedBlocker (Final) - violates "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods" (as LUC/FMW is an 'officially supported method') 17:23:45 <cmurf> ack 17:23:49 <kparal> ack 17:23:56 <coremodule> ack 17:24:05 <adamw> #agreed 1377616 - AcceptedBlocker (Final) - violates "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods" (as LUC/FMW is an 'officially supported method') 17:24:12 <adamw> #topic (1372300) GDM does not use the keyboard layout which is selected 17:24:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1372300 17:24:12 <adamw> #info Proposed Blocker, mutter, NEW 17:24:17 <cmurf> this is a fantastic one 17:24:28 <cmurf> i think we hemmed and hawed for 20 minutes on this last week 17:25:11 <Southern_Gentlem> +1 17:25:14 <adamw> "this bug makes multilingual use of F25 unusable" seems like a rather strong assertion 17:25:17 <adamw> given the actual data in the bug 17:25:24 <adamw> is there additional data not in the bug? 17:25:33 <kparal> nope 17:26:21 <adamw> so long as this only happens if you go and do stuff in the GNOME control center i'd be inclined to -1, though it is a shame 17:26:21 <cmurf> i wonder what i18n folks think of this? 17:26:42 <adamw> i also actually recall i know approximately why this bug happens, but i just can't quite recall the details 17:26:51 <cmurf> haha 17:27:21 <cmurf> i really want to be +1 17:27:25 <cmurf> i think language is basic 17:27:27 <adamw> i actually fiddled around with this exact stuff a few months back and i'd noticed that Shell's layout indicator could get out of sync with X's actual behaviour in certain circumstances, but i just don't quite have all the details to hand 17:27:44 <cmurf> but then no criterion 17:27:58 <cmurf> and no isolated problem with specific solution 17:28:01 <adamw> basically it's if you adjust X's layout order on the fly, Shell doesn't know about it and gets out of sync, I *think* 17:28:19 <cmurf> yeah it's icky 17:28:28 <adamw> e.g. if you boot with layouts 'en,ru' then shell is just *always* going to consider 'layout 0' to be en and 'layout 1' to be ru, so if you change the layout order behind its back it will show them reversed 17:28:43 <adamw> but yeah, i'd have to dig back into it all again, sigh. 17:29:00 <adamw> and of course i've no idea how wayland affects things. lalala. 17:29:07 <adamw> keyboards are hard, film at 11 17:29:10 <cmurf> well it sounds like a problem for i18n folks to stake a stand on, and if release criteria need tweaking 17:29:39 * kparal is tired of this one, doesn't care much 17:29:46 <cmurf> haha 17:29:57 <cmurf> kparal got burned out from it 17:30:14 <mkolman> I've seen something sounding familiar recently on 24 17:30:28 <mkolman> Gnome Shell indicator was set to CS 17:30:47 <adamw> i'm basically only a clear +1 on keyboard layout bugs if it can be described as 'i did a default install for my country and it didn't work right' *or* 'i installed the way everyone from my country always does and it didn't work right' 17:30:48 <mkolman> but Chrome was apparently set to something else 17:30:54 <adamw> because this stuff is too damn fragile for any other case 17:31:14 <kparal> adamw: yeah, I tried to do that and couldn't reproduce the issue 17:31:47 <cmurf> ok so -1 blocker 17:32:12 <adamw> yeah, i'm -1 with current data 17:32:26 <adamw> open to changing my mind if someone has a convincing-sounding argument 17:33:11 <Southern_Gentlem> -1 17:33:29 <pschindl> -1 17:33:44 <cmurf> adamw i think we'd need a 'this is just f'n tragic' criterion... 17:34:01 <adamw> proposed #agreed 1372300 - RejectedBlocker (Final) - as the bug currently stands, this bug doesn't violate any criteria as it does not affect a default or 'typical' install for any language, it is triggered by post-install changes to the locale configuration, which the criteria do not cover 17:34:03 <Southern_Gentlem> cmurf, we would never get a release out 17:34:06 <adamw> cmurf: heh 17:34:10 <adamw> ^^^ 17:34:25 <kparal> ack 17:34:29 <pschindl> ack 17:34:31 <cmurf> ack 17:34:32 <Southern_Gentlem> ack 17:34:45 <adamw> #agreed 1372300 - RejectedBlocker (Final) - as the bug currently stands, this bug doesn't violate any criteria as it does not affect a default or 'typical' install for any language, it is triggered by post-install changes to the locale configuration, which the criteria do not cover 17:34:52 <cmurf> there really aren't that many f'n tragic bugs in Fedora 17:35:06 <adamw> cmurf: southern_gentlem: I didn't show you guys the new Fedora logo, right? https://twitter.com/ntakayama/status/779180488405585920/photo/1 17:35:15 <cmurf> uh oh 17:35:17 <Southern_Gentlem> cmurf, depends on the reporter 17:35:21 * cmurf hesitates to click the link 17:35:37 <adamw> it's okay. there's no rick astley. 17:36:04 <cmurf> roflcopter 17:36:11 <cmurf> my FAVORITE! 17:36:29 <Southern_Gentlem> adamw, but a rickroll would be good to attach to that graphic 17:36:32 <adamw> and with that, we're done with the bug list 17:36:50 * cmurf is still giggling 17:36:59 <adamw> =) 17:37:03 <adamw> jkeating found that one 17:37:13 <adamw> the guy who drew it is an iOS engineer, which made me feel substantially better about life 17:37:18 <Southern_Gentlem> figures he would 17:37:21 <cmurf> he's losing his hat 17:37:25 <cmurf> grin on his face 17:37:27 <adamw> but this is still fine 17:37:31 <cmurf> boat on fire, headed downward 17:37:35 <adamw> you know it's the 'this is fine' dog, right? 17:37:42 <cmurf> yes 17:37:45 <adamw> sooo...any other business? 17:37:53 <cmurf> accepteds? 17:37:56 <adamw> any bugs i missed (or that got proposed in the last hour or so?) 17:38:00 <adamw> cmurf: we did 'em already 17:38:08 <cmurf> not accepted finals 17:38:08 <adamw> no need to do final accepted's really 17:38:13 <cmurf> oook 17:38:53 <adamw> unless you're super keen to or something :P 17:39:04 <cmurf> no no not really 17:39:30 <cmurf> they're pouring cement on the mountain and i'm more curious about that 17:39:47 <Southern_Gentlem> still alot to do before the 6th 17:40:29 <adamw> ....why would you pour cement on a mountain 17:40:30 <Southern_Gentlem> is it me or if we push again it will mean a December release 17:40:33 <adamw> this seems superfluous 17:40:41 <adamw> Southern_Gentlem: didn't even look that far ahead yet. 17:41:59 <Southern_Gentlem> https://fedoraproject.org/wiki/Releases/25/Schedule if we push its thankgiving week so most likely the 29th 17:42:11 <adamw> welp, let's ss shipit then 17:42:19 <adamw> alrighty, thanks for coming everyone 17:43:12 <coremodule> Thanks for hosting adamw. 17:43:20 <coremodule> See ya. 17:43:28 <adamw> ypuyup 17:43:55 <Southern_Gentlem> end so i can send my ad 17:45:45 <adamw> #endmeeting