16:00:22 <adamw> #startmeeting F27-blocker-review
16:00:22 <zodbot> Meeting started Mon Oct 23 16:00:22 2017 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:22 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:00:38 <adamw> #meetingname F27-blocker-review
16:00:38 <zodbot> The meeting name has been set to 'f27-blocker-review'
16:00:38 <adamw> #topic Roll Call
16:00:44 <adamw> morning folks, who's around to review some blockers?
16:01:19 <frantisekz> Hey Adam, I am around :)
16:01:32 <frantisekz> .hello2
16:01:33 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:01:40 <Kohane> Hi! Good afternoon.
16:01:46 * pschindl is here
16:02:24 <Kohane> .hello lailah
16:02:25 <zodbot> Kohane: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:02:37 * mkolman is likely to be there for a bit more today
16:02:45 * kparal is here for limited time, probably around 90 minutes
16:03:55 <adamw> .fire kparal
16:03:55 <zodbot> adamw fires kparal
16:04:07 <kparal> great, bye!
16:04:18 <Kohane> wow
16:04:20 * kparal has left the room
16:04:28 * coremodule is here.
16:04:39 <frantisekz> ... :D
16:04:39 * adamw hires kparal on a lower salary, working from the parking lot
16:04:50 <Kohane> LOL
16:04:57 * kparal decreases the available time slot to 9 minutes
16:05:02 <adamw> =)
16:05:06 * sumantrom[m] is here
16:05:19 <adamw> #chair kparal pschindl
16:05:19 <zodbot> Current chairs: adamw kparal pschindl
16:05:30 <adamw> alrighty, let's get going
16:06:05 <adamw> #topic Introduction
16:06:05 <adamw> Why are we here?
16:06:05 <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:06:05 <adamw> #info We'll be following the process outlined at:
16:06:06 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:07 <adamw> #info The bugs up for review today are available at:
16:06:09 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:13 <adamw> #info The criteria for release blocking bugs can be found at:
16:06:15 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:06:17 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria
16:06:19 <adamw> #link https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria
16:06:23 <adamw> #info Note we'll be reviewing both 'main stream' and Server blockers / FEs today
16:06:55 <kparal> booooring
16:06:57 <adamw> #info for Fedora 27 Final, we have:
16:06:57 <adamw> #info 8 Proposed Blockers
16:06:58 <adamw> #info 3 Accepted Blockers
16:06:58 <adamw> #info 0 Accepted 0-day Blockers
16:06:59 <adamw> #info 1 Accepted Previous Release Blockers
16:06:59 <adamw> #info 9 Proposed Freeze Exceptions
16:07:02 <adamw> #info 1 Accepted Freeze Exceptions
16:07:17 <adamw> #info for Fedora 27 Server Beta, we have:
16:07:17 <adamw> #info 5 Proposed Blockers
16:07:18 <adamw> #info 0 Accepted Blockers
16:07:18 <adamw> #info 0 Accepted 0-day Blockers
16:07:18 <adamw> #info 0 Accepted Previous Release Blockers
16:07:18 <adamw> #info 1 Proposed Freeze Exceptions
16:07:21 <adamw> #info 1 Accepted Freeze Exceptions
16:07:33 <adamw> who'd like to secretarialize?
16:08:32 <Kohane> I'm trying to read everything, give me a sec, please.
16:08:46 * kparal don't want to promise that today
16:09:37 * adamw grabs the Volunteer Pokin' Stick and goes on the prowl
16:09:41 <adamw> Kohane: it's mostly boilerplate
16:10:45 * kparal pokes pschindl frantisekz and coremodule
16:10:49 <adamw> sumantrom[m]: coremodule: have either of you secretarialized before?
16:11:05 <kparal> doh, I forgot about sumantrom[m], sorry sumantrom[m] :)
16:11:35 <coremodule> Yeah, I'll do it.
16:11:46 <kparal> it's easy, like learning how to swim
16:12:04 <kparal> we'll drop you to the water and you'll learn it magically
16:12:16 <frantisekz> or not... :)
16:12:21 <ignatenkobrain> :D
16:12:30 <kparal> frantisekz: in that case... next!
16:12:35 <frantisekz> :O
16:13:04 <Kohane> adamw I don't know what is a boilerplate. Anything to do with cooking?
16:13:26 <adamw> sigh, my desktop just hung. did anyone volunteer?
16:13:33 <kparal> coremodule did
16:13:45 <adamw> Kohane: sorry, jargon term :) it means those big chunks of text that you see in things like ads, that you don't usually really read all of
16:13:52 <kparal> and you missed my awesome jokes, shame on you
16:13:58 <adamw> whew, dodged a bullet there
16:14:06 <adamw> #info coremodule will secretarialize
16:14:13 <adamw> alrighty, let's get going!
16:14:25 <Kohane> adamw  Oh! Okay. Learnt something new. Thanks!
16:14:39 <sumantrom[m]> Hi kparal
16:14:47 * pwhalen is here
16:15:11 <adamw> starting with proposed F27 Final blockers:
16:15:11 <adamw> #topic (1503496) FileNotFoundError: [Errno 2] No such file or directory: 'grub2-mkconfig'
16:15:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1503496
16:15:12 <adamw> #info Proposed Blocker, anaconda, POST
16:15:28 <adamw> as I read it, this would prevent all Mac UEFI installs from working.
16:15:30 <sumantrom[m]> I will learn :D
16:15:40 <adamw> (which really just means all Mac installs)
16:16:00 <pwhalen> +1
16:16:28 <Kohane> Okay, this is a blocker indeed.
16:16:36 <kparal> +1
16:16:40 <frantisekz> +1
16:16:40 <Kohane> +1
16:16:45 <sumantrom[m]> +1
16:17:00 <kparal> adamw: exactly, jkonecny talked to me in person about this
16:17:24 <pschindl> +1
16:17:34 <ignatenkobrain> +1
16:18:13 <adamw> proposed #agreed 1503496 - AcceptedBlocker (Final) - violates "The installer must be able to install into free space alongside an existing OS X installation, install and configure a bootloader that will boot Fedora" (and all 'must complete installation' criteria for Macs)
16:18:22 <adamw> kparal: could you get him to test the updates.img?
16:19:25 <pwhalen> ack
16:19:26 <kparal> I can try
16:19:30 <kparal> ack
16:19:36 <Kohane> ack
16:19:42 <pschindl> ack
16:19:45 <frantisekz> ack
16:19:59 <adamw> #agreed 1503496 - AcceptedBlocker (Final) - violates "The installer must be able to install into free space alongside an existing OS X installation, install and configure a bootloader that will boot Fedora" (and all 'must complete installation' criteria for Macs)
16:20:04 <kparal> but I assume we'll need to test it ourselves, not sure if they have a mac
16:20:10 <adamw> #topic (1489942) dbxtool fails at boot 'Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Permission denied'
16:20:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1489942
16:20:10 <adamw> #info Proposed Blocker, dbxtool, ON_QA
16:20:14 <kparal> (let's action someone)
16:20:19 <sumantrom[m]> ack
16:20:40 <adamw> so I was wrong about this being aarch64-specific, for the record
16:20:48 <adamw> it likely occurs on all UEFI installs, x86_64 or aarch64
16:22:43 <adamw> so it's a conditional violation of the 'no failed services on install and boot' criterion
16:22:52 <kparal> is there any negative impact?
16:23:20 <kparal> because we have some provision there about hardware dependent services, which seems to be this one as well?
16:23:21 <adamw> well, AIUI this is the Secure Boot key blacklist updater
16:23:37 <adamw> i'd say it doesn't hit that provision
16:23:42 <kparal> does it fail on all instances (we encountered)?
16:23:47 <adamw> that provision is about 'services that require hardware which isn't present'
16:23:54 <adamw> this isn't that case
16:23:55 <Kohane> I don't know, I couldn't test this. I have no UEFI machine at hand. Sorry,
16:24:13 <kparal> well, +1 per criterion then
16:24:37 <adamw> hmm
16:24:50 <adamw> looking at it in more detail i'm not 100% sure about the circumstances for this one
16:25:00 <adamw> perhaps it's 'UEFI but non-Secure Boot installs'
16:25:52 <pwhalen> adamw, that would be the case for aarch64 ('UEFI but non-Secure Boot installs')
16:26:32 <kparal> if the service only fails if SB is disabled, then it could be understood as "hardware not present"
16:26:59 <adamw> kparal: i disagree, we wrote the exception for cases like rngd.service, where we're talking about an actual piece of hardware. secure boot isn't a piece of hardware.
16:27:10 <adamw> however, i'd say this one probably doesn't pass the last blocker test
16:27:39 <Kohane> So... what should we do?
16:27:42 <kparal> unless it has some bad consequences, which we don't know
16:27:44 <adamw> i suspect if this was the last blocker on the list at go/no-go we'd -1 it on the grounds that it's only conditional violation...
16:27:59 <adamw> kparal: if I'm reading the issue correctly, it doesn't.
16:28:05 <Southern_Gentlem> what iso does this effect ?
16:28:15 <adamw> kparal: note that pjones' latest attempt to fix it is simply about not printing any messages in this case: https://koji.fedoraproject.org/koji/buildinfo?buildID=987936
16:28:24 <adamw> Southern_Gentlem: i don't think the install source matters.
16:28:50 <Southern_Gentlem> give me a link to an iso and i will test it with vbox with uefi
16:29:11 <adamw> Kohane: as it's a 'conditional' violation - meaning the criterion is only broken in *some* cases, not all (or nearly all) cases - it becomes a subjective decision, which we talk out here
16:29:38 <adamw> Kohane: we generally try to balance how serious the issue is and how many people are likely to hit it, in evaluating 'conditional' cases like this
16:29:41 <kparal> "- Also don't return error if we're using --quiet and PK/KEK are absent."
16:29:48 <adamw> kparal: right.
16:29:53 <kparal> which kinds looks like hw missing (well, disabled in bios) :)
16:29:59 <adamw> kparal: no, it's not hw.
16:29:59 <Kohane> I would say -1 in this case.
16:30:02 <kparal> even though I don't know what PK/KEK is
16:30:03 <adamw> kparal: those are the keys related to secure boot.
16:30:09 <kparal> ok
16:30:09 <Kohane> adamw thanks for the explanation
16:30:24 <adamw> platform key / key encryption key. (iirc)
16:30:30 <kparal> I don't have a particular opinion in this case
16:30:43 <adamw> so i believe they're 'absent' when secure boot is disabled.
16:30:46 <kparal> I guess it wouldn't last the last blocker test, no
16:30:52 <adamw> oh, key exchange key. duh
16:31:12 <kparal> maybe consult the importance with pjones?
16:31:17 <kparal> and punt today?
16:31:30 <adamw> Kohane: so my evaluation in this case is that quite a lot of people are likely to hit this, but the impact of it is not that bad
16:32:11 <pwhalen> minimally I think we should do a FE, failed services look bad on a fresh install
16:32:22 <adamw> oh, it's also worth considering the intent of the criterion. this criterion is a 'polish' criterion: the reason we have it is that we think it looks quite bad if we have a Fedora release where everyone who installs it sees a failed service right away. it looks like we don't know what the hell we're doing.
16:32:29 <adamw> oh yeah, definitely +1 FE.
16:32:32 <Kohane> adamw that sounds like  "0"  (+1-1)
16:32:48 <adamw> i'm on balance -1 blocker as i suspect we wouldn't "really" block on this, if it came down to it. +1 FE
16:33:05 <adamw> kparal: i'm about 95% sure I know that the importance is 'low'.
16:33:12 <pwhalen> -1 blocker, +1 FE
16:33:23 <Kohane> Agree.
16:33:30 <sumantrom[m]> +1 FE -1 Blocker
16:33:35 <Kohane> -1 blocker +1 FE
16:33:54 <coremodule> +1 FER
16:33:57 <coremodule> *FE
16:33:59 <Southern_Gentlem> -1 bl;ocker +fe
16:34:12 <Southern_Gentlem> -1 blocker +fe
16:34:42 <kparal> wfm
16:35:55 <adamw> proposed #agreed 1489942 - RejectedBlocker AcceptedFreezeException (Final) - this is rejected as a blocker on the basis it won't affect all installs (we believe it affects UEFI non-Secure Boot installs) and there is no real practical consequence of the error. However, fixing this will improve release polish and that can't be done with an update, so accepted FE.
16:36:26 <coremodule> ack
16:36:26 <kparal> ack
16:36:29 <frantisekz> ack
16:36:31 <Kohane> ack
16:36:36 <pwhalen> ack
16:37:03 <adamw> #agreed 1489942 - RejectedBlocker AcceptedFreezeException (Final) - this is rejected as a blocker on the basis it won't affect all installs (we believe it affects UEFI non-Secure Boot installs) and there is no real practical consequence of the error. However, fixing this will improve release polish and that can't be done with an update, so accepted FE.
16:37:12 <adamw> #topic (1504059) Include Firefox 57 at compose
16:37:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1504059
16:37:13 <adamw> #info Proposed Blocker, distribution, NEW
16:37:42 <adamw> do we have anyone from fesco here?
16:38:11 <sgallagh> Sorry I’m late
16:38:30 <kparal> that page is really long. but if fesco decided that, I don't have a problem with it
16:38:35 <adamw> i'm not 100% clear whether fesco's decision on FF57 was "it can be in F27 final" or "it *MUST* be in F27 final"
16:38:55 <adamw> https://pagure.io/fesco/issue/1783 was the fesco ticket
16:39:29 <sgallagh> Oof, no it wasn’t.
16:39:58 <adamw> https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2017-10-13-16.01.log.html is the fesco meeting log
16:40:01 <adamw> sgallagh: ?
16:40:12 <sgallagh> I’m personally of the opinion that it doesn’t warrant an FE
16:40:22 <kparal> sgallagh: this is a blocker proposal
16:40:30 <kparal> but FE is the next question, yes
16:40:53 <sgallagh> Wait, what’s the reason for a blocker ?
16:41:04 <kparal> "Fesco decided to include Firefox 57 Beta at Fedora 27 compose."
16:41:17 <adamw> sgallagh: if we were gonna make it a blocker, it'd be on the grounds of 'fesco sez'
16:41:31 <adamw> (there is a clause in the process docs somewhere that allows fesco to declare any bug to be a blocker)
16:41:34 <kparal> I found in the ticket: "firefox 57beta is removed from f25/f26 updates-testing but stays in f27/rawhide. When final it out, maintainer is encouraged to allow extra time in f25/f26 for testing (+1:7, -1:0, +0:0)"
16:41:49 <adamw> there really isn't a lot of *context* in the meeting
16:42:04 <adamw> shortly after the discussion started, nirik proposed something that was more or less immediately agreed on:
16:42:05 <adamw> <nirik> I have a straw man proposal to try: proposal: firefox 57beta is removed from f25/f26 updates-testing... but stays in f27/rawhide. When final is out maintainer is encouraged to allow extra time in f25/f26 for testing.
16:42:05 <sgallagh> I don't recall us declaring that it MUST be in F27
16:42:17 <adamw> nirik then expanded "<nirik> that allows f27 to ship with something close to final firefox 57 (it releases a week later)"
16:42:26 <sgallagh> I think it was that we would not hold it back if it hit final upstream in time for F27
16:42:28 * nirik nods.
16:42:38 <sgallagh> ...
16:42:42 <adamw> the thing is, to me it reads as if it was written in the belief that ff57 was *already in* f27 stable
16:42:44 <nirik> shipping 56 and then immediately breaking everyone with 57 seems poor
16:43:03 <sgallagh> nirik: Better to break them right from the get-go? :)
16:43:05 <nirik> given that many people look for breakage at system upgrade boundries.
16:43:15 <adamw> given that that isn't in fact the case (it was in updates-testing at the time, and still is now), it's not entirely clear to me what fesco 'meant'
16:43:19 <nirik> people are looking for it, set time aside for it.
16:43:19 <kparal> sgallagh: there's nothing broken for clean installs
16:43:51 <nirik> if they do that, upgrade to f27, then a week later firefox update silently disables all their plugins, they are not likely to be happy.
16:44:13 <adamw> i think i'd be at least +1 FE, as to me the fesco decision at least seems to be clearly on board with *allowing* ff57 in f27 final. but i'm not sure about blocker.
16:44:35 <sgallagh> I'm still pissed off that Firefox didn't declare 56 to be an LTS to let people deal with this in a reasonable way
16:45:05 <nirik> IMHO we should pass the beta through asap, but then perhaps thats not what the rest of fesco wanted. :)
16:45:23 <Kohane> I'm getting lost...  Is it FF57 in F27, yes or no?
16:45:28 <adamw> sgallagh: oh, come on, that would've been far too sensible. :P
16:45:38 <sgallagh> Kohane: A beta of FF57 is in updates-testing at present
16:45:49 <adamw> Kohane: the bug is effectively requesting that we make ff57 in f27 a release blocker: ff57 *must* be in f27.
16:45:50 <Kohane> yes, I'm using it
16:46:08 <Kohane> oh, okay, now I get it
16:46:11 <sgallagh> The fact that FF57 Final isn't out really concerns me
16:46:16 <nirik> as is everyone else testing f27 since updates-testing is enabled by default. ;) well,unless you didn't ever apply updates
16:46:18 <Kohane> thanks sgallagh adamw
16:46:34 <sgallagh> It's not impossible that FF upstream will make further big changes before that.
16:46:37 <adamw> Kohane: this is based on a fesco ticket - #1783 - and a decision made in a fesco meeting. but it's not really quite clear precisely what fesco intended, given the wording of the agreement compared to the reality of what's actually going on in f27.
16:46:52 <sgallagh> Yeah, sorry about that.
16:46:55 <adamw> sgallagh: the ff57-ites seem to be behaving as if it won't
16:46:56 <nirik> "I expect latest beta (which becomes release-candidate and candidate) may be available one or two weeks before final release. Mozilla usually spins that builds for minor/internal issues which do not affect us."
16:47:02 <Kohane> uhm...  sounds bad...
16:47:15 <nirik> from firefox maintainer.
16:47:20 <adamw> right.
16:47:30 <adamw> when's the next fesco meeting?
16:47:34 <sgallagh> Friday
16:47:36 <nirik> friday
16:47:42 <adamw> hum, that's a while.
16:47:48 <adamw> i was gonna propose we punt to fesco to clarify their decision here
16:47:54 <adamw> any way we could get a decision from fesco faster?
16:48:03 <sgallagh> We could try to scrape up a quorum of FESCo real quick
16:48:04 <nirik> we could try...
16:48:43 <kparal> the decision could include FE status
16:48:58 <kparal> since blocker will be rejected, I assume
16:49:01 <adamw> okay, so proposal: we ask fesco to clarify their intent here, given the true circumstances (no ff57 build has yet landed in f27 stable but one is in updates-testing, ff57 final will likely not come out before f27 final but a late beta/rc should be available)
16:49:40 <Kohane> sounds reasonable
16:50:01 <sumantrom[m]> sounds good
16:51:08 <adamw> proposed #agreed 1504059 - punt (delay decision) - FESCo's intent is not clear to us, given the wording of their agreement and the lack of context in the meeting logs. we ask FESCo to clarify their intent on what should be done with FF57 in F27, given that it is *not* currently in stable but updates-testing and the maintainer would like to push it stable. does FESCo mean for this to be blocker, or FE, and exactly what ff57 build is it
16:51:08 <adamw> expecting, when?
16:51:16 <adamw> (will trim that a little)
16:51:37 * sgallagh feels like the answer should either be "ship 56 or slip Fedora to ship 57 Final"
16:51:51 <sgallagh> I don't like the idea of shipping a prerelease of a known-breaking change.
16:51:54 * nirik disagrees, but ok
16:52:05 * Kohane agrees with sgallagh
16:52:38 <nirik> sgallagh: we can try and vote in that existing ticket?
16:52:48 <adamw> do you guys agree with the proposal to have you disagree about it elsewhere and get back to us, though? :)
16:52:49 <sgallagh> yes
16:52:56 <sgallagh> adamw: yes
16:53:05 <kparal> ack
16:53:05 <sgallagh> also nirik: yes
16:53:06 <nirik> ack on proposal
16:53:10 <sgallagh> ack
16:53:12 <frantisekz> ack
16:53:15 <Kohane> adamw  +1 to the proposal
16:53:20 <sumantrom[m]> ack
16:54:24 <adamw> #agreed 1504059 - punt (delay decision) - FESCo's intent is not clear to us, given the wording of their agreement and the lack of context in the meeting logs. we ask FESCo to clarify their intent on what should be done with FF57 in F27, given that it is *not* in stable but updates-testing and the maintainer would like to push it stable. does FESCo mean for this to be blocker, or FE, and what ff57 build(s) is it expecting when?
16:54:40 <adamw> #topic (1497691) CVE-2017-14491 CVE-2017-14492 CVE-2017-14493 CVE-2017-14494 CVE-2017-14495 CVE-2017-14496 dnsmasq: various flaws [fedora-all]
16:54:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1497691
16:54:41 <adamw> #info Proposed Blocker, dnsmasq, ON_QA
16:54:56 <adamw> this is the famous 'krack' thing, basically; seems an obvious +1 to me, on the security criterion
16:55:21 <kparal> +1
16:55:21 <sgallagh> +1
16:55:23 <frantisekz> +1
16:55:40 <kparal> I wonder why we haven't pushed this already as FE
16:56:26 <coremodule> +1
16:56:26 <adamw> i didn't send a stable push request for a hot minute.
16:56:37 <sumantrom[m]> +1
16:57:10 <pschindl> +1
16:57:32 <adamw> proposed #agreed 1497691 - AcceptedBlocker (Final) - clearly violates "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)"
16:57:48 <adamw> (wifi usage in live mode / during install can't be fixed by an update)
16:57:58 <kparal> ack
16:57:59 <pschindl> ack
16:58:02 <frantisekz> ack
16:58:03 <coremodule> ack
16:58:04 <sumantrom[m]> ack
16:58:40 <Kohane> ack
16:58:43 <adamw> #agreed 1497691 - AcceptedBlocker (Final) - clearly violates "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)"
16:58:53 <adamw> #topic (1500834) VirtualBox: black screen on fedora 27
16:58:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1500834
16:58:54 <adamw> #info Proposed Blocker, kernel, MODIFIED
16:59:53 <adamw> vbox isn't in the criteria, iirc
16:59:56 <adamw> but it *is* widely used
17:00:03 <adamw> i'm probably -1/+1, but...any arguments?
17:00:55 <sumantrom[m]> +1 cz its widely used
17:01:08 <frantisekz> -1 blocker, +1 FE seems fine
17:01:16 <kparal> is there a workaround - basic graphics mode perhaps?
17:01:27 <kparal> otherwise we will doom the installer until F28
17:01:52 <kparal> yeah, the workaround is described in comment 0
17:01:56 <adamw> "The work around is to start the live image with basic graphic mode"
17:02:10 <kparal> -1/+1 I guess
17:02:27 <sgallagh> -1Blocker, +1 FE
17:02:53 <coremodule> +1 FE
17:02:59 <sumantrom[m]> +1 FE
17:03:10 <Kohane> -1 blocker +FE
17:04:43 <adamw> proposed #agreed 1500834 - RejectedBlocker (Final) AcceptedFreezeException (Final) - vbox isn't one of the officially-blocking virt technologies and a workaround is available so we don't think this qualifies as a blocker, but as vbox is widely used we certainly think it's worth a freeze exception
17:04:47 <frantisekz> ack
17:04:57 <sumantrom[m]> ack
17:04:58 <sgallagh> ack
17:05:03 <Kohane> ACK
17:05:07 <Kohane> ack
17:05:19 <pschindl> ack
17:05:43 <kparal> ack
17:06:08 <adamw> #agreed 1500834 - RejectedBlocker (Final) AcceptedFreezeException (Final) - vbox isn't one of the officially-blocking virt technologies and a workaround is available so we don't think this qualifies as a blocker, but as vbox is widely used we certainly think it's worth a freeze exception
17:06:15 <adamw> #topic (1501762) CVE-2017-5123 kernel: Missing access_ok() checks in waitid() [fedora-all]
17:06:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1501762
17:06:16 <adamw> #info Proposed Blocker, kernel, ON_QA
17:06:38 <adamw> so this is kind of a stand-in for *all* the CVEs fixed by the pending kernel update
17:06:41 <adamw> (there are a chunk)
17:07:07 <adamw> this one is rated Important - see https://access.redhat.com/security/cve/cve-2017-5123 - and obviously kernel security issues can't be fully fixed with an update, so i'm +1
17:07:21 <sgallagh> +1
17:07:22 <kparal> +1
17:07:25 <frantisekz> +1
17:07:28 <Kohane> +1
17:07:33 <sumantrom[m]> +1
17:08:49 <pschindl> +1
17:09:01 <skydiver> +1
17:09:22 <adamw> proposed #agreed 1501762 - AcceptedBlocker (Final) - violates "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)."
17:10:11 <kparal> ack
17:10:12 <pschindl> ack
17:10:17 <frantisekz> ack
17:10:26 <sgallagh> ack
17:10:27 <adamw> #agreed 1501762 - AcceptedBlocker (Final) - violates "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)."
17:10:29 <sumantrom[m]> ack
17:10:35 <adamw> #topic (1502915) World map missing in Time & Date
17:10:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1502915
17:10:35 <adamw> #info Proposed Blocker, libtimezonemap, ON_QA
17:10:42 <adamw> this is a fun one, because we really don't have a criterion that covers it
17:10:54 <adamw> i'm not sure what criterion i'd write to cover it, really...
17:11:20 <kparal> there's no loss in functionality
17:11:24 <kparal> it just looks bad
17:11:29 <kparal> so -1/+1 from me
17:11:50 <coremodule> Agreed, -1 blocker, +1 FE.
17:11:51 <sumantrom[m]> -1/+1
17:12:11 <frantisekz> -1, +1
17:12:34 <sgallagh> adamw: Isn't this the "basic functionality" criterion?
17:12:45 <Southern_Gentlem> -1 +fe
17:13:05 <adamw> sgallagh: sorry, which?
17:13:15 <kparal> sgallagh: hehe, that's inventive
17:13:18 <sgallagh> Oh, wait. This is in anaconda
17:13:24 <sgallagh> Not the installed desktop
17:14:12 <adamw> yeah.
17:14:24 <adamw> given that we have a fix, i think let's just go with -1/+1 and move on..
17:14:57 <adamw> proposed #agreed 1502915 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this does not seem to violate any existing criterion, but is a very obvious error in the installer so we're happy to grant it a freeze exception.
17:15:04 <Kohane> -1 +1
17:15:07 <frantisekz> ack
17:15:15 <sumantrom[m]> ack
17:15:20 <coremodule> ack
17:15:29 <Kohane> ack
17:15:39 <kparal> ack
17:15:52 <adamw> #agreed 1502915 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this does not seem to violate any existing criterion, but is a very obvious error in the installer so we're happy to grant it a freeze exception.
17:16:00 <adamw> #topic (1501362) Intel microcode not updating --> [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x25 (or later)
17:16:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1501362
17:16:00 <adamw> #info Proposed Blocker, microcode_ctl, ASSIGNED
17:16:54 <adamw> so my reading of this is it's really just a somewhat-scary message, it doesn't mean anything is really *broken*. i'm -1 blocker, probably -1 FE too as i think an update would probably be fine for dealing with this.
17:17:19 <sgallagh> I agree, -1/-1
17:17:35 <sgallagh> (Any fix to this is as likely to introduce new issues as it is to fix the warning)
17:17:43 <kparal> wfm
17:18:05 <Kohane> yeah, -1 blocker and -1 FE
17:18:10 <sumantrom[m]> wfm too
17:18:32 <frantisekz> -1 blocker, +1 FE
17:19:28 <adamw> proposed #agreed 1501362 - RejectedBlocker (Final) RejectedFreezeException (Final) - as we understand this, nothing is really broken, it's just a warning about a feature that could be enabled with a microcode update. we think a regular update is the best way to fix this, rushing a fix in via blocker/FE is not needed and potentially dangerous.
17:20:10 <frantisekz> ack
17:20:21 <sumantrom[m]> ack
17:20:38 <coremodule> ack
17:20:40 <kparal> ack
17:21:15 <Kohane> ack
17:22:54 <adamw> #agreed 1501362 - RejectedBlocker (Final) RejectedFreezeException (Final) - as we understand this, nothing is really broken, it's just a warning about a feature that could be enabled with a microcode update. we think a regular update is the best way to fix this, rushing a fix in via blocker/FE is not needed and potentially dangerous.
17:23:07 <adamw> OK, that's all the proposed Final blockers
17:23:16 <adamw> let's flip over to proposed Server Beta blockers before we do FEs
17:23:22 <adamw> #info continuing with proposed Server Beta blockers
17:24:10 <adamw> i'm going to skip the trackers that are set as blocking the tracker for now...
17:24:18 <adamw> will talk to sgallagh about what to do with those
17:24:57 <sgallagh> Sorry, I'm back
17:24:58 <adamw> well, hmm
17:25:06 <adamw> actually it was explicitly proposed, so let's do it.
17:25:16 <adamw> #topic (1474910) Host and Platform
17:25:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1474910
17:25:16 <adamw> #info Proposed Blocker, Changes Tracking, MODIFIED
17:25:51 <sgallagh> I'm not sure why mattdm proposed this
17:26:05 <sgallagh> Also, we should close it as it's complete.
17:26:26 <sgallagh> Or at least, it's functionally complete and the remainder are bugfixes.
17:29:45 <adamw> is there a rule about who closes Change bugs and when?
17:30:16 <Kohane> I don't remember that is any....
17:30:37 <sgallagh> I can never remember.
17:31:05 <adamw> #info sgallagh believes this bug should be closed, so we'll assume that's going to happen and move on.
17:31:13 <sgallagh> ack
17:31:15 <adamw> #undo
17:31:15 <zodbot> Removing item from minutes: INFO by adamw at 17:31:05 : sgallagh believes this bug should be closed, so we'll assume that's going to happen and move on.
17:31:27 <adamw> #info sgallagh believes this bug (1474910) should be closed, so we'll assume that's going to happen and move on.
17:31:33 <adamw> (easier to search)
17:31:42 <adamw> #topic (1492237) tracker bug for Update Fedora Release Criteria for Modular Server
17:31:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1492237
17:31:43 <adamw> #info Proposed Blocker, Changes Tracking, NEW
17:32:03 <adamw> the idea here is that we can't possibly decide whether this thing is ready to go until we've actually written/modified criteria for it.
17:32:09 <sgallagh> langdon promised to do this and hasn't, though I'm not sure whether the lack of blocker criteria is itself a blocker.
17:32:17 <sgallagh> That's all very philosophical.
17:32:39 * adamw puts on beret and turtleneck, looks for pipe
17:32:43 <kparal> no criteria, no problem -> just release
17:33:47 <kparal> automatic GO :)
17:34:15 <sgallagh> Woohoo, we're Ubuntu now!
17:34:20 * sgallagh ducks
17:34:28 <mattdm> I'm not trying to be overly bureaucratic, let alone completely academic...
17:34:41 <adamw> mattdm: here, have a turtleneck
17:34:44 <mattdm> but it seems like if we're going to do this *at all*, this part is kind of important
17:34:56 * mattdm sighs, pulls it on
17:35:46 <Kohane> I don't think the lack of a blocker critera is a blocker itself.
17:35:56 <adamw> i mean, i kinda agree with this theoretically. i dunno whether we really need it on the blocker tracker, but it probably wouldn't hurt either.
17:36:02 <Kohane> But that's just my opinion I guess.
17:37:12 <adamw> so in conclusion...meh?
17:37:20 <adamw> everyone toss a coin and vote, go
17:37:49 <Kohane> -1
17:38:42 <kparal> sure, +1
17:39:03 <sumantrom[m]> +1 :)
17:39:11 <mattdm> +1 because I just want to be able to track all the vital work in one place
17:39:13 <sgallagh> Landed on the edge
17:39:20 <frantisekz> +1
17:39:40 <sgallagh> I guess +1
17:39:46 * adamw blows on sgallagh's coin
17:40:00 <adamw> proposed #agreed 1492237 - AcceptedBlocker (Server Beta) - ok, sure, whatever
17:40:07 <sgallagh> *it falls down an A/C grate*
17:40:28 <adamw> sgallagh: well, too bad - that was all your money.
17:41:01 <mattdm> ack
17:41:06 <Kohane> ack
17:41:55 <sumantrom[m]> ack
17:42:05 <kparal> ack
17:42:20 <adamw> #agreed 1492237 - AcceptedBlocker (Server Beta) - ok, sure, whatever
17:42:25 <adamw> best. acceptance message. ever.
17:42:39 <adamw> #topic (1503321) FreeIPA server upgraded from F26 to F27 fails to start with "ModuleNotFoundError: No module named 'ipapython.secrets'"
17:42:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1503321
17:42:40 <adamw> #info Proposed Blocker, freeipa, NEW
17:42:46 <adamw> so, this one may get a bit controversial, i guess?
17:43:08 <adamw> it's a bit arguable whether the upgrade criteria cover this (and whether they *should*)
17:43:24 <adamw> the upgrade criterion says: "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed."
17:43:27 <adamw> with a footnote:
17:43:36 <adamw> "The upgraded system must meet all release criteria."
17:44:33 <kparal> and?
17:44:49 <sgallagh> This seems pretty straightforward to me
17:44:54 <sgallagh> +1 blocker
17:45:07 <kparal> I don't get why this is controversial
17:45:46 <adamw> well, maybe only to me. i guess i'm not sure we necessarily meant to cover every possible configuration of the default packages on upgrade, only out-of-the-box functionality
17:45:52 <adamw> but if we wanna just take it, hey, fine by me.
17:47:05 * kparal needs to depart, so he'll dodge this one (and all the next ones)
17:47:39 <sgallagh> adamw: Wait, what am I missing?
17:47:41 <adamw> .fire kparal again
17:47:41 <zodbot> adamw fires kparal again
17:47:59 <kparal> thanks, couldn't leave otherwise
17:48:22 <Kohane> adamw didn't you fire kparal already?
17:48:30 <adamw> sgallagh: well, the criterion talks about 'complete a direct upgrade from....installations of...Fedora...with that package set installed'
17:48:34 <adamw> Kohane: i fire him all the time!
17:48:53 <sgallagh> adamw: Oh, hang on. Is Custodia/Secrets an add-on? I guess I'd thought it was a default component. Is it optional?
17:48:53 <adamw> sgallagh: it doesn't say anything about, you know, installations with that package set installed and then some other stuff done to them (like deploying a freeipa server)
17:49:22 <sgallagh> Does it cause it to stop functioning as a basic domain controller when this happens?
17:49:24 <adamw> sgallagh: freeipa is on the server DVD by default, but it's not actually part of a default server install. and even if the packages were installed, the system isn't actually deployed as a freeipa server by default.
17:49:30 <adamw> sgallagh: yes.
17:49:58 <adamw> i'd say we probably *want* to have a criteria that says supported server roles must upgrade successfully, but arguably we don't actually have such a criterion at present.
17:49:59 <sgallagh> OK, then I'm going to +1 blocker this on the grounds that this causes it to fail to meet the server role criteria on upgrade
17:50:14 <adamw> i'm fine with going +1 and a #action to tweak the criterion a bit
17:51:01 <frantisekz> +1 blocker here
17:51:05 <mattdm> the freeipa role is basically the centerpiece functionality for Fedora server
17:51:12 <sumantrom[m]> +1 blocker
17:51:20 <mattdm> +1 with adam tweaking whatever he has to tweak to feel good about it :)
17:51:50 <adamw> =)
17:51:51 <adamw> okay
17:52:39 <adamw> proposed #agreed 1503321 - AcceptedBlocker (Server Beta) - adam's not entirely sure if the upgrade criterion technically covers this, but there's strong agreement that we do *intend* to require that release-blocking server roles upgrade successfully, so this is accepted and adam will propose a criteria change to make the intent clearer
17:52:52 <frantisekz> ack
17:52:56 <Kohane> ack
17:53:05 <sumantrom[m]> ack
17:53:36 <sgallagh> ack
17:53:44 <adamw> #agreed 1503321 - AcceptedBlocker (Server Beta) - adam's not entirely sure if the upgrade criterion technically covers this, but there's strong agreement that we do *intend* to require that release-blocking server roles upgrade successfully, so this is accepted and adam will propose a criteria change to make the intent clearer
17:53:51 <adamw> #topic (1504602) Image build fails because of dracut warning "/dev/root does not exist"
17:53:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1504602
17:53:52 <adamw> #info Proposed Blocker, lorax, NEW
17:55:54 <adamw> well, assuming this is still current, it's obviously a blocker
17:55:59 <adamw> can't ship something we can't build...
17:56:07 <adamw> oh
17:56:10 <adamw> but it's only two arches...
17:56:18 <sgallagh> I fixed this on Friday
17:56:41 <adamw> modular 27 composes *are* currently failing, though.
17:56:43 <sgallagh> Or, wait.
17:56:50 <Kohane> Did you already fixed it sgallagh ?
17:56:53 <sgallagh> This might be a different one. I need to double-check
17:57:24 <sgallagh> Well, it's a blocker in any case.
17:57:28 <sgallagh> Because these failures cascade
17:58:22 <adamw> the report only lists two, non-blocking arches, though
17:58:33 <adamw> do we know if this is still happening, and affecting armhfp or x86_64 ?
17:59:18 <sgallagh> adamw: As described, it's a blocker. If it got resolved since I last looked, so much the better
17:59:37 * mattdm afk for about 15 minutes
17:59:49 <sgallagh> Because right now the composes, if they fail, fail for all of the arches because of Reasons
18:00:24 <adamw> ah, i see.
18:00:49 <adamw> so even though:
18:00:49 <adamw> https://koji.fedoraproject.org/koji/taskinfo?taskID=22555870
18:01:05 <adamw> succeeded on armhfp and x86_64, the overall failure of the task dooms the compose?
18:01:31 <sgallagh> Yes
18:02:12 <adamw> okay.
18:02:14 <sgallagh> If it turns out I'm wrong, I'll propose to strike the blocker status
18:02:19 <adamw> fine
18:02:52 <adamw> proposed #agreed - 1504602 - AcceptedBlocker (Server Beta) - we believe this failure dooms the compose even though the task only fails on two non-blocking arches, thus this is accepted as it prevents compose working at all
18:03:34 <Kohane> ack
18:03:47 <frantisekz> ack
18:04:31 <mkolman> IIRC the cascading compose failures have been there for a while
18:04:42 <mkolman> even on regular non modular Fedora
18:04:47 <mkolman> (at least IIRC)
18:04:57 <sgallagh> ack
18:05:32 <adamw> mkolman: the regular composes are set up a bit better so that failures in the non-blocking arches don't usually fail the compose, i think
18:05:50 <adamw> mkolman: failures to build release-blocking images on release-blocking arches fail the entire compose by design
18:05:57 <adamw> #agreed - 1504602 - AcceptedBlocker (Server Beta) - we believe this failure dooms the compose even though the task only fails on two non-blocking arches, thus this is accepted as it prevents compose working at all
18:06:06 <adamw> #topic (1504745) Modular server autopart gives invalid partitioning
18:06:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1504745
18:06:06 <adamw> #info Proposed Blocker, python-blivet, NEW
18:06:55 <adamw> seems blocker-y as described, prevents compose on a blocking arch (armhfp)
18:08:55 <frantisekz> +1 blocker
18:09:09 <Kohane> +1 blocker
18:09:59 <sumantrom[m]> +1 blocker
18:10:07 * mkolman remembers something about non-blocking arch failure a while ago failing a lot of rawhide composes, but it might have been changed since then
18:10:58 <adamw> mkolman: yeah, it has been adjusted some.
18:11:25 <adamw> proposed #agreed 1504745 - AcceptedBlocker (Server Beta) - this prevents some images building on a release-blocking arch (armhfp)
18:11:54 <frantisekz> ack
18:12:21 <sumantrom[m]> ack
18:14:14 <Kohane> ack
18:15:06 <adamw> #agreed 1504745 - AcceptedBlocker (Server Beta) - this prevents some images building on a release-blocking arch (armhfp)
18:15:32 <adamw> #info that covers proposed server blockers and also FEs, as the only proposed FE was accepted as a blocker
18:15:39 <adamw> #info returning to proposed Final FEs
18:15:52 <adamw> #topic (1478141) Anaconda gives a traceback if there is non-activated InfiniBand network device present during an attempt to install in text mode
18:15:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1478141
18:15:53 <adamw> #info Proposed Freeze Exceptions, anaconda, MODIFIED
18:16:08 <adamw> as described, sounds like a clear +1 to me, avoiding installer tracebacks is good.
18:16:39 <frantisekz> +1 blocker
18:17:39 <adamw> FE, not blocker
18:17:45 <adamw> (is the proposal)
18:18:01 * mattdm is excited that someone is testing infiniband
18:18:11 <Kohane> What thing is Infiniband?
18:18:51 <Kohane> Oh, now I see
18:19:11 <adamw> mattdm: i suspect it was just a case of the hardware happening to be lying around, but...:)
18:19:13 <Kohane> I didn't know it existed, sorry.
18:19:37 <mattdm> it's important in hpc
18:20:10 * mkolman notes Anaconda supports even crazier hardware, specially in the s390 land
18:21:02 <adamw> so, votes?
18:21:16 <mattdm> +1 fe
18:21:18 <sharkcz> +1 FE as I'm waiting for my FE :-)
18:21:59 <sumantrom[m]> +1
18:22:02 <sumantrom[m]> FE
18:22:09 <frantisekz> +1 fe then :)
18:22:15 <Kohane> +FE
18:22:21 <Southern_Gentlem> +1fe
18:22:29 <adamw> roger
18:22:38 <Kohane> +1 FE
18:22:56 <adamw> proposed #agreed 1478141 - AcceptedFreezeException (Final) - this obviously can't be fixed by an update and will inconvenience anyone who runs into it, fixing it is definitely worth a freeze exception
18:23:05 <Southern_Gentlem> ack
18:23:24 <frantisekz> ack
18:23:32 <sharkcz> ack
18:23:39 <Kohane> ack
18:24:11 <sumantrom[m]> ack
18:24:27 <adamw> #agreed 1478141 - AcceptedFreezeException (Final) - this obviously can't be fixed by an update and will inconvenience anyone who runs into it, fixing it is definitely worth a freeze exception
18:24:36 <adamw> #topic (1487787) corosync libraries built with work-in-progress fix in libqb so as to re-establishing compatibility with ld from binutils 2.29 unusuable on powerpc platforms for further link
18:24:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1487787
18:24:36 <adamw> #info Proposed Freeze Exceptions, corosync, ON_QA
18:24:44 <adamw> well, i've now tried to read that three times
18:26:12 <adamw> anyone know what the heck this is about?
18:27:00 * mattdm reading still
18:27:19 <sharkcz> I guess libqb is doing some weird things with symbols it provides to its users and somehow newer binutils made some change, as result all these packages had to be be rebuilt
18:27:27 <adamw> ah, it seems like building various things against libqb will fail on a couple of arches...
18:27:55 <adamw> +1 fe, now i've read it.
18:27:58 <Southern_Gentlem> +1 FE
18:28:02 <sharkcz> +1 FE
18:28:17 <Kohane> +1 FE
18:28:22 <sumantrom[m]> +1 FE
18:28:28 <frantisekz> +1 FE
18:30:42 <adamw> proposed #agreed 1487787 - AcceptedFreezeException (Final) - this seems to affect build and correct functionality of several packages and dependency chains on a couple of non-release blocking arches, it would be good to straighten that out in stable rather than waiting for a post-release update
18:30:53 <sumantrom[m]> ack
18:30:54 <sharkcz> ack
18:30:56 <frantisekz> ack
18:31:51 <adamw> #agreed 1487787 - AcceptedFreezeException (Final) - this seems to affect build and correct functionality of several packages and dependency chains on a couple of non-release blocking arches, it would be good to straighten that out in stable rather than waiting for a post-release update
18:32:03 <adamw> #topic (1499260) Failing HTM tbegin for z Series guests despite claiming support.
18:32:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1499260
18:32:04 <adamw> #info Proposed Freeze Exceptions, glibc, ON_QA
18:32:23 <sharkcz> it blocks the s390 installer to even start
18:32:52 <adamw> yeah
18:32:56 <adamw> so on that basis, +1 FE
18:33:00 <sharkcz> and needs glibc build with disabled performance optimalization of lock handling
18:33:45 <sharkcz> there is already +2 FE in the bug, any more votes?
18:34:37 <Kohane> +1 FE
18:34:45 <frantisekz> +1 FE
18:34:57 <Southern_Gentlem> +1 fe
18:36:38 <adamw> proposed #agreed 1499260 - AcceptedFreezeException (Final) - this breaks installer boot on a non-blocking arch (ppc64), so obviously cannot be fully fixed with an update and is serious enough to grant an FE
18:36:47 <Southern_Gentlem> ack
18:36:50 <Kohane> ack
18:36:52 <sharkcz> adamw: s/ppc64/s390x/
18:37:09 <frantisekz> ack
18:37:12 <adamw> sorry, right
18:37:19 <adamw> will fix
18:37:29 <adamw> #agreed 1499260 - AcceptedFreezeException (Final) - this breaks installer boot on a non-blocking arch (s390x), so obviously cannot be fully fixed with an update and is serious enough to grant an FE
18:37:44 <adamw> #topic (1502827) gnome-initial-setup 'user creation' mode no longer runs after install with no user account (since 3.26.1)
18:37:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1502827
18:37:44 <adamw> #info Proposed Freeze Exceptions, gnome-session, NEW
18:39:38 <adamw> so i proposed this as FE because the criteria explicitly don't *require* that a firstboot utility run on install with no user (they just say that it *can*). but there is a blocker argument, i guess, in that if you do a Workstation install and don't create a user account, you can't really log into the installed system
18:39:41 <sharkcz> so you can only log in as root?
18:39:50 <adamw> well, I dunno if logging in as root from gdm works now...
18:39:53 <adamw> it didn't used to
18:40:37 <sharkcz> I would lean to a blocker as the system is not usable ...
18:41:40 <adamw> i'm definitely +1 FE at least
18:41:45 <Kohane> Yes, I can't imagine anyone not creating a user during the install process...
18:42:01 <Kohane> I mean, you can't use the system without a user anyway.
18:42:24 <frantisekz> +1 FE, I wont block on this
18:42:46 <Kohane> Neither I.
18:42:57 <Kohane> +1 FE
18:43:36 <sumantrom[m]> +1 FE
18:43:55 <adamw> Kohane: well, the behaviour where an initial-setup utility runs on first boot after install if you don't create a user during boot is fairly well known, some people may be accustomed to it and just rely on it
18:44:04 <sharkcz> is there a workaround? I mean to create a user when anaconda runs? /me has no experience with workstation
18:44:25 <adamw> sharkcz: well, the obvious workaround is just to create a user during install.
18:44:41 <sharkcz> ok, then +1 FE
18:44:42 <adamw> the other workaround would be to log in as root and create a user, either via a tty or from GNOME itself, if gdm does now allow you to log in as root
18:45:08 <Kohane> Yeah, but I think GDM doesn't allow root log in.
18:45:42 <halfline> pretty sure we backpedaled on that a couple of years ago
18:45:43 <Kohane> KDM does if you configure to it. Well, it used to do it, at least
18:45:44 <halfline> and do allow it
18:46:08 <adamw> okay
18:46:19 <adamw> let's accept as an FE for now
18:46:25 <adamw> if it gets fixed, no need to worry about blocker status
18:46:30 <adamw> if it doesn't we can argue about it again later...
18:46:59 <adamw> proposed #agreed 1502827 - AcceptedFreezeException (Final) - this is a prominent incorrect behaviour in the initial install and boot workflow, cannot be fully fixed with an update
18:47:22 <sharkcz> ack
18:47:28 <Kohane> ack
18:47:35 <frantisekz> ack
18:47:39 <sumantrom[m]> Ack
18:47:40 <adamw> #agreed 1502827 - AcceptedFreezeException (Final) - this is a prominent incorrect behaviour in the initial install and boot workflow, cannot be fully fixed with an update
18:47:51 <adamw> #topic (1478089) logging feature silently severed due to changed treatment of orphaned sections in ld.bfd/binutils-2.29
18:47:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1478089
18:47:51 <adamw> #info Proposed Freeze Exceptions, libqb, ON_QA
18:48:05 <adamw> this sounds like it's related to the one we just took as a server beta fe?
18:48:15 <adamw> er, sorry, we just took as a final fe earlier
18:48:19 <sharkcz> yup
18:48:30 <sharkcz> same with  	1503843 	pacemaker
18:48:59 <adamw> 1487787 was the one we discussed
18:49:55 <adamw> propose we skip this as we've already granted the same update an FE
18:50:10 <Kohane> I agree.
18:50:24 <sharkcz> ack, and skip 1503843 too
18:50:55 <sumantrom[m]> Ack
18:51:32 <adamw> #info we will skip 1478089 and 1503843 as they all seem to be covering broadly the same territory and we have granted an FE under 1487787
18:52:09 <adamw> #info we already discussed 1502915 as a proposed blocker and granted it accepted FE status
18:52:18 <adamw> #info ditto 1501362
18:52:28 <adamw> well, we rejected that one, but we discussed it.
18:52:39 <adamw> so, last one: #topic (1500734) CVE-2017-2888 SDL2: SDL: Integer overflow while creating a new RGB surface [fedora-all]
18:52:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1500734
18:52:40 <adamw> #info Proposed Freeze Exceptions, SDL2, VERIFIED
18:52:43 <adamw> grrr
18:52:45 <adamw> #undo
18:52:45 <zodbot> Removing item from minutes: INFO by adamw at 18:52:40 : Proposed Freeze Exceptions, SDL2, VERIFIED
18:52:46 <adamw> #undo
18:52:46 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x268834d0>
18:52:51 <adamw> #topic (1500734) CVE-2017-2888 SDL2: SDL: Integer overflow while creating a new RGB surface [fedora-all]
18:52:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1500734
18:52:51 <adamw> #info Proposed Freeze Exceptions, SDL2, VERIFIED
18:53:42 <sharkcz> +1 FE
18:53:49 <adamw> i might even call this a blocker...
18:53:56 <adamw> but definitely FE
18:54:09 <Kohane> +1 blocker
18:54:48 <sharkcz> right
18:55:31 <frantisekz> +1 blocker, security
18:55:51 <mattdm> what's the criteria for security issues being blockers?
18:56:20 <mattdm> that is, what level do they need to be rated at
18:56:31 <sumantrom[m]> +1 blocker
18:56:32 <adamw> "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation). "
18:56:44 <mattdm> well then. this one is "important"
18:56:51 <adamw> ah, it is? i couldn't find an official evaluation
18:57:09 <adamw> but 'potential code execution via rogue image file' sure sounds like it *ought* to be important
18:57:21 <sharkcz> impact=important in the CVE bug linked
18:57:23 <adamw> and I think SDL is on some of the live media
18:57:25 <adamw> ah, k
18:57:28 <adamw> so +1 blocker
18:57:31 <sharkcz> +1 blocker
18:57:58 <mattdm> and it's a dep of qemu
18:58:01 <adamw> proposed #agreed 1500734 - AcceptedBlocker (Final) - violates "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)", as this is rated 'important' and SDL may be used during live sessions
18:58:24 <frantisekz> ack
18:58:29 <mattdm> ack
18:58:37 <sharkcz> ack
18:59:16 <Kohane> ack
18:59:21 <adamw> #agreed 1500734 - AcceptedBlocker (Final) - violates "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)", as this is rated 'important' and SDL may be used during live sessions
18:59:26 <adamw> grr
18:59:29 <adamw> #agreed 1500734 - AcceptedBlocker (Final) - violates "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)", as this is rated 'important' and SDL may be used during live sessions
18:59:32 <adamw> (space)
18:59:41 <adamw> alright, that's all proposed blockers/FEs, right on the time limit
18:59:44 <adamw> #topic Open floor
18:59:49 <adamw> any other business, very quickly? any missed bugs?
18:59:54 <mattdm> #shippit
19:00:49 <adamw> the official hashtag of the fedora 27 release
19:00:53 <mkolman> there is a time limit for blocker bug meetings ?
19:01:02 <adamw> officially, yeah, we're supposed to cut off at 3 hours
19:01:20 <adamw> (we used to have like 6-hour long meetings which made everyone want to run away)
19:01:40 <Kohane> adamw not that I remember
19:01:45 <mattdm> 3 hour meetings make everyone want to run away too
19:01:47 <adamw> Kohane: it was a bit before your time
19:01:48 <adamw> mattdm: hehe
19:01:58 <Kohane> adamw  Thankfully
19:02:02 <adamw> when we used to not review beta or final blockers in earlier meetings
19:02:16 <adamw> so when we got to the first final blocker review meeting we'd have like 30 proposed blockers waiting to be evaluated
19:02:30 * Kohane faints
19:02:30 <adamw> i dunno why we ever did it that way, it was silly...
19:02:38 <Kohane> Indeed.
19:03:07 <adamw> welp, sounds like we're done here
19:03:12 <Kohane> adamw There were any breaks? Or it was 6 hours in a row?
19:03:12 <adamw> thanks for sticking it out everyone
19:03:22 <Kohane> No worries.
19:03:23 <adamw> Kohane: there are breaks whenever i need to go to the washroom :P
19:03:28 <frantisekz> adam, thanks for leading this :)
19:03:29 <Kohane> LOL
19:03:32 <sumantrom[m]> thanks adamw kpa
19:03:43 <sumantrom[m]> kparal  for hosting us :)
19:04:45 <mkolman> I kinda remember something like a continuous blocker meeting combined with a QA hero maraton
19:04:53 <mkolman> combined with some releng fun
19:05:01 <mkolman> back in the ~F20 timeframe
19:05:26 <Kohane> Back in the times I was using but not contributing to Fedora....
19:05:47 <adamw> mkolman: you're obviously not drinking enough
19:05:58 <adamw> on a proper drinking schedule you shouldn't be able to remember anything before fedora 25
19:06:20 * adamw sets the fuse
19:06:21 <mkolman> Fedora blocker bug drinking game ?
19:06:28 <mkolman> sounds perfectly doable :)
19:09:45 <Kohane> mkolman .....  I can imagine how the bugs will be cared of....
19:09:57 <adamw> thanks again everyone!
19:09:59 <adamw> #endmeeting