16:00:31 <adamw> #startmeeting F25-blocker-review
16:00:31 <adamw> #meetingname F25-blocker-review
16:00:31 <adamw> #topic Roll Call
16:00:31 <zodbot> Meeting started Mon Aug 22 16:00:31 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:31 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:31 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:38 <adamw> ahoyhoy folks, who's around for blocker review fun?
16:01:22 * pwhalen is here
16:01:27 * coremodule is here.
16:01:39 * satellit listening
16:01:41 * kparal is here
16:01:43 * brunowolff is here
16:01:46 * Southern_Gentlem 
16:01:52 <adamw> dgilmore: nirik: pingle
16:02:08 * mboddu is here
16:02:09 <adamw> #chair pwhalen brunowolff
16:02:09 <zodbot> Current chairs: adamw brunowolff pwhalen
16:02:41 * pschindl is here
16:02:56 <jforbes> .hello jforbes
16:03:02 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:03:15 <dgilmore> hola adamw
16:03:34 <adamw> alrighty, nice turnout - thanks everyone
16:03:46 <adamw> #topic Introduction
16:03:46 <adamw> Why are we here?
16:03:46 <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:03:46 <adamw> #info We'll be following the process outlined at:
16:03:47 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:48 <adamw> #info The bugs up for review today are available at:
16:03:49 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:51 <adamw> #info The criteria for release blocking bugs can be found at:
16:03:53 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
16:03:55 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
16:03:58 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
16:04:10 <adamw> for Alpha, we have:
16:04:10 <adamw> #info 3 Proposed Blockers
16:04:10 <adamw> #info 1 Accepted Blockers
16:04:10 <adamw> #info 3 Proposed Freeze Exceptions
16:04:11 <adamw> #info 3 Accepted Freeze Exceptions
16:04:17 <brunowolff> How much do we care about a kernel bug that prevents input on a few laptops?
16:04:31 <kparal> brunowolff: enough to hear about it
16:04:33 <adamw> #info also 1 Proposed Blocker (Beta) and 6 Proposed Blockers (Final)
16:04:35 <brunowolff> There is an upstream fix, but it isan't in Linus' tree yet and probably won't be in alpha.
16:04:52 <adamw> brunowolff: is there an RHBZ?
16:05:42 <adamw> who wants to secretarialize?
16:05:44 <brunowolff> .bug 1366224
16:05:44 <zodbot> brunowolff: Bug 1366224 – Recent 4.8 kernels do not read keyboard for entering disk password - https://bugzilla.redhat.com/1366224
16:05:44 <brunowolff> bug 1366224
16:05:44 <brunowolff> https://bugzilla.redhat.com/show_bug.cgi?id=1366224
16:05:46 <adamw> don't all shout at once
16:05:56 <brunowolff> I can't remember the zodbot command to show bugs.
16:05:58 <adamw> brunowolff: i'd suggest just throw a blocker or FE nomination at it and we'll include it at the relevant point
16:06:04 <coremodule> I'll act as secretary.
16:06:13 <brunowolff> OK, I'll do that.
16:06:17 <adamw> #info coremodule will secretarialize
16:06:41 <adamw> #info starting with Alpha proposed blockers...
16:06:43 <adamw> #topic (1367321) system reboots 1 second after selecting a kernel in grub
16:06:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1367321
16:06:43 <adamw> #info Proposed Blocker, kernel, VERIFIED
16:06:59 <adamw> oh yeah, so this one basically doesn't need discussing, as the kernel that fixes it is going stable (I just sent the request)
16:07:40 <adamw> #info testing has confirmed this is fixed by 4.8.0-0.rc2.git3.1 which is now being pushed to stable, no action is needed
16:08:05 <adamw> #topic (1315541) fsck.ext4 discard sometimes fails when run in Koji (results in live image compose failure)
16:08:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1315541
16:08:05 <adamw> #info Proposed Blocker, lorax, ASSIGNED
16:08:12 <adamw> ooo, so, this one...*rubs hands*
16:08:21 <jforbes> woohoo
16:08:28 <kparal> thumbs up
16:08:37 <cmurf> oh ok that fixes another bug also maybe
16:08:37 <cmurf> testing that now
16:08:41 <adamw> so i did some digging into this over the weekend, cmurf poked around also
16:08:43 <striker> any ipa/realm/sssd things still to be tested?
16:09:02 <adamw> striker: the bot took care of most of it, the 'enrol via cockpit' test needs some screenshot updates which i'll get to later
16:09:09 <adamw> things are basically working now though
16:09:18 <adamw> (that was about freeipa)
16:09:47 <adamw> so, on this bug: to cut a long story short, basically, i poked into what the problematic mounts actually *are* in the live image compose environment and there's some wacky stuff going on there
16:10:12 <cmurf> the time stamps in /dev/ are really weird compared to either a VM or baremetal machine
16:10:16 <striker> awesome
16:10:16 <adamw> mock bind mounts the builder's /dev into the mock chroot (but not recursively, so submounts - like the builder's /dev/shm - are not bind mounted)
16:11:06 <adamw> livemedia-creator creates a disk image file and mounts it at /mnt/sysimage , then anaconda bind mounts the mock chroot's /dev (which is itself a bind mount of the builder's /dev) as /mnt/sysimage/dev , then mounts a tmpfs on top of *that* as /mnt/sysimage/dev/shm
16:12:01 <adamw> note that if we have multiple image compose tasks running on a builder at once, they're all basically doing a nested bind mount of the builder's /dev and trying to mount a tmpfs on top of it
16:12:46 <adamw> so my suggestion is that this is quite likely to be somehow involved in the issue, and we should try tweaking koji so that live media creation tasks *don't* bind mount the builder's /dev in this way, and see if it improves things
16:12:52 <cmurf> yes
16:12:54 * dgilmore is working on making koji not bind mount /dev into the chroot as it was never supposed to
16:13:22 <dgilmore> I went to a lot of effort to make sure mock had what we need
16:13:24 <adamw> dgilmore: so i figured just for testing purposes it should be easy enough just to copy the function down to the LiveMediaTask class and change the bind_dirs definition
16:13:47 <adamw> dgilmore: for a final fix i was thinking bind_dirs should be a class attribute and the function should just read self.bind_dirs or something like that
16:13:59 <adamw> so the classes all use the same function, but a class can say 'i don't want any bind_dirs'
16:13:59 <cmurf> in effect i think there are multiple dev/shm's and it's not clear the right one for each environment gets umounted because the logs show dev/shm gets umounted successfully but then later it won't umount because it's busy, etc.
16:14:00 <adamw> anyhoo
16:14:47 <adamw> dgilmore: so should it be possible to run a compose with the change today and see how that goes?
16:14:54 <cmurf> the /dev looks like it has some items from the builder, dates of the builder's boot time, and then it has items with very recent times; like it's a hybrid /dev
16:15:26 <adamw> cmurf: a bind mount is...live, for want of a better word; it's not a snapshot. when anything changes on the builder it will show up in the bind mounts too.
16:16:02 <adamw> anyhoo, doesn't really matter, we know what we want to change
16:16:33 <adamw> i dunno if any of this changes anyone's mind on whether the bug should be considered a 'blocker' or not, but we at least have a possibility for fixing it.
16:17:52 <dgilmore> adamw: there is no need anymore at all to bind mount /dev
16:18:24 <cmurf> good news
16:18:36 <adamw> dgilmore: did you check with bcl? i ran a test here creating an image in a mock root without the bind mount and it ran fine and everything, but there could be subtle issues of course
16:18:38 <cmurf> i don't know though if making this a blocker helps progress the fix
16:19:00 <dgilmore> adamw: it works fine because I made sure it did
16:19:07 <adamw> cmurf: not really, the change would be to the koji code, it wouldn't need to go in packages or anything
16:19:21 <dgilmore> adamw: that koji was bind mounting /dev/ was news to me because it dhould have been removed ages ago
16:19:46 <dgilmore> adamw: we have to have a koji build to deploy on the builders
16:20:02 <dgilmore> so it does have to go in a package, but it does not need to have an update etc
16:20:05 <adamw> dgilmore: okay :) i'm just saying, the live compose process is pretty complex, it seems entirely possible that you can get to a point where everything looks good and a live image spits out and mostly works OK, but perhaps the lack of a real /dev during the compose process could have some not-immediately-visible result
16:20:13 <dgilmore> though we hopefully will have a new koji release soon
16:20:14 <adamw> dgilmore: kk
16:21:22 <adamw> so, do people want to make a definite blocker decision on this? or do you all want to be chickens and wave your hands and hope it goes away? :P
16:22:21 <cmurf> I'm a duck, not a chicken, quack quack
16:22:37 <cmurf> Since I haven't heard a compelling case for it being a blocker making this get fixed faster, I'm -1
16:22:42 <brunowolff> I don't think it is a blocker, just a high priority bug.
16:22:48 <adamw> wait, chickens don't have hands
16:23:25 <jforbes> just tasty, tasty wings
16:23:34 <Southern_Gentlem> -1 blocker +1 infra bug
16:23:36 * satellit thanks for the detective work on this
16:23:37 <adamw> i'm still -1 on strict principles, but as i mentioned i also believe releng has the power to say 'we're not doing any composes till this is fixed' without the bug being a blocker per the blocker process.
16:24:02 <cmurf> yeah I agree with that logic
16:24:20 <dgilmore> I think it is a blocker
16:24:38 <adamw> basically i'm hoping it goes away, and that's why i spent half my goddamn saturday figuring this crap out :P
16:24:52 <adamw> so we're at -3 / +1
16:24:54 <dgilmore> if we can not compose release blocking images, we play compose roulette and thats just not good for anyone
16:24:55 <Southern_Gentlem> (and you loved it )
16:25:19 <kparal> if this is not a rare issue but a frequent one, I'm +1 blocker
16:25:20 * satellit hurts the non blocking spins the most...
16:25:23 <brunowolff> They have their own freeze exception process and switching to use something from updates-testing on infra is something they can do separate from what is in the compose.
16:25:26 <pwhalen> dgilmore, i agree with that as well, +1
16:25:32 <cmurf> Southern_Gentlem: not so sure of that, adamw was getting a bit testy...
16:25:41 <adamw> kparal: it happens to at least *one* image on just about every compose, i think
16:25:51 <dgilmore> kparal: every compose at least 1 if not more fail
16:25:52 <kparal> in that case +1
16:26:01 <adamw> kparal: but not always a blocking one; it almost never seems to hit workstation for some reason, it relatively often hits kde
16:26:17 <pschindl> +1
16:26:45 <cmurf> and kde is release blocking so...
16:26:47 <adamw> (we still don't know why it affects some images more than others, though i'm gonna guess it's to do with whether the packages in the compose touch /dev/shm or something)
16:26:55 <cmurf> in effect the bug often blocks itself
16:27:02 <kparal> infra and qa tools need to have some reasonable level of stability, otherwise everything else falls down. it makes sense to block on this
16:27:11 <adamw> so that'
16:27:15 <adamw> so that's +3/-3 ?
16:27:17 <kparal> *and releng
16:27:35 <cmurf> adamw: it may be the composes are issued non-randomly and it just so happens this affects the outcome
16:27:48 <Southern_Gentlem> ok since dgilmore says its a blocker +1
16:27:56 <brunowolff> So if we randomly got a good compose of all images we still wouldn't do a release if the bug is still there? That seems wrong.
16:28:15 * satellit not voting as I am biased..
16:28:25 <adamw> brunowolff: as it stands, we just fire composes until we get one with kde and workstation in it, then we ship that
16:28:34 <adamw> and whichever non-blocking images failed...tough luck to them
16:28:40 <cmurf> brunowolff: well the issue is if it's a blocker even if we do get composes that all work, we're now blocking release
16:28:53 <adamw> that's what we've done for every milestone affected by the bug (which is i think all the f24 ones)
16:29:01 <cmurf> since february
16:29:21 * dgilmore does not want to have mboddu or himself doing compose after compose hoping to get the release blocking images built
16:29:46 <dgilmore> adamw: does not mean we should continue to do so
16:29:58 <adamw> welp, we're at a bit of a deadlock
16:30:10 <cmurf> we need someone else to vote
16:30:14 <adamw> so instead of escalating pointlessly, i'm gonna suggest we put on our chicken wings and punt this
16:30:35 <adamw> in the hope that my theory's right...because if it is, we can have this fixed very quickly.
16:30:37 <Southern_Gentlem> 4-2
16:30:44 <adamw> sound ok?
16:30:49 <brunowolff> I agree there is a problem that deserves a lot of resources to solve, I just don't think blocker is the correct terminology to use for the problem.
16:31:06 <cmurf> oh he's right it's +4/-3
16:31:29 <cmurf> Southern_Gentlem voted +1 when it was +3/-3
16:31:36 <Southern_Gentlem> cmurf,  i was one of the -1 before
16:31:41 <cmurf> OH
16:31:45 <cmurf> so it's +4/-2
16:31:55 <adamw> right
16:31:55 <Southern_Gentlem> thats what i was saying
16:32:01 <cmurf> ok so it blocks
16:32:11 <adamw> meh, we usually go for a clearer cut vote
16:32:16 <adamw> which is why i'm proposing to punt
16:32:29 <brunowolff> I need to head off for a while. I think the needed info is in the bug I added as a FE. I don't really need to be here if you discuss it.
16:32:33 <cmurf> haha what?
16:32:51 <adamw> brunowolff: roger, thanks
16:33:01 <adamw> cmurf: we usually get a consensus or at least a large majority on votes
16:33:08 <cmurf> super majorities?
16:33:23 <adamw> whenever it's less than, like, an 80% majority i try to get better consensus somehow or fudge
16:33:37 <adamw> we've never actually agreed a concrete rule for the voting, so it's all kinda mushy
16:33:51 <cmurf> oh my dear sweet potatoes
16:34:01 <cmurf> we've turned into the U.S. senate
16:34:09 <adamw> i kinda like it this way as it forces people to agree :P
16:34:24 <cmurf> i dunno about that
16:34:34 <adamw> otherwise i can just make my vote a +1 and we can take it as a blocker, i guess. and suffer the wrath of the board when we can't fix it.
16:34:46 <cmurf> dgilmore: just do a releng work stoppage on account that this is a crap bug and i'll run interference ;-P
16:34:50 <adamw> proposed #agreed 1315541 - AcceptedBlocker - releng made us do it
16:34:54 <adamw> no? :P
16:35:01 <cmurf> (that's a bill the cat wink and tongue)
16:35:06 <kparal> :D
16:35:08 <dgilmore> cmurf: well scratch build is underway
16:35:17 <dgilmore> ill do some testing in stage
16:35:25 <kparal> ack
16:35:30 <Southern_Gentlem> ack
16:35:31 <cmurf> ack
16:35:38 <dgilmore> ack
16:35:47 <mboddu> ack
16:35:55 <pwhalen> ack
16:36:08 <adamw> haha, that was a joke
16:36:11 * adamw tries a better one
16:36:14 <cmurf> we're all playing along
16:36:52 <pschindl> ack
16:37:04 <kparal> quack
16:37:22 <cmurf> look at the concensus we get with "releng made us do it" that's the largest number of acks I've seen in a year
16:37:23 <cmurf> or more
16:37:30 <adamw> proposed #agreed 1315541 - AcceptedBlocker - this has been happening long enough and affects KDE often enough that we are now willing to take it as a blocker as a conditional violation of "All release-blocking images must boot in their supported configurations." (the criterion which implicitly covers 'the release-blocking images must actually exist')
16:37:38 <adamw> cmurf: :P
16:37:44 <Southern_Gentlem> ack
16:38:00 <dgilmore> ack
16:38:02 <cmurf> ack
16:38:14 <pschindl> previous was better but ack
16:38:17 <adamw> pschindl: :P
16:38:21 <cmurf> haha pschindl
16:38:32 <cmurf> i liked the previous one better also
16:38:33 <pwhalen> ack
16:38:36 <adamw> #agreed 1315541 - AcceptedBlocker - this has been happening long enough and affects KDE often enough that we are now willing to take it as a blocker as a conditional violation of "All release-blocking images must boot in their supported configurations", the criterion which implicitly covers 'the release-blocking images must actually exist'. AKA: releng made us do it
16:38:44 <adamw> there, now everyone's happy
16:38:52 <cmurf> awesome
16:38:56 <Southern_Gentlem> next
16:39:03 <adamw> #topic (1368743) size=10 causes arm composers to hang
16:39:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1368743
16:39:04 <adamw> #info Proposed Blocker, lorax, NEW
16:39:41 <dgilmore> +1 blocker
16:39:43 <adamw> this doesn't actually need review, since it prevents compose of release-blocking images
16:39:46 <Southern_Gentlem> is arm a blocking arch?
16:39:49 <pwhalen> +1
16:40:07 <adamw> #info this actually meets the 'automatic blocker' requirements and can simply be marked as AcceptedBlocker (it entirely prevents compose of two release-blocking images - the ARM ones)
16:40:13 <cmurf> +1 blocker
16:40:19 <cmurf> yeah exactly
16:40:29 <adamw> Southern_Gentlem: yeah
16:40:30 <dgilmore> Southern_Gentlem: it is
16:40:32 <Southern_Gentlem> +1
16:40:41 <mboddu> +1 blocker
16:40:49 <adamw> it's fine, we don't need votes
16:40:50 <adamw> moving on
16:41:01 <adamw> #info moving to the proposed Alpha freeze exceptions
16:41:10 <adamw> #topic (1200901) invisible mouse cursor in wayland login-screen when in VM (qxl makes cursor disappear as soon as drmModeSetCrtc is called)
16:41:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1200901
16:41:11 <adamw> #info Proposed Freeze Exceptions, kernel, POST
16:41:21 <adamw> yeah, i'm fine with an FE for this...+1
16:41:29 <kparal> +1 FE
16:41:38 <Southern_Gentlem> +1`fe
16:41:39 <satellit> +1 FE
16:41:40 <kparal> the patch has been in use in older releases, should be safe
16:41:41 <adamw> oh, and actually it should be in the kernel we're pushing stable anyhow
16:41:46 <cmurf> the newer kernel being pushed to stable will fix this
16:41:47 <adamw> but no reason not to grant it an explict FE
16:41:49 <cmurf> i just ested it
16:41:50 <pwhalen> +1 FE
16:41:58 <cmurf> +1 FE
16:42:07 <adamw> proposed #agreed 1200901 - AcceptedFreezeException (Alpha) - this is an annoying bug and affects live images, so cannot be fixed with an update
16:42:14 <dgilmore> there is abouyt the same bug on arm
16:42:37 <dgilmore> ack
16:42:41 <Southern_Gentlem> ack
16:42:49 <cmurf> ack
16:42:53 <coremodule> ack
16:42:53 <pwhalen> ack
16:42:57 <mboddu> ack
16:43:00 <adamw> #agreed 1200901 - AcceptedFreezeException (Alpha) - this is an annoying bug and affects live images, so cannot be fixed with an update
16:43:09 <adamw> #topic (1366224) Recent 4.8 kernels do not read keyboard for entering disk password
16:43:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366224
16:43:09 <adamw> #info Proposed Freeze Exceptions, kernel, NEW
16:43:15 <adamw> this is the one brunowolff added, i believe
16:43:27 * jforbes notes this is pretty much academic since the fix is included in the kernels that have other accepted FEs
16:43:47 <Southern_Gentlem> +1fe
16:45:25 <adamw> jforbes: are you sure? bruno says "The patch is now in Dmitry Torokhov's tree, but didn't make rc3"
16:45:39 <jforbes> For this one, the patch is simple, but not upstream yet, and not included in the rc3 builds. Even if I do another build this evening, it would be morning before it could be tested and filed
16:45:50 <jforbes> adamw: no, my earlier comment was on the qxl issue
16:45:51 <adamw> ah, you were one bug behind
16:45:53 <adamw> gotcha
16:46:08 <adamw> jforbes: thanks for the timeline - still, no harm to grant it an FE in case we slip again or do a late RC
16:46:30 <adamw> +1fe - we don't really have any indication how much hardware is affected, i don't think, but it's obviously a bad bug if you *are* affected and the fix looks pretty safe to me
16:46:39 <jforbes> adamw: yeah, I am not opposed to it. I reviewed the patch, no reason not to put it into the next build
16:47:02 <pwhalen> +1 FE
16:47:28 <jforbes> well, it's not just the hardware, seems it is a combination of hardware and luks.
16:48:01 <jforbes> Either way, FE is fine, as given a chance, I always want the newest kernel in a release
16:48:06 <adamw> jforbes: isn't it just that you only actually need the keyboard during early boot if you have encrypted partitions?
16:48:18 <jforbes> adamw: right
16:48:26 <adamw> so the bug is *there* still, just not as important...
16:48:28 <adamw> aanyhoo
16:48:35 <adamw> that's +4 if we count jforbes
16:48:45 <cmurf> +1FE
16:49:07 <adamw> proposed #agreed 1366224 - AcceptedFreezeException - we're not sure how much hardware this affects but it's serious enough and the fix is small enough that we're fine with an FE
16:49:31 <Southern_Gentlem> ack
16:49:59 <cmurf> ackbar
16:50:00 <coremodule> ack
16:50:30 <pwhalen> ack
16:50:46 <adamw> #agreed 1366224 - AcceptedFreezeException - we're not sure how much hardware this affects but it's serious enough and the fix is small enough that we're fine with an FE
16:51:09 <adamw> #topic (1367321) system reboots 1 second after selecting a kernel in grub
16:51:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1367321
16:51:10 <adamw> #info Proposed Freeze Exceptions, kernel, VERIFIED
16:51:23 <adamw> so as mentioned earlier this should already be fixed by the kernel being pushed stable
16:51:31 <adamw> but i think we can wave a +1 stamp at it just to make things nice and official
16:51:37 <adamw> +1 FE, fixing boot fails is good
16:51:49 <pwhalen> +1 FE
16:52:11 <pschindl> +1 FE
16:52:14 <adamw> proposed #agreed 1367321 - AcceptedFreezeException (Alpha) - boot fails obviously are bad and cannot be fixed fully with updates, so fixing this is a good idea
16:52:16 <satellit> + 1 FE
16:52:19 <dgilmore> ack
16:52:27 <kparal> +1 FE
16:52:34 <coremodule> ack
16:53:01 <pwhalen> ack
16:53:04 <kparal> ack
16:53:09 <adamw> #agreed 1367321 - AcceptedFreezeException (Alpha) - boot fails obviously are bad and cannot be fixed fully with updates, so fixing this is a good idea
16:53:15 <adamw> #topic (1368574) Needs rebuild against latest PHP, does not currently build
16:53:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1368574
16:53:15 <adamw> #info Proposed Freeze Exceptions, maniadrive, NEW
16:53:41 <adamw> this was preventing the games spin composing; they've now taken it out of the kickstart temporarily, but i'm still fine with giving maniadrive an FE so if they can fix it they can put it back in
16:53:47 <adamw> wouldn't affect any other image
16:54:01 <dgilmore> +1 FE
16:54:02 <kparal> +1 FE
16:54:02 <pwhalen> +1 FE
16:54:14 <mboddu> +FE
16:54:17 <coremodule> +1 FE
16:54:27 <mboddu> +1 FE
16:55:35 <adamw> proposed #agreed 1368574 - AcceptedFreezeException (Alpha) - games spin would like to have this back in if it can be fixed, does not affect any other images
16:55:52 <kparal> ack
16:55:54 <pwhalen> ack
16:56:19 <coremodule> ack
16:56:37 <Southern_Gentlem> ack
16:56:53 <mboddu> ack
16:58:32 <adamw> #agreed 1368574 - AcceptedFreezeException (Alpha) - games spin would like to have this back in if it can be fixed, does not affect any other images
16:58:33 <satellit> ack
16:58:39 <dgilmore> ack
16:59:17 <Southern_Gentlem> ack
16:59:26 <adamw> OK, that's all the Alpha proposals
16:59:31 <adamw> let's do accepted Alpha blockers next
16:59:37 <adamw> #info moving onto accepted Alpha blockers
16:59:43 <adamw> there's just one:
16:59:44 <adamw> #topic (1365661) Cloud images fail to compose from 20160809.n.0
16:59:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1365661
16:59:44 <adamw> #info Accepted Blocker, distribution, NEW
16:59:57 <adamw> dgilmore: what did you think of my theory about this one, that it's the kernel?
17:00:27 <dgilmore> adamw: had not seen that
17:00:35 <dgilmore> adamw: but it is entirely possible
17:00:58 <adamw> dgilmore: i didn't identify a specific kernel issue or anything, but just from the timings of when the composes started failing and when they started working again on rawhide it seems plausible
17:01:02 <dgilmore> adamw: pushing a new kernel stable will test it
17:01:16 <dgilmore> yep
17:01:19 <adamw> right
17:01:32 <adamw> so if we get that stable push i requested done before you fire the next compose we can test two birds with one stone
17:01:39 <adamw> the /dev thing and this
17:02:39 <dgilmore> sure
17:02:43 <adamw> #info an updated kernel will soon be pushed stable for f25 (to fix other FE issues), so the first compose run after that push will test my theory that a new kernel will fix this
17:02:55 <adamw> i'll mark the bug as ON_QA to denote that, i guess
17:04:56 * dgilmore updated koji on stg builders
17:05:21 <adamw> awesome
17:05:30 <adamw> alright, let's knock off the beta and final proposed blockers if we can
17:05:35 <adamw> #info moving on to Beta proposed blockers
17:05:54 <adamw> #topic (1366793) Nothing obsoletes retired dnf-langpacks packages, breaks upgrade from Fedora 23 to 25+
17:05:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366793
17:05:54 <adamw> #info Proposed Blocker, dnf, ASSIGNED
17:06:00 <cmurf> there is one and it's an obvious +1 blocker
17:07:02 <dgilmore> +1
17:07:43 <adamw> slightly open whether allowerasing is enough, but i'm fine with +1
17:09:32 <cmurf> how would graphical upgrade deal with it?
17:09:32 <adamw> any other votes?
17:09:50 <adamw> cmurf: kparal says it has something similar to allowerasing (but independently implemented)
17:10:18 <kparal> cmurf: it shows a popup with "these packages need to be removed"
17:10:24 <cmurf> ahh
17:10:54 * kparal reading the fesco ticket, but not finding any concrete guidance
17:10:59 <kparal> *fpc ticket
17:12:02 <kparal> at this moment, I have no idea which approach we should take
17:13:19 <pwhalen> +1
17:14:26 <cmurf> punt
17:14:36 <cmurf> see what happens in the fpc ticket (?)
17:16:06 * adamw updating the fpc ticket
17:18:01 <adamw> so are we blockin' or puntin'?
17:18:37 * kparal shrugs
17:19:32 <adamw> eh, let's punt once at least.
17:19:32 <pwhalen> punt wfm
17:20:20 <adamw> proposed #agreed 1366793 - punt (delay decision) - it's not entirely clear whether we want to interpret the upgrade criteria to mean that all retired packages should be actively obsoleted, there is not a clear enough lead from FPC on this yet; we will delay the decision at least for a while
17:20:34 <kparal> ack
17:20:40 <coremodule> ack
17:20:43 <pwhalen> ack
17:21:50 <adamw> #agreed 1366793 - punt (delay decision) - it's not entirely clear whether we want to interpret the upgrade criteria to mean that all retired packages should be actively obsoleted, there is not a clear enough lead from FPC on this yet; we will delay the decision at least for a while
17:23:25 <adamw> #info moving on to Final blockers
17:23:30 <adamw> #topic (1342732) SELinux is preventing accounts-daemon from 'write' accesses on the directory root.
17:23:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1342732
17:23:31 <adamw> #info Proposed Blocker, accountsservice, ASSIGNED
17:23:42 <adamw> i think AVC notification got fixed in f25, right?
17:23:47 <adamw> so these should indeed be blockers again..
17:23:54 <adamw> +1
17:24:02 <pschindl> +1
17:24:21 <kparal> +1
17:24:33 <coremodule> +1
17:24:47 <adamw> proposed #agreed 1342732 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:24:56 <pwhalen> +1
17:24:58 <pwhalen> ack
17:25:36 <coremodule> ack
17:26:04 <kparal> ack
17:26:20 <adamw> #agreed 1342732 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:26:29 <adamw> #topic (1367338) gnome-maps: moving and zooming with mouse and keyboard doesn't work
17:26:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1367338
17:26:29 <adamw> #info Proposed Blocker, gnome-maps, NEW
17:27:00 <kparal> +1
17:27:04 <adamw> wonder if this is a Wayland bug?
17:27:07 <adamw> it works for me, but I'm on X
17:27:10 <adamw> did you try X?
17:27:16 <kparal> hmm
17:27:28 <coremodule> Did gnome-maps move from mapquest image data to something new?
17:27:39 <kparal> was wayland default a week back? we used the default session
17:27:48 <adamw> i think so
17:27:55 <cmurf> wayland's default for a while
17:27:57 <cmurf> months
17:28:11 <adamw> anyhoo, if it's reproducible in a clean live boot / install i'm +1
17:28:30 <kparal> we have a clean VM and a clean bare metal. didn't work on either one
17:28:35 <cmurf> works for me
17:28:39 <cmurf> and i'm on wayland
17:28:53 <kparal> I wonder if this is related to just clean installs
17:28:57 <pschindl> +1
17:29:01 <kparal> let me try a live cd in VM
17:29:43 <cmurf> oh wait i'm an idiot
17:29:45 <cmurf> hold on
17:29:53 <cmurf> wrong VM wrong version of Fedora
17:30:10 <adamw> apart from that, you got everything right? :P
17:30:26 <kparal> doesn't work for me on Live
17:30:29 <kparal> 0816
17:30:36 <kparal> wayland, it seems
17:30:44 <cmurf> does not work on Live, wayland
17:30:45 <cmurf> logging out
17:31:13 <cmurf> does not work as installed, in a VM, Wayland
17:31:22 <kparal> and X can't be used on Live because the selector is not there if the user doesn't have a password. sigh, poor our users
17:31:53 <cmurf> yeah i always though that was screwy to have the selector only at the password entry...
17:31:59 <cmurf> does not work on X
17:32:03 <cmurf> doesn't work
17:32:06 <cmurf> +1 blocker
17:32:08 <kparal> works on X for me
17:32:13 <kparal> on Live
17:32:15 <adamw> OK
17:32:22 <cmurf> not for me as installed in a VM using X
17:32:28 <cmurf> unless X isn't actually being used
17:32:37 <adamw> same here, yeah
17:32:38 <adamw> +1
17:33:21 <adamw> proposed #agreed 1367338 - AcceptedBlocker (Final) - this fails the 'basic functionality' part of "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." looks like it may be a Wayland issue, as it seems to work with X for at least two people.
17:33:27 <cmurf> yeah this is definitely an x session and it's not working
17:33:28 <adamw> meh
17:33:34 <adamw> proposed #agreed 1367338 - AcceptedBlocker (Final) - this fails the 'basic functionality' part of "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:33:37 <cmurf> ack
17:33:38 <adamw> we don't need that last bit
17:34:06 <kparal> ack
17:34:23 * satellit booting f25 wks now in wayland to test
17:34:26 <pschindl> ack
17:34:40 <adamw> #agreed 1367338 - AcceptedBlocker (Final) - this fails the 'basic functionality' part of "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:35:09 <cmurf> I have a clean F25 in VM running X now and it doesn't work.
17:35:12 <adamw> #topic (1367780) nothing happens when I try to install a local rpm file in gnome-software
17:35:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1367780
17:35:12 <adamw> #info Proposed Blocker, gnome-software, NEW
17:35:27 <cmurf> gnome-maps has been using openstreetmaps for as long as I can remember...
17:35:47 <cmurf> +1 blocker
17:35:53 <cmurf> gotta be able to install things
17:36:29 <kparal> I tested this several times, didn't work at all except for one case, when I restarted packagekitd a few times and run it in the foreground and it magically started working. but couldn't repeat that
17:36:50 <pwhalen> +1 blocker
17:37:06 <pschindl> +1
17:37:17 <kparal> I pinged hughsie and kalev about this
17:37:21 <adamw> mmmm...i'm kinda on the fence about whether this is 'basic functionality'
17:37:31 <adamw> especially to the point we need to block the release on it (as opposed to fixing it with an update)
17:37:39 <kparal> your mom doesn't use skype?
17:37:42 <kparal> mine does
17:38:02 <adamw> does she install it on live images?
17:38:05 <kparal> but better example is probably 50% of fedora users who use google chrome
17:38:21 <adamw> but i guess fair point
17:38:27 * satellit mouse and keyboard work on f25 efi boot workstation install in weather here
17:38:31 <kparal> adamw: nope, but it probably will be the first app they will try to install after a fresh system install
17:38:59 <kparal> also, rpmfusion
17:39:21 <cmurf> I think installing a local package is kinda basic isn't it?
17:39:26 <adamw> jeez you people and your logic
17:39:27 <adamw> fine
17:39:33 <kparal> ;)
17:39:47 <kparal> +1 blocker
17:39:55 <cmurf> There's what, 2 months before final?
17:40:04 <adamw> proposed #agreed 1367780 - AcceptedBlocker (Final) - we agreed that installing a local RPM constitutes 'basic functionality' for Software, thus this violates "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:40:07 <cmurf> It'll get fixed
17:40:12 <kparal> ack
17:40:14 <coremodule> ack
17:40:15 <cmurf> ack
17:40:15 <pwhalen> ack
17:40:18 <adamw> #agreed 1367780 - AcceptedBlocker (Final) - we agreed that installing a local RPM constitutes 'basic functionality' for Software, thus this violates "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:40:30 <adamw> #topic (1340611) SELinux is preventing firewalld from 'write' accesses on the directory root.
17:40:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1340611
17:40:30 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
17:40:42 <kparal> cmurf: I have a better one up my sleeve, but for that, this basic bug needs to get fixed ;)
17:41:01 <cmurf> oh that's just teasting kparal
17:41:06 <cmurf> teasing rather
17:41:16 <adamw> sure, fine, +1
17:41:19 <cmurf> pretty much +1 blocker on all the selinux bugs
17:41:23 <kparal> +1
17:41:27 <cmurf> i'm hitting them also, I get notifications for them in gnome-shell
17:41:30 <adamw> well, assuming they actually show up on all boots/installs
17:41:36 <adamw> but i trust kparal
17:41:44 <cmurf> they show up on lives and as installed in VMs
17:41:53 <coremodule> +1 blocker
17:42:06 <adamw> proposed #agreed 1340611 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:42:07 <kparal> I ran a default installation and then reporting everything that popped up
17:42:11 <kparal> *reported
17:42:20 <coremodule> ack
17:42:23 <kparal> ack
17:42:28 <cmurf> what you're saying you don't trust me? Just because I filed a bunch of selinux bugs as blockers last cycle even though they didn't trigger setroubleshooter?
17:43:00 <adamw> not *only* that. ;)
17:43:02 <cmurf> (in my defense that was an setroubleshooter bug)
17:43:29 <adamw> one more ack?
17:43:32 <cmurf> ack
17:44:02 <pschindl> ack
17:44:12 <cmurf> ok i gotta go, I'm still +1 blocker on the other two selinux bugs
17:44:18 * cmurf waves
17:44:52 <adamw> thanks....oh.
17:44:56 <adamw> #agreed 1340611 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:45:07 <adamw> #topic (1367280) SELinux is preventing systemd from 'getattr' accesses on the blk_file /run/systemd/inaccessible/blk.
17:45:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1367280
17:45:07 <adamw> #info Proposed Blocker, selinux-policy, ASSIGNED
17:45:09 <adamw> +1, sure, same
17:45:12 <kparal> +1
17:45:19 <pwhalen> +1
17:45:27 <adamw> proposed #agreed 1367280 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:45:32 <coremodule> ack
17:46:08 <pwhalen> ack
17:46:44 <pschindl> ack
17:46:49 <kparal> ack
17:47:36 <adamw> #agreed 1367280 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:47:38 <adamw> ok, one more
17:47:44 <adamw> #topic (1367292) SELinux is preventing (ostnamed) from 'mounton' accesses on the directory /dev.
17:47:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1367292
17:47:44 <adamw> #info Proposed Blocker, selinux-policy, ASSIGNED
17:47:47 <adamw> aaand one more +1`
17:47:50 <pwhalen> +1
17:47:55 <coremodule> +1
17:47:57 <adamw> proposed #agreed 1367292 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:47:59 <pwhalen> heh
17:48:00 <pwhalen> ack
17:48:04 <coremodule> ack
17:48:13 <kparal> ack
17:48:35 <adamw> #agreed 1367292 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
17:48:44 <adamw> alright, everyone put away your rubber stamp now :P
17:49:05 <kparal> ack
17:49:22 <kparal> ^H^H^H
17:51:12 <adamw> hehe
17:51:13 <adamw> alrighty
17:51:16 <adamw> #topic Open floor
17:51:19 <adamw> so I think that's everything
17:51:23 <adamw> any other business, concerns, missed bugs?
17:51:45 <kparal> nothing here
17:51:52 <satellit> i did get weather app to work in wayland install wks f25
17:52:33 <kparal> but I plan to propose https://bugzilla.redhat.com/show_bug.cgi?id=1344643 once I can test it on F25 (once the gnome-software starts installing packages)
17:52:33 * satellit efi
17:53:23 <kparal> hmm, I guess I could work around it just by using pkcon directly. will try that.
17:53:23 <adamw> kparal: for final?
17:53:26 <kparal> adamw: yeah
17:53:29 <adamw> kk
17:53:59 <coremodule> I am going to take a lunch right after we finish here, so allow an hour or two for the changes to be made to Bugzilla and show up on the blocker bugs page.
17:54:17 <adamw> .fire coremodule NOT ACCEPTABLE
17:54:17 <zodbot> adamw fires coremodule NOT ACCEPTABLE
17:54:28 <adamw> nutrition is for the weak
17:54:39 <coremodule> Hah! Consider me the weakest of the weak...
17:55:42 <adamw> alrighty, thanks for coming everyone
17:55:50 <adamw> hopefully we'll get alpha composed and shipped this week
17:55:58 * striker claps
17:56:01 * adamw sets fuse
17:57:59 <coremodule> Thanks for hosting adamw.
17:58:18 <adamw> thanks for secretarializing (srsly)
17:58:19 <adamw> #endmeeting