16:00:45 <adamw> #startmeeting F24-blocker-review
16:00:45 <zodbot> Meeting started Mon Jun  6 16:00:45 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:45 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:45 <adamw> #meetingname F24-blocker-review
16:00:45 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:45 <adamw> #topic Roll Call
16:00:58 <adamw> ahoy hoy folks, who's around for blocker review funtimes? apart from kparal, i mean, who I just know is raring to go?
16:01:08 * garretraziel is here
16:01:11 * adamw will leave roll call open for a bit while people get coffees etc
16:01:23 * kparal is here
16:02:21 * coremodule is here!
16:03:01 * cmurf got distracted by pushups on the way to coffeemaking
16:03:07 * RaphGro o/
16:03:08 <cmurf> i vote with adamw
16:03:43 <RaphGro> is it too late for a proposal of freeze exception?
16:04:12 <RaphGro> I get again and again nasty e-mails about the b0rken dependency to (gone) nc6
16:04:33 * pwhalen_ is here
16:05:33 * pschindl is here
16:06:36 <adamw> RaphGro: no, you can propose it now
16:06:49 <adamw> #chair kparal  pwhalen
16:06:49 <zodbot> Current chairs: adamw kparal pwhalen
16:07:59 <adamw> #topic Introduction
16:07:59 <adamw> Why are we here?
16:07:59 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:07:59 <adamw> #info We'll be following the process outlined at:
16:08:01 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:02 <adamw> #info The bugs up for review today are available at:
16:08:04 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:05 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:05 * brunowolff will be here for a little while but will need to leave soon.
16:08:07 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:08:09 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:08:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:08:19 <adamw> #info 3 Proposed Blockers
16:08:20 <adamw> #info 4 Accepted Blockers
16:08:20 <adamw> #info 11 Proposed Freeze Exceptions
16:08:20 <adamw> #info 2 Accepted Freeze Exceptions
16:08:25 <adamw> who wants to secretarialize?
16:08:31 <coremodule> adamw, I'll do it.
16:08:57 <adamw> thanks
16:09:04 <adamw> #info coremodule will secretarialize
16:09:06 <coremodule> No problem.
16:09:13 <adamw> okey dokey, obvious place to start: proposed blockers
16:09:24 <adamw> there are in-bug votes for these i think, but i didn't get time to process them over the weekend
16:09:28 <adamw> so hopefully this should be quick
16:09:39 <adamw> #topic (1331926) AVC denied accounts-daemon write access root
16:09:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331926
16:09:39 <adamw> #info Proposed Blocker, accountsservice, ON_QA
16:09:48 <adamw> so...we actually have kinda an interesting situation here
16:09:54 <adamw> two of the proposed blockers are SELinux AVCs
16:10:39 <adamw> from discussion it appears there's a bug preventing sealert from showing notifications for AVCs
16:11:10 <adamw> so it seems as long as that bug exists we'll never trigger the "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop. " criterion
16:11:22 <adamw> but if we were to *fix* that bug, we might suddenly have a lot more blockers...
16:11:53 <adamw> it seems like the easiest thing to do is just intentionally leave sealert broken, i guess.
16:12:24 <adamw> though it seems kinda like a cheat, and means when something is prevented from working by an AVC the user won't know why...
16:13:29 <cmurf> seems like a cheat but the denials appear to be inconsequential
16:13:34 <cmurf> i don't think it's worth slipping
16:13:45 <pschindl> It is a cheat, but 3 days before go/no-go I would leave it that way
16:13:49 <adamw> the ones we know about so far, anyway :P
16:14:09 <adamw> i guess we should just vote on the merits for now, though...
16:14:24 <adamw> so i'm -1 on the basis there's no notification and this violation apparently doesn't break any other criteria
16:14:28 <adamw> er, denial.
16:14:30 <brunowolff> Sort of. The reason for blocking is to not give people confusing alerts. That isn't happening. The logging of the alerts is happening if people want to see them.
16:14:45 <cmurf> exactly
16:14:51 <cmurf> plus this stuff is all fixable with updates
16:15:01 <cmurf> -1 blocker
16:15:18 <coremodule> -1 blocker here.
16:15:21 <brunowolff> -1 blocker
16:15:22 <garretraziel> -1 blocker
16:15:25 <adamw> brunowolff: well yeah, but you have to know about it and run sealert manually.
16:15:27 <pwhalen> -1 blocker as well
16:16:02 <brunowolff> Right, but I don't think that should be a blocker. We can fix it later.
16:16:06 <adamw> proposed #agreed 1331926 - RejectedBlocker - as no notification is shown this does not violate the "There must be no SELinux denial notifications or crash notifications..." criterion, and it does not appear to violate any of the more functional release criteria either
16:16:25 <coremodule> ack
16:16:29 <brunowolff> ack
16:16:34 <kparal> ack
16:16:39 <pwhalen> ack
16:16:46 <garretraziel> ack
16:16:54 <pschindl> ack
16:16:56 <RaphGro> adamw, https://bodhi.fedoraproject.org/updates/FEDORA-2016-a7af5e90d1
16:16:59 <adamw> #agreed 1331926 - RejectedBlocker - as no notification is shown this does not violate the "There must be no SELinux denial notifications or crash notifications..." criterion, and it does not appear to violate any of the more functional release criteria either
16:17:19 <adamw> RaphGro: you have to propose a *bug* for FE status, not an update.
16:17:31 <adamw> #topic (1331382) Anaconda layout indicator does not switch the keyboard layout when clicked when running live
16:17:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331382
16:17:32 <adamw> #info Proposed Blocker, anaconda, NEW
16:17:38 <adamw> so this one is kinda unfortunate
16:17:52 <adamw> it's definitely an annoying bug and a bad experience for live install in an affected language
16:17:57 <adamw> i'm not sure it's quite bad enough to block though
16:18:17 <kparal> contrary to general opinion, I'm convinced this should be +1
16:18:32 <cmurf> interesting
16:18:33 <kparal> it's very problematic for certain languages
16:18:35 <RaphGro> adamw, the bug is missing dependency to nc6 that got retired.
16:19:03 <kparal> btw I cited one criterion in comment 14
16:19:04 <kparal> 15
16:19:11 <adamw> kparal: yeah, i don't buy that one i'm afraid
16:19:25 <cmurf> is there an idea for a fix?
16:19:33 <cmurf> we're talking 1 week or 2 weeks slippage?
16:19:36 <kparal> so, what do you do, when you can't create an user, because you have a russian keymap
16:19:42 <adamw> kparal: you do it on first boot
16:19:48 <adamw> the criterion says "during installation and/or first boot of the installed system"
16:19:59 <kparal> I read that that both must work
16:20:08 <adamw> nope, that's exactly the opposite.
16:20:14 <adamw> "and/or" specifically means "one or the other".
16:20:18 <adamw> "or both"
16:20:36 <cmurf> might be better to just say or
16:20:44 <adamw> meh
16:20:47 <cmurf> ha
16:20:48 <kparal> I read that as "it doesn't have to exist in both places, but at least at one of them"
16:20:50 <adamw> not technically
16:20:55 <kparal> but if it exists, it has to work
16:21:00 <kparal> it's Final, damn it
16:21:09 <cmurf> it's a compelling argument that "if it exists" it should work
16:21:16 <adamw> kparal: i don't read it that way (and I wrote it :>)
16:21:21 <cmurf> we apply that metric often in manual storage setups
16:21:30 <adamw> because that's what we wrote down
16:21:34 <adamw> it's not what we wrote down here
16:21:42 <adamw> we just said that somehow it must be possible to get a user account created
16:21:54 <adamw> and it is (well, we're assuming it is, if someone finds that i-s doesn't work either that's a different story)
16:22:01 <kparal> I'd be OK with this reasoning for Alpha or Beta
16:22:06 <cmurf> does this problem happen with kde?
16:22:11 <cmurf> or just gnome shell
16:22:15 <adamw> only Workstation
16:22:18 <adamw> so i meant g-i-s there.
16:22:37 <cmurf> ok so there is a work around
16:22:40 <cmurf> we can document it
16:22:41 <adamw> there are several
16:22:54 <cmurf> this is an anaconda bug?
16:22:58 <adamw> we don't know yet.
16:23:04 <adamw> no-one has looked into it in any detail, i did not get time
16:23:55 <cmurf> we need to know the scope of the fix and what delays this translates into
16:24:03 <cmurf> i'd say it's worth blocking a week on
16:24:05 <adamw> well we don't, not really
16:24:07 <adamw> we don't vote that way
16:24:19 <adamw> at least in theory. heh.
16:24:29 <adamw> though in practice it kinda matters. meh
16:25:04 <danofsatx> when is go/nogo?
16:25:09 <cmurf> thursday
16:25:11 <adamw> thusrday.
16:25:18 <cmurf> punt
16:25:24 <adamw> that's really not realistic.
16:25:26 <adamw> punt to when?
16:25:30 <cmurf> tomorrow
16:25:51 <adamw> what are we expecting to find out by tomorrow that's gonna help?>
16:25:57 <cmurf> if anaconda can id and fix this in a week I'd +1 block
16:26:20 <RaphGro> .bug 1343159
16:26:21 <zodbot> RaphGro: Bug 1343159 Missing dependency to nc6 - https://bugzilla.redhat.com/1343159
16:26:28 <RaphGro> sorry for my interruption with that
16:26:40 <cmurf> i'd like to know what languages are affected
16:27:25 <brunowolff> We really shouldn't be deciding on whether or not to block based on how long a fix will take.
16:28:20 <cmurf> it's a borderline blocker so to break that tie in my mind, cost is a factor
16:28:33 <cmurf> scope is a factor also
16:28:52 <adamw> cmurf: so basically you think it's a release blocker so long as it doesn't block the release? :)
16:29:06 <adamw> russian is the most obvious affected language
16:29:08 <kparal> I think I'm outvoted here anyway
16:29:22 <adamw> kparal: is the default for czech a switched layout atm?
16:29:24 <adamw> i always forget
16:29:25 <kparal> adamw: any keymap with non-ascii characters
16:29:31 <adamw> kparal: no, that's not correct
16:29:35 <kparal> I believe it is
16:29:50 <adamw> kparal: only locales for which the default config is multiple switched layouts
16:29:50 <cmurf> adamw: no, it's a release blocker so long as it doesn't block for 3 weeks
16:29:54 <kparal> I can't switch keymaps even with czech
16:30:03 <kparal> or whichever othery keynap
16:30:05 <kparal> keymap
16:30:23 <kparal> so if it's japanese or chinese, I won't be able to create a user
16:30:36 <kparal> or turkish, etc
16:30:41 <adamw> cjk are kinda different
16:30:53 <adamw> since they use input methods, not simple layouts
16:30:57 <kparal> I assume this breaks installation for 90% of users
16:31:01 <adamw> i suspect they would not be affected by this but i haven't verified it yet
16:32:58 * kparal trying greek
16:33:03 <adamw> kparal: greek would be affected, i think.
16:33:19 <adamw> https://github.com/systemd/systemd/blob/master/src/locale/kbd-model-map is a handy reference here (though the actual locale defaults come from langtable these days I think)
16:33:33 <kparal> it is
16:33:38 <adamw> anything which is "foo,us" in the second column is a switched layout
16:33:48 <kparal> I don't think this is related to dual layouts
16:34:01 <kparal> simply anything non-ascii prevents you from creating a user
16:34:10 <kparal> since you can't fill in the field
16:34:40 <adamw> ok, the czech default is not switched
16:34:49 <adamw> kparal: it is related to dual layouts
16:35:09 <kparal> is there a language with which the keymap switcher works?
16:35:11 <adamw> kparal: because all the ones which *aren't* dual can type ASCII characters
16:35:26 <kparal> I see
16:35:26 <adamw> kparal: you only need to switch when there are two layouts to switch between!
16:35:31 <adamw> kparal: e.g. just run the live installer and pick czech
16:35:46 <adamw> you get a single layout, called 'Cestina (Ceske)' except with accents i can't type
16:35:56 <kparal> czech actually gives you two keymaps in anaconda keyboard spoke
16:36:02 <adamw> not here it doesn't
16:36:04 <kparal> but you can type ascii with czech, yes
16:36:07 <adamw> and if you hit the 'a' key (on a US layout) you get an 'a', not some kinda non-ASCII character
16:36:22 <kparal> adamw: just czech should give you two layouts, czech (qwerty) a single one
16:36:30 <adamw> no.,
16:36:39 <adamw> i just picked Czech on the welcome screen.
16:36:49 <adamw> and on the keyboard spoke I have a single layout labelled "Cestina (Ceske)".
16:36:51 <adamw> that's the default.
16:38:10 <kparal> interesting. works as you say
16:38:17 <kparal> maybe there's a different on netinst or something?
16:38:24 <kparal> I quite remember getting two layouts
16:38:34 <kparal> nevermind
16:38:45 <adamw> so can we agree that this bug does not have any impact on any locale for which the default keyboard layout configuration is a single layout?
16:39:00 <adamw> shouldn't be, they use the same data source...but in any case it's not relevant to the bug since the bug only affects workstation live
16:39:43 <kparal> it has limited impact on layouts on keymaps which can output ascii. provided that users know how to do that (might be more complicated with some of them, I imagine)
16:40:27 <adamw> kparal: but...this bug has nothing at all to do with that
16:41:00 <adamw> for any such layout, by default there is no option to switch to US anyway
16:41:16 <adamw> if you pick French, we don't configure X with fr and us and enable the switcher
16:41:19 <adamw> we just configure it with fer
16:41:19 <adamw> fr
16:41:23 <kparal> you're right
16:41:52 <kparal> ok, yes, it affects only dual layout keymaps
16:41:55 <adamw> the only affected cases here are cases where we configure more than one X layout (and i guess cases where the user goes into the keyboard spoke and does that manually).
16:42:01 <kparal> I thought it was broader
16:42:03 <adamw> the biggest one of those is russian, there are others
16:42:27 <kparal> also manual configuration, right
16:42:35 <adamw> so, i guess...on the one had this is kinda limited in impact and there are workarounds. on the other hand, Workstation live is still kinda the premier Fedora deliverable so if you're a Russian person who just wants to try Fedora this kinda sucks.
16:43:22 <kparal> I'd still block on that, but I my strong stance has been shattered
16:43:46 <adamw> i'd kinda like opinions from non-QA people but we don't have many :(
16:44:00 <adamw> i'd be interested in mattdm or nirik or dgilmore or kalev or someone like that
16:44:18 <kparal> garretraziel: pschindl: wakey wakey
16:44:37 <kparal> stop playing witcher 3, all of you
16:44:42 <pschindl> I'm still -1. If at least one way works.
16:44:43 <garretraziel> I don't have an opinion on that
16:45:18 <pwhalen> kparal you had me in your camp, scope is smaller now but the workstation live is as adamw says one of our premier deliverables. its still kinda sad
16:45:19 <pschindl> But yes it is ugly. So I'd propose that for F25 blocker.
16:45:20 <garretraziel> I guess that I'd block also, but since it's workaroundable...
16:46:22 <kparal> hmm, I wonder, what about the root password?
16:46:33 <kparal> since the user is not created, you have to provide root password
16:46:48 <kparal> if you have russian keyboard, you have to fill it in in russian alphabet
16:46:59 <cmurf> i was just going to ask that question
16:47:00 <kparal> there's a big warning that you might not be able to log in
16:47:04 <kparal> will you?
16:48:58 <kparal> at least here in CZ people are quite used to fill in all credentials in ascii
16:49:05 <kparal> because of all the i18n issues
16:49:20 <adamw> non-ASCII passwords are allowed but warned about iirc
16:49:31 <adamw> and non-ASCII layouts usually at least can type numbers (so '111111' will work :>)
16:49:38 <pschindl> Will it be possible to log in as root if I create only root in Server version?
16:49:50 <adamw> server is not affected by this
16:49:59 <adamw> the only affected image is the Workstation live
16:50:00 <pschindl> ah, sorry, Live cds only
16:50:06 <adamw> *workstation* live only
16:50:08 <adamw> KDE live works fine
16:50:50 <kparal> adamw: the problem is that you don't even see what you're typing into the password field (I have a long-standing request for "show password" checkbox"(
16:50:53 <adamw> in any case, GDM does not let you log in as root so it's kinda moot (except for console login)
16:50:56 * kparal testing russian now
16:51:05 <adamw> what will actually happen after install is complete is you'll boot to g-i-s and it'll force you to create a user account
16:51:50 <kparal> does it create the user as admin?
16:52:00 <adamw> iirc yes
16:52:47 * adamw will wait for the outcome of kparal's test...
16:53:00 * kparal generating initrd
16:53:22 <garretraziel> you don't have to do it by hand, anaconda will generate initrd for you
16:53:37 <kparal> garretraziel: I like shuffling bits around
16:53:50 <kparal> I take a large piece of paper, and start writing
16:54:05 <cmurf> adamw thats a good point, the root pw is pointless
16:54:19 <garretraziel> are you doing it hardcore way and writing it by magnetic needle directly to HDD?
16:54:20 * cmurf wishes all that root and user UI stuff in the installer would go away
16:54:45 <kparal> interesting, default keymap is us
16:54:51 <kparal> but that's the other blocker, right?
16:55:10 <adamw> kparal: on boot of the installed system? yes.
16:55:12 <adamw> uh
16:55:13 <adamw> no.
16:55:23 <adamw> it actually should default to the US layout
16:55:24 <kparal> I have an older image
16:55:28 <adamw> that's what russian users want apparently
16:55:30 <kparal> ok
16:55:32 <adamw> but switching to ru should work
16:55:49 <kparal> g-i-s doesn't want to allow my password, and I have no idea what it wants :)
16:55:55 <adamw> i use 'correcthorse'
16:55:59 <adamw> it's happy with that
16:56:07 <adamw> 'weakpassword' works also i think
16:56:23 <kparal> in gdm, the default is ru
16:56:30 <kparal> in g-i-s, it was us
16:56:42 <adamw> i think coremodule mentioned that in another context
16:57:06 <adamw> iirc what users have told us is they always want us as the default, but anyhow, it's kinda off topic here...does switching work at each point?
16:58:02 <kparal> ok, my user was created as admin and everything works
16:58:09 <kparal> I can't log in as root in VT, though
16:58:21 <adamw> kparal: that might be the console layout bug
16:58:22 <kparal> because default keymap is us, and I typed in my pw in anaconda with ru
16:58:29 <kparal> yeah, I guess
16:59:05 <kparal> switching worked in gnome and in gdm
16:59:13 <adamw> kparal: when it's configured correctly, ctrl+shift should switch between inputting cyrillic and latin characters at the console
16:59:40 <kparal> adamw: wow, logged in as root
16:59:42 <adamw> if /etc/vconsole.conf says 'us' (not 'ru') for the keymap then you hit the other bug
16:59:54 <kparal> such magic, didn't know
17:00:06 <adamw> i can bore you about it at great length in #fedora-qa if you like :P{
17:00:10 * cmurf is reading this with fascination
17:00:11 <kparal> vconsole says ru
17:00:21 <adamw> ok, you obviously have a new enough image not to hit the other bug.
17:00:37 <kparal> 20160529.n.0.
17:01:24 <adamw> huh. that's odd. the systemd update only went stable on 20160601. color me confused.
17:01:34 <adamw> aaaaanyhoo
17:01:41 <adamw> let's skate right over that
17:01:54 <adamw> so ultimately if you just power through this bug you *do* get a system that works
17:02:08 <adamw> but i can see affected people getting angry/confused in the installer and giving up, for sure
17:02:21 <adamw> so, yeah....tough call.
17:02:28 <adamw> i'm definitely +1 FE, obv.
17:02:58 <kparal> it's better than I thought, I'm OK if we don't block on this
17:03:00 <pwhalen> yea, -1 blocker, +1 FE
17:03:21 <garretraziel> ok, so I'm -1 blocker and +1 FE
17:03:29 <danofsatx> +1 FE
17:03:38 <coremodule> -1 blocker, +1 freeze
17:04:16 <pschindl> -1 blocker +1 FE
17:05:18 <cmurf> -1 blocker +1 FE
17:06:07 <adamw> ok, seems like a consensus
17:06:12 <adamw> sorry for the long discussion, everyone :/
17:06:21 <cmurf> Nope it's worth it to get it right!
17:06:29 <danofsatx> no worries, I'm job shopping in the browser while y'all argue
17:06:36 <cmurf> utf8 all the way around man...
17:08:00 <adamw> proposed #agreed 1331382 - RejectedBlocker AcceptedFreezeException - this is definitely an unfortunate bug and a bad experience for affected users, but the impact is limited to switched keyboard layouts on the Workstation live image and it does not in fact prevent a working installation or, technically, precisely violate any of the release criteria (as gnome-initial-setup constitutes a working mechanism for creating a user). There are also sever
17:08:00 <adamw> al workarounds which can be documented.
17:08:02 <adamw> grr
17:08:41 <adamw> proposed #agreed 1331382 - RejectedBlocker AcceptedFreezeException - this is an unfortunate bug and a bad experience for affected users, but impact is limited to switched keyboard layouts on Workstation live image and does not prevent a working installation or quite violate any of the release criteria (as gnome-initial-setup constitutes a working mechanism for creating a user). There are also several workarounds which can be documented.
17:09:02 <kparal> ack
17:09:04 <pwhalen> ack
17:09:06 <kparal> please add to commonbugs
17:09:10 <kparal> coremodule: ^^
17:09:10 <danofsatx> pacth
17:09:23 <coremodule> kparal, Roger that!
17:09:28 <coremodule> ack
17:09:39 <garretraziel> ack
17:10:23 <kparal> coremodule: you do that by putting CommonBugs to Keywords, not Whiteboard. because things would be too simple if we used just one field :)
17:10:26 <danofsatx> this is an unfortunate bug and a bad experience for affected users, but impact is limited to switched keyboard layouts on Workstation live image and does not prevent a working installation, or violate any of the release criteria as gnome-initial-setup constitutes a working mechanism for creating a user. There are also several workarounds which can be documented.
17:10:47 <danofsatx> (minor grammar fixes)
17:11:10 <kparal> hey, adamw does not do grammar mistakes
17:11:20 * kparal comparing texts
17:11:24 <coremodule> kparal, Thanks, I'll do it.
17:11:31 <danofsatx> I didn't say there were mistakes, I just provided some tweaks ;)
17:12:04 <adamw> :P for the record the problem with keywords is you have to get the bugzilla admins to add them and we're lazy
17:12:26 <coremodule> Ha, alright, who do I talk to/
17:12:27 <coremodule> ?
17:12:35 <adamw> ah, the eternal mystery...
17:13:00 * adamw goes with a grammar hybrid
17:13:01 <cmurf> adamw is British his English is flawless
17:13:19 <adamw> proposed #agreed 1331382 - RejectedBlocker AcceptedFreezeException - this is an unfortunate bug and a bad experience for affected users, but impact is limited to switched keyboard layouts on Workstation live image and does not prevent a working installation, or quite violate any of the release criteria (as gnome-initial-setup constitutes a working mechanism for creating a user). There are also several workarounds which can be documented.
17:13:22 <adamw> grr
17:13:25 <adamw> #agreed 1331382 - RejectedBlocker AcceptedFreezeException - this is an unfortunate bug and a bad experience for affected users, but impact is limited to switched keyboard layouts on Workstation live image and does not prevent a working installation, or quite violate any of the release criteria (as gnome-initial-setup constitutes a working mechanism for creating a user). There are also several workarounds which can be documented.
17:13:37 <adamw> #topic (1284293) SELinux is preventing systemd-logind from getattr access on the file /dev/shm/lldpad.state
17:13:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1284293
17:13:37 <adamw> #info Proposed Blocker, systemd, POST
17:13:44 <adamw> so this is a nice easy one as it's just like the first one, i think.
17:13:49 <cmurf> yep
17:13:52 <cmurf> -1 blocker
17:14:04 <adamw> -1
17:14:31 <cmurf> i think there's another -1 in the bug?
17:14:47 <adamw> probably!
17:14:50 <kparal> -1
17:14:59 <kparal> doesn't seem to break anything, hopefully
17:15:05 <pwhalen> -1
17:15:11 <cmurf> no it's just noise as far as I can tell
17:15:16 <pschindl> -1
17:15:33 <danofsatx> -1
17:15:56 <coremodule> If we're voting based on the criteria, it seems that Zdenek reported that there is indeed a notification, and the criteria states that there should be no notifications of failures upon boot, so I vote +1 blocker.
17:16:56 <kparal> it's not really clear from comment 29 if it was a popup
17:17:04 <adamw> i think he's lying. :P
17:17:05 <kparal> or if he manually opened setroubleshoot
17:17:20 <adamw> i tested on a couple of bare metal intel machines. no notification.
17:17:51 <kparal> if it affects just selected environments, I think it's further reason to reject it
17:18:02 <kparal> is it related to intel or bare metal?
17:18:05 <adamw> seriously, though - #c29 doesn't actually state there was a notification, to me.
17:18:35 <adamw> kparal: well, i don't know for sure, i just tested on bare metal to make sure, since lldpad is some kinda intel thing
17:19:54 <coremodule> Yeah, when I tested for this, I couldn't get it to fail either. According to C29 though, something appeared after his login to the desktop. Whether it was automatic or user-induced is up for speculation.
17:20:04 <adamw> in #c29, you *could* read 'appears' as 'a notification appears', but you could also read it as 'the AVC appears'.
17:20:15 <adamw> and since no-one else managed to see a notification...
17:20:31 <cmurf> So this bug has been around for a while and I vaguely recall seeing a notification early on like alpha or beta, so maybe sealert was working at some early point and then stopped working?
17:20:56 <cmurf> But it doesn't really matter, it's not alerting now. I ran through this a bunch of times on baremetal and VM and I do not get a notification in the DE for this avc denial.
17:21:33 <garretraziel> then I'm -1 blocker
17:21:40 <adamw> cmurf: yeah, that seems to be the case. we're not getting alerts because sealert is broken. but so long as we leave sealert broken, we're good. :P
17:22:40 <adamw> proposed #agreed 1284293 - RejectedBlocker - as per 1331926, there appears to be no desktop notification for this and it causes no significant practical consequences, so it does not violate the criteria
17:22:44 <coremodule> adamw, I see what you mean. If a notification appeared, it violates the criteria, but since there have been no more reports of this, can an assumption be made that this was a one-off instance and possibly due to an "unusual configuration"?
17:22:50 <cmurf> Yeah and I would not support blocking or FE for fixing sealert now. Who knows what that'd dig up.
17:23:00 <cmurf> Just fix it with an update...
17:23:15 <adamw> coremodule: what i'm saying is we don't actually even know that he saw a notification. you can read his comment as saying that, but you can also read it as not saying that.
17:23:30 <coremodule> cmurf, Alright, I can get behind the update idea.
17:23:41 <kparal> ack
17:23:49 <coremodule> adamw, Alright, sure. I gotcha.
17:23:51 <coremodule> ack
17:23:59 <garretraziel> ack
17:24:06 <adamw> #agreed 1284293 - RejectedBlocker - as per 1331926, there appears to be no desktop notification for this and it causes no significant practical consequences, so it does not violate the criteria
17:24:39 <adamw> ok
17:24:52 <adamw> we do not really have anything interesting on the accepted blockers, just my job to chase down pjones today and get a status report
17:24:55 <adamw> so let's move onto proposed FEs
17:25:12 <adamw> in the interest of time/keeping everyone from dying of boredom, let's start with the ones that are in ON_QA / MODIFIED / POST
17:25:21 <adamw> #info moving onto proposed FEs with a fix available
17:25:32 <adamw> #topic (1338010) fedora-bookmarks don't show up in Firefox
17:25:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1338010
17:25:33 <adamw> #info Proposed Freeze Exceptions, firefox, MODIFIED
17:26:51 <kparal> +1 fe
17:26:55 <adamw> +1, affects the live image and it's part of the 'initial experience'
17:27:14 <pwhalen> +1
17:27:35 <adamw> oh. hmm
17:27:52 <adamw> firefox-46.0.1-4.fc24 is current stable, the new build is firefox-47.0-4.fc24
17:27:58 <adamw> so there's more than just this change in it, unfortunately...
17:28:42 <adamw> there have been 7 package builds since 46.0.1-4.fc24, none of which was submitted as an update, so we have no feedback on any of 'em
17:29:04 <kparal> we can test new firefox easily
17:29:19 <kparal> maybe even right now
17:29:50 <adamw> yeah...
17:30:11 <adamw> i guess we can say we accept it but we want some testing on the new firefox before we pull it into a compose
17:30:53 <cmurf> i agree
17:30:55 <adamw> proposed #agreed 1338010 - AcceptedFreezeException - this is accepted in principle as it's important to have Fedora 'branding' stuff in place on lives, but we note the updated Firefox includes several other changes and has not been tested, it should be tested before being included in a compose
17:31:06 <cmurf> ack
17:31:06 <pschindl> ack
17:31:06 * kparal upgrading
17:31:31 <kparal> well it runs and renders getfedora.org
17:31:33 <kparal> ack
17:31:36 <garretraziel> ack
17:31:41 <pwhalen> ack
17:31:44 <coremodule> ack
17:32:26 <adamw> #agreed 1338010 - AcceptedFreezeException - this is accepted in principle as it's important to have Fedora 'branding' stuff in place on lives, but we note the updated Firefox includes several other changes and has not been tested, it should be tested before being included in a compose
17:32:40 <adamw> #topic (1334075) TPM prevents grub menu, drops to grub rescue; BIOS settings no help
17:32:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1334075
17:32:41 <adamw> #info Proposed Freeze Exceptions, grub2, NEW
17:32:48 <adamw> i'm gonna break my own rule and include this one because we know what the change would be
17:33:18 <adamw> this is just kinda to get process approval to drop the TPM changes that were introduced in the F24 cycle along with fixing the Windows dual-boot b ug
17:33:34 <adamw> those don't seem to be fully-baked yet and have caused some boot problems
17:34:28 <cmurf> yep
17:34:36 <cmurf> revert
17:35:23 <kparal> this is only i686?
17:35:45 <adamw> possibly not
17:35:58 <cmurf> there's one report somewhere of x86_64
17:35:59 <kparal> if not, shouldn't it be a blocker?
17:35:59 <adamw> the tpm changes are in place for other arches and certainly *could* affect stuff there
17:36:05 <adamw> well, it's system-specific
17:36:15 <adamw> so it'd be a conditional call
17:37:45 <kparal> I don't see how much hardware is affected
17:37:48 <kparal> +1 FE for sure
17:38:22 <adamw> i'd probably say -1 blocker if we were voting simply because we haven't had any other reports of x86_64 breakage i can think of. but +1 FE.
17:38:37 <garretraziel> +1 FE
17:39:10 <pwhalen> +1 FE
17:39:32 <pschindl> +1 fe
17:39:56 <adamw> proposed #agreed 1334075 - AcceptedFreezeException - breaking boot is obviously Bad(tm) so we approve fixing this bug or dropping the TPM patchset as part of the freeze-breaking grub2 update
17:40:47 <coremodule> ack
17:41:18 <pschindl> ack
17:41:31 <kparal> ack
17:41:31 <pwhalen> ack
17:41:35 <garretraziel> ack
17:41:43 <adamw> #agreed 1334075 - AcceptedFreezeException - breaking boot is obviously Bad(tm) so we approve fixing this bug or dropping the TPM patchset as part of the freeze-breaking grub2 update
17:41:49 <adamw> #topic (1307278) IQmol: FTBFS in rawhide
17:41:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1307278
17:41:49 <adamw> #info Proposed Freeze Exceptions, IQmol, ON_QA
17:42:18 <adamw> we get a few of these each cycle, people trying to make the frozen repos as clean as possible
17:42:23 <adamw> so seems fine to me, +1
17:42:32 <kparal> +1
17:42:37 <pschindl> +1
17:43:05 <pwhalen> +1
17:44:32 <adamw> proposed #agreed 1307278 - AcceptedFreezeException - fixing broken deps in the frozen repos is a good and noble pursuit and we see no danger of breakage from this
17:44:49 <kparal> ack
17:44:53 <garretraziel> ack
17:45:04 <pschindl> ack
17:45:10 <adamw> #agreed 1307278 - AcceptedFreezeException - fixing broken deps in the frozen repos is a good and noble pursuit and we see no danger of breakage from this
17:45:57 <adamw> #topic (1331869) i686 images are about 400MB larger than x86_64 images
17:45:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331869
17:45:58 <adamw> #info Proposed Freeze Exceptions, lorax, POST
17:46:48 <adamw> so we punted on this one last time
17:47:06 <adamw> #c16 and #c17 provide some of the info we asked for
17:48:13 <adamw> so i believe this would need lorax and anaconda changes
17:48:48 <adamw> i think i'm kinda -1y at this point
17:49:03 <adamw> if we'd had all the info last week i could've been +1 and get it done, but not sure it's worth it now just to save a bit of space
17:49:21 <kparal> does it save 40 or 400 MB?
17:49:37 <kparal> it seems 40
17:49:50 * kparal has no real opinion
17:52:22 <garretraziel> hmm, is 40 mbs worth it?
17:52:36 <adamw> i'd say for FEs, a 0 is a -1...:P
17:53:11 <kparal> we can accept it in case of slip
17:53:31 <adamw> true
17:53:37 <adamw> i could get behind that
17:53:54 <pwhalen> seems a bit safer
17:55:13 <adamw> somebody vote, damnit
17:55:59 <pwhalen> -1, +1 if we slip
17:56:06 * kparal that ^^
17:56:48 <coremodule> I'm willing to test it today if we can get a fix out ASAP.
17:57:17 <adamw> not really, too many wheels
17:58:27 <adamw> proposed #agreed 1331869 - AcceptedFreezeException - we'll accept this, but only in the case of a slip; we think it's too tight to make these changes on the current schedule in case anything goes wrong, but if new lorax and anaconda builds with these changes are queued up and we wind up slipping, we can do the first post-slip build with them
17:58:40 <garretraziel> ack
17:58:56 <pschindl> ack
17:59:02 <kparal> ack
17:59:06 <coremodule> ack
17:59:10 <adamw> #agreed 1331869 - AcceptedFreezeException - we'll accept this, but only in the case of a slip; we think it's too tight to make these changes on the current schedule in case anything goes wrong, but if new lorax and anaconda builds with these changes are queued up and we wind up slipping, we can do the first post-slip build with them
17:59:17 <adamw> #topic (1341947) Got an error from DNF about the 'logging' function
17:59:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1341947
17:59:18 <adamw> #info Proposed Freeze Exceptions, lorax, POST
18:00:03 <adamw> eh, i'm fine with throwing this in along with any other lorax changes
18:00:06 <adamw> so +1
18:00:26 <adamw> (since that's effectively what bcl wants, just a sign-off to push it to git so it comes along if we do take a lorax build)
18:00:46 <garretraziel> +1
18:01:00 <kparal> +1
18:01:24 <pschindl> +1
18:01:41 <pwhalen> +1
18:02:51 <adamw> proposed #agreed 1341947 - AcceptedFreezeException - as per 1331869 we're not going to take a lorax build this week unless it fixes something more serious, but we're OK with this if there's a slip
18:02:55 <brunowolff> There was a process issue here that I think could have been handled better. Though at this point waiting is better.
18:03:21 <RaphGro> what's lorax?
18:03:39 <adamw> part of the toolchain that builds images
18:04:22 <brunowolff> The change could have gone in long ago, but the dev wanted to wait for a freeze exception ruling before pushing the change, but we were not in a rush to evaluate freeze exceptions early and it really isn't something we want to change at the very end.
18:04:35 <adamw> yeah, there's a process issue there as we noted earlier
18:04:40 <adamw> (last week or so)
18:06:52 <adamw> ack/nack/patch?
18:07:00 <kparal> ack
18:07:00 <brunowolff> It does mean the i686 Games spin we will probably be oversize. It was just barely undersize a week ago, but got bigger very recently. But it will still work and its i386 which isn't blocking. Someone might have a file system issue downloading it since it will be just over 4GiB.
18:07:02 <garretraziel> ack
18:07:24 <adamw> brunowolff: we're not on that bug any more.
18:07:27 <pwhalen> ack
18:07:28 <pschindl> ack
18:07:34 <adamw> #agreed 1341947 - AcceptedFreezeException - as per 1331869 we're not going to take a lorax build this week unless it fixes something more serious, but we're OK with this if there's a slip
18:07:46 <adamw> #topic (1342289) If livemedia-creator crashes while trying to cleanup anaconda mounts it doesn't copy the anaconda logs
18:07:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1342289
18:07:46 <adamw> #info Proposed Freeze Exceptions, lorax, ON_QA
18:08:15 <kparal> +1
18:08:41 <garretraziel> +1
18:08:50 <adamw> i'm +1 on this (since it's part of trying to fix that goddamn periodic live image creation fail bug)
18:09:21 <adamw> the change seems pretty simple and it could only really go wrong by failing entirely to create the image, it doesn't seem like it could introduce some subtle bug to the created image or anything
18:09:54 <cmurf> +1
18:09:58 <pwhalen> +1
18:11:39 <adamw> proposed #agreed 1342289 - AcceptedFreezeException - this would be useful in debugging #1315541 and we judge the change is unlikely to cause any breakage that isn't immediately obvious (and thus testable)
18:11:43 <brunowolff> ack
18:11:58 <coremodule> ack
18:11:59 <kparal> ack
18:12:09 <pschindl> ack
18:12:11 <adamw> #agreed 1342289 - AcceptedFreezeException - this would be useful in debugging #1315541 and we judge the change is unlikely to cause any breakage that isn't immediately obvious (and thus testable)
18:12:19 <adamw> #topic (1259472) [abrt] plasma-workspace: KCrash::defaultCrashHandler(int)(): kscreenlocker_greet killed by SIGSEGV
18:12:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1259472
18:12:19 <adamw> #info Proposed Freeze Exceptions, plasma-workspace, ON_QA
18:12:38 <adamw> seems like a pretty straightforward +1
18:13:19 <kparal> +1
18:13:19 <pwhalen> +1
18:13:38 <garretraziel> yup, +1
18:14:18 <cmurf> we're in the home stretch
18:14:19 <adamw> proposed #agreed 1259472 - AcceptedFreezeException - fixing crashes that multiple reporters have hit in a release-blocking desktop is obviously worth doing
18:14:31 <coremodule> ack
18:14:32 <brunowolff> ack
18:14:36 <cmurf> ackbar
18:15:07 <adamw> #agreed 1259472 - AcceptedFreezeException - fixing crashes that multiple reporters have hit in a release-blocking desktop is obviously worth doing
18:15:15 <adamw> #topic (1328865) qgis should be rebuilt
18:15:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1328865
18:15:16 <adamw> #info Proposed Freeze Exceptions, qgis, ON_QA
18:15:33 <brunowolff> +1 seems very safe.
18:15:47 <pwhalen> +1
18:15:58 <kparal> +1
18:16:02 <garretraziel> +1
18:16:16 <adamw> more dep fixin'
18:16:34 <adamw> proposed #agreed 1328865 - AcceptedFreezeException - fixing broken deps in the frozen repos is a good and noble pursuit and we see no danger of breakage from this
18:16:46 <coremodule> ack
18:16:55 <pwhalen> ack
18:17:38 <danofsatx> ack
18:17:39 <brunowolff> ack
18:17:44 <kparal> ack
18:17:49 <adamw> #agreed 1328865 - AcceptedFreezeException - fixing broken deps in the frozen repos is a good and noble pursuit and we see no danger of breakage from this
18:17:54 <adamw> #topic (1343159) Missing dependency to nc6
18:17:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1343159
18:17:54 <adamw> #info Proposed Freeze Exceptions, qt-virt-manager, MODIFIED
18:18:14 <adamw> hey, another one
18:18:15 <adamw> +1
18:18:38 <pschindl> +1
18:18:49 <kparal> +1
18:18:51 <pwhalen> +1
18:18:54 <garretraziel> +1
18:19:08 <adamw> #agreed 1343159 - AcceptedFreezeException - fixing broken deps in the frozen repos is a good and noble pursuit and we see no danger of breakage from this
18:19:17 <coremodule> ack
18:19:18 <pwhalen> ack
18:19:53 <brunowolff> ack
18:20:17 <adamw> er whoops, i missed the proposed
18:20:20 <adamw> ah well, we're good . :P
18:20:26 <adamw> ok, last one!
18:20:27 <adamw> #topic (1308203) ugene: FTBFS in rawhide
18:20:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1308203
18:20:27 <adamw> #info Proposed Freeze Exceptions, ugene, ON_QA
18:20:54 <kparal> +1
18:20:56 <brunowolff> +1
18:21:06 <pwhalen> +1
18:21:07 <coremodule> +1
18:21:15 <adamw> proposed #agreed 1308203 - AcceptedFreezeException - fixing broken deps in the frozen repos is a good and noble pursuit and we see no danger of breakage from this
18:21:26 <garretraziel> ack
18:21:28 <kparal> ack
18:21:31 <coremodule> ack
18:21:46 <pwhalen> ack
18:21:49 <pschindl> ack
18:22:17 <adamw> #agreed 1308203 - AcceptedFreezeException - fixing broken deps in the frozen repos is a good and noble pursuit and we see no danger of breakage from this
18:22:21 <adamw> allllllrightyt
18:22:26 <adamw> unless i missed anything, that's the lot
18:23:31 <pwhalen> \o/
18:23:47 <adamw> #topic Open floor
18:23:56 <adamw> any other business before we all hit the bar, er, i mean go and do some tests?
18:24:33 <cmurf> hit the bar
18:24:35 <cmurf> haha
18:24:51 <garretraziel> adam meant "spacebar"
18:24:54 <cmurf> this blocker review almost went that long, happy hour is only 3 hours away
18:25:10 <adamw> every hour is happy hour around here
18:25:38 <garretraziel> (it's like normal bar, but in space)
18:26:07 <RaphGro> thanks for awareness!
18:28:08 <adamw> hmm
18:28:24 <adamw> anaconda folks are reporting a bug with the infobars in the installer...
18:28:26 <adamw> looking into it now
18:30:01 <adamw> hmm, can we do a quick new FE?
18:30:08 <coremodule> Do it!
18:30:48 <adamw> ok
18:30:50 * adamw files bug
18:33:50 <adamw> ok, bug is https://bugzilla.redhat.com/show_bug.cgi?id=1343195
18:34:35 <garretraziel> +1 FE
18:34:39 <coremodule> +1
18:35:20 <kparal> +1
18:35:32 <brunowolff> +1 FE
18:36:12 <adamw> #topic (1343195) 'infobar' (warnings that appear at bottom of screen) text is white, intended to be black
18:36:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1343195
18:36:30 <kparal> +1 FE
18:36:30 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
18:36:35 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
18:37:33 <adamw> #info we have several other +1s from before i changed the topic
18:37:54 <pwhalen> +1
18:37:58 <adamw> proposed #agreed 1343195 - AcceptedFreezeException - this is cosmetic, but it's in the installer and it makes the text kind of a pain to read and the fix should be safe enough
18:38:16 <coremodule> ack
18:38:17 <pwhalen> ack
18:39:01 <brunowolff> ack
18:39:27 <adamw> #agreed 1343195 - AcceptedFreezeException - this is cosmetic, but it's in the installer and it makes the text kind of a pain to read and the fix should be safe enough
18:40:39 <adamw> ok, thanks!
18:40:42 <adamw> returning to:
18:40:44 <adamw> #topic Open floor
18:40:47 <adamw> so i guess that's really it :)
18:40:51 <adamw> thanks for sticking around everyone
18:40:55 * adamw sets fuse
18:42:36 <adamw> #endmeeting