16:01:19 <adamw> #startmeeting F27-blocker-review
16:01:19 <zodbot> Meeting started Mon Aug 21 16:01:19 2017 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:19 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:01:20 <adamw> #meetingname F27-blocker-review
16:01:20 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:01:20 <adamw> #topic Roll Call
16:01:26 * pschindl_ is here
16:01:29 <adamw> morning folks! who's around for blocker review fun?
16:01:41 * satellit listening
16:02:14 * kparal is here
16:04:34 <adamw> the usual suspects, huh
16:05:25 * kparal admits he's suspect
16:07:47 <adamw> welp, four of us is barely a quorum, i guess we can try
16:07:55 <adamw> #chair kparal pschindl_
16:07:55 <zodbot> Current chairs: adamw kparal pschindl_
16:08:15 <adamw> #topic Introduction
16:08:15 <adamw> Why are we here?
16:08:15 <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:08:16 <adamw> #info We'll be following the process outlined at:
16:08:16 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:17 <adamw> #info The bugs up for review today are available at:
16:08:19 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:21 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:25 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Alpha_Release_Criteria
16:08:27 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria
16:08:29 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria
16:08:31 <adamw> (yes, the Alpha criteria page is still there for now)
16:08:37 <adamw> I guess we should mention that up front:
16:09:00 <adamw> #info For the Fedora 27 cycle there is no Alpha release; the first milestone is Beta. Alpha criteria are all in effect for Beta, until we change the criteria layout on the wiki.
16:09:41 <kparal> should I remove the Alpha milestones from blockerbugs app?
16:09:50 <adamw> #info 8 Proposed Blockers (Beta), 5 Proposed Blockers (Final)
16:09:54 <adamw> kparal: yeah, we should
16:09:59 <kparal> ok, I'll do it
16:10:07 <adamw> #info 3 Accepted Blockers (Beta), 1 Accepted Blocker (Final)
16:10:32 <adamw> anyone willing to secretarialize?
16:11:01 <adamw> mboddu: sgallagh: ping just in case
16:11:24 <kparal> if pschindl_ doesn't sign up I guess I can secretarialize
16:11:30 * roshi is here-ish
16:12:43 <adamw> oh hey roshi
16:13:00 <roshi> o/
16:14:03 <kparal> me it is, it seems :)
16:14:28 <adamw> sounds like it
16:14:32 <adamw> kparal: have you done it before?
16:14:39 <kparal> sure
16:14:54 <adamw> coolbeans
16:14:59 <adamw> #info kparal will secretarialize
16:15:12 <adamw> #info starting with the proposed Beta blockers
16:15:19 <adamw> #topic (1439411) AttributeError: 'LUKS' object has no attribute 'hasKey'
16:15:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1439411
16:15:19 <adamw> #info Proposed Blocker, anaconda, MODIFIED
16:15:35 <adamw> we may run across some which should be closed already, i didn't have time to weed them all
16:16:57 <kparal> +1
16:17:06 <kparal> hmm, pushed 3 months ago
16:17:10 <kparal> just close?
16:17:46 <adamw> yeah, and the encrypted install test failed with the most recent rawhide compose
16:17:51 <adamw> lemme see about f27
16:18:13 <adamw> failed on the bootloader install error, but at least got there
16:18:20 <adamw> and worked on the previous compose (there was a grub regression in the most recent one)
16:18:22 <adamw> so, looks fixed.
16:18:29 <adamw> #info current openQA test results indicate this is fixed, we will close it
16:19:07 * kparal closed it
16:19:10 <adamw> #topic (1470552) Kickstarted Fedora 26 installation always uses public repositorys
16:19:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1470552
16:19:10 <adamw> #info Proposed Blocker, anaconda, MODIFIED
16:19:15 <adamw> kparal: no, i did. you were too slow. :P
16:19:16 <kparal> no I didn't, adamw ninja'd me
16:19:24 <kparal> damn, ninja'd again
16:20:29 <adamw> hum, so we don't need to waste too much time on this one as it's getting fixed, but i'd probably be more final than beta blocker
16:20:37 <adamw> it's the kinda thing that could be documented for a beta
16:20:37 <kparal> so, we still don't have any kickstart criteria basically
16:21:14 <kparal> -1 most probably, no criteria
16:21:30 <kparal> commonbugs
16:21:49 <roshi> -1
16:21:52 * roshi agres
16:21:55 <roshi> agrees, even
16:22:29 <adamw> OK, let's just reject it for beta and then it'll go away and solve itselfd
16:23:13 <pschindl_> -1
16:23:23 <adamw> proposed #agreed RejectedBlocker (Beta) - this doesn't seem like a clear enough violation to block the Beta on. We considered it might be appropriate as a Final blocker, but decided not to make a decision on that as the fix is imminent in any case
16:23:39 <kparal> ack
16:23:48 <adamw> whoops, patch:
16:24:04 <adamw> proposed #agreed 1470552 - RejectedBlocker (Beta) - this doesn't seem like a clear enough violation to block the Beta on. We considered it might be appropriate as a Final blocker, but decided not to make a decision on that as the fix is imminent in any case
16:24:15 <roshi> ack
16:24:45 <adamw> #agreed 1470552 - RejectedBlocker (Beta) - this doesn't seem like a clear enough violation to block the Beta on. We considered it might be appropriate as a Final blocker, but decided not to make a decision on that as the fix is imminent in any case
16:24:53 <adamw> #topic (1477916) Workstation boot.iso is 1.8 GB, seems to be ostree iso
16:24:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1477916
16:24:54 <adamw> #info Proposed Blocker, distribution, NEW
16:25:41 <kparal> I'd say this is either Beta or Final
16:25:47 <adamw> those *ARE* the choices!
16:25:57 <kparal> there is also a choice of rejecting it
16:26:03 <kparal> but I reject that!
16:26:41 <kparal> I guess Beta is more appropriate - images should be what they're supposed to be
16:26:54 <adamw> there's also "It must be possible to install by booting the installation kernel directly (including via PXE) and correctly specifying a remote source for the installer itself." at beta
16:27:01 <adamw> which i think is affected, though i still haven't had time to test
16:27:10 <adamw> (i.e. do you get an ostree install if you do a PXE install from the Workstation tree)
16:27:54 <adamw> neither of the criteria is quite exactly broken by this, though
16:27:58 <kparal> good question
16:28:16 <kparal> yeah, we never actually said 'compose must be correct' in criteria
16:28:30 <adamw> yeah
16:28:35 <kparal> I'd assume it's assumed :)
16:29:15 <adamw> not sure exactly what criterion i'd write to cover this...
16:29:47 <roshi> correct is kinda implied by all the criteria though...
16:29:52 <kparal> I think it should be obvious that if a product image is actually a different product, it's not the quality level we want
16:30:02 * roshi concurs
16:30:02 <adamw> well, when we wrote the PXE criteria, there *weren't* any flavors
16:30:05 <adamw> and there wasn't any ostree
16:30:13 <adamw> so this kinda wasn't...possible
16:30:31 <adamw> i mean, i guess there could always have been some funky bug that caused the PXE installer to install Ubuntu instead or something, but it seemed unlikely..
16:30:44 <adamw> there was just one stage2. so, i mean, either that worked or you got nothing.
16:30:58 <adamw> ahhh, simpler times.
16:31:32 <adamw> thoughts? should we punt on this to test the impact, and possibly tweak the criterion? or what?
16:31:43 <kparal> accept as Beta
16:31:51 <adamw> as a violation of which criterion?
16:31:55 <roshi> looks like a time to tweak the criterion
16:32:09 <adamw> note, my whole thing about PXE Install giving you ostree is only a *theory* so far
16:32:15 <roshi> because it's obviously wrong, but we never annotated that this is a way it can be wrong
16:32:16 <kparal> I'd say it's a pre-requisite to any criterion
16:32:34 <adamw> the impacts we know about for sure are: boot.iso isn't what it used to be, and installing using the workstation stage2 eats more bandwidth and RAM than it should
16:33:08 <adamw> note that boot.iso isn't really that important any more, it's not talked about or linked to anywhere, it's mostly there for Legacy Reasons(tm) AIUI
16:33:41 <adamw> i guess i'm a bit less of an 'oh obviously this is a blocker' than you
16:33:47 <kparal> netinst is the same as boot iso
16:33:53 <adamw> no, it isn't
16:33:55 <kparal> and that is publicly available from the website
16:33:57 <kparal> no?
16:33:59 <adamw> the actual netinst image was built and works fine
16:34:10 <adamw> this is only about whether the ostree image or the netinst image ultimately got linked as boot.iso
16:34:11 <roshi> well, if you expect workstation and get atomic ostree, that's kinda prima facie wrong, right?
16:34:55 <adamw> the install process built the netinst bits, linked them into this location, which was all as normal...*then* it built the ostree bits and linked them into this location, overwriting the netinst bits
16:35:01 <adamw> roshi: it's a *workstation* ostree. :P
16:35:12 <adamw> that's the cause of this whole problem: we now have a workstation ostree installer image
16:35:16 <adamw> which we never had till late in the f26 cycle
16:35:20 * kparal checks netinst
16:35:22 <adamw> kparal: https://dl.fedoraproject.org/pub/fedora/linux/releases/26/Workstation/x86_64/iso/
16:35:35 <adamw> note the netinst image is 482M, the ostree image is 1.6G
16:35:38 <kparal> ok
16:35:38 <adamw> they're definitely not the same thing
16:35:48 <roshi> still though
16:35:53 <roshi> is it usable?
16:36:03 <roshi> iirc, workstation atomic isn't very usable
16:36:08 <kparal> so, if pxe gets you ostree, Beta, otherwise Final, from my pov
16:36:16 <roshi> and we haven't announced, "Hey, Workstation is Atomic too now!"
16:36:28 <adamw> roshi: it's a soft launch!
16:36:42 <adamw> it passes openqa tests, usually. i haven't played with it much beyond that.
16:36:52 <roshi> lol
16:36:53 <kparal> also note that boot.iso is used often because it's assumed to be the same as netinst
16:37:01 <adamw> but i mean, if you just do a PXE install from the Workstation tree, it's probably not what you expect to get. we still don't know if that's actually what happens, though.
16:37:08 <adamw> (i probably could've tested it while we were arguing about this!)
16:37:28 <roshi> is just the installer ostree, or the installed system?
16:37:30 <adamw> kparal: hum, you think so? that seems like one of those 'hard to be sure about' things to me.
16:37:32 <kparal> let's accept as Final and perhaps move to Beta if it turns out to affect pxe
16:37:49 * roshi can live with that
16:38:02 <adamw> personally i wouldn't necessarily block either milestone *yet*. but if i'm outvoted, fine. can someone else draft a #agreed?
16:38:12 <adamw> preferably with *some* sort of reference to, you know, an actual release criterion? :P
16:38:40 <adamw> (since i still can't understand what grounds we're accepting this on)
16:39:04 * kparal brb in 2 minutes
16:39:04 <roshi> I'm +1 blocker against the yet to be written criterion :p
16:39:13 <roshi> otherwise, it's not violating anything atm
16:40:34 <adamw> i mean, if we agree to add some kinda criterion covering this, great...but i wasn't sure if that was on the table.
16:40:55 <adamw> (and what does that criterion say? everything about the compose must be correct? seems like a hostage to fortune...)
16:41:55 <roshi> boot.iso should be the actual boot.iso people have grown to expect, not some new artifact that hasn't been announced as a change to the boot.iso default
16:42:03 <roshi> or something to that affect
16:43:25 <adamw> well, that'd be simple, sure.
16:43:28 * adamw waits for kparal
16:43:39 <adamw> to me, the boot.iso part of this problem is the last important part, but hey.
16:44:41 <kparal> sorry, I need to deal with something here right now. ignore my arguments, resolve it somehow, thanks
16:44:48 * kparal doesn't care that much
16:45:41 <adamw> well, since this seems a bit complicated, i'm gonna propose we just punt on it till we have a meeting with more people present
16:45:43 <adamw> including releng
16:45:49 <adamw> seem OK?
16:47:15 <adamw> proposed #agreed 1477916 - punt (delay decision) - there was a general feeling in favour of this being a blocker, but it does not clearly violate any existing criteria. we're delaying the decision until there are more folks to help come up with a plan, including release engineering
16:49:40 <kparal> ack
16:50:14 * adamw pokes roshi, satellit and pschindl_ with the pokey stick of shame
16:50:23 <roshi> ack
16:50:24 <pschindl_> ack
16:52:30 <adamw> #agreed 1477916 - punt (delay decision) - there was a general feeling in favour of this being a blocker, but it does not clearly violate any existing criteria. we're delaying the decision until there are more folks to help come up with a plan, including release engineering
16:52:44 <adamw> #topic (1483159) Server deployment still sets up Firefox extension, this is no longer necessary and broken on F27+
16:52:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1483159
16:52:45 <adamw> #info Proposed Blocker, freeipa, NEW
16:52:57 * mboddu is kinda here, but I got a meeting in 10 min
16:53:04 <adamw> this is a nice simple one, it prevents FreeIPA server deployment. (well, it will, once the *other* bug breaking server deployment is fixed.)
16:53:19 <roshi> +1
16:53:48 <kparal> +1
16:54:51 <adamw> proposed #agreed 1483159 - AcceptedBlocker (Beta) - breaks deployment of FreeIPA servers, clear violation of Alpha criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started..." for the domain controller role
16:55:41 <kparal> ack
16:56:29 <mboddu> ack
16:56:29 <pschindl_> ack
16:56:56 <adamw> #agreed 1483159 - AcceptedBlocker (Beta) - breaks deployment of FreeIPA servers, clear violation of Alpha criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started..." for the domain controller role
16:57:05 <adamw> #topic (1479825) Install of Fedora 27 Rawhide 20170804.n.1 Workstation live image fails with the following error - boot loader install failed
16:57:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1479825
16:57:05 <adamw> #info Proposed Blocker, grub2, MODIFIED
16:57:38 <adamw> so, a brief history of this bug: it looks like -8 fixed it, then -9 introduced a related but not-quite-the-same regression (results in the installer failing with the same GUI error, but a somewhat different error from grub in the logs)
16:58:05 <adamw> -10 should fix *that*, but we haven't had a successful compose since it built, so i'm not sure yet.
16:58:13 <kparal> +1
16:58:21 <adamw> easiest option would just be to accept it, then figure out the details in the bug.
16:58:29 <adamw> it definitely seems to break all live installs.
16:58:51 <mboddu> adamw: +1 and figure it out
16:59:29 <pschindl_> +1
17:00:05 <adamw> proposed #agreed 1479825 - AcceptedBlocker (Beta) - this seems to cause all BIOS live installs to fail, which is a clear violation of several "must be able to complete an installation" Alpha criteria for the Workstation and KDE live images
17:00:26 <kparal> ack
17:01:09 <mboddu> ack
17:01:30 <roshi> ack
17:01:40 <adamw> #agreed 1479825 - AcceptedBlocker (Beta) - this seems to cause all BIOS live installs to fail, which is a clear violation of several "must be able to complete an installation" Alpha criteria for the Workstation and KDE live images
17:02:03 <adamw> #topic (1464556) [abrt] PackageKit: pk_backend_refresh_cache_thread(): packagekitd killed by signal 11
17:02:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1464556
17:02:03 <adamw> #info Proposed Blocker, PackageKit, ASSIGNED
17:03:13 <adamw> most recent comment claims this is fixed already
17:03:14 <adamw> lemme check
17:03:34 <kparal> close and reopen if it happens again?
17:03:47 <adamw> well, last time the test ran, it failed: https://openqa.fedoraproject.org/tests/131596
17:03:53 * adamw checks the logs
17:04:53 <kparal> ok, so accept and verify later
17:06:15 <roshi> wfm
17:06:20 <adamw> oh, failure looks like a needle mismatch
17:06:25 <adamw> so, i can go with close and reopen
17:06:30 <roshi> also wfm
17:06:32 <roshi> lol
17:06:34 <adamw> =)
17:07:19 <kparal> adamw: feel free to close
17:08:27 <adamw> #info 1464556 - it looks like this is resolved already; indeed latest openQA test did not run into the crash (though it failed due to a needle mismatch). we will close this as a duplicate of the resolved bug
17:09:36 <adamw> #topic (1480929) SELinux is preventing journalctl from 'map' accesses on the file /var/log/journal/e0215049b3ad4b45be988a3894bb0931/system@000555eff2a070fa-00d74fe76412519e.journal~.
17:09:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1480929
17:09:37 <adamw> #info Proposed Blocker, selinux-policy, POST
17:10:05 <adamw> it seems pretty likely this is the specific denial that caused journald to break after the 'map' permission was introduced.
17:11:03 <kparal> +1
17:11:07 <pschindl_> +1
17:11:11 <adamw> i think we can probably close it, in fact
17:11:22 <adamw> 3.13.1-272 seems to fix it
17:11:31 <adamw> or is anyone still seeing this denial with that selinux-policy?
17:11:45 <kparal> I don't run F27
17:11:47 * adamw is booted with that selinux-policy, in enforcing mode, and his journal works
17:12:14 <kparal> I can check rawhide if that helps
17:12:39 <adamw> nah, if no-one has a contrary experience i think it'd be fine to just close it and re-open if necessary
17:13:08 <kparal> wow, 28 selinux alerts about 'map'
17:13:28 <kparal> none of that is against journald, though
17:14:02 <kparal> but just about everything else :)
17:14:15 <adamw> yeah, it's a flood
17:14:28 <adamw> quite a few were resolved with -272, but some are still outstanding
17:14:31 <adamw> please do report all the ones you hit
17:14:39 <kparal> so, close this one?
17:14:44 <adamw> yeah, unless anyone objects
17:14:47 <kparal> nope
17:14:56 <kparal> adamw: feel free to close it, thanks
17:15:05 <adamw> #info 1480929 - testing indicates that selinux-policy 3.13.1-272 resolves this denial, so we will close this bug as fixed
17:16:51 <adamw> #topic (1483170) 'map' denial for comm 'ns-slapd' path '/run/dirsrv/slapd-DOMAIN-LOCAL.stats' (breaks FreeIPA deployment)
17:16:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1483170
17:16:51 <adamw> #info Proposed Blocker, selinux-policy-targeted, NEW
17:17:01 <adamw> so this is the *other* bug breaking freeipa server deployment, another of these 'map' denials
17:17:31 <kparal> +1
17:18:19 <roshi> +1
17:18:25 <adamw> the deployment log links up the denial and the error pretty clearly
17:19:05 <adamw> proposed #agreed 1483170 - AcceptedBlocker (Beta) - breaks deployment of FreeIPA servers, clear violation of Alpha criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started..." for the domain controller role
17:19:34 <kparal> ack
17:20:11 <kparal> let's speed this up, there are 5 very similar bugs
17:20:23 * kparal pokes pschindl_
17:20:28 <adamw> this is the last of the beta proposals
17:20:35 <pschindl_> ack
17:21:00 <adamw> #agreed 1483170 - AcceptedBlocker (Beta) - breaks deployment of FreeIPA servers, clear violation of Alpha criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started..." for the domain controller role
17:21:03 <kparal> ah, I thought this was the first of dac_read_search
17:21:16 <kparal> anyway, 5 same bugs incoming
17:21:20 <adamw> nah, they come next
17:21:44 <adamw> #info that's all the proposed Beta blockers, moving onto proposed Final blockers
17:22:19 <adamw> so, proposal: as these are all basically the same, let's vote on them as a block
17:22:46 <kparal> yep
17:23:06 <roshi> wfm
17:23:49 <adamw> #info all 5 proposed Final blockers are SELinux denials encountered during boot of several release-blocking package sets
17:23:57 <adamw> #info to speed things up, we will vote on them as a block
17:24:21 <adamw> I'm obviously +1 to all of them, clear violations of Final criterion "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:29 <kparal> +1
17:25:01 <pschindl_> +1
17:26:53 <adamw> proposed #agreed 1451377 1451379 1451381 1451385 1459081 - all AcceptedBlocker (Final) - clear violations of Final criterion "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:27:36 <pschindl_> ack
17:27:42 <roshi> ack
17:27:54 <kparal> ack
17:28:14 <adamw> #agreed 1451377 1451379 1451381 1451385 1459081 - all AcceptedBlocker (Final) - clear violations of Final criterion "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:28:20 <adamw> okay, that was nice and quick :P
17:28:25 * adamw looks at the accepted blockers
17:28:46 <adamw> we need to test and confirm the #1170803 fix i think
17:29:37 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1438495 was just marked as an accepted blocker by Dennis back in April, i will ping him about that one
17:30:01 <adamw> other than that, not really seeing a lot to discuss
17:30:11 <adamw> anyone want to go through any of the accepted blockers, or should we close up?
17:30:36 <kparal> close up
17:32:44 * kparal needs to go. thanks everyone, see you
17:33:21 <adamw> thanks kparal
17:33:27 <adamw> hope whatever you need to sort out is OK
17:33:32 <adamw> #topic Open floor
17:33:35 <adamw> any other business, folks?
17:33:39 * roshi has nothing
17:35:44 <adamw> .fire roshi
17:35:44 <zodbot> adamw fires roshi
17:35:44 <roshi> much easier to attend than run, I'll say that much :p
17:35:52 <adamw> for old times' sake
17:35:58 <roshi> :D
17:38:00 <adamw> alrighty then, thanks for coming folks
17:38:12 <adamw> see you next time, same bat-channel
17:38:15 * roshi ambles off...
19:24:12 <nirik> #endmeeting