16:02:01 <roshi> #startmeeting F23-blocker-review
16:02:01 <zodbot> Meeting started Mon Jun 22 16:02:01 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:02 <roshi> #meetingname F23-blocker-review
16:02:02 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:02:02 <roshi> #topic Roll Call
16:02:13 <roshi> who's around for some blocker fun?
16:03:14 * Corey84 here
16:03:17 * satellit listening
16:03:23 <kparal> only if you promise it will be fun
16:03:31 <Corey84> been kinda   absent on 23  cycle thp
16:03:44 <Corey84> blocker mtg = fun?  since when
16:03:49 <Corey84> :)
16:03:59 <jkurik> hi roshi; I am here, but mostly for listening
16:04:34 * pwhalen is here
16:04:52 <roshi> I promise it'll meet some definitions of what people could consider to be "fun" under certain specific circumstances
16:05:01 <roshi> that work kparal ?
16:05:12 <kparal> hmmm
16:05:24 <roshi> hey jkurik :) Feel free to join in as well if you like :)
16:05:43 <Corey84> deal
16:06:08 <roshi> #chair kparal Corey84 satellit tflink adamw
16:06:08 <zodbot> Current chairs: Corey84 adamw kparal roshi satellit tflink
16:06:22 <roshi> there you go kparal, chairs are fun!
16:06:38 * kparal 's in
16:06:45 <roshi> #topic Introduction
16:06:45 <roshi> Why are we here?
16:06:45 <roshi> #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:06:49 <roshi> #info We'll be following the process outlined at:
16:06:52 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:52 * adamw back
16:06:55 <roshi> #info The bugs up for review today are available at:
16:06:57 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:00 <roshi> #info The criteria for release blocking bugs can be found at:
16:07:02 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:07:05 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:07:08 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:07:48 <roshi> blockerbugs is taking a long time to laod for me...
16:07:58 <kparal> works here
16:08:05 <Corey84> same  ...2secs tops
16:08:13 <roshi> kk, got it
16:08:24 <roshi> we have 2 proposed blockers and 1 proposed FE
16:08:27 <roshi> first blocker!
16:08:32 <roshi> #topic (1218787) gdm-wayland-session fails to present login screen after successful installation
16:08:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1218787
16:08:37 <roshi> #info Proposed Blocker, gdm, NEW
16:09:00 <adamw> same one we rejected for f22 on the grounds it didn't affect enough hardware to be a blocker..
16:09:22 <Corey84> Southern_Gentlem hgd  some  sucess with  setting  the value to  false  forcing gdm
16:10:28 <kparal> there's comment 51 about seeing this on a thinkpad as well, so probably not just Mac specific
16:10:48 <kparal> the question is whether it is the same bug
16:10:54 <adamw> right
16:11:07 <adamw> i'm sceptical of comments which say 'seeing this' without details that confirm it's actually 'this' they're seeing
16:11:29 <roshi> true
16:11:56 <roshi> we can punt and see if there's a reproducer
16:12:02 <adamw> #c48 gets the 'oh no' screen, which isn't the same bug, most likely. #c46 needs 'nomodeset'. #c45 has two seats connected to different video adapters.
16:12:16 <kparal> otoh, I reproduced the oh no screen on my thinkpad t500 as well. but it this very probably a different issue
16:12:20 <roshi> if bugs could get badges, this one would get one for being punted
16:12:34 <kparal> :)
16:13:44 <roshi> it's +1 being strict with the criteria
16:13:55 <kparal> I think we should ask people seeing "something similar" to report separate bugs with full logs
16:14:04 <roshi> but until we get more hardware to confirm, I'm still leaning -1
16:14:14 <roshi> sgtm kparal
16:14:21 <kparal> as for this particular bug, we still don't see any confirmation it affects more hardware
16:14:51 <kparal> so I'd stay consistent with F22 decision, until somebody can show otherwise
16:15:18 <adamw> roshi: no, it's not. there's a subjective 'breadth of impact' test for hardware-related bugs.
16:15:19 <Corey84> a  guy in  fedora i think had a repro  seeing if he  comes in
16:15:28 <adamw> roshi: we can call it -1 and we're entirely within the criteria, as we did for 22
16:15:45 <roshi> right
16:15:55 <Corey84> -1
16:15:57 <adamw> Corey84: the initial reporter is plenty responsive, having a person who can reproduce the bug doesn't actually help us much atm
16:16:20 <adamw> knowing exactly how many people are seeing this exact bug would help us but is likely impossible :/
16:16:33 <roshi> I meant being strict with just that criteria - -1 is right within the whole of them
16:16:39 <roshi> -1 from me
16:16:45 <adamw> i'd be willing to reconsider this on the grounds that more people are affected than we think, but right now i don't see any solid data indicating that
16:16:46 <Corey84> so its the  slice of the  pie  issue more than anything ?
16:17:15 <SDGathman> How do you know if an issue is related to wayland?
16:17:20 <adamw> Corey84: yeah. so far as *fixing the bug* goes i could do with some input from the devs; for blocker purposes it's kind of a headcount game. having one person who's affected by the bug around doesn't help either much right now
16:17:28 <adamw> SDGathman: disable it and see if the issue goes away :)
16:17:42 <adamw> SDGathman: there's a line in /etc/gdm/custom.conf you can uncomment to disable gdm-on-wayland
16:18:00 <adamw> also if you see the issue with anything other than GDM, it's probably not wayland, because nothing else is configured to use wayland by default.
16:18:04 <SDGathman> I disabled in custom.conf, but gnome-shell still crashes (but not MATE or cunnamon) - so that rules out wayland?
16:18:07 <roshi> proposed #agreed - 1218787 - RejectedBlocker - We still don't see any data indicating this is a wide spread problem. If more hardware profiles can be found to reproduce this bug, please repropose with those datum.
16:18:31 <adamw> SDGathman: yup - both of those things indicate wayland is likely not involved.
16:18:42 <adamw> (the fact that shell crashes and that MATE and cinnamon don't.)
16:18:56 <kparal> roshi: is datum some kind of plural for data?
16:19:02 <adamw> kparal: it's the opposite
16:19:14 <adamw> so, he's wrong :)
16:19:15 <kparal> but "those" indicate plural?
16:19:16 <adamw> patch
16:19:18 <adamw> yeah
16:19:28 <adamw> in Latin, datum is singular, data is plural.
16:19:31 <Corey84> seperate  data sets
16:19:54 <Corey84> h/w profile -  data sets   multiple   profiles multi  data sets
16:20:11 <kparal> maybe include request for people with slightly different problems to report them separately, in the patch
16:20:18 <roshi> proposed #agreed - 1218787 - RejectedBlocker - We still don't see any data indicating this is a wide spread problem. If more hardware profiles can be found to reproduce this bug, please repropose with that data.
16:20:29 <Corey84> +1 agreed
16:20:35 <adamw> ack
16:20:37 <kparal> ack
16:20:49 <roshi> #agreed - 1218787 - RejectedBlocker - We still don't see any data indicating this is a wide spread problem. If more hardware profiles can be found to reproduce this bug, please repropose with that data.
16:20:56 <adamw> kparal: yeah, i guess i'll add another comment with instructions
16:21:01 <kparal> ok
16:21:02 <roshi> who wants to secretarialize?
16:21:03 <kparal> thanks
16:21:55 <kparal> nobody, but I can do it :)
16:22:05 <adamw> OH NO i didn't volunteer in time
16:22:08 <adamw> how terrible
16:22:11 <kparal> :D
16:22:18 <Corey84> lol @ adamw
16:22:21 <roshi> lol
16:22:24 <kparal> adamw: I can still let you do it, adamw
16:22:43 <roshi> where's danofsatx ?
16:22:47 <kparal> if it should broke your heart
16:22:51 <roshi> he's usually willing to fight over it
16:23:10 <kparal> that's ok, let me do it
16:23:21 <roshi> #topic (1220517) Rawhide build of grub2 failing (so #1215839 fix is still not in Rawhide)
16:23:24 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1220517
16:23:26 <roshi> #info Proposed Blocker, grub2, NEW
16:23:29 * danofsatx is here, studying for RHCE, sorry
16:23:29 <roshi> thanks kparal :)
16:23:56 <adamw> so this does still seem to be affecting rawhide, when I got a successful live install last week it had this problem.
16:24:04 <kparal> meetbot links don't work, hmm
16:24:07 <adamw> er, that is, it had the issue described in 1215839.
16:24:39 <satellit> boot.iso still fails this way
16:25:03 <satellit> todays lives fail earlier
16:25:40 <Corey84> seems a  obvious  alpha  criteria  violation as written
16:26:09 <adamw> satellit: current boot.iso failure has nothing to do with this bug, fwiw.
16:26:10 <jkurik> Corey84: +1
16:26:26 <Corey84> adamw,  how not?
16:26:33 <satellit> lives were working in 0619
16:26:35 <adamw> boot.iso failing to boot is https://bugzilla.redhat.com/show_bug.cgi?id=1232411
16:26:41 <Corey84> ah
16:26:51 <Corey84> related bug but not this one
16:26:52 <adamw> which i've marked as acceptedblocker already under the automatic blocker policy
16:27:00 <adamw> not really related, no, that's all to do with dracut
16:27:32 <roshi> +1
16:27:47 <adamw> the problem that won't be fixed until we get grub2 rebuilt for f23 is that after a live install, the grub.cfg kernel entry doesn't have an initrd16 lines and so the system probably won't boot
16:28:24 <roshi> proposed #agreed - 1220517 - AcceptedBlocker - This bug is a clear violation of the Alpha criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
16:29:10 <jkurik> ack
16:29:28 <adamw> ack
16:29:37 <roshi> #agreed - 1220517 - AcceptedBlocker - This bug is a clear violation of the Alpha criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
16:29:38 <danofsatx> ack
16:29:47 <Corey84> ack
16:29:53 <satellit> ack
16:30:01 <roshi> #topic (1222413) It takes a long time for shell to show up on tty2 after do"ctrl+alt+F2"
16:30:04 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1222413
16:30:06 <roshi> #info Proposed Freeze Exceptions, anaconda, NEW
16:31:14 <Corey84> totally out of the loop on this one
16:32:07 <adamw> eh, i'm not sure i have a criterion i can cite for Alpha, i guess.
16:32:40 <adamw> still seems like a pretty bad bug, though.
16:32:44 <kparal> even if it broke our tests, we don't have a criterion which would require the tests to be functional
16:32:49 <kparal> unfortunately
16:33:03 <adamw> we kinda do
16:33:23 <kparal> I think this is problematic mainly from automation point of view. I think that regular users are not that affected
16:33:31 <adamw> it's part of that section under the criteria which actually does the work of defining release blocking bugs
16:33:34 <adamw> " Bug hinders execution of required Beta test plans or dramatically reduces test coverage "
16:33:38 <jkurik> Comment #12 describes a workaround - so it should not be considered as a Freeze Exception - right ?
16:33:38 <roshi> perhaps "The default system init daemon (e.g. systemd) must be capable of starting, stopping, enabling and disabling correctly-defined services. "
16:33:40 <adamw> though we don't refer to it much
16:33:46 <adamw> roshi: nah, that doesn't fit
16:33:58 <kparal> adamw: ok, good to know
16:34:32 <roshi> well, if systemd isn't starting services when it should be, I thought it'd intersect with that criteria at least a little
16:34:41 <adamw> jkurik: eh, a workaround that requires using a kickstart isn't great
16:34:49 <adamw> but one of the other bugs mentions you can get to a console via tmux commands
16:35:02 <danofsatx> isn't the workaround to, well, wait for it?
16:35:18 <roshi> I guess the "correctly define services" section clears it of that criteria
16:35:36 <adamw> roshi: i guess it's *possible* there's actually a bug in systemd but i was reading it more that there was some kind of issue with how we try to get the shell started
16:35:40 <adamw> yeah
16:35:45 <kparal> you can use alt+tab or ctrl+b 1
16:35:48 <adamw> danofsatx: 'sometimes a long time is never'
16:35:55 <kparal> or 2, I don't know
16:36:00 <danofsatx> oh, ok
16:36:06 <adamw> kparal: right, so if that's available i guess i can't really defend it as a blocker. did we note that in commonbugs?
16:36:17 * danofsatx is slacking in not actualy, you know, like, opening the BZ links and stuph
16:36:19 <Corey84> clt+b ?
16:36:31 <kparal> adamw: I don't see it in commonbugs
16:36:42 <roshi> Corey84: ctrl+b is tmux command
16:36:49 <Corey84> ah
16:36:52 * adamw edits the summary
16:36:54 <roshi> ctrl+b <number of window you want>
16:36:55 <kparal> but it is definitely available
16:36:59 <Corey84> not a  versed in tmux as i thought
16:37:02 <adamw> kparal: k, we should probably add it
16:37:10 <roshi> so, -1 for this, and document in common bugs?
16:37:21 <kparal> I guess so
16:37:22 <adamw> for 22 and 23, yeah
16:37:31 <Corey84> due to lack of knowledge  withholding this one
16:38:37 <roshi> proposed #agreed - 1222413 - RejectedFreezeException - This bug doesn't violate any criteria and there are means around this issue. Please document in F22/F23 Common Bugs pages.
16:38:43 <kparal> ack
16:38:46 <danofsatx> ack
16:38:48 <jkurik> ack
16:39:13 <roshi> #agreed - 1222413 - RejectedFreezeException - This bug doesn't violate any criteria and there are means around this issue. Please document in F22/F23 Common Bugs pages.
16:39:21 <roshi> #topic Open Floor
16:39:32 <roshi> that's all we've got - anybody have anything to add?
16:40:28 <adamw> don't think so, i'm trying to lean on harald to get something done about the busted boot.iso's
16:40:47 <adamw> nightlies aren't getting 'nominated' at present because of a timing issue between my cron script and the nightly generation process, but i'm intentionally not fixing it until the boot.iso's work :)
16:41:09 * satellit hope we get something to test...
16:41:09 <adamw> satellit: did you say lives aren't working now either? what's the bug?
16:41:26 <satellit> stops at linux   on boot
16:41:37 <adamw> oh fun
16:41:44 <adamw> i guess i'll look into that too :)
16:41:53 <satellit> 0619 worked
16:42:00 <adamw> kk, thanks - that should make it easier to track down
16:42:52 <Corey84> fun times
16:42:55 <roshi> anything else?
16:43:33 * roshi sets the fuse...
16:43:37 <roshi> 3...
16:43:50 <Corey84> 2...
16:44:09 <danofsatx> we're done?
16:44:13 * danofsatx looks up
16:44:16 <adamw> danofsatx: yeah, not many blockers at this point in the cycle
16:44:17 <Corey84> danofsatx,  yup
16:44:20 <adamw> danofsatx: cherish it while it lasts :P
16:44:25 <Corey84> ^
16:44:31 <roshi> hehe
16:44:36 <roshi> 2...
16:45:05 <jkurik> we are not done yet, we need to wait for roshi to finish his countdown first
16:45:13 <Corey84> 1....
16:45:21 <roshi> 1...
16:45:23 <roshi> :p
16:45:28 <roshi> thanks for coming folks!
16:45:32 <roshi> see you next week!
16:45:37 <roshi> #endmeeting