16:00:12 <jkurik> #startmeeting F23 Final Go/No-Go meeting
16:00:12 <zodbot> Meeting started Thu Oct 22 16:00:12 2015 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:23 <jkurik> #meetingname F23-Final-Go_No_Go-meeting
16:00:23 <zodbot> The meeting name has been set to 'f23-final-go_no_go-meeting'
16:00:33 <jkurik> #topic Roll Call
16:00:35 <nirik> morning everyone
16:00:40 <puiterwijk> morning
16:00:40 <mattdm> good afternoon
16:00:41 <roshi> morning
16:00:43 <jkurik> Hi there
16:01:11 <Zironid> Hello
16:01:17 <jkurik> so, we already have QE & FESCo representative
16:01:27 <jkurik> anyone from relese-engineering ?
16:01:45 <jkurik> dgilmore: are you here ?
16:01:54 <adamw> ahoy to the oy
16:02:00 <adamw> pfah, roshi doesn't count.
16:02:13 <jkurik> why ?
16:02:17 <adamw> .fire roshi that's why
16:02:17 <zodbot> adamw fires roshi that's why
16:02:25 <roshi> that's right, I calculate, not count
16:03:08 <adamw> nirik can count as releng in a push, i think
16:03:22 * nirik can push updates, does that count? ;)
16:03:25 <dgilmore> i am here
16:03:39 <jkurik> great
16:03:44 <jkurik> so we can start ...
16:04:18 <jkurik> #chair dgilmore nirik roshi adamw stickster mattdm
16:04:18 <zodbot> Current chairs: adamw dgilmore jkurik mattdm nirik roshi stickster
16:04:28 <jkurik> #topic Purpose of this meeting
16:04:35 <jkurik> #info Purpose of this meeting is to see whether or not F23 Final is ready for shipment, according to the release criteria.
16:04:45 <sgallagh> I was planning to be here, but I just had something come up. Sorry about that.
16:04:47 <sgallagh> /me leaves.
16:04:51 <jkurik> #info This is determined in a few ways:
16:04:52 <jkurik> #info No remaining blocker bugs
16:04:54 <jkurik> #info Release candidate compose is available
16:04:55 <jkurik> #info Test matrices for Final are fully completed
16:04:57 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/23/final/buglist
16:04:58 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC2_Installation
16:05:00 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC2_Base
16:05:02 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC2_Desktop
16:05:03 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC2_Server
16:05:05 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC2_Cloud
16:05:29 <jkurik> sgallagh: ok, thanks for letting us know
16:05:37 <jkurik> #topic Current status
16:05:45 <jkurik> #info We have several accepted blockers for the Final and also several proposed blockers for the Final.
16:05:56 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/23/final/buglist
16:06:05 <jkurik> Let's start with Mini-blocker review
16:06:39 <jkurik> roshi: may I ask you please to chair the mini-blocker review ?
16:06:49 <roshi> sure thing
16:06:56 <roshi> #topic Mini-Blocker Review
16:07:03 <roshi> there are 8 proposed
16:07:05 <roshi> first up
16:07:05 <roshi> #topic (1272737) Black screen after logout
16:07:05 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1272737
16:07:06 <roshi> #info Proposed Blocker, cogl, MODIFIED
16:07:18 * linuxmodder late
16:07:25 <adamw> we have several +1s for this in the bug, I'm still +1
16:07:56 <nirik> so, it's not 100% of the time
16:07:59 <nirik> but can hit anyone
16:08:04 <roshi> I'm +1 as well
16:08:04 <adamw> quick summary: sometimes when you log out from GNOME the system hangs at a blank screen (you can ssh in but no local interaction is possible). it's easier to hit in a VM but it certainly *can* happen on bare metal, halfline says it's not possible to reliably guess how common it'll be
16:08:14 <dgilmore> I am +1 also
16:08:28 <nirik> yeah, sadly +1 as well...
16:08:32 <adamw> just for the record, if we take this as a blocker, we should slip.
16:08:33 <jkurik> we have a fix right ? can we make this as a 0day ?
16:08:39 <nirik> adamw: yep. ;(
16:08:55 <dgilmore> jkurik: live media would be affected and not fixed
16:09:00 <adamw> jkurik: we *could*, but i think it's bad enough we should fix as shipped.
16:09:23 <jkurik> ok
16:09:30 <nirik> people shutting down live media or the like would be a nasty bug... "I thought I shutdown"
16:09:38 <adamw> dgilmore: people don't often log out of live images, the case that mostly worries me is between-install-and-update
16:09:52 <adamw> nirik: aiui this will only happen on logout (not shutdown)
16:09:56 <mattdm> (right, what adam just said)
16:09:57 <dgilmore> adamw: sure. but its possible
16:10:01 <adamw> dgilmore: yeah, it is.
16:10:05 <nirik> hum, ok...
16:10:07 <stickster> who's logging out of live media?
16:10:17 <Zironid> I did
16:10:19 <dgilmore> stickster: I have ;)
16:10:38 <nirik> adamw: right, so I guess they would need a reboot too ...
16:10:55 <roshi> proposed #agreed - 1272737 - AcceptedBlocker Final - This bug is a violation of the following Beta criterion: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. [...] Logging out must return the user to the environment from which they logged in, working as expected."
16:10:58 <stickster> seems specious for most.
16:10:58 <nirik> ie, install, update, reboot (possibly hit bug), ok after
16:11:03 * kparal joins
16:11:13 <mattdm> If this happened all the time, I think it'd be clear cut (and we would have caught it sooner)
16:11:19 <adamw> stickster: as i said it's not the case i really care about.
16:11:29 <stickster> *nod
16:11:38 <adamw> but it *is* possible. we do still have live image persistence support lying around somewhere too. maybe it even works!
16:11:55 <nirik> yeah, it's the install, update, logout that people would likely hit it on
16:11:59 <kparal> stickster: anyone who wants to change a language
16:12:04 * adamw will ack that
16:12:09 <mattdm> but with it being sporadic, and I think increasingly a corner case anyway, my opinion is -1 as blocker
16:12:12 <dgilmore> ack
16:12:20 <kparal> ack
16:12:22 <stickster> good point kparal
16:12:33 <roshi> #agreed - 1272737 - AcceptedBlocker Final - This bug is a violation of the following Beta criterion: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. [...] Logging out must return the user to the environment from which they logged in, working as expected."
16:12:36 <nirik> so, there was still discussion? or... I guess we just moved on?
16:12:46 <mattdm> eh, I'm clearly in the minority :)
16:13:05 * nirik was trying to wrap around all the cases, but I think I am still +1
16:13:11 <jkurik> mattdm: I am with you, if it counts ...
16:13:16 <dgilmore> nirik: i missed roshi's proposal until ad	acked it
16:13:21 <roshi> we had the votes, and we've got 7 more to do - all of QA is pretty solid on this being a blocker
16:13:31 <roshi> afaict
16:13:37 <mattdm> Yeah, and I'm solid on it being a QA call, so, there's that. :)
16:13:43 <nirik> alright
16:13:46 <roshi> :D
16:13:53 <roshi> #topic (1273390) upgrade progress is not shown in Fedora 21
16:13:54 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273390
16:13:54 <roshi> #info Proposed Blocker, dnf-plugin-system-upgrade, MODIFIED
16:15:31 <adamw> side note: anyone here have a real 32-bit system?
16:15:44 * roshi does
16:15:56 <adamw> -1 on this
16:15:58 <nirik> so, this is just a fix in f21 packages we need before release?
16:16:04 <roshi> a couple, though, I'd have to put a PSU back in it...
16:16:10 <kparal> this does not affect compose process, correct
16:16:10 <adamw> the fact that we don't block on two-release upgrades is intentional
16:16:19 <nirik> yeah, -1
16:16:22 * tflink also has a 32 bit system he can test with
16:16:29 <Zironid> -y here
16:16:30 <roshi> yeah -1, but +1 FE
16:16:34 <Zironid> * -1
16:16:58 <adamw> tflink: roshi: can you grab a 32-bit Workstation image and boot it, see if you hit https://bugzilla.redhat.com/show_bug.cgi?id=1274403 ?
16:17:00 <jkurik> -1 ; if F21 -> F22 -> F23 works
16:17:01 <kparal> I don't think it's a good idea to not block on it and still not even print a warning about it
16:17:10 <adamw> I don't think FE is relevant
16:17:14 <adamw> this would be an F21 update
16:17:35 <Zironid> adamw: agree
16:18:14 <tflink> adamw: downloading and moving cables around
16:18:16 <nirik> yeah, this is really outside the scope...
16:18:29 <roshi> oh right
16:18:34 <roshi> nvm then
16:18:36 * nirik has a hard stop in 40min or less, just FYI
16:18:41 <adamw> we really need a better process for 'special' blockers. damned if i know what it'd be though.
16:19:19 <roshi> looks like plenty of -1
16:19:54 <dgilmore> with the fix for these
16:20:03 <roshi> proposed #agreed - 1273390 - RejectedBlocker Final - This bug doesn't violate any criteria and can be fixed with an update to F21 packages.
16:20:11 <jkurik> ack
16:20:30 * kparal mutters he'll need to try to propose a new criterion
16:20:42 <dgilmore> gahh
16:20:52 <roshi> kparal: I'll second it :p
16:21:08 <Zironid> ack
16:21:13 <adamw> kparal: go for it ;) things have changed a lot since we wrote the upgrade criteria, but you'd need to get whoever will maintain dnf-plugin-system-upgrade to sign off on supporting N-1.
16:21:26 <roshi> any other acks?
16:21:42 <kparal> supporting or clearly stating that N+2 upgrade is risky and unsupported
16:21:51 <kparal> that would be the purpose of the criterion
16:21:52 <roshi> I'm not sure how to parse dgilmore's response...
16:21:55 <dgilmore> was going to say with the fix for these bugs being in the older releases its a bit hard to block the release on them. but we need to ensure that we common bugs it and document that you have to have a fully updated system to do the upgrade, and ensure that the updates are stable before we ship f23
16:22:17 <kparal> s/unsupported/officially unsupported/
16:22:21 <dgilmore> roshi: don't try
16:22:37 <adamw> dgilmore: yeah, like i said, better process.
16:22:40 <adamw> ack
16:22:42 <roshi> #agreed - 1273390 - RejectedBlocker Final - This bug doesn't violate any criteria and can be fixed with an update to F21 packages.
16:22:58 <dgilmore> ack
16:23:02 <kalev> ack
16:23:11 <roshi> lol, now the gahh makes sense
16:23:12 <roshi> #topic (1273112) First attempt to log out fails
16:23:12 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273112
16:23:12 <roshi> #info Proposed Blocker, gdm, NEW
16:24:23 <dgilmore> Its a pretty shitty first impression
16:24:28 <dgilmore> so i am +1 to blocker
16:24:43 <Zironid> +1 too
16:24:51 <kparal> I'm more inclined to -1
16:24:58 <kparal> happens only once and has no severe consequences
16:25:02 <kparal> iiuic
16:25:20 <roshi> it's only in g-i-s, and it doesn't take long enough for the user to think they've been logged out, does it?
16:25:37 <roshi> "in g-i-s" meaning from a first login after creating the user there
16:26:05 <dgilmore> i am +1 FE if people are leaning more that way also
16:26:06 <kalev> I think it's less severe than the black screen bug where the whole machine basically just becomes unusable
16:26:26 <Zironid> Thats true
16:26:37 <kalev> in this case, it's just the first logout that fails and after that trying to log out again succeeds, right?
16:26:41 <adamw> yes
16:26:45 * roshi wishes he had metrics of how many people create users in which place
16:26:54 <kalev> definitely bad impression, but not totally breaking the user experience
16:26:55 <adamw> my call on this would be -1 blocker +1 FE, it's a one-time thing and it's easy to document
16:26:56 <dgilmore> yes but it is shitty and may confuse people
16:26:59 * roshi only uses g-i-s for testing
16:27:07 <adamw> but yeah, it's bad polish
16:27:15 <nirik> -1 blocker, +1 FE
16:27:24 <roshi> -1 blocker, +1 FE
16:27:26 <kparal> -1/+1
16:27:27 <Zironid> Changed my mind, -1 blocker
16:27:30 <nirik> but yeah, since we are slipping... perhaps it's worth waiting for
16:27:34 <jkurik> -1 blocker, +1 FE
16:27:57 <kalev> -1 blocker, +1 FE -- but can we make it a special FE, so that if we get a fix by monday, we'd roll a new image even if there's no known blockers to roll an image for?
16:28:07 <danofsatx> I'd vote +1 FE if I were at this meeting ;)
16:28:09 <nirik> thats not generally how it works. ;)
16:28:24 <Zironid> kalev: that sounds like a good idea
16:28:25 <roshi> proposed #agreed - 1273112 - RejectedBlocker AcceptedFreezeException Final - This bug is really pretty minor, so not considered blocking. However, it's not nearly the level of polish that we'd like to see, so granted FE to get a fix tested and in.
16:28:27 <dgilmore> has to be a blocker to repin
16:28:34 <dgilmore> ack
16:28:36 <nirik> ack
16:28:40 <kalev> ack
16:28:42 <Zironid> ack
16:28:48 <jkurik> ack
16:28:49 <roshi> #agreed - 1273112 - RejectedBlocker AcceptedFreezeException Final - This bug is really pretty minor, so not considered blocking. However, it's not nearly the level of polish that we'd like to see, so granted FE to get a fix tested and in.
16:28:57 <roshi> #topic (1273102) Gnutls Servers (eg: cockpit) fail fallback with Google Chrome 46
16:29:00 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273102
16:29:02 <roshi> #info Proposed Blocker, gnutls, MODIFIED
16:29:03 <dgilmore> kalev: we could respin for it, t it means repining everything.
16:29:07 <dgilmore> but it
16:29:11 * kalev nods.
16:29:21 * nirik is still -1 blocker, +1 FE on this. Since we have a fix in hand, we could take it tho.
16:30:05 <dgilmore> -1  blocker +1 FE
16:31:09 <roshi> I fluctuate with this one
16:31:15 <roshi> for sure +1 FE though
16:31:48 <adamw> definitely +1 FE
16:32:00 <adamw> i'm not really slam-dunk -1 blocker on this, it's pretty bad.
16:32:05 <kalev> definitely +1 FE here as well, not sure about blocker status
16:32:24 <jkurik> -1 for blocker
16:32:50 <adamw> i know cockpit sounds like 'eh, whatever' stuff, but the *idea* is that it should be a really major feature of Server
16:33:25 <dgilmore> adamw: but we can not control 3rd party software
16:33:30 <adamw> sure i guess most of us are SUPER L33T NERDS who do all our admin with ssh because we're so cool, but providing a GUI interface is kind of a major feature for Server, and it's a bad look if it's broken on the world's most popular browser
16:33:36 <adamw> dgilmore: the bug isn't in the third party software.
16:33:47 <adamw> dgilmore: the bug is in gnutls. Chrome is doing nothing wrong.
16:34:10 <nirik> does it matter that much? we already pulled it into a rc as a FE
16:34:16 <dgilmore> but it works with the software we ship
16:34:29 <dgilmore> but then I guess we do not know that will always be the case
16:34:30 <adamw> nirik: did we? i thought it wasn't in rC2
16:34:31 * adamw checks
16:34:32 <roshi> I really lean +1 blocker on this, I think
16:34:47 <adamw> nirik: it kinda sets a precedent for the future too
16:34:50 <nirik> I thought it was. but I was/am away...
16:34:50 <kalev> yeah, let's not discuss it to death, we have a fix that works and let's just take it as a FE
16:34:52 <dgilmore> and a freshly installed system may be unmanagable down the road
16:35:12 <adamw> dgilmore: i think 'the software we ship' is just irrelevant here.
16:35:21 <roshi> like it or not, chrome is out there and popular (much as I'd rather it be something else), it not working is going to hurt the Server WG's efforts
16:35:28 <dgilmore> RC1 and RC2 had the same packages
16:35:33 <adamw> nirik: oh yeah you're right, it's in RC2.
16:35:35 <dgilmore> RC1 broke during compose
16:35:50 <roshi> which I think we should at least consider the definition of "working" for the purposes of something like cockpit
16:36:11 <nirik> IMHO, lets take it as a FE now and ask the server working group what they want to do for these kinds of things down the road?
16:36:22 * adamw puts on his server WG hat
16:36:25 <kalev> yes, good plan
16:36:25 <adamw> we want to block on it. ;)
16:36:41 <adamw> seriously, the fact sgallagh proposed it as a blocker should be a clue.
16:36:58 <roshi> that works for me, provided the discussion happens
16:36:59 <dgilmore> it is moot if iwe had it in RC2
16:37:06 <mattdm> lol
16:37:11 <nirik> ok, fine.
16:37:14 <dgilmore> so lets move on and discuss how to handle these bugs later
16:37:17 <adamw> anyway, i don't want to push too hard, just establish that cockpit is a big deal for server and make sure no-one uses this as a precedent to ignore stuff related to it in future.
16:37:22 <roshi> I could easily see a cockpit criteria that said it had to work with browsers, x, y and z
16:37:37 <dgilmore> adamw: I do not disagree its a big deal
16:37:59 <dgilmore> roshi: sure.
16:38:11 <kalev> I totally agree that cockpit is a big deal and worth making sure it works well. just in this case, we already pulled in a fix and it's not worth splitting the hair if it's a FE or blocker :)
16:38:12 <dgilmore> roshi: and I waould agree with that criteria
16:38:17 <dgilmore> but we do not have it now
16:38:32 <dgilmore> kalev: indeed
16:38:35 <adamw> dgilmore: the current criterion doesn't restrict it to browsers that are in fedora either.
16:38:41 <roshi> proposed #agreed - 1273102 - RejectedBlocker AcceptedFreezeException Final - This but presents some interesting blocker questions that need to be discussed at a later point. However, it's not considered blocking at this point in time, but getting the fix in would be great - accepted as an FE.
16:38:45 <adamw> dgilmore: that would make no sense: the *point* of a web UI is it's OS-independent.
16:38:48 <dgilmore> ack
16:38:54 <adamw> dgilmore: cockpit certainly isn't intended to only work from Fedora systems.
16:38:58 <kalev> ack
16:39:05 <dgilmore> adamw: I realise
16:39:09 <adamw> reluctant ack for the purpose of moving along, i think this is a bad call.
16:39:16 <roshi> proposed #agreed - 1273102 - RejectedBlocker AcceptedFreezeException Final - This bug presents some interesting blocker questions that need to be discussed at a later point. However, it's not considered blocking at this point in time, but getting the fix in would be great - accepted as an FE.
16:39:21 <dgilmore> adamw: I think we are getting into a discussion that needs to happen elsewhere
16:39:21 <roshi> s/but/bug/
16:39:29 <roshi> #agreed - 1273102 - RejectedBlocker AcceptedFreezeException Final - This bug presents some interesting blocker questions that need to be discussed at a later point. However, it's not considered blocking at this point in time, but getting the fix in would be great - accepted as an FE.
16:39:30 <jkurik> ack
16:39:43 <adamw> dgilmore: i don't see why there's a discussion. the criterion says cockpit has to work. this bug is clearly a case where it isn't working for a large chunk of users.
16:39:56 <adamw> the fact that said users might be using a browser fedora doesn't happen to ship seems irrelevant.
16:39:57 <roshi> perhaps the largest chunk, at that
16:39:58 <adamw> anyhow, moving on
16:40:06 <roshi> next up: #topic (1200901) invisible mouse cursor in wayland login-screen when in VM (qxl makes cursor disappear as soon as drmModeSetCrtc is called)
16:40:09 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1200901
16:40:09 <adamw> s/might be/are/
16:40:11 <roshi> #info Proposed Blocker, kernel, VERIFIED
16:40:14 <roshi> #topic (1200901) invisible mouse cursor in wayland login-screen when in VM (qxl makes cursor disappear as soon as drmModeSetCrtc is called)
16:40:38 <dgilmore> +1 blocker  though I do wonder how many people it would effect
16:41:13 * kparal already voted -1/+1 in the bug
16:41:19 <jkurik> -1 blocker, +1 FE
16:41:20 <dgilmore> we had a similiar bug on arm a few releases ago
16:42:16 <Zironid> -1 blocker
16:42:23 <Zironid> +1 FE
16:42:35 <nirik> -1/+1 here.
16:42:49 <adamw> dgilmore: it affects anyone who logs out in a KVM, pretty much.
16:43:05 <adamw> +1 FE at least, probably -1 blocker, it's annoying but not really that bad
16:43:12 <adamw> keyboard navigation is pretty obvious
16:43:28 <kparal> adamw: have you found out why your VM was not affected?
16:43:47 <adamw> kparal: i dunno why i wasn't hitting it on tuesday, but I started hitting it reliably yesterday
16:44:01 <roshi> proposed #agreed - 1200901 - RejectedBlocker AcceptedFreezeException Final - While this bug is annoying, it doesn't actually make the VM unusable. We'd gladly consider a fix during freeze for this though.
16:44:03 <dgilmore> https://bugzilla.redhat.com/show_bug.cgi?id=1205725
16:44:09 <adamw> ack
16:44:10 <kalev> ack
16:44:13 <dgilmore> its kinda like ^
16:44:14 <kparal> ack
16:44:15 <jkurik> ack
16:44:17 <Zironid> ack
16:44:18 <dgilmore> ack
16:44:22 <nirik> ack
16:44:29 <roshi> #agreed - 1200901 - RejectedBlocker AcceptedFreezeException Final - While this bug is annoying, it doesn't actually make the VM unusable. We'd gladly consider a fix during freeze for this though.
16:44:40 <roshi> #topic (1274193) mcelog AMD Processor family 21: Please load edac_mce_amd module
16:44:44 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1274193
16:44:46 <roshi> #info Proposed Blocker, mcelog, NEW
16:46:03 <nirik> hum, not much detail here.
16:46:08 <kparal> it seems we're not loading required module
16:46:19 <roshi> I do like though, proposing a blocker just to vote against it :p
16:46:20 <kparal> "Please use the edac_mce_amd module instead."
16:46:36 <adamw> -1 blocker, as the service criterion is essentially polish
16:46:40 <nirik> -1 blocker
16:46:45 <adamw> since this doesn't really cause any major problem i can see
16:46:45 <kalev> -1 blocker
16:46:55 <Zironid> -1 blocker
16:47:01 <dgilmore> -1
16:47:10 <kparal> -1
16:47:12 <adamw> would want more details before going +1 FE too
16:47:14 <dgilmore> +1 FE though
16:47:23 <jkurik> -1 blocker to vote against roshi
16:47:30 <adamw> eh, i'd want to at least get an idea what might have to change
16:47:32 <kalev> I'd like to see the fix before voting on FE
16:47:34 <kalev> yup
16:47:51 <dgilmore> either we would take a fix if its available or not
16:48:05 <dgilmore> if we think the fix is too invasive we do not have to take it
16:48:14 <roshi> proposed #agreed - 1274193 - RejectedBlocker Final - This bug only seems to affect a single processor family and isn't considered blocking. If a fix becomes available, please post so we can determine FE status.
16:48:22 <dgilmore> there is nothing that says we have to take a FE
16:48:28 <roshi> right
16:48:32 <kparal> I think this might pop up an abrt notification every time you boot. but maybe that's a different issue. I just remember Petr noted something like that.
16:48:36 <adamw> dgilmore: if you take that too far, though, we might as well grant *Everything* an FE
16:48:40 <roshi> who's voting against me for what?
16:48:53 <adamw> as this is a pretty minor issue i'd at least want some kind of idea of what we might be fixing before giving it a +1
16:49:08 <roshi> ack/nack/patch?
16:49:10 <kalev> ack
16:49:11 <kparal> ack
16:49:13 <dgilmore> ack
16:49:17 <jkurik> ack
16:49:18 <Zironid> ack
16:49:19 <roshi> #agreed - 1274193 - RejectedBlocker Final - This bug only seems to affect a single processor family and isn't considered blocking. If a fix becomes available, please post so we can determine FE status.
16:49:19 <adamw> kparal: just looking at the logs i'd be surprised if that were the case
16:49:20 <adamw> ack
16:49:34 <kparal> adamw: ok, so it was probably a different bug
16:49:34 <roshi> #topic (1274309) KDE isn't starting, showing only cursor on 32bit virtualized CPU (qemu32)
16:49:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1274309
16:49:40 <roshi> #info Proposed Blocker, plasma-workspace, NEW
16:49:42 <adamw> kparal: it sure doesn't look like anything crashes, it all seems to close down in good order...
16:49:59 <adamw> unless anyone can reproduce this on a real 32-bit system i'm -1
16:50:05 <adamw> qemu32 is kinda artificial
16:50:17 <adamw> (we hit these in openQA testing, if anyone's wondering how we found 'em in the first place)
16:50:21 <kalev> did FESCo decide that 32 bit issues are blocking for F23?
16:50:29 <kparal> I have some more info to this bug
16:50:33 <kparal> last minute testing
16:51:09 <roshi> fwiw, I saw the oops in my 32bit vm testing on workstation - but the same image dd'd do a usb key booted and installed fine on bare metal
16:51:12 <kalev> from what I get, virtualization is one area where people really want 32 bit guests because they take less RAM
16:51:26 <adamw> kalev: we've rejected 32-bit virt stuff before IIRC
16:51:29 <kalev> okay
16:51:38 <kparal> I tested Workstation Live on that Pentium4 machine and it booted OK 3 times out of 3. however, I also tested KDE Live and it booted 1 time out of 3, other times Login Service failed to start, but I wasn't able to collect any logs.
16:51:56 <adamw> kparal: that's bad, but it doesn't sound like *this* bug?
16:51:57 <kparal> also, if you use kvm32 instead of qemu32 in virt-manager, all the images boot fine
16:52:04 * roshi hadn't tested the kde image
16:52:22 <kparal> adamw: no, I'm just saying we tested 32bit bare metal and this qemu32 issues are not present
16:52:32 <kparal> so we can give -1 to this
16:52:35 <kalev> ahh, sorry, I didn't see the kvm32 vs qemu32 distinction. if kvm works, I think that's most important
16:52:44 <roshi> I'd be fine with common bugs for this - it's an easy change for VMs and bare metal seems to work (me will test kde here after the meeting)
16:52:57 <adamw> kalev: right, you can run the 32-bit image with a 64-bit CPU model and it works fine
16:52:59 <jkurik> does not sound like something we should block on, I am -1 for blocker
16:53:09 <adamw> hmm, can someone test with 'nomodeset'?
16:53:15 <adamw> for the record there's a similar case for GNOME:
16:53:19 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1274403
16:53:29 <adamw> which *looks* like it's in llvmpipe
16:53:30 * nirik has to run, but since we have unfixed blockers, it's nogo IMHO.
16:53:35 <kparal> adamw: nomodeset doesn't help with qemu32, iirc
16:53:36 <adamw> so i wonder if the reproducer is 'llvmpipe on 32-bit'
16:53:48 <adamw> kparal: i meant, see if the bug happens on real hardware if you use nomodeset, to force llvmpipe
16:53:54 <kparal> ah
16:53:54 <adamw> nirik: thansk!
16:54:00 * kparal can't test that now
16:54:13 <dgilmore> nirik: indeed. enjoy the time off
16:54:30 <kalev> the shell javascript errors seem to be all harmless, it's the llvm "Do not know how to split the result of this operator!" that's making it all fail I think
16:54:34 <adamw> i'm way off into theoretical-land here, but i guess it's *possible* we could have an issue for 32-bit systems with non-supported graphics adapters
16:54:40 <adamw> kalev: yeah, that's my bet.
16:55:00 <adamw> and I think Plasma has some GL stuff OOTB, so it may be the same issue. (though imbw.)
16:55:06 <kparal> so who has some 32bit machine?
16:55:09 <adamw> roshi does
16:55:16 <dgilmore> adamw: is it x86 only?
16:55:22 <dgilmore> I can test on 32 bit arm
16:55:24 <adamw> he's checking the workstation case now, dunno if he has a KDE image
16:55:26 * roshi is writing a usb stick right now
16:55:31 <adamw> dgilmore: i'd imagine they'd be different
16:55:34 <roshi> to test nomodeset
16:55:45 <dgilmore> adamw: okay
16:56:02 <roshi> downloading the kde image
16:56:06 <dgilmore> I got rid of my last 32 bit x86 box when I moved
16:56:27 <adamw> yeah, i haven't had one for a while
16:56:32 <Zironid> I have acces to a 32 bit pc
16:56:50 <roshi> 20% written
16:57:03 <roshi> do we want to wait while I start this thing?
16:57:46 <adamw> how long's it gonna take?
16:57:53 <kalev> we can maybe move ahead and wrap up the go/no-go meeting and have a small FE review at the end, and then look over your 32 bit testing results as well?
16:57:55 * adamw is at least moderately interested in getting the result
16:58:46 <jkurik> I would prefer to postpone the testing and move on
16:58:55 <roshi> it's half written
16:59:11 <roshi> so, another 3 minutes or so to finish writing, then enough time for it to boot
16:59:19 <roshi> so ~5 minutes
16:59:20 <kparal> let's move to the next one, then get back
16:59:23 <dgilmore> roshi: so 5-10 mins
16:59:36 <roshi> we can move on
16:59:39 <tflink> booting with nomodeset now
16:59:49 <adamw> yeah, let's move on
16:59:51 <roshi> #topic (1273247) Mouse cursor lost completely upon log out (sddm / KDE)
16:59:54 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273247
16:59:57 <roshi> #info Proposed Blocker, xorg-x11-drv-qxl, NEW
17:00:18 <kalev> the other cursor bug was -1/+1, so I'd imagine this one would be too
17:00:32 <dgilmore> kalev: thats my vote
17:00:43 <adamw> yeah, i think this one isn't so reproducible but as the effect is basically the same, i vote the same.
17:00:55 <kparal> I think only roshi reproduced this one. I couldn't
17:01:04 <kparal> -1/+1
17:01:09 <kalev> -1/+1
17:01:28 <roshi> that's a relief then :p
17:02:08 <jkurik> -1/+1
17:02:28 <adamw> -1/+1
17:02:33 <Zironid> -1/+1
17:02:39 <roshi> proposed #agreed - 1273247 - RejectedBlocker AcceptedFreezeException Final - This bug hasn't been reproducible for anyone but the reporter, so is not considered blocking. We'd consider a fix if one shows up before we cut another RC though.
17:02:45 <adamw> ack
17:02:49 <jkurik> ack
17:02:56 <dgilmore> ack
17:02:58 <kparal> ack
17:02:59 <Zironid> ack
17:03:01 <roshi> #agreed - 1273247 - RejectedBlocker AcceptedFreezeException Final - This bug hasn't been reproducible for anyone but the reporter, so is not considered blocking. We'd consider a fix if one shows up before we cut another RC though.
17:03:08 <roshi> ok, that was the last one
17:03:22 <roshi> tflink: did you machine boot with nomodeset for the previous bug?
17:03:28 <tflink> yep
17:03:44 <roshi> #topic (1274309) KDE isn't starting, showing only cursor on 32bit virtualized CPU (qemu32)
17:03:47 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1274309
17:03:48 <tflink> flashed some odd colors during plymouth but otherwise booted fine
17:03:49 <roshi> #info Proposed Blocker, plasma-workspace, NEW
17:03:52 <roshi> so, back to this one
17:04:07 <roshi> mines 99% written
17:04:13 <adamw> are you writing KDE or GNOME?
17:04:17 <roshi> yay for PV being able to show dd progress!
17:04:19 <adamw> tflink tried the GNOME case
17:04:20 * tflink hasn't tried KDE, though
17:04:26 <roshi> gnome - downloading kde now
17:04:28 <adamw> k
17:04:31 <roshi> didn't have the 32 bit of that
17:04:39 <adamw> I'm definitely -1 if we can't reproduce it on real hardware
17:04:53 <Zironid> adamw: agree
17:04:55 <adamw> if we could reproduce on real hardware with 'nomodeset'...ehhh, it's a tougher call, but maybe still -1.
17:05:01 <dgilmore> I am with adamw here
17:05:18 <adamw> kparal: definitely investigate the other problem, though...
17:05:22 <roshi> plymouth is working
17:06:13 <adamw> well, yeah, we haven't reached the point of 3d-accelerating plymouth yet. :P
17:06:22 <adamw> (f24 feature!)
17:06:29 <roshi> lol
17:06:33 <jkurik> :)
17:06:37 <Zironid> lol
17:07:21 <pwhalen> fwiw kde is working ok on arm
17:07:52 <roshi> booted fine for me
17:07:55 <roshi> writing KDE now
17:08:03 <roshi> I think we can probably vote on this
17:08:20 <jkurik> -1 for blocker
17:08:26 <kparal> -1
17:08:33 <Zironid> -1 blocker
17:09:09 <adamw> yeah, -1 for now
17:09:18 <adamw> we can always re-vote if we find some plausible real world scenario
17:09:25 <adamw> pwhalen: thanks
17:09:54 <roshi> proposed #agreed - 1274309 - RejectedBlocker Final - We weren't able to reproduce this on bare metal, so it's not considered blocking.
17:10:00 <jkurik> ack
17:10:01 <kparal> ack
17:10:05 <kalev> ack
17:10:09 <Zironid> ack
17:10:10 <roshi> #agreed - 1274309 - RejectedBlocker Final - We weren't able to reproduce this on bare metal, so it's not considered blocking.
17:10:37 <roshi> that's all the proposed blockers
17:10:45 <adamw> woohoo?
17:10:58 * roshi will still test the kde nomodeset though
17:11:16 <kalev> can we go through FE's as well? not right now, but after go/no-go decision?
17:11:23 <roshi> sure - we can
17:11:30 <kalev> thanks
17:11:33 <roshi> do an out of sync review
17:11:45 <roshi> jkurik: back to you
17:11:58 <jkurik> roshi: ok, thanks
17:12:06 <jkurik> #topic Test Matrices coverage
17:12:19 <adamw> maybe make it a meeting in fedora-blocker-review after the go/no-go (FEs)
17:12:26 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC2_Summary
17:12:28 <roshi> yeah, that was my thought
17:12:32 <adamw> so, since we were already expecting to slip yesterday, we didn't kill ourselves with RC2 testing
17:12:38 <adamw> thus the coverage isn't near complete yet.
17:12:39 <roshi> I'll ping in fedora-qa after the meeting
17:12:59 <jkurik> there will be Readiness meeting after Go/No-go
17:13:09 <adamw> we can multitask :P
17:13:13 <roshi> I did do some broad strokes testing last night - things were looking good (meaning I didn't find any new blockers)
17:13:14 <jkurik> great :)
17:13:40 <jkurik> shall we go through Test Matrices, even we will probably slip ?
17:13:48 <adamw> nah, there's no point
17:13:58 <adamw> we're locked into slipping now, with unfixed blockers in rc2
17:14:03 <adamw> just say it's not complete and move on
17:14:12 <adamw> we can do more detailed status update in readiness meeting
17:15:00 <jkurik> #info skipping the Test Matrices coverage as we already have blocking issues
17:15:10 <jkurik> #topic Go/No-Go decision
17:15:15 <jkurik> so, here we go ...
17:15:48 <jkurik> due to blockers, the slip is necessary IMO
17:15:54 <roshi> yup
17:15:59 <dgilmore> releng is no go
17:16:22 <adamw> per our policy, QA is no go (unaddressed blockers in RC2, and incomplete test coverage)
17:16:59 <jkurik> proposed #agreed Due to present blockers in the RC2 build, the decision is No-Go
17:17:18 <roshi> ack
17:18:06 <jkurik> one week slip should be ok, imo, so we will have go/no-go once more in one week
17:18:45 <adamw> yeah, from QA's perspective it'd be good to get a solid week's testing in on an RC.
17:19:12 <jkurik> proposed #agreed Due to present blockers in the RC2 build, the decision is No-Go. The release slips for one week. Second Go/No-Go meeting to be planned for the next Thursday.
17:19:32 <jkurik> ack/nack/patch ?
17:19:35 <adamw> ack
17:19:35 <kalev> ack
17:19:37 <roshi> ack
17:19:45 <Zironid> ack
17:20:42 <jkurik> dgilmore: is rel-eng ack as well ?
17:21:22 <dgilmore> ack
17:21:27 <dgilmore> sorry in another meeting also
17:21:30 <jkurik> #agreed Due to present blockers in the RC2 build, the decision is No-Go. The release slips for one week. Second Go/No-Go meeting to be planned for the next Thursday.
17:21:42 <jkurik> #topic Open floor
17:21:44 <mattdm> Ah well. :)
17:21:48 <mattdm> Thanks everyone!
17:22:10 <jkurik> anything else to discuss today ?
17:22:58 * roshi has nothing
17:23:00 <dgilmore> nada
17:23:03 <adamw> can't think of anything
17:23:05 <adamw> thanks jkurik!
17:23:23 <jkurik> #action jkurik to publish the Go/No-Go result
17:23:42 <jkurik> ok, so then thanks to everyone
17:23:53 <jkurik> #endmeeting