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