16:00:47 <adamw> #startmeeting F28-blocker-review
16:00:47 <zodbot> Meeting started Mon Apr 16 16:00:47 2018 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:47 <zodbot> The meeting name has been set to 'f28-blocker-review'
16:00:49 <adamw> #meetingname F28-blocker-review
16:00:49 <zodbot> The meeting name has been set to 'f28-blocker-review'
16:00:51 <adamw> #topic Roll Call
16:00:59 * kparal is here
16:00:59 <adamw> morning folks, who's around for blocker reviewwwwwwwwwwwwwwwww fun?
16:01:01 <sgallagh> .hello2
16:01:02 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:03 <adamw> also review
16:01:09 <frantisekz> .hello2
16:01:10 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:01:27 * lbrabec is here
16:01:46 * pwhalen is here
16:02:07 * jsmith lurks
16:02:20 <jsmith> (as I'll likely be leaving for lunch soon)
16:03:26 <adamw> new rule: all blockers are assigned to lurkers
16:03:32 <Southern_Gentlem> .hello jbwillia
16:03:33 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:03:35 <jsmith> adamw: Gee, thanks :-)
16:04:09 <jsmith> <humor>I guess I didn't do enough of a disaster as the FPL</humor>
16:04:35 <sgallagh> awwwwkward
16:04:59 <lroca> .hello roca
16:05:00 <zodbot> lroca: roca 'Luis Roca' <luisroca@protonmail.com>
16:05:32 <adamw> aw i mean you weren't that ba- oh. a joke? i mean, of course, a joke. ahahha. haha.
16:08:56 <adamw> sorry folks, short cat pill feeding break there.
16:09:02 <adamw> #chair kparal sgallagh
16:09:02 <zodbot> Current chairs: adamw kparal sgallagh
16:09:13 <adamw> #topic Introduction
16:09:13 <adamw> Why are we here?
16:09:13 <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:09:13 <adamw> #info We'll be following the process outlined at:
16:09:15 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:15 <adamw> #info The bugs up for review today are available at:
16:09:17 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:19 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:21 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:25 <adamw> #link https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria
16:09:27 <adamw> #link https://fedoraproject.org/wiki/Fedora_28_Final_Release_Criteria
16:09:49 <adamw> did someone volunteer to secretary yet?
16:11:08 * kparal points at frantisekz
16:12:11 <frantisekz> well... Kamil volunteered me, sigh :)
16:12:27 <Southern_Gentlem> frantisekz++
16:12:28 <adamw> eeeexcellent volunteering there
16:12:29 <adamw> kparal++
16:12:29 <zodbot> adamw: Karma for kparal changed to 10 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:12:35 * lroca hides behind curtains
16:12:38 <adamw> #info frantisekz will secretarialize
16:12:49 <adamw> lroca: you realize that counts as lurking?
16:12:55 <adamw> now you get to split the bugs with jsmithg
16:13:06 * lroca faints
16:13:08 <lroca> :)
16:14:27 <adamw> we have:
16:14:27 <adamw> #info 7 Proposed Blockers
16:14:27 <adamw> #info 5 Accepted Blockers
16:14:32 <adamw> #info 8 Proposed Freeze Exceptions
16:14:42 <adamw> so without further ado, let's get to the proposed blockers
16:14:46 <adamw> #topic (1566621) initial-setup fails on aarch64 disk images
16:14:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1566621
16:14:46 <adamw> #info Proposed Blocker, anaconda, ASSIGNED
16:15:51 <sgallagh> +1. It's a serious issue on a blocking arch and the anaconda folks have already acknowledged it.
16:16:19 <kparal> +1
16:16:36 <frantisekz> +1
16:16:38 <pwhalen> +1 of course
16:16:44 <lbrabec> +1
16:16:45 <mkolman> this will be very soon in POST thanks to vponcova :)
16:17:19 <pwhalen> awesome thanks mkolman, vponcova
16:17:25 <adamw> in fact it is now
16:17:26 * sumantrom is here
16:17:27 <Lailah> Hi
16:17:34 <Lailah> Sorry for been late
16:17:39 <Lailah> I mixed times again
16:17:40 <sumantrom> +1
16:17:45 <Lailah> .fas lailah
16:17:46 <zodbot> Lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:17:59 <adamw> hmm
16:18:06 <adamw> i thought anaconda was the 'normal' deployment method for aarch64?
16:18:10 <adamw> is it not, pwhalen?
16:18:21 <pwhalen> adamw, we also have disk images
16:18:27 <adamw> yes, we *have* them
16:18:44 <adamw> but that criterion was written on the basis that the disk images are the main way to deploy arm, on many of the supported platforms the *only* way
16:18:56 <adamw> it was written before aarch64 was release blocking, possibly before we even had it
16:19:05 <sgallagh> adamw: We have three blocking boards, at least one of them can only use the disk images (RPi3)
16:19:20 <adamw> if that's the case, then fine.
16:19:37 <adamw> and the disk image is marked as blocking on https://fedoraproject.org/wiki/Releases/28/ReleaseBlocking , so i guess that's covered.
16:20:01 <sgallagh> Right, to be clear it is conditionally blocking on that being one of the three boards.
16:20:18 <sgallagh> pwhalen can remind me which the other two are; one is an enterprise server.
16:20:21 <adamw> proposed #agreed 1566621 - AcceptedBlocker (Final) - accepted as a violation of "Release-blocking ARM disk images must boot to the initial-setup utility" (note that at least one blocking aarch64 platform can only deploy from disk images, and the aarch64 Server disk image is marked as release blocking)
16:20:29 <sumantrom> ack
16:20:31 <lbrabec> ack
16:20:35 <Lailah> ack
16:20:38 <lroca> ack
16:20:40 <pwhalen> ack
16:20:46 <sgallagh> ack
16:20:46 <frantisekz> ack
16:20:53 <jsmith> ACK
16:21:07 <pwhalen> sgallagh, pine64 and virt(sbsa) are the others
16:21:15 <sgallagh> thanks
16:21:26 <kparal> ack
16:21:33 <adamw> #agreed 1566621 - AcceptedBlocker (Final) - accepted as a violation of "Release-blocking ARM disk images must boot to the initial-setup utility" (note that at least one blocking aarch64 platform can only deploy from disk images, and the aarch64 Server disk image is marked as release blocking)
16:21:43 <adamw> #topic (1566344) Traceback from DNF
16:21:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1566344
16:21:43 <adamw> #info Proposed Blocker, dnf, POST
16:22:57 <Lailah> adamw: can you give me a quick brief of this? My laptop is slow and my connection is unreliable to say the least.
16:23:08 <adamw> it's new to me, i need to read it
16:23:16 <Lailah> By the time I'll get to read most likely you all read it.
16:23:27 <Lailah> Oh, then it's not just me. Okay.
16:24:07 <sgallagh> Short version: there was a bug in the switch from python-modulemd to libmodulemd and it's fixed upstream
16:24:50 <sgallagh> The bug would break anything involving modularity, so based on FESCo's declaration of modularity being a blocking issue, I think this is a clear +1
16:24:54 <adamw> oh, it's this one
16:24:56 <adamw> isn't this a dupe?
16:25:16 <adamw> or was this the original? hm
16:25:26 <Lailah> This is the original AFAIK
16:25:37 <sgallagh> mhatina marked another one as a dupe of this
16:25:44 <Lailah> It says that some another bug has been marked as duplicate if this one
16:26:05 <adamw> oh, never mind, i was confusing it with 1566593
16:26:38 <adamw> so upshot of this is, if you have the modularity repos enabled, almost any dnf thing is gonna crash?
16:26:51 <lroca> +1
16:27:10 <adamw> sgallagh: what is the status of the python-modulemd to libmodulemd migration? is that in stable? u-t?
16:28:37 <sgallagh> adamw: Well, we thought it was all in stable. Apparently some codepath that this triggered identified a place where it was still trying to use the previous API
16:28:40 <Lailah> Yeah, but there's a fix.
16:28:50 <Lailah> Well, in Github
16:29:32 <adamw> sgallagh: i'm trying to ascertain if this is broken right now, in stable, or if it's only going to break when some update gets pushed stable, or what
16:29:36 <sgallagh> Because python doesn't give us nice compilation warnings
16:29:40 <sgallagh> Oh
16:29:40 <adamw> but i guess we can approve it as a blocker and figure that out later
16:29:57 <adamw> so based on sgallagh's description, +1
16:29:57 <Lailah> Yes, I agree
16:30:00 <sgallagh> I think we have to approve it in any case
16:30:31 <sgallagh> Because it's all but certain we'll end up having another DNF build at some point before GA
16:31:22 <Lailah> And this is going to bother, isn't it?
16:32:26 <adamw> proposed #agreed 1566344 - AcceptedBlocker (Final) - accepted as a clear violation of the requirements for Modularity specified in https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6 , as FESCo has declared modularity blocking F28
16:32:44 <sumantrom> ack
16:32:45 <lbrabec> ack
16:32:53 <Lailah> ack
16:32:54 <lroca> ack
16:32:54 <sgallagh> ack
16:33:07 <frantisekz> ack
16:33:09 <kparal> ack
16:33:13 <jsmith> ACK
16:34:01 <adamw> #agreed 1566344 - AcceptedBlocker (Final) - accepted as a clear violation of the requirements for Modularity specified in https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6 , as FESCo has declared modularity blocking F28
16:34:18 <adamw> #topic (1566464) crypt in fedora28 does crash in code which works fine under fedora27
16:34:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1566464
16:34:19 <adamw> #info Proposed Blocker, glibc, NEW
16:35:14 <sgallagh> So, basic gist here: libxcrypt is a drop-in ABI-compatible replacement, but it is not *API*-compatible
16:35:38 <sgallagh> Meaning that an existing build will work fine, but rebuilding against libxcrypt requires changes
16:36:34 <sgallagh> My impression is that we're getting asked to override the glibc maintainers' intent to deprecate and remove the crypt() API from glibc
16:36:40 <kparal> thank you for a summary
16:37:22 <sgallagh> I humbly suggest that we should kick this one to FESCo as it directly impacts an approved F28 Change
16:38:55 <adamw> well, based on the bug so far i'm -1.
16:39:06 <adamw> nothing here is breaking any release blocking functionality in fedora, or even close to it.
16:39:26 <adamw> if fesco wants to weigh in on whether glibc team should change this they can feel free, but i am not seeing anything close to justification for blocking on this
16:39:30 <adamw> sgallagh: do you see anything?
16:40:11 <sgallagh> adamw: Nothing directly referenced here, no.
16:40:19 <adamw> so yeah, this is -1 for me.
16:40:40 <sgallagh> I wonder if this is going to have impact down the line with FreeIPA/dogtag stuff, but I agree; let's only block on it if we see that happen.
16:40:42 <adamw> we can tag it for release notes
16:40:43 <sgallagh> -1
16:40:57 <adamw> we've already rebuilt all of that stack with the updated glibc, haven't we?
16:41:13 <adamw> any other votes?
16:41:18 <sgallagh> adamw: Actually, I think you may be right.
16:41:25 <Southern_Gentlem> -1
16:41:36 <Lailah> -1
16:41:53 <pwhalen> -1
16:42:43 <kparal> -1
16:43:02 <lroca> -1
16:43:55 <sumantrom> -1
16:44:03 <adamw> proposed #agreed 1566464 - RejectedBlocker (Final) - this is an interesting issue and may well need to be prominently communicated, but nothing cited so far comes close to breaking any of the release criteria. no functional impact on any part of Fedora itself has yet been noted at all.
16:44:32 <lroca> ack
16:44:58 <pwhalen> ack
16:45:23 <frantisekz> ack
16:45:28 <kparal> ack
16:45:31 <Lailah> ack
16:45:39 <sgallagh> ack
16:46:03 <Southern_Gentlem> ack
16:46:31 <adamw> #agreed 1566464 - RejectedBlocker (Final) - this is an interesting issue and may well need to be prominently communicated, but nothing cited so far comes close to breaking any of the release criteria. no functional impact on any part of Fedora itself has yet been noted at all.
16:46:46 <adamw> #topic (1566566) The Fedora 28 KDE Live background wallpaper image is old (from Fedora 27)
16:46:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1566566
16:46:47 <adamw> #info Proposed Blocker, kde-settings, VERIFIED
16:46:50 <adamw> obvious +1
16:47:02 <Lailah> +1
16:47:13 <lroca> +1
16:47:30 <frantisekz> +1
16:47:36 <Southern_Gentlem> +1
16:47:46 <pwhalen> +1
16:48:07 <kparal> +1
16:48:23 * sgallagh weeps
16:48:31 <sgallagh> +1
16:49:53 <adamw> proposed #agreed 1566566 - AcceptedBlocker (Final) - clear violation of "The default desktop background must be different from that of the last two stable releases"
16:50:16 <frantisekz> ack
16:50:18 <sgallagh> ack
16:50:33 <kparal> ack
16:50:36 <Lailah> ack
16:50:50 <pwhalen> ack
16:51:07 <lroca> ack
16:52:26 <adamw> #agreed 1566566 - AcceptedBlocker (Final) - clear violation of "The default desktop background must be different from that of the last two stable releases"
16:52:37 <adamw> #topic (1567921) libmodulemd emits modulemd-defaults with incorrect keys
16:52:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1567921
16:52:37 <adamw> #info Proposed Blocker, libmodulemd, MODIFIED
16:54:12 <kparal> +1
16:54:13 <sgallagh> Right, so this one is on me
16:54:36 <sgallagh> It was fixed this morning and is targeted for stable.
16:54:55 <sgallagh> It's a definite +1 from the modularity perspective, as it renders the module default streams nonfunctional
16:55:06 <sgallagh> Or rather, the modules have no default streams without this.
16:55:20 <sgallagh> The modules still function, but they have to be manually enabled
16:55:32 <lroca> +1
16:55:41 <adamw> ok, +1 then
16:55:50 <Lailah> +1
16:56:06 <pwhalen> +1
16:56:42 * adamw recycles the agreement from earlier...
16:56:55 <adamw> proposed #agreed 1567921 - AcceptedBlocker (Final) - accepted as a clear violation of the requirements for Modularity specified in https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6 , as FESCo has declared modularity blocking F28
16:57:12 <kparal> ack
16:57:13 <sgallagh> ack
16:57:17 <Lailah> ack
16:57:18 <frantisekz> ack
16:57:18 <pwhalen> ack
16:57:22 <sumantrom> ack
16:57:56 <lroca> ack
16:58:45 <adamw> #agreed 1567921 - AcceptedBlocker (Final) - accepted as a clear violation of the requirements for Modularity specified in https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6 , as FESCo has declared modularity blocking F28
16:58:51 <adamw> #topic (1567897) Fedora Media Writer shows Fedora 26 instead of Fedora 27
16:58:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1567897
16:58:51 <adamw> #info Proposed Blocker, mediawriter, NEW
16:58:58 <adamw> uhhh...both those numbers seem small. :P
16:59:12 <kparal> yep, but that's not the point
16:59:25 <Lailah> Shouldn't be F28?
17:00:02 <kparal> honestly this is an epic fail for F27 and we should make sure it doesn't repeat for F28
17:00:14 <kparal> so a 0day blocker for updating releases.json
17:00:29 <kparal> I don't understand why it's not part of a releng process
17:00:42 <frantisekz> this wasn't an issue few weeks ago
17:00:51 <frantisekz> something must gone wrong recently
17:00:56 <kparal> ah
17:01:03 <kparal> so the contents got reverted somehow
17:01:27 <sumantrom> yes , it was alright when i tested it
17:01:28 <kparal> I found it weird that nobody complained
17:01:43 <adamw> it's probably my fault
17:01:47 <adamw> things usually are
17:01:50 <kparal> ha!
17:01:51 <lroca> Yes this is recent..
17:01:53 <lroca> :)
17:01:58 <kparal> you know what's coming...
17:02:01 <kparal> .fire adamw
17:02:01 <zodbot> adamw fires adamw
17:02:11 <Lailah> Wow
17:02:14 <frantisekz> this looks like it: https://pagure.io/fedora-websites/c/b550b9046cdffaa883cbfefac27a004027dd96ad
17:02:17 <Lailah> adamw got fired
17:02:18 <kparal> still, we don't really have a process for checking this. shouldn't we?
17:02:21 <sgallagh> That should really be special-cased to say "adamw quits"
17:02:38 <lroca> Just checked and yes, it is still the case right now
17:03:07 <sgallagh> We also don't have a criterion that specifically covers this, so far as I know
17:03:09 <adamw> sgallagh: it's funnier this way
17:03:25 <adamw> we could apply some criteria wd40 to the branding criterion...
17:03:38 <sgallagh> ah, that could work
17:03:54 <kparal> well our criteria say that FMW has to work
17:04:04 <frantisekz> FMW works just fine.... :)
17:04:15 * sumantrom seconds frantisekz
17:04:16 <kparal> that depends on users expectations
17:04:34 <adamw> i'm not sure if the blocker process is really the right...thing here
17:04:45 <sgallagh> kparal: Has to work to install the latest version?
17:04:52 <adamw> but, i mean, if we need a hammer to beat releng with...
17:05:14 <lroca> Being prompted to downgrade to f26? (:
17:05:15 <sgallagh> mboddu: Are you present?
17:05:25 <adamw> no? good, we can keep insulting him!
17:05:34 <kparal> we don't need a hammer, just a process to ensure this gets updated on release day. I remember the outdated content was an issue in the past as well
17:05:35 <sgallagh> ...
17:06:24 <kparal> but checking releng outputs is still qa job
17:06:32 <adamw> yeah, but a blocker bug won't get us a process, is the thing
17:06:37 <adamw> it'll get it updated by hand again
17:06:44 <adamw> then we'll file another blocker next time then it'll get updated by hand again...
17:06:50 <adamw> it's the fking desktop backgrounds all over again
17:06:58 <kparal> it will serve as a reminder for us, because we don't have a better way
17:07:08 <adamw> yeah
17:07:50 <sumantrom> [OT] the desktop background did change .... did anyone notice it?
17:08:20 <Lailah> Nope. I didn't. Where?
17:08:30 <adamw> basic criterion "Any component which prominently identifies a Fedora release version number, code name, milestone (Beta, Final), or Edition (Workstation, Server, Atomic) must do so correctly"
17:08:30 <kparal> anyway, the processes can get discussed separately from this. if we don't want to have a tracking 0day blocker bug, we'll need to remember to check this
17:08:41 * adamw applies wd40 liberally to the word "component"
17:09:05 <adamw> i can go for +1 0day blocker on that criterion, i guess.
17:09:12 <lroca> +1
17:09:17 <sumantrom> +1
17:09:20 <frantisekz> +1
17:09:21 * kparal found what wd40 is
17:09:22 <Lailah> +1
17:09:37 <kparal> +1
17:09:47 <pwhalen> +1
17:09:54 <adamw> kparal: https://www.flickr.com/photos/dullhunk/7214525854
17:09:59 <lbrabec> +1
17:10:02 <adamw> this is absolutely all you ever need to know about engineering
17:10:34 <kparal> adamw: love it
17:10:40 <sgallagh> +1
17:10:49 <Lailah> adamw: That's accurate
17:10:56 <lroca> duct tape is the most powerful force in the universe
17:11:08 <adamw> proposed #agreed 1567897 - Accepted0DayBlocker (Final) - accepted as a violation of "Any component which prominently identifies a Fedora release version number, code name, milestone (Beta, Final), or Edition (Workstation, Server, Atomic) must do so correctly", with a liberal interpretation of 'component' - as there is apparently no good process to ensure this is updated at each milestone, we will use the blocker process to do it
17:11:25 <frantisekz> ack
17:11:26 <sumantrom> ack
17:11:27 <lbrabec> ack
17:11:28 <lroca> ack
17:11:34 <Lailah> ack
17:11:36 <kparal> one question
17:11:43 <kparal> should this get moved to fedora-websites tracker?
17:12:06 <kparal> or is it fine to have it in its current place?
17:12:28 <Lailah> To me it's fine where it is now.
17:12:35 <adamw> no, i'd move it.
17:12:39 <frantisekz> IDK, I have fix for this, I'd love to create PR but our great Pagure keeps forking fedora-websites repo for ages
17:12:44 <adamw> it needs to be on some component where it's assigned to releng or websites people.
17:12:49 <adamw> mediawriter maintainers cannot do anything about it.
17:12:50 <kparal> adamw: is fedora-websites in bugzilla?
17:12:58 <adamw> dunno.
17:13:02 <adamw> just pick something close
17:13:13 <adamw> whatever gets it assigned to someone logical
17:13:13 <adamw> :P
17:13:18 <adamw> #agreed 1567897 - Accepted0DayBlocker (Final) - accepted as a violation of "Any component which prominently identifies a Fedora release version number, code name, milestone (Beta, Final), or Edition (Workstation, Server, Atomic) must do so correctly", with a liberal interpretation of 'component' - as there is apparently no good process to ensure this is updated at each milestone, we will use the blocker process to do it
17:13:30 <kparal> frantisekz: just assign it to adamw directly, problem solved
17:13:47 <frantisekz> :)
17:14:18 <adamw> .fire kparal
17:14:18 <zodbot> adamw fires kparal
17:14:26 <adamw> #topic (1539327) SELinux is preventing logrotate from using the 'dac_override' capabilities.
17:14:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1539327
17:14:26 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
17:14:43 <adamw> kparal: remember it's got to be assigned to lroca or jsmith
17:16:07 * lroca orders a case of duct tape and wd40
17:16:44 <adamw> i guess technically this won't appear *at* first login, but it could appear fairly close to it.
17:16:54 <adamw> i could be +1 or -1/+1 on this, kinda in the middle.
17:16:54 <sgallagh> I'm pretty sure I wouldn't give this a +1 blocker at Go/No-Go
17:16:58 <Lailah> Iroca: Isn't a box of it enough?
17:17:07 <sgallagh> I'd happily give it an FE however
17:17:08 <adamw> yeah, i guess i'm a bit more +1 fe
17:17:27 <Lailah> I don't think it's a Beta blocker. Maybe a FE
17:17:28 <lroca> Lailah: can never be too sure
17:17:40 <Lailah> Iroca:  Good point
17:17:55 <sgallagh> Lailah: We're doing Final blockers. Beta is already out
17:18:00 <lroca> Is this SELinux?
17:18:04 <sgallagh> (In case that changes your perspective)
17:18:10 <Lailah> Oh, sorry.
17:18:42 <Lailah> Well, not really. I'm still hesitating.
17:18:56 <Lailah> It's bad but...  I don't see it as a blocker.
17:19:18 <Lailah> sgallagh:  Sorry. Messy day today. I got confused.
17:19:23 <adamw> lroca: yes.
17:19:24 <sgallagh> It looks like the policy guys have a fix ready anyhow.
17:19:27 <kparal> you'll not like me (nothing new) but I think this fits into the spirit of the criterion, provided this occurs right after an update notification is shown
17:19:34 <sgallagh> So I'm comfortable with an FE for today
17:19:35 <adamw> we have a criterion which says 'no AVCs out of the box during install or immediately after install'
17:19:38 <sgallagh> Let them get it in.
17:19:46 <adamw> kparal: it's a *logrotate* avc.
17:19:52 <adamw> so, i mean, logically speaking, this is gonna happen when logs get rotated.
17:20:06 <kparal> so likely not right after install
17:20:10 <adamw> which...depends a bit on what packages you have installed and what log rotation policies they specify, but also depends on when you install, i guess.
17:20:28 <sgallagh> Yeah, not without a contributing factor like an initial-setup log getting out of control or somewhing
17:20:28 <adamw> it could potentially depend what time of day you install
17:20:36 <kparal> I also agree that the severity of this seems low
17:20:47 <adamw> but yeah, seems unlikely that everyone will see it right after intsall, which is the thing the criterion is trying to avoid
17:20:59 <adamw> so i guess i'd say let's +1 FE it and hope it's fixed and we don't have to worry about it again.
17:21:04 <lroca> ok then +1 FE
17:21:08 <sgallagh> adamw++
17:21:08 <kparal> I'm 0/+1
17:21:14 <sgallagh> -1 Blocker, +1 FE
17:21:29 <lroca> -1 Blocker, +1 FE
17:21:31 <Lailah> +1 FE
17:21:43 <sgallagh> (I'm still fairly confident that we'd not call ita  blocker at Go/No-Go, which to me is the final arbiter of whether it's truly a blocker)
17:22:31 <pwhalen> +1 FE
17:22:36 <adamw> proposed #agreed 1539327 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we don't believe this actually happens consistently to all installs right after install, which is the scenario the criterion is intended to prevent, so we don't think it quite qualifies as a release blocker. However, it is a polish issue and should be fixed, so we grant it a freeze exception, and expect it will be fixed soon
17:22:52 <frantisekz> ack
17:22:53 <lbrabec> ack
17:23:16 <Lailah> ack
17:23:16 <kparal> ack
17:23:19 <pwhalen> ack
17:23:20 <adamw> #agreed 1539327 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we don't believe this actually happens consistently to all installs right after install, which is the scenario the criterion is intended to prevent, so we don't think it quite qualifies as a release blocker. However, it is a polish issue and should be fixed, so we grant it a freeze exception, and expect it will be fixed soon
17:23:33 <adamw> that's all the proposed blockers
17:23:39 <Lailah> Okay
17:23:41 <adamw> #info moving onto proposed freeze exceptions
17:23:46 <adamw> #topic (1565369) dvd-ostree installs require network, even though they shouldn't
17:23:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1565369
17:23:47 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:24:23 <adamw> mkolman: out of interest, when is there likely to be a build with the fix for this? walters seems impatient. :P
17:26:28 <sgallagh> I'm not sure if I'm comfortable with an FE for this, honestly. The overwhelming majority of people installing the Atomic Workstation will have a network connection.
17:26:48 <sgallagh> And I don't love the idea of changing bits of Anaconda post-Freeze that aren't blockers.
17:27:40 <sgallagh> I guess I'd be okay as long as it's going in *today*
17:27:53 <adamw> it can't possibly go wrong, though
17:27:54 <adamw> :P
17:28:05 * sgallagh grabs the fire extinguisher
17:28:14 <sgallagh> (Well, one of the seven he keeps in arms' reach at all times...)
17:28:18 <adamw> (srsly the worst thing the change can possibly do is make dvd ostree installs not require network when they should, or keep them requiring it when they shouldn't, it really can't do anything else)
17:28:25 <Lailah> Seven?
17:28:35 <Lailah> Why so few?
17:28:47 <sgallagh> Lailah: I usually manage to keep the blazes down to around five at a time.
17:29:06 <Lailah> Now...  how many arms do you have?
17:29:20 <sgallagh> That's an awfully personal question, don't you think?
17:29:27 <adamw> sgallagh: this is not just about the atomic workstation, btw.
17:29:41 <adamw> we also have an atomic host dvd installer.
17:29:48 <Lailah> I imagine you with many arms and extinguishers
17:30:01 <sgallagh> Sure, but same argument.
17:30:15 <sgallagh> Who is going to install Atomic Host without a network? What would be the point?
17:31:04 <adamw> i'm +1
17:31:08 <adamw> everyone vote as you will
17:31:10 <adamw> and we'll count!
17:31:55 <lbrabec> +1
17:31:55 <frantisekz> +1
17:31:59 <lroca> +1
17:32:03 <sgallagh> 0
17:32:13 <Lailah> +1
17:32:18 <sgallagh> I'm not strongly opposed, but I'd prefer to avoid non-blocker anaconda changes
17:32:59 <pwhalen> +1
17:33:43 <adamw> proposed #agreed 1565369 - AcceptedFreezeException (Final) - this isn't a super important fix, but it is to the installer (so cannot be done post-install) and is pretty isolated and safe, so accepted as an FE issue so long as it lands soon
17:34:23 <kparal> ack
17:34:28 <lroca> ack
17:34:33 <sgallagh> ack
17:34:41 <lbrabec> ack
17:34:42 <adamw> #info sgallagh reserves the right to say he told us so
17:34:48 <Lailah> ack
17:34:55 * sgallagh always reserves that right
17:35:01 <adamw> #agreed 1565369 - AcceptedFreezeException (Final) - this isn't a super important fix, but it is to the installer (so cannot be done post-install) and is pretty isolated and safe, so accepted as an FE issue so long as it lands soon
17:35:03 <adamw> =)
17:35:12 <adamw> #topic (1567875) Update appstream-data after final freeze
17:35:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1567875
17:35:12 <adamw> #info Proposed Freeze Exceptions, appstream-data, NEW
17:35:57 <sgallagh> We should probably consider just making this an official schedule item
17:36:43 <kparal> +1
17:36:52 <lroca> Am I confused to think this falls into the same bucket with FMW?
17:37:07 <sgallagh> lroca: This isn't really branding
17:37:19 <sgallagh> It's making sure our tacked-on metadata matches the reality in our repositories.
17:37:36 <lroca> ah, got it
17:37:41 <sgallagh> I think there's a strong argument to be made that FESCo should formally add this to the schedule starting with F29
17:37:47 * sgallagh goes to do that.
17:38:14 <sgallagh> err, *propose* that
17:38:34 <sgallagh> I'm +1 BTW, in case that was unclear
17:38:59 <lroca> +1
17:39:42 <Lailah> +1
17:39:53 <lbrabec> +1
17:39:53 <frantisekz> +1
17:39:54 <pwhalen> +1
17:40:31 <adamw> this would be a 0-day again?
17:40:44 <adamw> oh, no, this is a package?
17:40:53 <sgallagh> yeah, it's a package
17:41:05 <adamw> ehhh i kinda hate that.
17:41:11 <adamw> getting spin-kickstarts updated is enough of a drag.
17:41:41 <adamw> but sure, +1 FE
17:42:12 <adamw> proposed #agreed 1567875 - AcceptedFreezeException (Final) - there's clearly a benefit to having the appstream data as up to date as possible with the packages included in Final, so updating it after freeze is a good idea
17:42:39 <Lailah> Are you sarcastic adamw ?
17:42:49 <adamw> er...no?
17:42:55 <Lailah> On this particular subject. The last message
17:43:02 <Lailah> Ah, okay.
17:43:22 <kparal> ack
17:43:27 <Lailah> ack
17:43:30 <lroca> ack
17:43:35 <lbrabec> ack
17:43:46 <pwhalen> ack
17:43:51 <adamw> #agreed 1567875 - AcceptedFreezeException (Final) - there's clearly a benefit to having the appstream data as up to date as possible with the packages included in Final, so updating it after freeze is a good idea
17:43:59 <adamw> #topic (1558425) [f28] kubelet.service fails to start: Failed to create "/kubepods" cgroup
17:43:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1558425
17:43:59 <adamw> #info Proposed Freeze Exceptions, docker, ON_QA
17:46:55 <Kohane> Meh...  I've got my nick changedd
17:47:00 <Kohane> changed*
17:47:19 <sgallagh> I'd like to know if this can be fixed in an update or if it's broken if you install kube from the frozen package set
17:47:42 <adamw> Kohane: no problem
17:47:54 <Kohane> adamw: thanks
17:48:01 <Kohane> I'm Lailah, just in case
17:48:09 <adamw> sgallagh: also important: how commonly would you *get* it from the frozen package set (i.e. is it likely to come in in a server dvd install...)
17:48:13 <adamw> Kohane: yeah, i know :)
17:48:17 <adamw> #Info Kohane == Lailah
17:48:24 <Kohane> Haha, you know everything
17:48:38 <sgallagh> adamw: I *think* it's part of the base atomic install, but that's less worrisome because their updates can definitely resolve it.
17:49:10 <sgallagh> I don't believe it's on the Server DVD, but I'm going to check now
17:49:14 <adamw> hum, it's fairly likely you'd get docker from the dvd...
17:50:08 <sgallagh> Right... but again I want to know if it's fixable with an update.
17:50:37 <sgallagh> Or if the first installation writes some configuration that breaks it from then on
17:51:04 <adamw> it doesn't read that way to me
17:51:23 <adamw> i do think atomic folks want the day 0 releases to work right, though...
17:51:41 <adamw> so i think i'd be +1 if this is in the base atomic install
17:52:35 <sgallagh> I'm just kind of wary about that whole stack. It tends to be dominoes.
17:53:07 <sgallagh> "runc needs an update? Well, that's not compatible with Docker, so lets bump that to the latest release... oh, that broke kubernetes..."
17:53:32 <sgallagh> That entire stack is almost as much of a Jenga Tower as FreeIPA
17:55:18 <sgallagh> I guess I'm +1 FE, but this one makes me nervous
17:55:33 <adamw> yeah, i'm +1 *for an update with lots of reassuring positive karma*
17:55:35 <Kohane> Why?
17:55:39 <adamw> i certainly agree on the jenga tower
17:55:42 <sgallagh> adamw++
17:56:52 <Kohane> Does adamw get any cookies?
17:57:12 <adamw> he already gave me them apparently
17:57:17 <sgallagh> Kohane: If adamw ate every cookie I've given him over the years, he'd be dead of diabetic shock by now :)
17:57:17 <adamw> you can only do it once per person per release cycle
17:57:24 * adamw feeds them to the yaks
17:57:29 <adamw> other votes?
17:57:33 <pwhalen> +1
17:57:35 <frantisekz> +1
17:57:40 <lbrabec> +1
17:57:42 <lroca> +1
17:57:43 <Kohane> +1
17:57:44 * pwhalen was hoping to see an answer in #atomic
17:57:58 <sgallagh> pwhalen: I tried
17:58:13 <pwhalen> :)
17:58:28 <adamw> proposed #agreed 1558425 - AcceptedFreezeException (Final) - we're willing to grant this an FE as it's important that this stack work in the day 0 Atomic images if possible, but it seems that this is a complexly interdependent stack so we really only want to pull in a well-tested update with lots of reassuring positive karma
17:58:33 <adamw> sgallagh: thanks for that
17:58:51 <lroca> ack
17:59:03 <sgallagh> Hold up
17:59:09 <adamw> holding
17:59:11 <sgallagh> They're responding in #atomic now
18:00:23 * adamw plays elevator muzak
18:00:34 <adamw> we thank you for your patience. your bugs are important to us
18:00:45 <Kohane> xD
18:00:49 <adamw> if you would like sgallagh to call back and reject them later, you can press '2' to leave a callback number
18:01:20 <sgallagh> Hey, *someone* has to balance out kparal !
18:01:56 <Kohane> Still with elevator music?
18:02:08 <adamw> sure, i've got the whole Comcast tape here
18:02:11 * lroca turns up Kenny G
18:02:13 <adamw> it's seventy six hours long
18:02:23 <adamw> it usually only loops two or three times before they pick up
18:02:29 <adamw> (there, how's my joke localization, merkins?)
18:02:32 <Kohane> (O_O)
18:03:02 <Southern_Gentlem> greatest hits of Doc Serverson
18:03:34 <sgallagh> adamw: Uh... maybe not the best choice of words.
18:04:29 <Southern_Gentlem> https://www.youtube.com/watch?v=dwkwjOd7MCU
18:04:50 <sgallagh> So, the conversation in #atomic is not giving me a positive impression.
18:05:04 <Kohane> Read it as...
18:05:34 <sgallagh> I'm overly conservative when it comes to Final Freeze and this sounds a little more intrusive than I'd like
18:06:05 <Kohane> ok
18:08:06 <adamw> i guess the obvious risk here is we wind up breaking docker, right?
18:08:27 <sgallagh> adamw: Also potentially flatpak
18:08:30 <adamw> fun,
18:10:54 <adamw> in a sense i want to punt on this for a clearer plan to evolve, but that puts us closer to release
18:11:00 <adamw> especially if we put till next monday...
18:11:05 <mclasen> don't break flatpak, please
18:11:28 <lroca> Are we still waiting on #atomic ?
18:12:08 <adamw> it's still under discussion there
18:12:14 <adamw> but i don't think we're gonna solve all the problems in the next ten minutes
18:13:01 <sgallagh> Yeah, shall we table this and move on while adamw and I continue that discussion in parallel?
18:13:03 <adamw> i'm thinking i'd maybe want to punt on this and if they're able to come up with a comprehensive fix that makes sense and tests out in the next few days, maybe vote on it offline
18:13:09 <adamw> sgallagh: wdyt?
18:13:17 <sgallagh> Sounds good to me
18:13:30 <Kohane> I prefer punt, yes
18:14:12 <lroca> punt
18:15:30 <adamw> mclasen: so sgallagh's thought that this bug could have consequences for flatpak was based on the idea that flatpak uses runc; could you maybe comment (or ask someone to comment) on the bug or in #atomic ?
18:15:44 <mclasen> that is not the case
18:16:03 <sgallagh> mclasen: What container runtime does it use?
18:16:04 <adamw> ok
18:16:23 * sgallagh just asked a minute ago in #fedora-workstation as well
18:16:32 <mclasen> just bubblewrap
18:16:53 <adamw> proposed #agreed 1558425 - punt (delay decision) - we don't want to delay *too* long on this, but it's a fairly complex area and it doesn't feel like folks have all the consequences of this entirely worked out yet, so we would like to wait a few days to see if a clearer pictures emerges and then perhaps vote async (in bugzilla comments) on this one
18:17:15 <Kohane> ack
18:17:32 <sgallagh> Oh goody, *another* low-level container runtime.
18:17:32 <frantisekz> ack
18:17:37 <lbrabec> ack
18:17:41 <adamw> sgallagh: this is fine.
18:17:41 <sgallagh> Because docker, runc and rkt weren't enough, apparently.
18:17:49 <mclasen> https://c1.staticflickr.com/4/3110/2790566367_a25b088baf_b.jpg
18:17:52 <sgallagh> Oh and nspawn
18:17:52 <Kohane> Folks, I'm leaving. See you later. Bye!
18:17:56 <mclasen> its not 'another container runtime'
18:17:56 <adamw> cya kohane
18:17:58 <Kohane> Happy meeting!
18:18:05 <Kohane> adamw: cya
18:18:06 <adamw> it's...a kitten?
18:18:12 <Kohane> Who?
18:18:12 <sgallagh> mclasen: OK, you just defused my argument. Well played, sir.
18:18:18 <sgallagh> adamw: On bubble-wrap
18:18:19 <adamw> if so, then i am strongly pro-bubblewrap and would like to subscribe to your newsletter
18:18:53 <adamw> #agreed 1558425 - punt (delay decision) - we don't want to delay *too* long on this, but it's a fairly complex area and it doesn't feel like folks have all the consequences of this entirely worked out yet, so we would like to wait a few days to see if a clearer pictures emerges and then perhaps vote async (in bugzilla comments) on this one
18:19:02 <lroca> ttfn Kohane
18:19:42 <adamw> #topic (1567727) f28-backgrounds-extras filename mismatches
18:19:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1567727
18:19:43 <adamw> #info Proposed Freeze Exceptions, f28-backgrounds, NEW
18:20:12 <Southern_Gentlem> +1 FE
18:20:26 <lroca> +1
18:20:46 <sgallagh> +1 FE
18:21:04 <lbrabec> +1
18:21:33 <pwhalen> +1
18:22:44 <frantisekz> +1
18:23:28 <adamw> sure, looks clear enough.
18:23:32 <adamw> i mean we could fix it with an update, but eh.
18:23:51 <sgallagh> Do these end up on the Live media?
18:24:02 <adamw> oh, good question, actually
18:24:06 <adamw> if not, i don't see that this needs an fe
18:24:35 <adamw> MATE live has f28-backgrounds-extras-base
18:25:03 <adamw> cinnamon has f28-backgrounds-extras-gnome
18:25:19 <adamw> so i guess I could +1 on that basis.
18:25:30 * sgallagh nods
18:26:41 <adamw> proposed #agreed 1567727 - AcceptedFreezeException (Final) - this affects use of the affected backgrounds on at least the MATE and probably the Cinnamon live images, so it's worth fixing in the frozen package set
18:26:59 <sgallagh> ack
18:27:08 <lroca> ack
18:27:22 <kparal> ack
18:27:42 * lroca has to step away
18:27:59 <adamw> cya lroca, thanks
18:28:05 <adamw> just remember to fix all these bugs ;)
18:28:09 <adamw> #agreed 1567727 - AcceptedFreezeException (Final) - this affects use of the affected backgrounds on at least the MATE and probably the Cinnamon live images, so it's worth fixing in the frozen package set
18:28:16 <adamw> #topic (1565757) Update Fedora Server logo for anaconda installer
18:28:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1565757
18:28:16 <adamw> #info Proposed Freeze Exceptions, fedora-logos, ON_QA
18:28:29 <adamw> sure, +1, we want it to look how we want it to look.
18:28:31 <lroca> err thanks adamw :)
18:29:50 <sgallagh> adamw: Given that it's mostly visible in the Installer image, can we get it pulled into the compose repo for any RCs/test composes we do?
18:30:18 <sgallagh> I tested it with an updates.img and it worked fine, but that's asking a bit much from the general populace
18:30:18 <adamw> that's...what granting it an FE does?
18:30:40 <Southern_Gentlem> +1 FE
18:30:45 <sgallagh> adamw: I thought it just meant that it would get pushed stable during freeze.
18:30:49 <adamw> well, not automatically, but i generally list pending FEs in the compose requests.
18:30:51 <sgallagh> Right now it's just in u-t
18:30:58 <adamw> we don't *do* so many candidate composes as we used to, though.
18:31:03 * sgallagh nods
18:31:18 <sgallagh> Right, my point was mainly that without a compose, this can't be easily tested
18:31:21 <adamw> you could just stick the updates.img on a public server and add a comment with the param to use
18:31:25 <sgallagh> (And with a compose, it's trivial to test)
18:31:26 <adamw> it's easy enough if you tell people how
18:31:34 <sgallagh> Hmm, probably true
18:32:15 <adamw> anyway, i'll test it later.
18:32:19 <adamw> any other votes?
18:32:43 <sgallagh> +1
18:32:47 <kparal> +1
18:32:52 <pwhalen> +1
18:34:46 <adamw> alrighty
18:34:48 <sgallagh> adamw: BZ updated as requested
18:35:04 <adamw> sgallagh: i actually meant the *update*
18:35:10 <adamw> as people doing update testing see the update description
18:35:12 <adamw> they don't see the bz
18:35:17 <sgallagh> ah
18:35:28 <adamw> well, they see the bz number, but they'd have to go out of their way to visit the bug to read it there.
18:35:42 <adamw> sgallagh: adding a comment on the update would work fine.
18:36:03 <adamw> proposed #agreed 1565757 - AcceptedFreezeException (Final) - obviously this change can't be done with an update, and it's an important change to Server branding, so we should get it in
18:36:19 <kparal> ack
18:36:33 * sgallagh was *really* trying to get this in before Freeze, but it was not to be
18:37:30 <adamw> freeze isn't yet, is it?
18:37:37 <adamw> there's 5 hours to go! plenty of time
18:37:41 <adamw> #agreed 1565757 - AcceptedFreezeException (Final) - obviously this change can't be done with an update, and it's an important change to Server branding, so we should get it in
18:38:21 <sgallagh> Hmm, this could arguably be a blocker under the branding criteria... but let's not worry about that
18:39:56 <adamw> YES LET'S NOT
18:40:08 <adamw> #topic (1566464) crypt in fedora28 does crash in code which works fine under fedora27
18:40:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1566464
18:40:08 <adamw> #info Proposed Freeze Exceptions, glibc, NEW
18:40:15 <adamw> this is that same one from earlier, also proposed as an FE>
18:40:24 <adamw> i'm sort of -1 FE here too, as, what would we be granting a freeze exception *to*?
18:40:37 <adamw> i'm at least -1 FE unless and until there's some sort of actual package-y change proposed.
18:41:56 <sgallagh> -1 FE
18:42:51 <kparal> -1 fe
18:44:43 <adamw> proposed #agreed 1566464 - RejectedFreezeException (Final) - this is rejected at least for now as there's no concrete proposal to actually change a package here, so no way to judge whether such a change would be appropriate. It can be re-proposed with a more specific suggestion if we get to one
18:45:33 <Southern_Gentlem> ack
18:45:58 <kparal> ack
18:46:19 <adamw> sgallagh: ?
18:47:45 <sgallagh> Sorry, ack
18:48:06 <sgallagh> Running up against meeting fatigue :)
18:48:21 <Southern_Gentlem> more rum
18:49:28 <adamw> #agreed 1566464 - RejectedFreezeException (Final) - this is rejected at least for now as there's no concrete proposal to actually change a package here, so no way to judge whether such a change would be appropriate. It can be re-proposed with a more specific suggestion if we get to one
18:49:32 <adamw> only two to go
18:49:47 <adamw> oh, and one is the promised clone...
18:49:51 <adamw> #topic (1567229) [f28] kubelet.service fails to start: Failed to create "/kubepods" cgroup
18:49:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1567229
18:49:51 <adamw> #info Proposed Freeze Exceptions, runc, ON_QA
18:50:04 <sgallagh> Proposed: Punt alongside the docker one
18:50:09 <adamw> #info this is a clone of the earlier-discussed #1558425 against runc
18:50:13 <adamw> agreed
18:50:41 <Southern_Gentlem> +1 Punt
18:50:43 <adamw> proposed #agreed 1567229 - punt (delay decision) - following 1558425, we don't want to delay *too* long on this, but it's a fairly complex area and it doesn't feel like folks have all the consequences of this entirely worked out yet, so we would like to wait a few days to see if a clearer pictures emerges and then perhaps vote async (in bugzilla comments) on this one
18:50:48 <Southern_Gentlem> ack
18:51:06 <sgallagh> ack
18:51:20 <kparal> ack
18:51:55 <adamw> #agreed 1567229 - punt (delay decision) - following 1558425, we don't want to delay *too* long on this, but it's a fairly complex area and it doesn't feel like folks have all the consequences of this entirely worked out yet, so we would like to wait a few days to see if a clearer pictures emerges and then perhaps vote async (in bugzilla comments) on this one
18:52:04 <adamw> #topic (1566140) pyanaconda.bootloader.BootLoaderError: could not find IPL device
18:52:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1566140
18:52:04 <adamw> #info Proposed Freeze Exceptions, s390utils, ON_QA
18:52:31 <sgallagh> As this one would be a blocker if it was a blocking arch, I'm +1 FE
18:52:47 <sgallagh> ... that was poorly phrased, but I think you take my meaning
18:54:13 <adamw> no, it makes perfect sense.
18:54:20 <adamw> also +1.
18:54:25 <kparal> +1
18:54:30 <adamw> obviously can't be fully fixed with updates.
18:54:42 <sumantrom> +1
18:55:02 <adamw> proposed #agreed 1566140 - AcceptedFreezeException (Final) - this is an install time issue (so can't be fully fixed with updates) and is quite serious, would be a blocker on release-blocking arches, so is obviously accepted as an FE
18:55:45 <kparal> ack
18:55:56 <sumantrom> ack
18:56:04 <sgallagh> ack
18:56:21 <Southern_Gentlem> ack
18:56:56 <adamw> #agreed 1566140 - AcceptedFreezeException (Final) - this is an install time issue (so can't be fully fixed with updates) and is quite serious, would be a blocker on release-blocking arches, so is obviously accepted as an FE
18:57:01 <adamw> alrighty, that's all the proposals, right on time
18:57:04 <adamw> sorry for the long meeting, folks
18:57:08 <adamw> #topic Open floor
18:57:14 <adamw> any other issues? overlooked bugs, etc?
18:57:17 * sgallagh falls
18:58:27 <sgallagh> Thanks for chairing once again, adamw
18:58:45 <adamw> thanks sgallagh
18:59:44 <kparal> thanks adamw
19:00:28 <adamw> #endmeeting