17:00:57 <adamw> #startmeeting F25-blocker-review
17:00:57 <zodbot> Meeting started Mon Nov 14 17:00:57 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:57 <zodbot> The meeting name has been set to 'f25-blocker-review'
17:00:57 <adamw> #meetingname F25-blocker-review
17:00:57 <zodbot> The meeting name has been set to 'f25-blocker-review'
17:00:57 <adamw> #topic Roll Call
17:01:04 <adamw> ahoyhoy folks, who's around?
17:01:11 * satellit listening
17:01:18 * jkurik is here for approx. one hour
17:01:28 <adamw> admin note: i may not be here the whole time (or may be on cell sometimes), coremodule will take over if i disappear
17:01:35 <adamw> #chair coremodule
17:01:35 <zodbot> Current chairs: adamw coremodule
17:01:46 * coremodule is here.
17:01:50 * kparal is here
17:01:51 <jkurik> .hello jkurik
17:01:51 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:02:14 * pschindl is here
17:02:23 <adamw> #chair kparal pschindl jkurik
17:02:23 <zodbot> Current chairs: adamw coremodule jkurik kparal pschindl
17:03:14 * garretraziel is lurking around
17:05:02 <adamw> for the record, that's really me.
17:05:17 <adamw> #topic Introduction
17:05:17 <adamw> Why are we here?
17:05:17 <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.
17:05:17 <adamw> #info We'll be following the process outlined at:
17:05:19 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:05:19 <adamw> #info The bugs up for review today are available at:
17:05:22 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:05:23 <adamw> #info The criteria for release blocking bugs can be found at:
17:05:25 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
17:05:27 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
17:05:31 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
17:05:37 <adamw> we have:
17:05:38 <adamw> #info 3 Proposed Blockers
17:05:38 <adamw> #info 6 Accepted Blockers
17:05:44 <adamw> #info 4 Proposed Freeze Exceptions
17:05:44 <adamw> #info 15 Accepted Freeze Exceptions
17:06:07 <adamw> coremodule, you ok to secretary?
17:06:17 <coremodule> adamw, Sure, put me down.
17:06:33 <adamw> #info coremodule will secretarialize
17:06:42 <adamw> #topic (1394026) SAS address parsing issue
17:06:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1394026
17:06:42 <adamw> #info Proposed Blocker, anaconda, NEW
17:06:57 <adamw> so in theory this is a blocker, but we've never had the hw to test sas and have always kinda treated that as a running joke
17:07:04 <adamw> turns out, when someone does have the hardware, it's broken! what a surprise
17:07:27 <adamw> since this is a live issue and not a joke any more, i propose we tweak the criterion to cover commonly-used local storage and don't include sas in that list
17:08:33 <tflink> isn't SAS pretty common, though?
17:08:39 <kparal> I'd like to get rid of SAS criterion as well, but it's just a bit inconsistent with Mac decision last week
17:08:46 <adamw> no-one ever fills out the test for it, and this is the first bug i've seen
17:08:55 <tflink> we have the hardware to test it
17:09:10 <adamw> kparal: well, we've adjsuted criteria at the last minute before, and this one *is* kinda different because at *every* go/no-go we say, like 'oh, SAS isn't covered, har har!'
17:09:15 <adamw> we do?
17:09:17 <tflink> I'm 90% certain that we have the hw to test this
17:09:19 <adamw> then why doesn't anyone ever do it?
17:09:38 <kparal> we don't have it in Brno office
17:09:43 <tflink> dell gave 2 servers to make sure that fedora installed well on them
17:10:05 <jkurik> tflink: do you know where these two are located ?
17:10:15 <tflink> PHX2
17:10:23 <adamw> the practical scenario i'm worried about here is, sure we have a fix for the *first* bug the guy ran into
17:10:33 <adamw> if no-one's tested this stuff for years, chances he runs into *another* bug are high
17:11:01 <tflink> I'm more questioning the approach of changing criteria instead of just hand-waving
17:11:17 <adamw> how do we handwave?
17:11:28 <tflink> how can you call SAS not common?
17:11:31 * adamw going mobile, coremodule can you take over boilerplate stuff? i can't do it well on android
17:11:49 <adamw> tflink: see above. we never file test results for it, this is the first time i've seen someone show up in irc / bugzilla with it.
17:11:56 <adamw> in enterprise rhel use, sure? in fedora, apparently not.
17:12:11 <coremodule> adamw, Got it!
17:12:57 <tflink> saying "we don't really support SAS" seems to be at odds with having a server product
17:13:19 <tflink> note that I'm not arguing that we should slip now to fix it
17:13:29 <sgallagh> tflink: You're not wrong, but we also don't have access to hardware against which to test.
17:13:47 <tflink> sgallagh: we have 2 servers in PHX2 that were donated to test with
17:14:15 <sgallagh> tflink: This is news to me
17:14:26 <pschindl> Also users with SAS surely could use updates.img so let's put it to common bugs.
17:14:50 <adamw-mobile> So we have to use out of band to test installs?
17:14:53 <pschindl> And if we have hardware we can try to test updates.
17:15:38 <coremodule> adamw, Are you still +1 blocker on this one?
17:15:49 <tflink> just to repeat myself to make it more clear - I'm not arguing that we slip F25 for this bug - there has been a severe lack of testing and it's not like it was caught early. that being said, we do have some hardware to test this in the future and I'd prefer to see us take advantage of that in the future instead of writing SAS out of the criteria
17:16:47 <kparal> so let's vote on waiving this bug instead of dumping the criteria
17:17:02 <coremodule> tflink, How can we access the hardware so that we can test with it?
17:17:20 <cmurf> I've questioned SAS in the criteria several times, and keep forgetting that it's tested virtually which as it turns out may have been meaningless - kinda weird but I have no idea if this is a one off failure of hardware and thus a conditional case or if it's all baremetal SAS that's busted.
17:17:21 <adamw-mobile> How do we say this isn't a blocker without adjusting the criteria?
17:17:22 <tflink> coremodule: beaker. which explains why it isn't widely used yet
17:17:45 <adamw-mobile> How do we reject this without adjusting criteria?
17:18:12 <cmurf> is it hardware specific or all SAS?
17:18:18 <coremodule> tflink, Gotcha...
17:18:39 <cmurf> If it's all SAS, why isn't the qemu sas driver affected?
17:19:32 <cmurf> IF it's all hardware SAS, then +1 blocker on the basis there is a criterion for it. If it's this particular SAS hardware, and not all SAS hardware, then I'd say not a blocker because it's hardware specific.
17:20:36 <AndChat-742016> I don't know if we can say that for sure
17:21:41 <tflink> I can do a baremetal install on one of the donated boxes in beaker. if I hit the same bug, we assume that it's all SAS, if I don't, assume it's hardware-specific
17:21:47 <cmurf> I am gonna bet two bunnies that adamw is getting annoyed with his wireless connection :P
17:21:56 <adamwagain> So does anyone actually think we should block f25 release on this?
17:22:00 <cmurf> tflink: seems reasonable to me
17:22:12 <tflink> no, that seems silly
17:22:14 <adamwagain> Or are we just arguing about how not to?
17:22:15 <cmurf> No, but there is a criterion.
17:22:32 <jkurik> tflink: when you can do the test ?
17:22:52 <adamwagain> I just don't think we have a precedent for 'waiving' a blocker
17:22:55 <cmurf> It's like we're testing our criterion resolve at the last minute every release. It's an interesting way to cull the criteria list.
17:22:57 <tflink> I'm starting it now - is a default install of server good enough?
17:23:12 <cmurf> yes
17:23:31 <cmurf> so beaker somehow lets you do a baremetal install?
17:23:36 <cmurf> remotely?
17:23:44 <adamwagain> Cmurf: I really should've adjusted this before instead of making it a joke, sorry.
17:24:07 <adamwagain> Yes. That's what beaker is for, kinda.
17:24:16 <cmurf> that's neato
17:25:14 <adamwagain> So, I still think we should amend the criterion. But whatever approach the majority wants is fine.
17:25:24 <cmurf> While there's no precedent, there are at least two prior discussions about dropping this portion of the criterion. Wait, is it really explicitly part of the criterion? Or is it just a test case?
17:25:25 <coremodule> Votes?
17:25:41 * cmurf waits for tflink's beaker test results
17:26:19 <adamwagain> The criterion doesn't explicitly say 'SAS'. It says 'all supported local storage interfaces' or something like that.
17:26:27 <cmurf> IF the results suggest all SAS is affected, we still want to hand pass this ball in the defensive zone and see if the ref blows the whistle?
17:26:48 <adamwagain> Major foul, localized metaphor
17:27:03 <cmurf> hockey is hardly localized
17:27:17 <cmurf> s/ball/puck
17:27:21 <kparal> no, but I'm still wondering what you actually meant by that
17:27:23 <adamwagain> Heh
17:28:05 <cmurf> ehh not the best metaphor...
17:28:19 <tflink> if we change the criterion to mean something equivalent to "the storage interfaces that have regular test results submitted", I'm not going to argue with that
17:28:27 <tflink> we can't find what isn't being tested
17:29:13 <cmurf> well more importantly, it's come up in prior discussions if this should be dropped and we sorta joked about it
17:29:16 <adamwagain> Okay. How about we say we'll amend the criteria somehow and leave it at that?
17:29:32 <cmurf> and in retrospect we were committed to dropping SAS in mind, just not on paper
17:29:41 <adamwagain> Since everyone seems to agree we shouldn't actually block
17:30:15 <cmurf> yeah I'm still curious about the beaker result though
17:30:29 <kparal> adamwagain: sounds good, we can fine tune the details later
17:30:36 <kparal> let's not block the meeting
17:30:53 * tflink is still trying to verify which compose is RC 1.2
17:30:58 <adamwagain> Coremodule: can you propose?
17:31:03 <cmurf> sure, we've consumed 1/2 of jkurik's time on one bug
17:31:20 <kparal> tflink: http://dl.fedoraproject.org/pub/alt/stage/25_RC-1.2/
17:31:22 <adamwagain> Tflink: the one linked on the validation p a ges
17:31:31 <coremodule> adamw, yeh
17:31:31 <jkurik> cmurf: :)
17:31:39 <tflink> adamwagain: there's a link from the validation pages?
17:32:04 <adamwagain> Yeah. At the top. A bunch of then
17:32:09 <kparal> links to stage
17:32:12 <coremodule> proposed #agreed 1394026 - RejectedBlocker - We have decided to amend the SAS criteria to avoid blocking on this issue as it seems to be an uncommonly used testcase that doesn't get a lot of validiation testing. We will fine tune the criteria later.
17:32:12 <kparal> https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Installation#How_to_test
17:32:31 <kparal> ack
17:32:41 <adamwagain> Patch: local storage criterion, not sas
17:32:43 * tflink has had his head in automation for too long, apparently
17:33:04 <coremodule> proposed #agreed 1394026 - RejectedBlocker - We have decided to amend the local storage criteria to avoid blocking on this issue as it seems to be an uncommonly used testcase that doesn't get a lot of validiation testing. We will fine tune the criteria later.
17:33:11 <adamwagain> Ack
17:33:15 <cmurf> ack
17:33:21 <garretraziel> ack
17:33:22 <kparal> ack
17:33:24 <jkurik> ack
17:33:33 <coremodule> #agreed 1394026 - RejectedBlocker - We have decided to amend the local storage criteria to avoid blocking on this issue as it seems to be an uncommonly used testcase that doesn't get a lot of validiation testing. We will fine tune the criteria later.
17:34:09 <coremodule> #topic (1365435) Regression: SELinux prevents systemd from setting rlimits and breaks core dumping
17:34:09 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1365435
17:34:09 <coremodule> #info Proposed Blocker, selinux-policy-targeted, ASSIGNED
17:34:10 <adamwagain> Next bug!
17:34:17 <cmurf> -1 blocker
17:34:18 <adamwagain> -1.
17:34:29 <cmurf> -1 FE
17:34:39 <cmurf> fix it after release
17:35:36 <jkurik> -1 to block
17:35:45 <kparal> -1
17:36:11 <pschindl> -1
17:37:12 <coremodule> proposed #agreed 1365435 - RejectedBlocker - The decision was made to classify this bug as a RejectedBlocker as we don't see the impact of this as being critical to system function and this can be fixed with an update at a later time.
17:37:27 <adamwagain> Ack
17:37:38 <jkurik> ack
17:37:46 <kparal> ack
17:37:51 <coremodule> #agreed 1365435 - RejectedBlocker - The decision was made to classify this bug as a RejectedBlocker as we don't see the impact of this as being critical to system function and this can be fixed with an update at a later time.
17:38:01 <coremodule> #topic (1170765) systemd: all processes in scopes (including user sessions) SIGKILLed immediately on shutdown with no opportunity to shut down cleanly
17:38:01 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1170765
17:38:01 <coremodule> #info Proposed Blocker, systemd, ASSIGNED
17:38:25 <adamwagain> So here's the fun one!
17:38:28 <coremodule> I am running a test on this one right now, standby for the results...
17:38:31 <cmurf> -1 blocker
17:38:42 <cmurf> I don't like this bug. I get hit with it often.
17:39:04 <barq> I got this bug as well.
17:39:10 <cmurf> But it seems like it should be on jkurik and mattdm's future priority project pile
17:39:17 <adamwagain> Basically this seems to be back, lately. Processes killed on logout / shutdown.
17:39:28 <adamwagain> Well, we blocked 23 on it.
17:39:35 <cmurf> Now maybe if systemd in FEdora 26 gets the KillUserProcess=yes enabled, and it starts to nerf the files of applications...
17:39:45 <cmurf> that'd be worthy of the data corruption criterion
17:39:48 <adamwagain> Can someone ping zbyszek?
17:40:01 <adamwagain> He should be in #systemd
17:40:12 <cmurf> Huh no kidding we blocked F23 on it...
17:40:52 <adamwagain> And do we have any non-qa folks for perspective?
17:41:35 <adamwagain> Since this is big and messy...
17:41:40 * soas-0bb9 f25 soas USB boots
17:42:20 <coremodule> I'm seeing it on the latest F25 workstation.
17:43:39 <kparal> I saw apps reported as crashed (being killed) on a next login, but very rarely. not sure what triggers it
17:43:44 * satellit I see this in ff in f25 but restore is offered for open tabs
17:44:22 <adamwagain> I can't actually remember how often it happens to me
17:44:37 <barq> It happens to me every time I boot.
17:44:47 <kparal> it used to be very frequent early in F25 cycle but now I don't see it anymore
17:45:02 <adamwagain> Definitely happened on logout last week
17:46:06 <adamwagain> Really be nice to have systemd dev input
17:46:47 <kparal> we should start a new bug about this, really. the existing one is too long and this might be a different cause completely
17:47:56 <kparal> have some logs appended
17:48:12 <adamwagain> True, I was being a bit lazy
17:48:35 <coremodule> Could we reconvene later in the week after we get a systemd dev's input?
17:49:33 <adamwagain> I really want to do the compose today if possible... But we can always compose with what we have and decide about this later I guess
17:49:51 <kparal> maybe also ask on list how often this happens to people
17:50:07 <cmurf> i'm willing to bet it's often
17:50:15 <cmurf> but, what's being nerfed?
17:50:24 <coremodule> kparal, Yeah, good point. It seems to happen to me intermittently, so that would be a good metric to have.
17:50:59 <kparal> because to me everything seems fine at the moment, so it would be nice to know if it is really a frequent problem or not
17:51:17 * satellit block shutdown until all apps are closed (possible fix?)
17:51:27 <adamwagain> Cmurf: well, the logic last time was that really anything could get nerfed if it was expecting to be able to shut down cleanly
17:52:33 <adamwagain> I'm OK with punting for more info/input here
17:52:54 <coremodule> proposed #agreed 1170765 - punt (delay decision) - We have decided to delay the classification of this as a bug as we are unsure of how often it happens and would also like to get a systemd developers input on this one. We are also considering some ideas for a possible fix.
17:53:09 <garretraziel> ack
17:53:11 <kparal> ack
17:53:14 <satellit> ack
17:53:15 <adamwagain> Ack
17:53:15 <pschindl> ack
17:53:25 <coremodule> #agreed 1170765 - punt (delay decision) - We have decided to delay the classification of this as a bug as we are unsure of how often it happens and would also like to get a systemd developer's input on this one. We are also considering some ideas for a possible fix.
17:53:45 <jkurik> post ack
17:53:59 <coremodule> #info Moving on to Proposed FE's...
17:54:30 <coremodule> #topic (1379106) AttributeError: 'NoneType' object has no attribute 'format'
17:54:30 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1379106
17:54:31 <coremodule> #info Proposed Freeze Exceptions, anaconda, POST
17:55:11 <adamwagain> Thought this was approved? +1 as it's a safe fix
17:56:33 <jkurik> for me this should be +1 FE
17:56:53 <coremodule> I'm +1.
17:57:26 <coremodule> Any more votes?
17:58:00 <kparal> too long, +1 I guess
17:58:05 <coremodule> proposed #agreed 1379106 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as it is a safe fix that has been tested and proven to work without affecting the rest of the system.
17:58:17 <adamwagain> Ack
17:58:19 <kparal> ack
17:58:32 <jkurik> ack
17:58:34 <coremodule> #agreed 1379106 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as it is a safe fix that has been tested and proven to work without affecting the rest of the system.
17:58:43 <coremodule> #topic (1393945) syslinux-splash.png and syslinux-vesa-splash.png are in the wrong directory
17:58:44 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1393945
17:58:44 <coremodule> #info Proposed Freeze Exceptions, generic-logos, MODIFIED
17:59:01 <adamwagain> Only affects generic, then sure.
17:59:06 <coremodule> +1 FE
17:59:21 <garretraziel> +1 FE
17:59:34 <coremodule> We have sgallagh s vote in bug, so...
17:59:36 <kparal> +1
17:59:49 <jkurik> +1FE
18:00:20 <satellit> +1fe
18:00:34 <coremodule> proposed #agreed 1393945 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as it is a simple fix that only affects the generic-logos.
18:00:48 <adamwagain> Ack
18:00:54 <kparal> ack
18:01:28 <satellit> ack
18:01:30 <coremodule> #agreed 1393945 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as it is a simple fix that only affects the generic-logos.
18:01:39 <coremodule> #topic (1392885) External display doesn't disconnect after undocking with kernel 4.8.6
18:01:39 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1392885
18:01:39 <coremodule> #info Proposed Freeze Exceptions, kernel, ON_QA
18:02:09 <kparal> I'm a bit worried of updating kernel again at the last moment
18:02:11 <cmurf> thought we're committed to 4.8.6
18:02:22 <kparal> people probably don't undock when running Live
18:02:38 <kparal> on the other hand, it would be nice to have this working after a default installation, for reviews
18:03:13 <adamwagain> Yeah, I'm kinda unsure here
18:03:20 <cmurf> well there's not much 4.8.7 testing it's pretty new
18:03:27 <kparal> I'd rather say -1
18:03:36 <adamwagain> There are a lot of people with affected systems, but the ootb impact isn't huge
18:03:38 <kparal> unless we slip again
18:03:42 <cmurf> what's kernel team say?
18:03:50 <adamwagain> Yeah, definitely document it though
18:04:47 <adamwagain> We *could* do the two compose thing I guess
18:05:13 <adamwagain> One with 4.8.6 one with 4.8.7... Not sure if it's worth that though
18:05:33 <mkolman> adamwagain: so with that SAS thing rejected it leaves just the 1393945 FE for the Anaconda build, right ?
18:05:34 * kparal doesn't really want to do twice as much testing
18:06:10 <cmurf> well the kernel change log for 4.8.7 looks like it should just fix stuff
18:06:13 <adamwagain> Mkolman: we could take the SAS fix as an fe, since it's very isolated
18:06:25 <adamwagain> Let's vote on that in a sec
18:06:45 <mkolman> adamwagain: OK
18:06:54 <adamwagain> Okay, let's be strict here, -1 for me (on kernel bug)
18:07:09 <pschindl> -1 too
18:07:25 <coremodule> proposed #agreed 1392885 - RejectedFreezeException - The decision was made to classify this bug as a RejectedFreezeException as the fix would involve a kernel change and at this point in the release cycle of F25, we don't think that fixing this bug is worth the potential damage that could be caused by said kernel change.
18:07:34 <kparal> ack
18:07:42 <adamwagain> Ack
18:07:49 <garretraziel> ack
18:07:51 <cmurf> ack
18:07:56 <coremodule> #agreed 1392885 - RejectedFreezeException - The decision was made to classify this bug as a RejectedFreezeException as the fix would involve a kernel change and at this point in the release cycle of F25, we don't think that fixing this bug is worth the potential damage that could be caused by said kernel change.
18:08:06 <coremodule> Do we want to vote on the SAS bug as an FE?
18:08:15 <coremodule> Before we move on to the last Proposed FE?
18:08:36 <kparal> sure, why not
18:08:48 <adamwagain> Sure
18:08:52 <adamwagain> Sure
18:09:05 <coremodule> #info We're going to vote on the SAS bug as an FE.
18:09:07 <cmurf> depending on the fix, all the iscsi stuff should be retested if it's accepted FE
18:09:07 <coremodule> #topic (1394026) SAS address parsing issue
18:09:07 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1394026
18:09:08 <coremodule> #info Proposed Blocker, anaconda, NEW
18:09:27 <adamwagain> So the fix is in a codepath we only hit when dealing with sas
18:09:35 <kparal> +1
18:09:37 <adamwagain> Therefore I'm fine with +1 fe
18:09:57 <kparal> if something breaks, adamw fully tests the new compose on his own
18:10:22 <cmurf> ok sure +1 fe
18:10:27 <adamwagain> Yak farm
18:10:45 <coremodule> proposed #agreed 1394026 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as the fix involves a codepath that is only touched when dealing with SAS so at worst this bug would remain unfixed, at best we would have a working SAS-install ability.
18:10:46 <cmurf> yak farm in new zealand
18:10:53 <adamwagain> Ack
18:10:53 <cmurf> destination matters
18:10:55 <kparal> ack
18:10:57 <pschindl> ack
18:10:57 <cmurf> ack
18:11:00 <adamwagain> With no network connection
18:11:11 <coremodule> #agreed 1394026 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as the fix involves a codepath that is only touched when dealing with SAS so at worst this bug would remain unfixed, at best we would have a working SAS-install ability.
18:11:15 <cmurf> for sure no internet ever, done with that
18:11:23 <coremodule> #info Moving on to the final proposed FE...
18:11:32 <coremodule> #topic (1394449) f25 plasma "networks" and "instant messaging" icons are invisible.
18:11:32 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1394449
18:11:32 <coremodule> #info Proposed Freeze Exceptions, plasma-desktop, NEW
18:11:50 <satellit> look at the screenshot in bug
18:11:57 <cmurf> ok?
18:12:10 <kparal> might be even a blocker
18:12:36 <cmurf> since it's missing i'm not sure what i'm supposed to see
18:12:41 <satellit> fix is change theme
18:12:50 <satellit> look at attchment
18:12:54 <kparal> I don't see a patch here, so I'm not sure voting about FE is even worth it. but +1 in general
18:13:03 <cmurf> +1 FE
18:13:06 <cmurf> -1 blocker
18:13:31 <satellit> + FE
18:13:31 <kparal> cmurf: you see a white space :)
18:13:53 <pschindl> +1 FE
18:14:05 <satellit> affects live on wireless only boot
18:14:10 <adamwagain> I guess +1
18:14:21 <coremodule> proposed #agreed 1394449 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as this would be nice to fix for the final release. Note that changing the theme of the system will correct the error, in case this isn't fixed in time.
18:14:57 <garretraziel> ack
18:15:01 <satellit> ack
18:15:07 <adamwagain> Ack
18:15:14 <kparal> ack
18:15:30 <coremodule> #agreed 1394449 - AcceptedFreezeException - The decision was made to classify this bug as an AcceptedFreezeException as this would be nice to fix for the final release. Note that changing the theme of the system will correct the error, in case this isn't fixed in time.
18:15:53 <coremodule> Shall we call it for today, or do we want to reflect on the bugs we have?
18:16:35 <tflink> the baremetal install for RC1.2 went fine
18:16:43 <adamwagain> I'm OK with calling it
18:16:44 <tflink> don't know if that's something we want to deal with now or later
18:16:50 <adamwagain> Tflink: interesting
18:16:56 <adamwagain> Let's follow up in bug
18:17:07 <coremodule> #topic Open Floor
18:17:08 <tflink> k
18:17:13 <kparal> just a note about https://bugzilla.redhat.com/show_bug.cgi?id=1394755
18:17:21 <satellit> https://bugzilla.redhat.com/show_bug.cgi?id=1363915  fixed with https://pagure.io/fedora-kickstarts/pull-request/99#request_diff
18:17:26 <adamwagain> I should be back on a laptop in an hour or two to talk with blivet/anaconda/releng
18:17:32 <kparal> if any of you encounter login issues after upgrade, please see that bug
18:17:51 <kparal> I was trying to figure out when it happens and I didn't succeed
18:18:04 <kparal> but it would be a possible blocker material
18:18:29 <adamwagain> Criteria say upgrades are only blocking with default package sets
18:20:09 <kparal> well I'm currently not sure what the trigger is, it might be unrelated to the gstreamer plugin, that's just my guess
18:20:17 <adamwagain> OK
18:20:34 <adamwagain> I didn't get it on upgrade of my laptop, fwiw
18:20:35 <kparal> either way, it would be a bad bug
18:20:39 <kparal> ok
18:21:21 <coremodule> Anything else we need to cover?
18:21:30 <garretraziel> heh, bed bug
18:22:03 <coremodule> Beginning shutdown sequence in 3...
18:22:05 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=1390607 comes to mind, but we're waiting for dev response there
18:22:11 <kparal> it was reopened
18:22:22 <adamwagain> Our ears, when kparal says "I've found a blocker"
18:22:31 <kparal> haha
18:23:13 <coremodule> 3...
18:23:16 * kparal starts playing witcher 3 again, he definitely is not searcher for further blockers
18:23:22 <kparal> *searching
18:23:24 <coremodule> 2...
18:23:40 <coremodule> 1...
18:24:11 <coremodule> Thanks for the participation today guys.
18:24:16 <coremodule> #endmeeting