17:00:29 <jkurik> #startmeeting F27 Beta Go/No-Go meeting
17:00:29 <zodbot> Meeting started Thu Sep 14 17:00:29 2017 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:29 <zodbot> The meeting name has been set to 'f27_beta_go/no-go_meeting'
17:00:30 <jkurik> #meetingname F27-Beta-Go-No-Go-meeting
17:00:30 <zodbot> The meeting name has been set to 'f27-beta-go-no-go-meeting'
17:00:47 <zodbot> jkurik: Error: Can't start another meeting, one is in progress.
17:00:48 <jkurik> #meetingname F27-Beta-Go-No-Go-meeting
17:00:48 <zodbot> The meeting name has been set to 'f27-beta-go-no-go-meeting'
17:01:13 <jkurik> #topic Roll Call
17:01:14 <jkurik> .hello jkurik
17:01:15 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:01:26 <mboddu> .hello mohanboddu
17:01:26 <nirik> .hello kevin
17:01:27 <jkurik> #chair dgilmore nirik adamw sgallagh roshi mboddu
17:01:27 <zodbot> Current chairs: adamw dgilmore jkurik mboddu nirik roshi sgallagh
17:01:27 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:01:30 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:02:01 <sgallagh> .hello2
17:02:02 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:02:23 <jkurik> hi sgallagh, nirik, mboddu
17:02:36 <dgilmore> hi
17:02:43 <sgallagh> jkurik: roshi is still on your default chair list?
17:03:00 <jkurik> sgallagh: why he should not be ?
17:05:14 <jkurik> hmm.. looks like we are missing QE people
17:05:33 <roshi> .hello roshi
17:05:34 <zodbot> roshi: roshi 'Mike Ruckman' <roshi@mykolab.com>
17:05:45 <jkurik> hi roshi
17:05:57 <jkurik> #topic Purpose of this meeting
17:05:59 <jkurik> #info Purpose of this meeting is to check whether or not F27 Beta is ready for shipment, according to the release criteria.
17:06:00 <roshi> o/
17:06:10 <jkurik> #info This is determined in a few ways:
17:06:11 <jkurik> #info * No remaining blocker bugs
17:06:13 <jkurik> #info * Release candidate compose is available
17:06:14 <jkurik> #info * Test matrices for Beta are fully completed
17:06:21 <jkurik> #topic Current status
17:06:23 <jkurik> As far as I am aware, the RC for F27 Beta is not yet ready for several reasons:
17:06:39 <jkurik> 1) There are blockers https://qa.fedoraproject.org/blockerbugs/milestone/27/beta/buglist
17:07:03 <jkurik> 2) It has been decided to deliver Fedora Modular Edition asynchronously from the F27 release to give Server WG and Modularity WG more time.
17:07:05 <jkurik> https://pagure.io/Fedora-Council/tickets/issue/141
17:07:14 <jkurik> As such, we do not have test matrices for the RC.
17:07:23 <jkurik> FYI:
17:07:24 <jkurik> The lastest F27 nightly compose is available at https://kojipkgs.fedoraproject.org/compose//branched/Fedora-27-20170913.n.0/
17:07:35 <jkurik> And test matrices for nightly builds are available at: https://fedoraproject.org/wiki/Category:Fedora_27_Nightly_Test_Results
17:07:42 <dgilmore> jkurik: the modularity efforts have no effect on why we have nothing to test
17:07:56 <dgilmore> its all just number 1 :(
17:08:28 <roshi> yeah, even not being around as much I feel comfortable saying QA is a no-go if there are standing blockers :p
17:08:43 <roshi> but I'd still want adamw confirmation
17:08:52 * nirik nods. we are pretty clearly nogo... i
17:08:58 <bowlofeggs> .hello2
17:09:00 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
17:09:10 <jkurik> dgilmore: as the decision whether we will deliver Modular or Traditional Sever varian is still in progress, I think it affects RC as well
17:09:12 <nirik> if there were enough people here we could do a blocker bug review... but dunno if we want to
17:09:39 * roshi doesn't have the cycles right now to run the review
17:09:43 <dgilmore> jkurik: afaik it was never release blocking so no
17:09:47 <dgilmore> anyway
17:09:55 <jkurik> ok
17:10:15 <jkurik> #info The RC for F27 Beta is not yet ready due to present blockers
17:10:17 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/27/beta/buglist - F27 Blockers
17:10:27 <jkurik> #info As we have no RC there are subsequently no Test Matrices for the F27 Beta RC
17:10:48 <jkurik> roshi: are you willing to run Mini blocker review ?
17:10:58 <roshi> sorry jkurik :(
17:11:05 <sgallagh> dgilmore: That's a complicated topic. It *was* supposed to be release-blocking, but we weren't going to make it, so we were prepped to enact the contingency plan. But now the Council has told us that they want it blocking, but on a separate schedule
17:11:07 <roshi> I lack the cycles right this moment
17:11:35 <jkurik> roshi: ok, np
17:12:11 <roshi> sgallagh might be able to do it :p
17:12:19 <dgilmore> sgallagh: that was not ever communicated to release engineering until last week late, so no. but its off topic for here
17:12:22 <roshi> or any other QA joker :)
17:12:48 <jkurik> I am afraid I will not be able to run the Mini blocker review as I am not as familiar with the release criterias etc...
17:12:52 <sgallagh> I'm triple-tasking already, sorry.
17:13:05 <sgallagh> If we have one, I'll participate, but I can't run it
17:13:15 <jkurik> Is there any one who is willing to run the Mini blocker review ?
17:13:33 <jkurik> Or we can skip as the decision is no-go anyway
17:14:11 <roshi> probably easiest
17:15:01 <dgilmore> jkurik: seems best to skip
17:15:42 <roshi> sorry folks, I've failed you :(
17:15:58 <jkurik> ok
17:16:02 <jkurik> #info we are skipping the Mini blocker review
17:16:28 <dgilmore> #info please vote in the bugs
17:16:43 <jkurik> #info As there is no RC and no Test Matrices, we are skipping Test Matrices coverage review as well
17:16:53 <jkurik> dgilmore: thanks
17:17:02 <jkurik> #topic Go/No-Go decision
17:17:21 <sgallagh> Go! :-P (I kid, of course)
17:17:29 <jkurik> proposed #agreed Due to missing RC for the F27 Beta release and presence of blocker bugs, the decision is “No Go”. The Beta release slips for one week however due to “Rain date” feature for the Beta we are not going to slip the Final GA.
17:18:07 <sgallagh> ack
17:18:08 <dgilmore> -1 Go
17:18:15 <jkurik> dgilmore, nirik, sgallagh, roshi, mboddu ... may I have your +1 ?
17:18:26 <dgilmore> jkurik: +1 to proposed
17:18:37 <nirik> +1
17:18:37 <roshi> ack
17:18:37 <sgallagh> My "Ack" == +1 to proposal
17:18:59 <mboddu> +1 to proposed
17:19:15 <jkurik> roshi: as you are the only QA representative here  ^^^
17:19:25 <jkurik> ah sorry, I overlooked you
17:19:34 <roshi> no worries :)
17:19:53 <jkurik> #action jkurik to publish the Go/No-Go result
17:19:55 <jkurik> #action jkurik to organize second round of Go/No-Go meeting for F27 Beta on Thursday, September 21st at 17:00UTC
17:19:59 <sumantrom[m]> +1
17:20:20 <jkurik> #agreed Due to missing RC for the F27 Beta release and presence of blocker bugs, the decision is “No Go”. The Beta release slips for one week however due to “Rain date” feature for the Beta we are not going to slip the Final GA.
17:20:29 <jkurik> #topic Open floor
17:20:30 <jkurik> anything else to discuss today on this meeting ?
17:20:39 <jkurik> sumantrom[m]: hi
17:20:45 <dgilmore> nope
17:21:02 <sumantrom[m]> jkurik: hi
17:21:08 <sumantrom[m]> nothing from my side either
17:21:16 <mboddu> not from my side
17:21:30 <adamw> hi
17:21:38 <adamw> sorry folks, woke up feeling sick this morning
17:21:41 <jkurik> wow, hi adamw
17:22:05 <jkurik> we have decided on behalf of you to slip the F27 Beta
17:22:17 <adamw> heh
17:22:22 <adamw> i saw, yeah, it's kinda obvious
17:22:32 <adamw> anyone still want to do blocker review?
17:23:04 <sumantrom[m]> i would be happy to , if others are ready
17:23:13 * nirik would if someone else ran it. ;)
17:23:14 <jkurik> I am ok, to do it
17:23:45 <adamw> sure, i can run it, that's what i was offering :)
17:23:54 <jkurik> #topic Mini-Blocker Review
17:23:56 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/27/beta/buglist
17:24:00 <jkurik> adamw: the channel is yours
17:24:09 <adamw> woohoo
17:24:11 <adamw> did you chair me?
17:24:24 * bowlofeggs pulls the chair out from under adamw
17:24:29 <jkurik> I think so, but....
17:24:33 <adamw> alrighty
17:24:34 <jkurik> #chair adamw
17:24:34 <zodbot> Current chairs: adamw dgilmore jkurik mboddu nirik roshi sgallagh
17:24:44 <adamw> we've got 10 proposed beta blockers to look at...
17:24:59 <adamw> everyone OK if i skip the boiler plate? i think you all know what we're doing
17:25:09 <jkurik> skip
17:25:13 <adamw> roger
17:25:15 <adamw> so, first one:
17:25:15 <adamw> #topic (1491333) kickstart installations using autopart fail with 'Kickstart insufficient'
17:25:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1491333
17:25:16 <adamw> #info Proposed Blocker, anaconda, POST
17:25:29 <adamw> this is new with the recent anaconda update we pulled in to fix other blockers, i believe
17:25:54 * adamw looks for the kickstart criterion
17:25:56 <nirik> no good deed goes unpunished
17:26:17 <adamw> "The installer must be able to complete a scripted installation which duplicates the default interactive installation as closely as possible...Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention."
17:26:40 <adamw> i'd say this breaks that, since 'autopart' in the kickstart is the equivalent of guided partitioning in the installer.
17:26:50 <adamw> so, +1.
17:26:54 <dgilmore> +1
17:26:55 <jkurik> +1
17:26:56 <nirik> +1 blocker
17:27:09 * dgilmore tried to vote on all proposed blockers in the bugs
17:27:15 <sumantrom[m]> +1
17:27:33 <adamw> proposed #agreed 1491333 - AcceptedBlocker (Beta) - violates "The installer must be able to complete a scripted installation which duplicates the default interactive installation as closely as possible" and "Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention" from the Alpha criteria
17:27:42 <adamw> dgilmore: thanks for that, we'll use your votes from the bug if you have to leave here
17:27:46 <sgallagh> +1 blocker
17:27:52 <jkurik> ack
17:27:53 <nirik> ack
17:28:05 <sumantrom[m]> ack
17:28:22 <adamw> #agreed 1491333 - AcceptedBlocker (Beta) - violates "The installer must be able to complete a scripted installation which duplicates the default interactive installation as closely as possible" and "Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention" from the Alpha criteria
17:28:29 <adamw> #topic (1477916) Workstation boot.iso is 1.8 GB, seems to be ostree iso
17:28:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1477916
17:28:29 <adamw> #info Proposed Blocker, distribution, NEW
17:28:34 <adamw> so, this one came back
17:28:54 <nirik> +1 blocker. Just needs the fix applied to rawhide also applied to branched
17:29:04 <adamw> we un-nominated it on Monday as we weren't building the Workstation atomic installer for F27 at that time, but someone brought it back on tuesday or so.
17:29:23 <adamw> we've *still* not actually determined what this does to PXE installs, though (which is one of the key questions)
17:29:27 <dgilmore> adamw: should be okay today
17:29:29 <adamw> i'm at least +1 FE on it
17:29:31 <dgilmore> but +1 blocker
17:30:20 <jkurik> I am +1 FE, not sure about blocker
17:30:31 <nirik> well, without it the workstation netinstall is wrong right? but I suppose there's lots of workarounds... (use any of the others)
17:30:56 <dgilmore> nirik: the netinst is okay. but boot.iso is wrong
17:31:00 <dgilmore> as is the pxe tree
17:31:00 <sumantrom[m]> +1 FE
17:31:10 <sgallagh> Does the boot.iso have any release criteria associated with it?
17:31:19 <dgilmore> sgallagh: netinst does
17:31:20 <sgallagh> I thought only the Live DVD was blocking
17:31:23 <adamw> sgallagh: no, it's the netinst iso that's listed on the release blocking list
17:31:25 <dgilmore> they are supposed to be the same
17:31:30 <adamw> not the old 'boot.iso' name
17:31:34 <dgilmore> sgallagh: you are pulling at straws
17:31:36 <sgallagh> Is the netinst broken?
17:31:42 <adamw> the main point for me with this is the PXE case
17:31:55 <sgallagh> I'm +1 FE, I just don't see where it qualifies as a blocker.
17:31:59 <dgilmore> adamw: thats why I am +1 blocker
17:32:06 <adamw> if you do a PXE install using the Workstation tree, the installer environment you get will not be the correct one.
17:32:07 <dgilmore> not that it matters much
17:32:08 <nirik> yeah, pxe would be broken
17:32:10 <dgilmore> the fix is simple
17:32:16 <jkurik> my understanding is that the fix https://pagure.io/pungi-fedora/pull-request/354 has already been merged, so the next nightly compose should be safe
17:32:21 <dgilmore> and it will go in either way
17:32:33 <adamw> let's just accept as FE for now and hope it goes away?
17:32:39 <sgallagh> adamw: +1
17:32:40 <dgilmore> sure
17:32:43 <adamw> <--- the fudgemaster
17:32:45 <jkurik> +1
17:32:47 <nirik> sure, fine.
17:32:57 <sumantrom[m]> +1
17:33:16 <adamw> proposed #agreed 1477916 - AcceptedFreezeException (Beta) - we're still wrangling about whether this technically violates any criteria, but everyone's OK with giving it a freeze exception and hoping it goes away by Monday.
17:33:26 <dgilmore> ack
17:33:30 <sgallagh> ack
17:33:37 <sumantrom[m]> ack
17:33:37 <jkurik> ack
17:33:50 <nirik> ack
17:34:17 <adamw> #agreed 1477916 - AcceptedFreezeException (Beta) - we're still wrangling about whether this technically violates any criteria, but everyone's OK with giving it a freeze exception and hoping it goes away by Monday.
17:34:38 <adamw> #topic (1490832) dnf system-upgrade: dnf.exceptions.MarkingError: no package matched
17:34:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1490832
17:34:39 <adamw> #info Proposed Blocker, dnf-plugin-system-upgrade, NEW
17:34:50 <adamw> this one's fairly newly nominated / reported, i didn't get to look into it a lot yet
17:35:26 <adamw> but i think i did see a few cases where openqa upgrade tests failed and it looked like the reason was the upgrade simply didn't run, so the system booted back to 25/26
17:35:37 <adamw> i didn't get the time to poke into it more yet, it certainly doesn't seem to happen *every* time
17:35:40 <adamw> has anyone else seen this?
17:35:46 <nirik> so we don't know how common it is?
17:35:51 * nirik hasn't seen it
17:36:54 <adamw> so far as i know, yeah, we're a bit short on info here
17:36:57 <sgallagh> adamw: How many is "a few cases"
17:37:09 * dgilmore wonders how widespread it is
17:37:32 <adamw> sgallagh: i think i saw it twice for sure. but i haven't been checking the upgrade test results every day because of all the other stuff that's been broken.
17:37:38 <sumantrom[m]> a few cases --> me got it today
17:37:39 <adamw> (twice across 27 and rawhide)
17:37:46 * sgallagh nods
17:37:50 <Kellin> adamw: is it relevant if it happened going from 25-26?
17:38:20 * nirik wonders what dnf.rpm.log has. asks in bug
17:38:21 <sgallagh> It sounds like it's not making changes and just falling back, right?
17:38:22 <adamw> Kellin: i was talking about tests that upgrade from 25 and 26 to 27 and rawhide (openqa is set up to test upgrading from both current stable releases)
17:38:28 <adamw> sgallagh: yeah, that seems to be what it does.
17:38:45 <sgallagh> adamw: OK, we should figure out if a repeat performance succeeds.
17:38:47 <Kellin> adamw: my dnf upgrade from 25-26 failed twice on my desktop; just kept re-running and it eventually worked.  I don't know if that's relevant info for you
17:38:54 <adamw> i'd be curious to know if you can make it work by just trying the 'dnf system-upgrade reboot' step again
17:38:55 <sgallagh> If it does, I'd be fine with -1 blocker *at Beta*
17:39:01 <adamw> or if you have to run through the download step again first
17:39:08 <adamw> Kellin: was it this same error?
17:39:08 <sgallagh> yeah
17:39:37 <nirik> it's just returning 1, but nothing in the currently attached logs as to why
17:39:45 <Kellin> adamw: one of the two times, yes
17:40:14 <adamw> so i'm kinda sensing we're at the 'punt for info' stage here
17:40:24 <nirik> yeah. +1
17:40:38 <sgallagh> adamw: I'd be comfortable with a +1 FE vote in the interrim
17:40:52 <sgallagh> So if a fix does come in, we don't have to do this dance in the meantime
17:41:10 <adamw> seems reasonable
17:41:15 <jkurik> we can revisit on Monday, when we might have more info
17:41:17 <nb> sounds good
17:41:52 <nirik> we can always vote in bug too.
17:42:04 <adamw> proposed #agreed 1490832 - AcceptedFreezeException (Beta), punt (delay decision) on blocker status - we're missing quite a bit of info here (how common this is, does it just work if you try again, etc), but we've seen at least enough to grant a freeze exception
17:42:16 <sgallagh> ack
17:42:19 <jkurik> ack
17:42:27 <nirik> ack
17:42:28 <sumantrom[m]> ack
17:42:35 <roshi> ack
17:42:42 <adamw> #agreed 1490832 - AcceptedFreezeException (Beta), punt (delay decision) on blocker status - we're missing quite a bit of info here (how common this is, does it just work if you try again, etc), but we've seen at least enough to grant a freeze exception
17:42:52 <adamw> #topic (1491053) Firefox reports insecure TLS configuration when visiting FreeIPA web UI after standard server deployment
17:42:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1491053
17:42:53 <adamw> #info Proposed Blocker, freeipa, NEW
17:43:08 <adamw> so i'm still on the hook to get openQA to click on the little button to tell us *why* this is happening
17:43:27 <adamw> which i was gonna do this morning if i hadn't spent it communing with the porcelain god
17:44:02 <adamw> it's not a slam dunk blocker, as the criterion explicitly allows "moderate workarounds"
17:44:16 <adamw> so i guess the question is whether working around a bad tls cert is 'moderate'
17:44:19 <nirik> so, meta question here...
17:44:23 <adamw> i don't actually know if firefox even lets you do it any more...
17:44:26 <adamw> uh huh
17:44:45 <sgallagh> adamw: Where is the client here?
17:44:50 <nirik> if the council has decided we don't ship f27 traditional server and later ship f27 modular server, should we just punt these blockers?
17:45:12 <sgallagh> nirik: I think they'd still be blockers for those releases
17:45:27 <sgallagh> So they may not block Go/No-Go for Workstation and Atomic
17:45:31 <nirik> those releases? you mean for the later modular one?
17:45:40 <sgallagh> Right, should have been more explicit
17:45:53 <nirik> then we could just say: delay a month and revisit?
17:45:56 <sgallagh> I they are potentially blockers for Server
17:46:07 <adamw> sgallagh: the client is not the same box as the server
17:46:10 <sgallagh> Might as well classify them now to help prioritize
17:46:18 <adamw> it's another vm (that just enrolled itself into the domain via cockpit)
17:46:21 <sgallagh> adamw: And that worked before without manual configuration of the client?
17:46:28 <sgallagh> Or is the client enrolled with the FreeIPA server?
17:46:33 <adamw> it is enrolled.
17:46:38 <sgallagh> (Sorry, BZ is unclear on that)
17:46:52 <adamw> well...i mean, let's be technically correct here
17:47:01 <sgallagh> OK, then that's a problem. The enrollment step should be adding the CA cert to the local store
17:47:08 <adamw> what I *know* is that it clicked through the enrolment process in cockpit without any openqa checks failing
17:47:15 <nirik> for the record, I think we should ship f27 traditional server... but I know this isn't the place to decide that.
17:47:28 <dgilmore> nirik: afaik we will be
17:47:34 <adamw> oh wait, no, we *can* say it enrolled successfully
17:47:41 <dgilmore> and always were going to do so
17:47:47 <adamw> because after the webui test fails it carries on and runs the freeipa client test, and that passes.
17:47:58 <dgilmore> any difference was on the web side
17:48:10 <nirik> dgilmore: in the past yes, but after yesterday that was not my understanding from the council meeting minutes.
17:48:49 <dgilmore> nirik: not what I took away from it
17:48:54 <adamw> you know, the first question i asked mattdm when he told me about this cockamamie plan was 'okay, and what's the process for releasing one of our major flavors after the rest of the distro?'
17:49:00 <adamw> the answer appears to be 'uhhh, we don't know.'
17:49:32 <mattdm> adamw: I phrase that "TBD" :)
17:50:02 <jkurik> it is not in conflict with "we do not know" :-)
17:50:44 <adamw> so i am approximately of the opinion that we should just follow the existing process for now
17:50:48 <nirik> I don't know... fly casual!
17:51:10 <nirik> adamw: I'd be in favor of that.
17:51:15 <adamw> since it's the only way we can be sure anyone's caring about server's quality at all, until such time as someone actually comes up with a process for validating it on some alternate schedule.
17:52:38 <adamw> the other point i'd make is that if the one month delay is to give us time to get the modularity stuff in order, it follows that the *non* modularity related bits had probably better be working on the normal schedule.
17:53:03 <sgallagh> For today, let's operate as normal.
17:53:05 <adamw> if we're in the extra month and we're *still* trying to line up freeipa, that's probably not good.
17:53:19 <sgallagh> The rest of this is still pending a final decision.
17:53:24 <adamw> rgr
17:53:34 <sgallagh> If that final decision ends up being the status quo, let's not be days behind schedule
17:53:41 <adamw> excuse me while i go monkeypatch the tests on staging
17:54:35 <adamw> i guess we can probably punt on this for now as we maybe need a bit more info about why this is happening and to what extent it can be worked around?
17:54:59 <jkurik> I am +1 to punt this for now
17:55:43 <nirik> +1 punt and gather more info
17:56:09 <sgallagh> I'm -1 blocker, +1 FE on the grounds that the workaround isn't hard to figure out
17:56:23 <sgallagh> But I'd be +1 Final blocker
17:56:52 <adamw> sgallagh: well, i don't wanna -1 yet on the grounds that i'm not sure to what extent firefox actually allows you to just okay invalid certs now
17:56:59 <adamw> i know they've been tightening down on it
17:57:05 <adamw> if you know for sure it's just a couple of clicks, i can consider-1
17:57:18 <nirik> yeah, depends on why it doesn't like the cert
17:57:36 <sgallagh> adamw: It's just a couple clicks
17:57:45 <sgallagh> I used Firefox to test Cockpit on Server just the other day
17:57:50 <sgallagh> It had the same issue
17:57:55 <sgallagh> Or rather, experience, not issue.
17:58:11 <sgallagh> Oh, that's a good point.
17:58:23 <adamw> how about this
17:58:26 <adamw> we'll +1 FE it for now
17:58:30 <adamw> i'll keep looking into it
17:58:37 <adamw> if i find it's easily workaroundable i'll un-nominate it for blocker
17:58:37 <sgallagh> If the problem is just "unknown trust chain", it may be different from "we don't support 1024-bit certs"
17:58:44 <sgallagh> adamw: WFM
17:59:21 <adamw> proposed #agreed 1491053 - AcceptedFreezeException (Beta), punt (delay decision) on blocker status - we're not yet sure of the cause for this or how easy it is to workaround, so we cannot make a blocker decision. It's clearly a case for a freeze exception, however.
17:59:35 <jkurik> ack
18:00:00 <sgallagh> ack
18:00:02 <Southern_Gentlem> ack
18:00:44 <adamw> #agreed 1491053 - AcceptedFreezeException (Beta), punt (delay decision) on blocker status - we're not yet sure of the cause for this or how easy it is to workaround, so we cannot make a blocker decision. It's clearly a case for a freeze exception, however.
18:00:53 <adamw> #topic (1491056) FreeIPA enrolment via kickstart fails
18:00:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1491056
18:00:53 <adamw> #info Proposed Blocker, freeipa, MODIFIED
18:01:02 <adamw> this one's a fairly clear alpha criteria violation, +1 for me.
18:01:34 <Southern_Gentlem> +1
18:01:46 <nirik> +1 blocker
18:01:59 <jkurik> +1 to block
18:01:59 <sgallagh> +1 blocker
18:02:56 <adamw> proposed #agreed 1491056 - AcceptedBlocker (Beta) - clearly violates "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain"
18:02:58 <Southern_Gentlem> has the update fix this yet
18:03:12 <Southern_Gentlem> rather did the update fix this
18:03:14 <adamw> Southern_Gentlem: haven't tested yet (again i need to tweak things a bit to test it)
18:03:23 <Southern_Gentlem> ack
18:03:26 <jkurik> ack
18:04:22 <adamw> one more ack?
18:04:22 <mboddu> ack
18:04:27 <adamw> #agreed 1491056 - AcceptedBlocker (Beta) - clearly violates "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain"
18:04:39 <adamw> #topic (1490072) Program terminated with signal SIGSEGV, Segmentation fault. #0  0x00007f16279aa68f in _cogl_boxed_value_set_x () from /usr/lib64/mutter/libmutter-cogl-1.so
18:04:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1490072
18:04:40 <adamw> #info Proposed Blocker, gnome-shell, POST
18:05:00 <adamw> so, i did work on this one a bit
18:05:18 <adamw> reproduced it on a different test machine, found other reports both on gnome bugzilla and launchpad
18:05:36 <adamw> it seems to not be hardware related (does only happen on Wayland though) and to be related to the 'inhibit shortcuts' dialog
18:05:50 <adamw> on balance i'd say it's probably common / severe enough to be blocker
18:05:56 <adamw> so i'm a light +1
18:06:00 <Southern_Gentlem> +1
18:06:12 <sumantrom[m]> +1
18:06:21 <jkurik> +1
18:06:51 <adamw> i've also submitted a build with upstream's intended fix, but it is a mutter 3.26.0 build whereas we have 3.25.91 in stable atm
18:07:07 <adamw> i'll need to talk to the desktop team about whether we want to get the whole of 3.26 in with an FE or just take a mutter update or what
18:08:07 <adamw> proposed #agreed 1490072 - AcceptedBlocker (Beta) - conditional violation of "The release must be able host virtual guest instances of the same release", this bug means you're very likely to crash your GNOME session when trying to do this on GNOME
18:08:24 <adamw> oh yeah, there are reports of the same bug for both Boxes and virt-manager.
18:08:44 <adamw> (i hit it with virt-manager, one of the bgo reporters hit it with boxeS)
18:09:27 <nirik> might be good to just take 3.26.0 at this point, but if so we should land it asap so it gets enough testing before next go/nogo
18:09:35 <adamw> yeah
18:09:40 <adamw> ack/nack/patch?
18:09:43 <jkurik> ack to the proposal
18:09:50 <sumantrom[m]> ack
18:10:07 <Southern_Gentlem> ack
18:10:21 <adamw> #agreed 1490072 - AcceptedBlocker (Beta) - conditional violation of "The release must be able host virtual guest instances of the same release", this bug means you're very likely to crash your GNOME session when trying to do this on GNOME
18:10:54 <adamw> #topic (1490895) kernel crash when trying upgrade VM to F27
18:10:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1490895
18:10:54 <adamw> #info Proposed Blocker, kernel, NEW
18:11:36 <adamw> so i'm pretty sure this is basically just https://bugzilla.redhat.com/show_bug.cgi?id=1462381
18:11:55 <adamw> which means it's specific to VMs using qxl and there's a simple workaround - remove 'rhgb' from boot params
18:12:04 <jkurik> +1 FE -1 Blocker
18:12:15 <adamw> i might be +1 final blocker, but probably -1 Beta.
18:12:21 <adamw> +1 FE indeed.
18:12:48 <sumantrom[m]> +1 FE but not blocker for now
18:12:51 <sgallagh> +1 FE, +1 Final Blocker -1 Beta Blocker
18:13:11 <adamw> anyone else wanna vote on final blocker atm, or just beta fe?
18:13:54 <jkurik> I would say +1 FE for now and we can revisit before Final if not fixed
18:14:03 <adamw> ok
18:14:45 <adamw> proposed #agreed 1490895 - RejectedBlocker (Beta), AcceptedFreezeException (Beta) - this looks to be the same as #1462381, and is specific to VMs using the 'qxl' driver and can be easily worked around by disabling graphical boot. On that basis it's rejected as a blocker but accepted as an FE
18:14:56 <jkurik> ack
18:15:00 <sgallagh> ack
18:15:46 <sumantrom[m]> ack
18:15:47 <adamw> #agreed 1490895 - RejectedBlocker (Beta), AcceptedFreezeException (Beta) - this looks to be the same as #1462381, and is specific to VMs using the 'qxl' driver and can be easily worked around by disabling graphical boot. On that basis it's rejected as a blocker but accepted as an FE
18:15:49 <adamw> #topic (1489862) There is FW Raid set, but there is no /dev/md* device
18:15:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489862
18:15:49 <adamw> #info Proposed Blocker, selinux-policy, ON_QA
18:16:17 <adamw> on the basis of "I can confirm enforcing=0 fixes this problem with Live", i'm gonna be -1 blocker / +1 FE for this
18:16:32 <adamw> because that means it most likely works with the non-live installer (which always runs in permissive mode)
18:16:41 <nirik> -1/+1 here too
18:16:43 <adamw> and there is an easy workaround for live
18:16:59 * nirik wonders how common fw raid is anymore... but thats a sidetrack I guess.
18:17:00 <sgallagh> Yeah, -1 blocker, +1 FE
18:17:06 <Southern_Gentlem> -1, +1
18:17:14 <adamw> nirik: i've no idea. :P
18:17:21 <jkurik> -1 blocker, +1 FE
18:17:51 <adamw> proposed #agreed 1489862 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - per current information this works with SELinux in permissive mode, so it likely works on the non-live installer images and can easily be worked around for live installs with 'enforcing=0'
18:17:58 <adamw> of course, we should commonbugs it too...
18:18:16 <jkurik> ack to the proposal
18:18:30 <Southern_Gentlem> ack
18:18:48 <nirik> ack
18:18:50 <adamw> #agreed 1489862 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - per current information this works with SELinux in permissive mode, so it likely works on the non-live installer images and can easily be worked around for live installs with 'enforcing=0'
18:18:50 <adamw> #topic (1491508) FreeIPA server deployment fails with SELinux in enforcing mode, despite no obvious denials
18:18:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1491508
18:18:51 <adamw> #info Proposed Blocker, selinux-policy, ASSIGNED
18:19:06 <adamw> i swear, one day, we'll get to the end of the freeipa/selinux saga...
18:19:44 <Southern_Gentlem> +1
18:19:45 <jkurik> :)
18:19:46 <adamw> i've reproduced this four times, so i'm pretty sure it's real, so +1
18:19:56 <nirik> matryoshka bugs
18:19:59 <nirik> +1
18:20:09 <jkurik> +1 to block
18:20:09 <sgallagh> +1
18:20:35 <sumantrom[m]> +1
18:20:38 <adamw> proposed #agreed 1491508 - AcceptedBlocker (Beta) - once again, violates "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 blocking 'domain controller' role
18:20:44 <sgallagh> I just hit this as well (setting up a system to test that firefox cert issue)
18:21:14 <sgallagh> Oh, actually I *do* have a related AVC for that
18:21:21 <jkurik> ack
18:21:29 <Southern_Gentlem> ack
18:21:46 <adamw> sgallagh: if you're not using 4.6.0-3 from updates-testing you'll have four AVCs for a rolekit_tmp type
18:22:02 <sgallagh> Oh
18:22:07 <sgallagh> I'm using -2
18:22:10 <adamw> 4.6.0-3 fixes those, so all the AVCs we could see are gone now, but it *still* doesn't work. :P
18:22:12 <sgallagh> Never mind, then
18:22:18 <adamw> try it with 4.6.0-3
18:22:31 <adamw> one more ack?
18:22:41 <sgallagh> ack
18:22:43 <adamw> #agreed 1491508 - AcceptedBlocker (Beta) - once again, violates "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 blocking 'domain controller' role
18:22:49 <adamw> #topic (1491459) shim.efi missing from EFI partition, causes upgraded systems not to boot
18:22:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1491459
18:22:50 <adamw> #info Proposed Blocker, shim-signed, MODIFIED
18:22:51 <adamw> last one
18:22:59 <jkurik> \o/
18:23:03 <Southern_Gentlem> +1
18:23:08 <adamw> people have been reporting this all week but i just got around to pinning it down yesterday
18:23:39 <adamw> it's pretty simple, pjones forgot to include a UEFI bootloader executable with the same name as in previous releases after all his rejigging, so existing installs couldn't find the bootloader they were looking for
18:23:48 <adamw> he fixed it a while ago but didn't submit an update
18:23:54 <jkurik> +1 blocker
18:24:05 <adamw> uh, i mean, he did submit an update, we just didn't grok it was a blocker bug.
18:24:09 <sgallagh> adamw: Did this change go to F26 as well?
18:24:10 <adamw> so, +1 for me.
18:24:29 <adamw> sgallagh: nah, all this renaming stuff is F27+ only, for the 32-on-64 firmware thing.
18:24:30 <sgallagh> Because I think this might explain the upgrade nightmare I had last weekend on my parents' system
18:24:35 <sgallagh> Hmm
18:24:40 <sgallagh> ok then
18:24:48 <sumantrom[m]> +1 for me too
18:24:51 <sgallagh> +1
18:25:09 <adamw> proposed #agreed 1491459 - AcceptedBlocker (Beta) - violates the upgrade criteria for upgrades of UEFI installs (upgraded system may well not boot)
18:25:17 <jkurik> ack
18:25:28 <Southern_Gentlem> ack
18:26:02 <sumantrom[m]> ack
18:26:31 <mboddu> ack
18:26:36 <adamw> #agreed 1491459 - AcceptedBlocker (Beta) - violates the upgrade criteria for upgrades of UEFI installs (upgraded system may well not boot)
18:26:44 <adamw> alrighty
18:26:50 <adamw> #info that's all the blockers
18:27:00 <adamw> #info we have a bunch of proposed FEs too, but we don't really have time to go over those
18:27:15 <adamw> if folks can vote on them in-bug that'd be great, at least ones that look like they might get fixed.
18:27:34 * adamw hands back to jkurik and runs out to the hairdressers
18:27:57 <jkurik> thanks adamw and enjoy the hairdressers
18:28:08 <jkurik> so, once more....
18:28:44 <jkurik> #topic Open floor
18:28:45 <jkurik> anything else to discuss today on this meeting ?
18:29:02 <jkurik> otherwise I am closing the meeting in 1 minute
18:30:17 <jkurik> Thanks people for joining the meeting
18:30:24 <sumantrom[m]> nothing from my end
18:30:36 <jkurik> Lets meet in approx. 30 minutes on the Readiness meeting
18:30:45 <jkurik> #endmeeting