16:00:09 <adamw> #startmeeting F25-blocker-review
16:00:09 <zodbot> Meeting started Mon Sep 19 16:00:09 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:09 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:09 <adamw> #meetingname F25-blocker-review
16:00:09 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:10 <adamw> #topic Roll Call
16:00:20 <adamw> ahoyhoy folks, who's around for blocker review?
16:00:52 * coremodule is here.
16:00:59 <adamw> #chair coremodule
16:00:59 <zodbot> Current chairs: adamw coremodule
16:01:23 * pschindl is here
16:01:29 <adamw> #chair pschindl
16:01:29 <zodbot> Current chairs: adamw coremodule pschindl
16:01:31 * cmurf here
16:01:33 * kparal is here
16:01:33 <dgilmore> hola amigos
16:01:40 <adamw> mornin dgilmore
16:01:53 <adamw> heads up, folks - i'm on a train with patchy wifi and my battery's gonna run out at some point
16:01:59 <pschindl> I can run the meeting if needed.
16:02:00 <adamw> so coremodule will take over whenever it seems appropriate
16:02:06 <adamw> and/or pschindl
16:02:08 <adamw> fight it out ;)
16:02:22 <adamw> if i seem to disappear or whatever, just go ahead and take over from wherever i got up to.
16:02:24 <pschindl> I will gladly let it to coremodule's hands
16:02:31 <cmurf> on a train from where to where
16:02:39 <adamw> going to portland for LAS
16:02:46 <adamw> http://las.gnome.org/
16:02:55 <adamw> #topic Introduction
16:02:55 <adamw> Why are we here?
16:02:56 <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:02:56 <adamw> #info We'll be following the process outlined at:
16:02:56 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:02:58 <adamw> #info The bugs up for review today are available at:
16:03:00 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:07 <adamw> #info The criteria for release blocking bugs can be found at:
16:03:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
16:03:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
16:03:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
16:03:36 <adamw> who wants to be secretary? pschindl/coremodule, do you want to split the responsibilities? easier that way
16:04:00 <pschindl> I'll do the secretarization
16:04:14 <coremodule> That sounds good to me.
16:04:15 <adamw> #info pschindl to secretarialize
16:04:16 <adamw> thanks
16:04:48 <adamw> for Beta, we have:
16:04:49 <adamw> #info 4 Proposed Blockers
16:04:49 <adamw> #info 4 Accepted Blockers
16:04:49 <adamw> #info 1 Proposed Freeze Exceptions
16:04:51 <adamw> #info 1 Accepted Freeze Exceptions
16:04:52 <adamw> we also have:
16:05:04 <adamw> #info 8 Proposed Blockers (Final)
16:05:08 <adamw> we'll see how far we get, i guess :)
16:05:17 <adamw> starting with the proposed beta blockers...
16:05:34 <adamw> #info starting with Beta proposed blockers
16:05:35 <adamw> #info 4 Proposed Blockers
16:05:35 <adamw> #info 4 Accepted Blockers
16:05:35 <adamw> #info 1 Proposed Freeze Exceptions
16:05:36 <adamw> #info 1 Accepted Freeze Exceptions
16:05:36 <adamw> grr
16:05:42 <adamw> #topic (1372868) F25 Alpha-2 Installer Fails if  DVD-ROM is on Silicon Image 3114 SATA Controller
16:05:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1372868
16:05:44 <adamw> #info Proposed Blocker, anaconda, NEW
16:05:58 <adamw> so we asked for info on this last week, right?
16:05:59 <pschindl> -1 it doesn't seem to affect lot of machines
16:06:03 <cmurf> -1 blocker
16:06:10 <cmurf> and there's a work around
16:06:25 <cmurf> odd that the use of this controller is affecting video but...
16:06:37 <adamw> yeah, it's feeling pretty -1y
16:06:49 <kparal> -1
16:07:23 <adamw> proposed #agreed 1372868 - RejectedBlocker (Beta) - this does not seem to affect much hardware, and there is a workaround available
16:07:24 <coremodule> -1
16:07:34 <cmurf> ack
16:07:36 * satellit listening
16:07:38 <coremodule> ack
16:07:41 <adamw> morning satellit
16:08:10 <pschindl> ack
16:08:21 <adamw> #agreed 1372868 - RejectedBlocker (Beta) - this does not seem to affect much hardware, and there is a workaround available
16:08:34 <adamw> #topic (1373169) Can't login again after logout.
16:08:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1373169
16:08:34 <adamw> #info Proposed Blocker, gnome-session, NEW
16:08:48 <adamw> iirc we were more or less ready to accept this but just wanted to clear up a couple of details, right?
16:08:55 <adamw> i've seen this one in testing this week...
16:08:58 <kparal> I provided fresh logs
16:09:12 <kparal> seems to be really clear cut, it simply does not work
16:09:28 <kparal> there are suspicious errors in the log
16:10:09 <cmurf> there may be more than one bug here
16:10:27 <cmurf> making it hard to pin down "the" problem in this particular report
16:10:37 * adamw is fine with +1 at this point and sort out the details later
16:10:41 <kparal> +1
16:10:46 <cmurf> +1
16:10:48 <adamw> it certainly seems like enough of us experience the symptoms, whatever the details of the cause
16:10:49 <pschindl> I'm also +1
16:11:28 <cmurf> although i'm curious what this means for beta vs final
16:12:05 <adamw> hmm?
16:12:07 <cmurf> if the bug isn't isolated and fixed in a week then it blocks beta I guess
16:12:19 <cmurf> or 10 days, whatever
16:12:34 <kparal> sure
16:12:56 <adamw> go/no-go is 2016-10-06.
16:12:57 <kparal> btw, do we have a secretary?
16:13:01 <adamw> yeah, pschindl.
16:13:08 <kparal> pschindl++
16:13:09 <zodbot> kparal: Karma for pschindl changed to 1 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:13:11 <cmurf> oh i'm confused with freeze, nevermind the cmurf
16:13:51 * adamw not dead, just criteria hunting
16:14:27 <adamw> proposed #agreed 1373169 - AcceptedBlocker (Beta) - this constitutes a violation of "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops." - 'work' is defined as "Logging out must return the user to the environment from which they logged in, working as expected.", and if you can't log in again, it's not 'working as expected'
16:14:46 <coremodule> ack
16:14:52 <kparal> ack
16:15:33 <adamw> one more ack?
16:15:40 <pschindl> ack
16:15:49 <adamw> #agreed 1373169 - AcceptedBlocker (Beta) - this constitutes a violation of "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops." - 'work' is defined as "Logging out must return the user to the environment from which they logged in, working as expected.", and if you can't log in again, it's not 'working as expected'
16:16:01 <adamw> #topic (1372962) SELinux is preventing mount from 'unlink' accesses on the file utab.
16:16:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1372962
16:16:01 <adamw> #info Proposed Blocker, selinux-policy, ON_QA
16:16:53 <adamw> this breaks automount, i think
16:17:02 <pschindl> yes
16:17:04 <adamw> i've seen it here too
16:17:04 <adamw> so i'm +1
16:17:08 <pschindl> +1 too
16:17:15 <cmurf> well other than not liking automount :-P +1
16:17:21 <kparal> I tried to reproduce this today and encountered some weirdness, but didn't have time to dig into it
16:17:25 <kparal> +1 in general
16:17:40 <adamw> kparal: well, for me it was as simple as 'plug in a micro SD or usb stick and it didn't mount or appear in nautilus at all'
16:18:06 <adamw> proposed #agreed 1372962 - AcceptedBlocker (Beta) - violates "Automatic mounting of removable media on insertion must work in release-blocking desktops."
16:18:11 <kparal> ack
16:18:12 <cmurf> huh must be a regression because i had usb sticks automounting with a post alpha compose
16:18:29 <kparal> cmurf: are you running in enforcing mode?
16:18:31 <cmurf> akakakak
16:18:34 <pschindl> ack
16:18:42 <adamw> selinux regressions aren't that unusual until they stop adding extra restrictions
16:18:46 <cmurf> kparal: yes
16:18:53 <adamw> there's a point in the release cycle where by policy they only make selinux more permissive, not less
16:18:56 <cmurf> adamw: makes sense
16:19:00 <adamw> before that point, they add new restrictions
16:19:09 * adamw can never remember exactly when they stop doing that
16:19:18 <adamw> #agreed 1372962 - AcceptedBlocker (Beta) - violates "Automatic mounting of removable media on insertion must work in release-blocking desktops."
16:19:34 <adamw> #topic (1374670) KDE desktop freezes on login
16:19:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1374670
16:19:35 <adamw> #info Proposed Blocker, selinux-policy, VERIFIED
16:19:41 <adamw> more selinux fun
16:19:44 <adamw> did anyone else see this one?
16:20:06 <adamw> oh, you did, kamil?
16:20:51 <adamw> doesn't seem like the openqa tests ran into it, they test firefox and konsole...but maybe the offending selinux wasn't in stable at that point or something
16:21:13 <kparal> I did verify the fix today
16:21:21 <kparal> and currently it's broken, yes
16:21:34 <cmurf> seems like a clear +1 even withthe small sample size
16:21:36 <adamw> ok, i can go with +1 then
16:21:36 <kparal> adamw: well, depends on your timeouts, the actions are performed, but might take minutes
16:21:52 <cmurf> ok mostly clear then
16:22:01 <adamw> openqa would get bored and give up after ~30 secs, so i guess the bug hadn't shown up in stable last time we got an f25 compose
16:22:19 <kparal> adamw: 30 seconds would be definitely too short and would crash openqa
16:22:24 <adamw> one more vote? do we count you as +1 kparal?
16:22:28 <kparal> +1
16:22:46 <pschindl> +1
16:22:57 * satellit I have seen long wait on plasma start
16:23:17 <kparal> satellit: that's it, can be 5 minutes or more
16:23:28 <satellit> yes
16:23:50 <adamw> proposed #agreed 1374670 - AcceptedBlocker (Beta) - this is an effective violation of all desktop-related Alpha and Beta criteria (as it takes ~5 minutes to do anything at all)
16:24:07 <pschindl> ack
16:24:11 <satellit> ack
16:24:17 <coremodule> ack
16:24:24 <adamw> #agreed 1374670 - AcceptedBlocker (Beta) - this is an effective violation of all desktop-related Alpha and Beta criteria (as it takes ~5 minutes to do anything at all)
16:24:36 <adamw> OK, that's all the proposed beta blockers
16:24:43 <adamw> let's do the proposed beta FE next, since there's just the one
16:24:48 <adamw> then we can move onto final blockers and see how far we get
16:24:56 <adamw> #info moving to the proposed Beta freeze exception
16:25:04 <adamw> #topic (1375721) [abrt] initial-setup: common.py:356:_mark_screen_visited:AttributeError: 'NoneType' object has no attribute 'mark_screen_visited'
16:25:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1375721
16:25:04 <adamw> #info Proposed Freeze Exceptions, initial-setup, NEW
16:25:56 <kparal> sounds like a blocker?
16:26:08 <adamw> if it affects the text version on ARM it would be
16:26:15 <adamw> that's the only case in which i-s is considered blocking
16:26:38 <cmurf> right, there's no freeze yet so fe doesn't apply
16:26:40 <kparal> oh, it's the race again
16:26:48 <cmurf> so it's a dup?
16:26:49 <adamw> (we decided a while back we weren't gonna block on i-s bugs for anaconda installs, since you can create a user in anaconda and you can log in as root, to anything which uses i-s)
16:27:01 <adamw> cmurf: we can still grant freeze exceptions before the freeze
16:27:17 <adamw> (and yeah, wanted to consider if this would be a blocker too....)
16:27:42 <adamw> is pwhalen here?
16:27:50 <kparal> adamw: does the decision apply even to Final release?
16:27:55 * pwhalen is here
16:28:01 <kparal> I can understand it for Beta
16:28:07 <kparal> seems a bit far-fetched for Final
16:28:25 <adamw> kparal: welp, that's how i recall it anyhow, you can go back and check the details though...
16:28:35 <adamw> iirc that's why the criteria is worded as it is
16:28:46 <coremodule> So because, on first boot the user is presented with a user creation screen, the decision is made to not classify Anaconda bugs like this as blockers?
16:28:52 <adamw> pwhalen: have you seen this one on ARM?
16:29:18 <pwhalen> I saw the bug, but havent seen it on arm, just the other two open ones for i-s
16:29:38 <adamw> coremodule: no, the other way around. this is an initial-setup bug. since you can - and in fact *must* - create at least one of a user account or a root password in anaconda, we haven't considered i-s bugs blocking for cases where you go through anaconda to install
16:29:47 <adamw> pwhalen: hrmm. maybe needs more info then
16:30:05 <pwhalen> i-s doesnt run at all, so i cant select the spoke
16:30:26 <adamw> coremodule: the case where i-s is clearly blocking is on ARM disk images, where you don't go through anaconda; you boot straight to i-s on first boot after writing the image to your boot media, and if you can't use i-s to create a user and/or set the root password, you will not be able to log in
16:30:38 <adamw> pwhalen: oh, heh. so it could still be there after those other two are fixed, i guess
16:30:48 <pwhalen> it could..
16:30:56 <pwhalen> sounds liklely
16:31:04 <adamw> since giulio is usually right and the bug has a backtrace, i'm kinda inclined to a +1 FE at least
16:31:11 <kparal> +1 FE
16:31:15 <adamw> we could give it +1 blocker if it turns out to affect ARM as well, whenever we can test
16:31:26 <pwhalen> +1 FE
16:31:32 * adamw has like 8 mins battery left, so is gonna hand off to coremodule after this bug
16:31:45 <pschindl> +1 FE
16:31:47 <satellit> +1 FE
16:31:49 <coremodule> adamw, Gotcha, I see how it goes now. I agree to the +1 FE at least.
16:31:53 <coremodule> +1 FE
16:32:14 <adamw> proposed #agreed 1375721 - AcceptedFreezeException (Beta) - inability to create a user in i-s is clearly a serious problem that cannot be fixed in an update. if this bug turns out to affect ARM it will likely be upgraded to a blocker, but for now we grant it an FE at least.
16:32:36 <coremodule> ack
16:32:38 <kparal> ack
16:32:41 <satellit> ack
16:32:48 <adamw> #agreed 1375721 - AcceptedFreezeException (Beta) - inability to create a user in i-s is clearly a serious problem that cannot be fixed in an update. if this bug turns out to affect ARM it will likely be upgraded to a blocker, but for now we grant it an FE at least.
16:32:58 <adamw> #info we'll switch to final blockers now, and coremodule will take over
16:33:17 <coremodule> adamw, Glad to do it!
16:33:20 <adamw> coremodule: so go to https://qa.fedoraproject.org/blockerbugs/milestone/25/final/irc and just run through the Proposed Blockers one at a time as i've been doing :) thanks
16:33:34 <coremodule> adamw, No problem!
16:33:54 <kparal> some of those bugs are gonna be fun
16:33:57 <coremodule> #topic (1375712) [abrt] anaconda: TypeError: __new__() takes 3 positional arguments but 5 were given
16:34:02 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1375712
16:34:11 <coremodule> #info Proposed Blocker, anaconda, POST
16:34:40 * adamw checks if this is hitting f25 yet
16:34:49 <adamw> (if his battery holds out)
16:35:14 <kparal> the new lorax seems to be still in u-t
16:35:30 <kparal> should we vote on it or punt until it's pushed?
16:35:58 <adamw> oh, i think f25 is still hitting an earlier crash in iscsi tests
16:36:18 <adamw> 1347415
16:36:19 <coremodule> I say punt, and hope the update is released soon.
16:36:34 <adamw> coremodule: the update will *break* this, not *fix* it. (at least, if i haven't lost track).
16:36:53 <adamw> oh, i dunno, i'll leave it to you guys, i'd better shut down now
16:36:59 <adamw> lters
16:37:01 <kparal> the update in u-t will cause this issue
16:37:08 <kparal> adamw: see you
16:37:11 <coremodule> Cya!
16:38:10 <kparal> I think both approaches are kinda OK. but it might be a bit better to vote on that now, even if it is in u-t, so that maintainers know that if it hits stable, it's a blocker
16:38:34 <kparal> btw, this problem will repeat even for other proposed blocker, many of them are just in u-t
16:38:46 <coremodule> kparal, Okay, I understand.
16:39:27 <coremodule> If we punt and it's released, we're just going to end up classifying it as a blocker later, so may as well vote now, is that what you're suggesting kparal?
16:39:55 <kparal> yeah, there are pros and cons to both
16:40:06 <coremodule> Okay, I can get behind that.
16:40:18 <coremodule> +1 here.
16:40:29 <kparal> it's more work in advance, but the maintainers will know what's coming to them (and can better decide whether to push something or not)
16:40:31 <cmurf> in a sense sooner is better than later, there's over a week to sort it out now
16:40:40 <cmurf> yeah +1
16:40:46 <pschindl> I'm +1
16:41:09 <kparal> also, it might confuse us a bit when we want to ask for RC compose and we see some accepted blockers, even though they are still in u-t and therefore technically not blockers
16:41:23 <cmurf> right
16:41:35 <cmurf> and all we need is more confusion
16:41:41 <kparal> I don't remember we ever discussed what to do in this case
16:41:55 <kparal> and the single person who's enjoying process discussions just left
16:42:12 <coremodule> That is a good point.
16:42:26 <coremodule> The confusing blocker still in updates-testing I mean.
16:43:02 <kparal> ok, so let's do this. let's discuss these bugs and their severity, and write a summary as a comment into those bug reports, but leave them in their current state (proposed)
16:43:20 <cmurf> well how about everyone just -1 the version in u-t now and stop it from going stable?
16:43:40 <cmurf> it won't become a blocker if it gets to -3
16:43:43 <kparal> so we can say "this is a critical issue, if you push this, it's going to be a blocker", but not "accept" this and create some confusion
16:43:57 <kparal> cmurf: because in some cases you might want to push the update to resolve other bugs
16:44:13 <cmurf> or would it be a 0 day blocker?
16:44:37 <kparal> that depends on what software and what bug it is
16:44:49 <coremodule> Yikes, okay. kparal, will you write the Bugzilla summary and/or contact the maintainers and let them know our plan?
16:45:34 <kparal> coremodule: pschindl will write the decision same as for any other bug, just not update the whiteboard (no AcceptedBlocker or RejectedBlocker)
16:46:21 <coremodule> Okay great. We'll essentially punt for now, and classify later if need be.
16:46:51 <kparal> i.e. we'll just conclude these bugs with #agreed BZ - This is a serious issue, would be a blocker. Punting now because it's not stable.
16:46:57 <kparal> makes sense?
16:47:04 <cmurf> wfm
16:47:43 <kparal> so I'm +1 to this (1375712)
16:47:52 <cmurf> also +1
16:48:36 * kparal will suggest #agreed
16:48:41 <coremodule> proposed #agreed 1375712 - punt (delay decision) - This is a serious issue, should be a blocker, but we're going to notify the maintainers before it's officially released, and before we classify this bug to avoid a situation where the bug is still in updates-testing but is classified as an 'AcceptedBlocker'.
16:48:53 <kparal> coremodule: ok, you beat me to it :)
16:49:20 <coremodule> kparal, :P
16:49:39 <kparal> I might propose an easier to read version
16:49:54 <coremodule> Go for it!
16:50:58 <kparal> proposed #agreed 1375712 - tentative AcceptedBlocker - If the affected software hits stable repos, this will violate "The installer must be able to detect (if possible) and install to supported network-attached storage devices." for SCSi. Punting for the moment.
16:51:15 <kparal> proposed #agreed 1375712 - tentative AcceptedBlocker - If the affected software hits stable repos, this will violate "The installer must be able to detect (if possible) and install to supported network-attached storage devices." for SCSi and therefore be a blocker. Punting for the moment.
16:51:38 <cmurf> ackchoo
16:51:45 <kparal> sigh, it's iSCSI it seems
16:51:46 <pschindl> ack
16:51:49 <kparal> but whatever :)
16:52:04 <pschindl> I will amend it in the bug
16:52:05 <coremodule> ack
16:52:06 <cmurf> yea redo SCSi will confus someone
16:52:13 <coremodule> #agreed 1375712 - tentative AcceptedBlocker - If the affected software hits stable repos, this will violate "The installer must be able to detect (if possible) and install to supported network-attached storage devices." for SCSi and therefore be a blocker. Punting for the moment.
16:52:35 <kparal> pschindl: so, let's not touch the whiteboard or Blocks:, just put there this comment
16:52:50 <pschindl> kparal: yes sir
16:53:08 <coremodule> #topic (1366775) /usr/libexec/gnome-settings-daemon is hammering CPU after login tring to connect to local printing service
16:53:13 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366775
16:53:18 <coremodule> #info Proposed Blocker, cups, NEW
16:54:06 <cmurf> I'm still confused if the setup for this bug happening is the removal of cups.
16:54:46 <kparal> I'm still seeing this in my VMs, but not on bare metal
16:54:53 <cmurf> interesting
16:55:03 <cmurf> and you're not removing cups in either case first?
16:55:09 <kparal> nope
16:55:41 <cmurf> so comment 15 is not true in your case?
16:55:42 <kparal> pschindl: what about you, are you seeing this somewhere?
16:56:01 <kparal> cmurf: no, just a default VM install triggers this for me
16:56:12 <cmurf> hmm
16:56:22 <pschindl> I haven't noticed this
16:56:30 <cmurf> well i'm pretty finicky with this stuff working out of the box, I think whether VM or baremetal it needs to work
16:56:43 <cmurf> but VM stuff can be tricky
16:56:51 <kparal> I'm surprised your VMs are not affected
16:57:05 <kparal> I will try yet another VM install, with latest Workstation Live
16:57:15 <kparal> but that will take 10 minutes
16:57:42 <coremodule> Shall we move on and come back? I am testing too.
16:57:47 <kparal> ok
16:57:51 <cmurf> e.g. I can't connect to a Samba server in a VM using NAT
16:58:07 <cmurf> so I wonder if this bug goes away if the VM does not use NAT
16:58:29 <coremodule> #info Moving on to the next bug, we will return to 1366775 after some testing
16:58:34 <cmurf> OK
16:58:37 <coremodule> #topic (1375504) VM screen is often black after boot in gnome-boxes
16:58:42 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1375504
16:58:46 <coremodule> #info Proposed Blocker, gnome-boxes, NEW
16:58:51 <cmurf> onoz
16:59:22 <kparal> I saw this one today with latest Workstation Live (today's compose)
17:00:03 <cmurf> seems to fail basic functionality, but not always, it's conditional on what OS is used in Boxes?
17:00:05 <kparal> the funny thing is that it's broken differently for xorg and wayland
17:00:12 <kparal> the black screen (this bug) happens for X11
17:00:23 <kparal> X11 now boots by default due to a different bug
17:00:35 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=1374028
17:00:36 <cmurf> here's were the x and wayland folks are gonna get hit with double bugs during transition
17:00:52 <kparal> 1374028 seems it will get fixed in the next mutter
17:01:15 <kparal> but when it is and we get wayland instead of x11, we will get flickering display: https://bugzilla.redhat.com/show_bug.cgi?id=1266484
17:01:45 <kparal> so, this bug might easily go away just because they sweep it under the carpet by fixing wayland initialization, but it will cause a different bug to be a proposed blocker instead
17:01:52 <cmurf> It seems like a judgement call though in the Boxes case, because there's no requirement that Boxes runs the current release
17:02:27 * satellit prefer virtual machine manager
17:02:37 <cmurf> if the problem doesn't happen with Fedora 23/24 in Fedora 25 Boxes, or Windows (pretty common use case for Boxes) then I'd say it's not necessarily failing the basic functionality requirement
17:02:49 <kparal> hmm
17:03:05 <cmurf> I mean, it's a bad bug
17:03:09 <kparal> but imagine the reviewer trying boxes with the same iso he/she downloaded to test F25
17:03:20 <cmurf> sure
17:03:57 <cmurf> well I'm OK with +1 and seeing what the maintainer has to say about it, if they disagree with the judgement call on this
17:04:18 * kparal tests F24 guest
17:04:35 <coremodule> kparal, This works fine until the Boxes window is resized?
17:05:04 <cmurf> Good question
17:05:27 <cmurf> Although, resizing the window is a basic function :-)
17:05:34 <kparal> coremodule: it seems. however, for low resolution displays, you have it always resized (downsized). and for bigger displayes, you often make it larger, because the same window works as a VM window and as the overview "VM list" window
17:05:56 <kparal> cmurf: seems to work OK with F24 guest
17:06:11 <cmurf> OK I've hit this also
17:06:30 <coremodule> Sure. So what if you set the size of the window and it goes to black and you restart Boxes with the resized window, will it display?
17:07:06 <kparal> when you close boxes, it remembers the last window size
17:07:19 <kparal> I think that maybe after reboot you get back the default window size
17:07:26 <kparal> but definitely not on close/reopen
17:07:51 * kparal finished testing of 1366775
17:07:56 <cmurf> We could say something like "this seems like a blocker but some images (F24) work while others don't (F25), needinfo from maintainer"
17:08:15 <coremodule> Right, so when you close and reopend Boxes, and the resized box comes back up (the one that previously caused the screen to go black), is the screen black or does it display then?
17:09:07 <kparal> coremodule: it's easier to resize the window a few times which causes the screen to update and _often_ fix itself (sometimes not)
17:09:24 <kparal> if you close boxes, I have no idea what happens, if it kills the machines, or suspends them or what
17:10:06 <kparal> they're trying to be too clever without actually telling you what's happening
17:10:25 * kparal trying
17:10:49 <coremodule> I'm wondering if it has to do with Boxes being unable to display the VM in a certain-sized window, or if it will display the VM in any sized window providing Boxes has been restarted.
17:10:54 <coremodule> kparal, Gotcha.
17:11:44 <kparal> coremodule: still black
17:12:00 <kparal> and it suspends and resumes the machine, not like virt-manager which keeps them running
17:12:16 <coremodule> kparal, Hmm...
17:12:58 <kparal> I'd say this is +1, default functionality
17:13:29 <kparal> what do you expect from a default VM application in Fedora Workstation if not running a VM of the same distro release?
17:14:05 <kparal> this is a final blocker proposal, so it's not like we would ask boxes developers to support unstable fedora versions
17:14:20 <cmurf> sure
17:14:32 <coremodule> I agree, this does seem like a violation of 'basic functionality', even though it seems the actual use-case is small.
17:14:38 <kparal> if it can't virtualize our own release, it seems it should not be in the default installation
17:14:42 <cmurf> good point, so I'm +1 and if the maintainer disagrees I'm sure we'll hear about it
17:14:47 <kparal> (which might happen, from the comments I've seen)
17:15:04 <coremodule> +1 here.
17:15:44 <kparal> +1
17:16:31 <coremodule> proposed #agreed 1375504 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker as it seems to violate the following criteria:
17:16:31 <coremodule> "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
17:16:31 <coremodule> We will see if there is any backlash from the maintainer after classification and go from there.
17:16:35 <coremodule> Whoops.
17:16:47 <coremodule> proposed #agreed 1375504 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker as it seems to violate the following criteria: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." We will see if there is any backlash from the maintainer after cl
17:16:47 <coremodule> assification and go from
17:16:58 <kparal> cut the first sentence
17:17:12 <kparal> start with "Violates"
17:17:27 <kparal> and end with "for F25 guest VMs"
17:17:40 <coremodule> proposed #agreed 1375504 - AcceptedBlocker (Final) - Violates the following Blocker criteria: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." We will see if there is any backlash from the maintainer after classification and go from there.
17:18:28 <kparal> ack
17:18:55 <cmurf> ack
17:19:23 <kparal> coremodule: we could continue with  	1266484, since it's directly related
17:19:36 <kparal> or go back to 1366775
17:19:51 <coremodule> kparal, Sure, we'll move on to 1266484 and then return to the CUPS one.
17:19:57 <coremodule> Any more acks?
17:20:05 <kparal> pschindl: poke
17:20:56 <pschindl> ack
17:21:04 <coremodule> #agreed 1375504 - AcceptedBlocker (Final) - Violates the following Blocker criteria: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." We will see if there is any backlash from the maintainer after classification and go from there.
17:21:22 <coremodule> #info Moving to 1266484 as it's directly related to this bug.
17:21:30 <coremodule> #topic (1266484) spice + fedora wayland VM + spice-vdagent + resize-guest == flickering display
17:21:35 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1266484
17:21:40 <coremodule> #info Proposed Blocker, xorg-x11-drv-qxl, NEW
17:22:02 <kparal> so, this is the other half of the boxes mess
17:22:21 <kparal> if they fix wayland to start properly in F25 guests, we will get this bug instead of the previous one
17:22:57 <kparal> in short, the display is flickering every second, and it also cancels gnome-overview each time (every second)
17:23:06 <cmurf> oh dear
17:23:08 <kparal> so you can't even start anything from the overview
17:23:52 <pschindl> cool :)
17:24:05 <pschindl> so another tentative blocker?
17:24:06 <kparal> however, currently this does not happen, because X11 is used instead (which is an error)
17:24:24 <kparal> pschindl: yeah, I'd use my newly invented and coined tentative blocker :)
17:25:04 <cmurf> tblocker
17:25:17 <kparal> :)
17:25:33 <cmurf> +1 blocker
17:25:38 <kparal> +1
17:26:00 <cmurf> mainly based on 41 and 42 work around
17:26:07 <kparal> I'd again use "default app functionality" criterion
17:26:10 <cmurf> yes
17:26:26 <coremodule> Yeah, I'm +1, no tentative.
17:26:45 <pschindl> +1
17:26:47 <kparal> coremodule: well I think we can't really accepted it as a blocker because it's currently not happening
17:27:05 <kparal> 1375504 is currently happening
17:27:19 <coremodule> But the idea is to make it happen. Or switch to Wayland and as a result, make this happen.
17:27:36 <kparal> yes, but they might fail to actually fix wayland startup
17:27:39 <kparal> or decide not to
17:28:06 <kparal> I'm sure they intended to run F25 guest with wayland in boxes, but if it runs with X11, it's not really a problem per se
17:28:12 <kparal> it's just suboptimal
17:28:21 <coremodule> Well let's classify this and expedite their decision.
17:28:55 <kparal> I'd say "if F25 guests in boxes start using wayland again and this starts happening, we'll accept it as a blocker"
17:28:55 <cmurf> This is a gray area for sure, it's a unique situation.
17:28:58 <kparal> or something like that
17:30:12 <cmurf> If a work around exists, I'd be Ok not blocking release if it works on X but not on Wayland (either the host or the guest)
17:30:22 <cmurf> but it has to work on either X or Wayland
17:31:12 <kparal> right
17:31:28 <cmurf> If the WG wants to say, if you're going to use Boxes then you need to use X on the host, fine, that's their call.
17:31:31 <kparal> I mean if it fails to initialize wayland and falls back to X11 and it displays fine, there's no problem
17:31:47 <cmurf> that too
17:32:20 <coremodule> proposed #agreed 1266484 - punt (delay decision) - Currently F25 uses X11, but should the switch to Wayland be made in the future, this will inhibit the user from launching applications. If Wayland is confirmed, we will classify this bug as an AcceptedBlocker, but until then we will wait on any decision.
17:32:23 <kparal> cmurf: I think this is related mainly to the guest, and not much to the host
17:32:27 <cmurf> ok
17:32:29 <cmurf> ack
17:32:40 <kparal> patch
17:32:47 <kparal> just to make it clearer
17:33:12 <kparal> proposed #agreed 1266484 - punt (delay decision) - Currently F25 uses X11 in Boxes, but should the switch to Wayland be made in the future, this will inhibit the user from launching applications. If Wayland is confirmed, we will classify this bug as an AcceptedBlocker, but until then we will wait on any decision.
17:33:29 <coremodule> ack
17:33:30 <kparal> ack
17:33:42 <pschindl> ack
17:33:44 <coremodule> #agreed 1266484 - punt (delay decision) - Currently F25 uses X11 in Boxes, but should the switch to Wayland be made in the future, this will inhibit the user from launching applications. If Wayland is confirmed, we will classify this bug as an AcceptedBlocker, but until then we will wait on any decision.
17:33:54 <coremodule> Alright, let's get this CUPS issue sorted out.
17:34:04 <cmurf> acks are getting faster, must be dinner time somewhere
17:34:13 <kparal> :)
17:34:16 <cmurf> or bedtime
17:34:17 <coremodule> #info Back to 136675 to finalize on the details...
17:34:27 <coremodule> #topic (1366775) /usr/libexec/gnome-settings-daemon is hammering CPU after login tring to connect to local printing service
17:34:27 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366775
17:34:27 <coremodule> #info Proposed Blocker, cups, NEW
17:34:42 <coremodule> I am seeing this on baremetal, sure enough, full CPU usage.
17:34:44 <kparal> so I just made a clean install of Fedora-Workstation-Live-x86_64-25-20160919.n.0.iso
17:34:51 <kparal> and I can reproduce it 100%
17:35:07 <coremodule> kparal, Did you use a VM?
17:35:13 <kparal> 10-15 seconds delay during login, but 0% cpu usage
17:35:20 <kparal> which is weird and I wonder if it's the same bug
17:35:34 <kparal> coremodule: yes
17:35:41 <cmurf> with or without NAT
17:36:01 <coremodule> Great, we've got both baremetal and VM.
17:36:14 <kparal> the default, so NAT
17:36:18 <coremodule> With NAT here.
17:36:31 <cmurf> I wonder if it happens without or if that's unrelated.
17:36:46 <coremodule> I notice my machine won't go to sleep now...
17:37:00 <cmurf> ick
17:37:11 <cmurf> related or new bug?
17:37:27 <coremodule> All this aside however, I wonder if this is a real-world use-case?
17:37:29 <kparal> if gnome-settings-daemon is unresponsive, most actions won't work
17:37:42 <coremodule> cmurf, I'm not sure... I assume it's got to do with ^^ what kparal said.
17:38:09 <kparal> I'll have to dig deeper into it, because it seems weird I see 0% cpu usage - it just waits for 10-15 seconds
17:38:23 <kparal> I wonder if it's something different or not
17:38:48 <coremodule> Removing CUPS and everything related seems like something that 99.9% of people are not going to do. This bug seems to cater to that 0.01%.
17:38:54 <kparal> so I guess we should punt this and debug it more, all of us who can reproduce that
17:39:14 <cmurf> I thought removing cups isn't necessary to trigger this bug
17:39:26 <coremodule> It was for me.
17:39:37 <coremodule> kparal?
17:39:45 <kparal> I did a default install, cups is there
17:40:13 <cmurf> Yeah I think we need to isolate and determine if there's more than one bug.
17:40:34 <coremodule> Definitely seems like we've got multiple things going on here.
17:41:39 <coremodule> proposed #agreed 1366775 - punt (delay decision) - Based on information gathered during the meeting, it seems like there is a possibility of multiple bugs here. Until we can confirm that this is one, single bug, we are delaying the classification of this as a bug.
17:41:57 <coremodule> proposed #agreed 1366775 - punt (delay decision) - Based on information gathered during the meeting, it seems like there is a possibility of multiple bugs here. Until we can confirm that this is one single bug, we are delaying the classification of this as a bug.
17:42:02 <cmurf> nack "as a blocker"
17:42:22 <coremodule> proposed #agreed 1366775 - punt (delay decision) - Based on information gathered during the meeting, it seems like there is a possibility of multiple bugs here. Until we can confirm that this is one single bug, we are delaying the classification of this as a blocker.
17:42:27 <cmurf> ack
17:42:31 <kparal> ack
17:43:20 <pschindl> ack
17:43:31 <coremodule> #agreed 1366775 - punt (delay decision) - Based on information gathered during the meeting, it seems like there is a possibility of multiple bugs here. Until we can confirm that this is one single bug, we are delaying the classification of this as a blocker.
17:43:39 <coremodule> Moving on!
17:43:40 <coremodule> #topic (1372300) GDM does not use the keyboard layout which is selected
17:43:40 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1372300
17:43:41 <coremodule> #info Proposed Blocker, mutter, NEW
17:44:16 <kparal> so, it seems gdm messes up keyboard indicator if you change your system locale after installation
17:44:34 <kparal> I first thought it's messed up directly after installation, but that doesn't seem to be the case
17:44:43 <kparal> only if you change the locale afterwards
17:44:55 <kparal> locale+keymap, or maybe just locale, not sure
17:45:51 <cmurf> how ugly is the work around?
17:46:10 <kparal> switch the keymap twice each time before login
17:46:19 <kparal> if you happen to know about it
17:46:30 <cmurf> ick
17:46:30 <dgilmore> kparal: that is nasty
17:46:47 <cmurf> yeah I'm +1
17:46:59 <kparal> I'm not sure if our criteria cover this though. default app functionality for gnome-control-center? a bit far fetched
17:47:15 <cmurf> why?
17:47:27 <cmurf> seems like changing language is basic except for native english speakers
17:47:31 <kparal> well changing locale is probably not the most common thing you do there
17:47:54 <kparal> cmurf: yeah, but they would probably have selected it already in anaconda
17:48:02 <cmurf> grumble maybe
17:48:39 <cmurf> but it's a multi user system, so user 2 might prefer spanish or whatever
17:48:50 <cmurf> so it ought to work and not blow up their ability to login without weird work arounds
17:48:57 <kparal> I don't like this bug one bit, I'm just not sure whether we should block on it or not
17:49:03 <cmurf> gotcha
17:49:05 <coremodule> If a particular keyboard layout has been configured for the system, that keyboard layout must be used after logging in to a release-blocking desktop, if the user account does not have its own keyboard layout configuration for that desktop (if there is such a user/desktop-specific configuration, it must be used when that user logs in to that desktop)
17:49:09 <coremodule> How about that last part?
17:49:36 <coremodule> "it must be used when that user logs in to that desktop" - without having to change it two times.
17:49:47 <cmurf> seems convincing
17:50:18 <kparal> gnome-control-center actually changes your whole system settings, if you're the only user. which happened in this bug
17:50:25 <kparal> so this was not per-user setting
17:50:43 <kparal> but more or less could fit :)
17:50:55 <cmurf> yeah the release criterion doesn't require multiple users
17:51:48 <kparal> but all these criteria seem to only be concerned with the direct post-installation state, and not when you modify it somehow
17:51:50 <kparal> so, shrug
17:51:57 <coremodule> We could also delay on the grounds of a criteria change, but we know how successful that has been in the past... Somebody would have to spearhead the op.
17:52:56 <cmurf> is this reproducible a different way?
17:53:11 <cmurf> e.g. with live media
17:53:32 <cmurf> change the locale, unset autologin, set a password for live user, logout then login?
17:53:34 <kparal> hmm, like changing language and re-login to live media?
17:53:40 <cmurf> sure
17:53:44 <cmurf> that's basic functionality
17:53:56 <kparal> that's something that the i18n team needs for their test day
17:54:03 <cmurf> ok
17:54:05 <kparal> but I'm not sure we have it covered in our criteria either
17:54:29 <cmurf> ok well I'm fine with saying this sounds like a blocker, but we're punting for now, gather  more info
17:54:31 <kparal> and it would not hit the issue because liveuser is passwordless by default
17:54:32 <cmurf> see what can be done
17:55:00 <cmurf> I understand the technical aspect this is not basic, but from a human standpoint language is as basic as it gets.
17:55:49 <kparal> let's punt it and hopefully look more into it
17:55:58 <cmurf> +1 punt
17:57:27 <cmurf> i guess everyone's taken the corks off their bottles...
17:58:00 <coremodule> +1
17:58:05 <coremodule> +1 punt
17:58:14 <pschindl> +1 punt
17:58:24 <coremodule> proposed #agreed 1372300 - punt (delay decision) - We currently cannot find an appropriate criteria to block on, however this bug makes bilingual use of F25 unusable. We will delay the classification of this as a blocker until the criteria can be amended, we receive new info on this bug, or the bug is fixed.
17:58:47 <coremodule> proposed #agreed 1372300 - punt (delay decision) - We currently cannot find an appropriate criteria to block on, however this bug makes multilingual use of F25 unusable. We will delay the classification of this as a blocker until the criteria can be amended, we receive new info on this bug, or the bug is fixed.
17:59:02 <cmurf> hold on
17:59:13 <coremodule> Holding on.
17:59:24 <cmurf> ohok
17:59:26 <cmurf> ack
17:59:58 <kparal> ack
18:01:04 <pschindl> ack
18:01:07 <coremodule> Any more acks?
18:01:31 <kparal> ack
18:01:42 <kparal> how many more do you want? :)
18:02:01 <coremodule> Lol. ack and we'll call it good.
18:02:17 <coremodule> #agreed 1372300 - punt (delay decision) - We currently cannot find an appropriate criteria to block on, however this bug makes multilingual use of F25 unusable. We will delay the classification of this as a blocker until the criteria can be amended, we receive new info on this bug, or the bug is fixed.
18:02:32 <coremodule> #topic (1377313) mutter 3.21.92-1.fc25 prevents libreoffice from opening existing files
18:02:32 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1377313
18:02:33 <coremodule> #info Proposed Blocker, mutter, MODIFIED
18:02:41 <cmurf> egads
18:03:17 <kparal> now this is again only in u-t
18:03:18 <cmurf> yup +1
18:03:22 <cmurf> haha
18:03:25 <cmurf> ohno
18:03:28 <kparal> so again probably tenblocker
18:03:49 <kparal> (like +10 blocker) :)
18:03:51 <cmurf> +1 tblockistan
18:04:02 <kparal> but +1 in general
18:04:17 <pschindl> +1
18:04:43 <cmurf> but don't we generally just -1 karma to prevent essentially non-functional updates? that's what this does...
18:05:21 <kparal> cmurf: this is the whole gnome megaupdate
18:05:27 <cmurf> OH
18:05:29 <cmurf> well
18:05:32 <kparal> and I gave it -1 just so they notice :)
18:05:36 <cmurf> gotcha
18:05:41 <kparal> but they're fixing other blocker bugs with that
18:05:42 <kparal> so
18:05:52 <kparal> it's going to go stable, and this will need to get fixed
18:06:04 <cmurf> so it's a rebase of gnome, and this is predicting the inevitable new blockers
18:06:08 <cmurf> fine, so +1
18:06:54 <coremodule> proposed #agreed 1377313 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
18:07:02 <cmurf> ack
18:07:17 <pschindl> ack
18:07:45 <kparal> s/nominate/accept?
18:07:56 <kparal> I'd add "tentative"
18:08:03 <kparal> but ack
18:08:31 <coremodule> kparal, This is going to go stable, so may as well classify it now to avoid doing it later, right?
18:09:03 <kparal> depends on how much bureaucratic you want to be
18:09:10 <kparal> it's probably going stable :)
18:09:13 <coremodule> Hah, generally as little as possible.
18:09:20 <kparal> so ack as it is
18:09:34 <coremodule> Alright!
18:09:45 <coremodule> #agreed 1377313 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
18:09:54 <coremodule> #topic (1370222) KDE doesn't start if hostname changes during boot due to network (infamous xauth issue)
18:09:54 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370222
18:09:54 <coremodule> #info Proposed Blocker, sddm, NEW
18:10:11 <kparal> and, sigh, this is another "fun" issue
18:10:37 <cmurf> for so few blockers proposed compared to last week, yes this is a brutal review
18:10:47 <kparal> what happens is that if you have a dhcp server which assigns hostnames, and boot a KDE Live, its hostname is changed during boot and then sddm (login manager) doesn't start
18:11:00 <coremodule> What does it change it to?
18:11:12 <kparal> anything that your dhcp server gives you
18:11:20 <kparal> in our case, dhcp-ip-address :)
18:11:33 <cmurf> +1 blocker
18:11:38 <kparal> we've had this issue with GNOME in the past and accepted it as a blocker
18:11:46 <cmurf> yep
18:11:48 <kparal> we don't hit it with GNOME now, since it uses wayland
18:12:05 <pschindl> +1
18:12:05 <kparal> but KDE is blocking and same standards should apply
18:12:23 <kparal> I proposed another ugly workaround for spin-kickstarts
18:12:37 <kparal> because I don't expect xauth to finally fix this
18:12:43 <kparal> +1
18:12:47 <nb> +1
18:13:42 <coremodule> Here's a nice simple one:
18:13:43 <coremodule> proposed #agreed 1370222 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop."
18:13:50 <nb> ack
18:14:26 <kparal> ack
18:14:28 <pschindl> ack
18:14:44 <coremodule> #agreed 1370222 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop."
18:14:51 <coremodule> #topic (1375156) SELinux cripples storaged
18:14:51 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1375156
18:14:51 <coremodule> #info Proposed Blocker, selinux-policy, VERIFIED
18:15:28 <kparal> I think this is tightly related to the KDE login hang
18:15:31 <kparal> again udisks
18:15:53 <kparal> however, I haven't actually seen this particular issue, I just verified that it's no longer present today
18:16:27 <kparal> the nomination seems to come from https://bugzilla.redhat.com/show_bug.cgi?id=1374334
18:16:34 <cmurf> +1 blocker in case this one comes back for another round
18:16:43 <cmurf> it kinda needs to work
18:16:44 <kparal> which broke gnome-disks, which I've actually seen and reproduced
18:16:46 <kparal> so +1 from me
18:17:45 <coremodule> On SELinux denial critiera?
18:18:03 <kparal> I guess you can use default app functionality for gnome-disks
18:18:26 <kparal> or let me find a better one
18:18:39 <kparal> "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present. "
18:18:43 <kparal> https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria#System_services
18:18:45 <kparal> that's much better
18:18:46 <pschindl> +1
18:18:57 <nb> +1
18:19:46 <coremodule> proposed #agreed 1370222 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."
18:20:15 <nb> ack
18:20:24 <cmurf> ack
18:21:34 <kparal> ack
18:22:00 <cmurf> we're done
18:22:02 <cmurf> yay!
18:22:15 <coremodule> Whew!
18:22:19 <coremodule> #info Open Floor
18:22:29 <coremodule> Anything we need to discuss here?
18:22:33 <coremodule> Whoops.
18:22:42 <coremodule> #undo
18:22:42 <zodbot> Removing item from minutes: INFO by coremodule at 18:22:19 : Open Floor
18:22:45 <coremodule> #agreed 1370222 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."
18:22:53 <pschindl> and there is a wrong number of bug
18:22:54 <coremodule> #info Open Floor
18:22:55 <cmurf> I've got nothing that can't wait another day.
18:23:04 <coremodule> #undo
18:23:04 <zodbot> Removing item from minutes: INFO by coremodule at 18:22:54 : Open Floor
18:23:25 <kparal> yay, it's over
18:23:30 <kparal> nothing here
18:23:36 <coremodule> #agreed 1375156- AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."
18:23:44 <coremodule> Thanks pschindl .
18:23:47 <pschindl> wait a moment
18:23:56 <pschindl> you left there the wrong agreed
18:24:06 <coremodule> #undo
18:24:07 <zodbot> Removing item from minutes: AGREED by coremodule at 18:23:36 : 1375156- AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."
18:24:15 <pschindl> and one more time
18:24:15 <coremodule> #undo
18:24:15 <zodbot> Removing item from minutes: AGREED by coremodule at 18:22:45 : 1370222 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."
18:24:41 <coremodule> #agreed 1375156 - AcceptedBlocker (Final) - The decision was made to nominate this as a Final blocker: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present.
18:24:54 <pschindl> Now we can finish it :)
18:25:04 <coremodule> There we go. Got ahead of myself. Thanks pschindl.
18:25:11 <coremodule> #info Open Floor
18:25:34 <coremodule> #info Next meeting time - 16:00 UTC on 2016-09-26
18:26:09 <coremodule> Starting countdown to endmeeting:
18:26:11 <coremodule> 5...
18:26:15 <pschindl> Thanks coremodule for running this meeting.
18:26:17 <coremodule> 4...
18:26:30 <coremodule> Glad to do it!
18:26:31 <coremodule> 3...
18:26:43 <coremodule> Thanks for the participation, it wouldn't happen without it!
18:26:44 <coremodule> 2...
18:26:58 <coremodule> 1...
18:27:05 <coremodule> Thanks everyone.
18:27:11 <coremodule> #endmeeting