16:01:15 <adamw> #startmeeting F33-blocker-review
16:01:15 <zodbot> Meeting started Mon Oct 19 16:01:15 2020 UTC.
16:01:15 <zodbot> This meeting is logged and archived in a public location.
16:01:15 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:15 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:01:16 <adamw> #meetingname F33-blocker-review
16:01:16 <adamw> #topic Roll Call
16:01:16 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:01:21 <adamw> ahoyhoyhoy
16:01:24 <adamw> who's around for blocker fun?
16:01:24 <bcotton> .hello2\
16:01:31 <jsmith> .hello2
16:01:32 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:01:34 <bcotton> .hello2
16:01:35 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:01:46 <bcotton> oh hey, jsmith !
16:01:51 <jsmith> Funny seeing you here...
16:02:19 <Eighth_Doctor> .hello ngompa
16:02:19 <frantisekz> .hello2
16:02:19 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:02:22 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:22 * Eighth_Doctor waves
16:02:49 <coremodule> .hello
16:02:49 <zodbot> coremodule: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:02:54 <coremodule> .hello2
16:02:55 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:03:01 <coremodule> Good morning!
16:03:55 <lruzicka2> .hello lruzicka
16:03:56 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:05:47 <cmurf> .hello chrismurphy
16:05:48 <adamw> good turnout
16:05:48 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:05:59 <adamw> #chair coremodule jsmith
16:05:59 <zodbot> Current chairs: adamw coremodule jsmith
16:06:07 <adamw> IMPENDING BOILERPLATE ALERT
16:06:09 <adamw> #topic Introduction
16:06:09 <adamw> Why are we here?
16:06:09 <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:09 <adamw> #info We'll be following the process outlined at:
16:06:10 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:11 <adamw> #info The bugs up for review today are available at:
16:06:13 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:15 <adamw> #info The criteria for release blocking bugs can be found at:
16:06:17 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:06:19 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:06:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:06:23 <adamw> #info for Final, we have:
16:06:25 <adamw> #info 2 Accepted Blockers
16:06:28 <adamw> #info 2 Proposed Freeze Exceptions
16:06:31 <adamw> #info 10 Accepted Freeze Exceptions
16:06:33 <adamw> ...and that's it
16:06:35 <adamw> yay for async voting
16:06:40 * pwhalen is here
16:07:05 <bcotton> yay for kamil's baby distracting him ;-)
16:08:13 <adamw> who wants to secretarialize?
16:08:39 * jsmith can't, sorry -- multi-tasking with $DAYJOB
16:09:31 * bcotton can do it
16:09:33 * coremodule will do it.
16:09:41 * bcotton defers to coremodule
16:09:48 <adamw> #info coremodule will secretarialize
16:10:01 <adamw> @info bcotton will lurk menacingly behind him, nursing his grievances
16:10:13 <bcotton> adamw++
16:10:17 <coremodule> thnak you bcotton
16:10:22 <adamw> welp we have no proposed blockers
16:10:23 <Lailah> Hi!
16:10:25 <adamw> so let's go straight to
16:10:27 <adamw> hi lailah!
16:10:32 <Lailah> .fas lailah
16:10:33 <adamw> #topic Proposed Final freeze exceptions
16:10:33 <zodbot> Lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:10:45 <Lailah> hi adamw !
16:10:48 <adamw> #topic (1889349) fish setting for nano-default-editor is unremovable (usage of universal variable)
16:10:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1889349
16:10:48 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/182
16:10:48 <adamw> #info Proposed Freeze Exceptions, nano, MODIFIED
16:11:00 <adamw> we have +2 in the ticket here, from kparal and I
16:11:07 <cmurf> +1 FE
16:11:18 <lruzicka2> +1 fe
16:11:19 * kparal is mostly not available today, sorry
16:11:21 <bcotton> +! FE
16:11:23 <adamw> the bug description says the bug is persistent if you install the broken package, so seems worthwhile to fix it so anyone who happens to include the package in their initial install doesn't fix it
16:11:23 <Eighth_Doctor> +1 FE
16:11:24 <bcotton> +1 also
16:11:25 <adamw> hit it *
16:11:30 <jsmith> +1 from me
16:11:40 <frantisekz> +1 FE
16:12:15 <coremodule> +1fe
16:12:15 <adamw> proposed #agreed 1889349 - AcceptedFreezeException (Final) - this is accepted as an FE to ensure people who include the package in their initial install don't get stuck with the bug
16:12:22 <bcotton> ack
16:12:23 <coremodule> ack
16:12:35 <lruzicka2> ack
16:12:40 <jsmith> ACK
16:12:48 <Eighth_Doctor> ack
16:13:17 <adamw> #agreed 1889349 - AcceptedFreezeException (Final) - this is accepted as an FE to ensure people who include the package in their initial install don't get stuck with the bug
16:13:33 <adamw> #topic (1878909) pkgconf-pkg-config generates file conflict between i686 & x86_64 packages
16:13:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1878909
16:13:33 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/175
16:13:33 <adamw> #info Proposed Freeze Exceptions, pkgconf, ON_QA
16:14:00 <adamw> this is of a type we'd usually accept (as it can cause issues with upgrades) but the fix looked a bit more invasive than the usual to me
16:14:06 <adamw> so i'm a tad hesitant
16:14:10 <adamw> there are no votes either way in the ticket yet
16:14:26 <Eighth_Doctor> a commenter in the bug and the update confirmed that it worked
16:14:34 <jsmith> Consider me +1... having both installed would be nice if you're still doing x86 development
16:15:05 <Eighth_Doctor> I was tempted to say no to fixing this, but I discovered I had accidentally made pkgconf-pkg-config multilib safe, so...
16:15:10 <Lailah> Are there anyone still developing for x86 nowadays?
16:15:18 <frantisekz> +1 FE
16:15:19 <Eighth_Doctor> it's a pretty severe breakage that's hard to get around
16:15:23 <Lailah> +1 FE
16:15:29 <cmurf> +1 FE
16:15:30 <Southern_Gentlem> +1 FE
16:16:13 <adamw> Lailah: we still build for 32-bit x86 even though we don't release images, for multilib purposes
16:16:22 <bcotton> +1 FE
16:16:33 <lruzicka2> +1fe
16:16:45 <adamw> proposed #agreed 1878908 - AcceptedFreezeException (Final) - this is accepted in order to smooth upgrades ASAP for folks with both packages installed
16:16:48 <Eighth_Doctor> ack
16:16:53 <lruzicka2> ack
16:16:56 <Southern_Gentlem> ack
16:16:57 <Lailah> ack
16:17:10 <Lailah> adamw: Oh, okay. Thank you!
16:17:13 <adamw> #agreed 1878908 - AcceptedFreezeException (Final) - this is accepted in order to smooth upgrades ASAP for folks with both packages installed
16:18:12 <adamw> ...well that's everything, cya folks
16:18:17 <adamw> OKAY FINE we can do the accepted blockers :P
16:18:23 <adamw> #topic Accepted Final blockers
16:18:26 <Eighth_Doctor> haha
16:18:35 <adamw> they are both a bit awkward
16:18:35 <adamw> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
16:18:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
16:18:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/16
16:18:36 <adamw> #info Accepted Blocker, sddm, ON_QA
16:18:42 <adamw> so, we have tried uh three different fixes for this so far
16:18:46 <Southern_Gentlem> dang wishful thinking
16:18:46 <adamw> and none of them really....works
16:18:51 <Eighth_Doctor> :(
16:18:59 <Lailah> Oof, this one...
16:19:01 <Lailah> I hate it.
16:19:03 <adamw> at least kparal who's not available isn't a fan of the latest one, which is the closest to sort-of working so far
16:19:06 <Eighth_Doctor> me too
16:19:13 <adamw> i think we all hate it!
16:19:17 <Lailah> Every time I think it's solved, it's not and I never know what's wrong
16:19:38 * Eighth_Doctor is looking forward to Plasma 5.21 with systemd-based session management
16:19:43 <adamw> i do wonder if kparal's multi-user case is actually a different bug...
16:19:51 * Lailah too
16:20:04 <adamw> but still, that's supposed to work.
16:20:11 <cmurf> propose to consider this under the Difficult to fix blocker bugs exception again and punt it to f34
16:20:20 <adamw> yeah, i was working up to that
16:20:26 <Eighth_Doctor> unfortunately, as much as I dislike it, I would agree
16:20:26 <adamw> i think we have clearly established that it's difficult to fix
16:20:37 <Lailah> adamw: I have only one user and in the best of cases I manage to log out but never to log back in.
16:20:45 <Lailah> And that's the best I got.
16:21:07 <adamw> and it seems a better idea to try and get a good fix in post-release than hold up the release for some kind of bodge that we get kparal to sign off on by feeding him beer
16:21:17 <jsmith> +1 to that idea
16:21:23 <adamw> Lailah: with the latest "fix" the single user case should work so long as you wait 8 seconds between logins, it seems
16:21:40 <Lailah> Uhm... okay.
16:21:53 <coremodule> i think that's reasonable
16:21:53 <Eighth_Doctor> while that's crappy for automated testing, at least most humans it should be okay
16:22:04 <frantisekz> +1 punt
16:22:07 <Lailah> But yeah, I prefer to get a good fix post-release than holding.
16:22:43 <Eighth_Doctor> and we may get this fully fixed when Plasma 5.21 lands in F33 post-GA anyway
16:23:14 <Eighth_Doctor> (Plasma 5.21 is several months away, mind you, but still...)
16:23:48 <lruzicka2> I have now tried in a VM and I could log out and log in repetitively 4 times without getting the bug.
16:24:37 <Lailah> Okay...  so...  punt?
16:24:40 <Lailah> Or...?
16:24:55 <adamw> no, we're using the 'waive' mechanism here
16:25:19 <adamw> https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases
16:25:21 <lruzicka2> Lailah, the so called TSUNAMI principle
16:25:29 <adamw> so, following that policy: the bug is already accepted as a blocker
16:26:02 <adamw> so now we can vote on whether we think it's reasonable to count this as a "difficult to fix blocker bug" and waive blocker status to F34 Beta
16:26:13 <adamw> weighing the factors outlined there
16:26:18 <adamw> i'm gonna say +1 to that proposal, I think
16:26:27 <bcotton> +1 waive
16:26:38 <coremodule> I agree, I am +1 waive
16:26:43 <frantisekz> +1 waive then :)
16:26:50 <adamw> i would have been more reluctant to do so if the bug had just been sitting around not getting worked on, but in the last week we've had four people bashing on it quite hard and got nowhere good
16:26:54 <Lailah> I'm a bit confused
16:26:59 <Lailah> But anyway
16:27:02 <Lailah> +1 waive
16:27:04 <adamw> Lailah: what's confusing you?
16:27:10 <pwhalen> +1 waive
16:27:17 <Eighth_Doctor> +1 waive
16:27:23 <lruzicka2> +1 waive
16:27:42 <cmurf> +1
16:27:49 <lruzicka2> 7 waves = tsunami
16:27:56 <Eighth_Doctor> btw, do we have an upstream bug report about this?
16:28:11 <Eighth_Doctor> I don't see one on https://github.com/sddm/sddm/issues
16:28:20 <Lailah> adamw: What confuses me is that.. uh... I'm not clear if it will be fixed or not, and if it's a blocker for this release or not.
16:28:32 <Lailah> Because F34 Beta is a long way from now.
16:28:43 <adamw> Lailah: if we waive it, that means we say it doesn't need to be fixed for f33 final
16:28:44 <lruzicka2> Lailah, it is, but we are saying that we cannot fix it and will release anyway
16:28:58 <Lailah> Oh right
16:28:59 <Lailah> Okay
16:29:07 <Lailah> Then yes, waive.
16:29:22 <adamw> it would be made a blocker for f34 beta. but of course we would *try* to fix it in f33 as soon as we can come up with a working fix that doesn't break anything else.
16:29:28 <lruzicka2> +1 commonbugs
16:29:45 <Eighth_Doctor> yeah, probably worth documenting as a commonbug too
16:30:00 <Lailah> adamw:  "...and doesn't break anything else."  Yeah, that's the trick.
16:30:07 <bcotton> mock shell
16:30:10 <bcotton> whoops!
16:30:40 <frantisekz> bcotton: <mock-chroot> sh-5.0#
16:30:50 <bcotton> frantisekz++
16:30:50 <zodbot> bcotton: Karma for frantisekz changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:30:53 <frantisekz> :)
16:31:14 <adamw> yes, commonbugs for sure. i think it's already tagged
16:31:46 <Southern_Gentlem> +1 waive
16:32:20 <adamw> proposed #agreed 1861700 is waived as an F33 Final blocker under the "Difficult to fix blocker bugs" proviso at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases , as we have tried multiple approaches to fix this bug and it's not going away, we are not confident that we'll be able to produce a clear fix any time soon. it will be made an F34 Beta blocker instead.
16:32:36 <bcotton> ack
16:32:38 <Eighth_Doctor> ack
16:32:44 <Southern_Gentlem> ack
16:32:44 <Lailah> ack
16:32:50 <cmurf> ack
16:32:50 <frantisekz> ack
16:32:55 <Eighth_Doctor> adamw: do we have enough understanding to at least attempt to file an upstream bug report?
16:33:12 <adamw> Eighth_Doctor: i think so, but i think the result would basically be "just wait for the systemd session stuff"
16:33:36 <lruzicka2> ack
16:33:38 <Eighth_Doctor> it'd probably still be worth filing the report
16:33:39 <Eighth_Doctor> it'd be nice to know for sure :)
16:33:39 <coremodule> ack
16:33:51 <pwhalen> ack
16:35:39 <adamw> #agreed 1861700 is waived as an F33 Final blocker under the "Difficult to fix blocker bugs" proviso at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases , as we have tried multiple approaches to fix this bug and it's not going away, we are not confident that we'll be able to produce a clear fix any time soon. it will be made an F34 Beta blocker instead.
16:35:49 <adamw> ok, now the other fun one!
16:35:55 <adamw> #topic (1883609) Secure Boot fails to boot F33 Beta image
16:35:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1883609
16:35:55 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/135
16:35:55 <adamw> #info Accepted Blocker, shim, ASSIGNED
16:35:59 <adamw> so, well, this one is more clear cut, at least
16:36:03 <adamw> we are just waiting on the re-signed shim
16:36:14 <adamw> last update i got was last tuesday or wednesday we expected it back in two days, so hm
16:36:19 <adamw> anyone heard anything since?
16:36:26 <Eighth_Doctor> nope
16:36:27 <bcotton> nope :/
16:36:40 * adamw brb, call of nature
16:36:46 <Eighth_Doctor> pjones doesn't seem to be here in this channel
16:36:55 <Lailah> I hadn't hear anything sorry
16:37:29 * bcotton pinged pjones in #fedora-devel
16:39:14 <cmurf> i haven't heard a status about signing progress
16:39:44 <Southern_Gentlem> other distros pointing fingers at M$
16:40:38 <cmurf> not sure
16:40:47 <cmurf> i haven't tracked down the problem
16:41:08 <cmurf> i did a windows 10 update and it didn't install the embargoed dbx
16:41:50 <adamw> yeah, pjones was saying it was ubuntu installing it and microsoft isn't doing it till next year.
16:42:08 <adamw> bcotton: i pinged him in fedora-desktop but he's not responding
16:42:21 <cmurf> and in VM with ovmf uefi secboot, ubuntu 20.04.1 with all updates did update dbx to version 77 which is NOT embargoed
16:42:42 <cmurf> so either they were doing it and then pulled the update or it's something else like a vendor firmware update including it
16:42:49 * Lailah brb
16:42:58 * Lailah needs a cup of tea
16:44:07 <cmurf> the embargoed version is >=190
16:44:08 <adamw> <pjones> bcotton: I'm still working on it; just did another test build a bit ago.
16:44:14 <Southern_Gentlem> so we cant reproduve the issue?
16:44:32 <cmurf> not exactly
16:44:34 <Southern_Gentlem> reproduce
16:44:36 <adamw> well, not trivially. but we know exactly what's going on
16:44:48 <cmurf> i don't know exactly what's going on
16:45:06 <Eighth_Doctor> I've been afraid to try to test this, because I don't want to brick my computer :(
16:45:14 <cmurf> i've got a few ideas but i don't know for sure who released the embargoed dbx
16:45:25 <Southern_Gentlem> what is the percentage of users this may affect
16:45:27 <Eighth_Doctor> I know the sequence how to make it happen, I just don't want to do it
16:45:57 <Eighth_Doctor> Southern_Gentlem: ideally, it'd be small, but the problem is that it has disproportionate impact
16:46:04 <adamw> cmurf: i didn't mean that, i mean we know the actual technical details of how the bug happens.
16:46:16 <Southern_Gentlem> Eighth_Doctor, pm me the sequence and i will try on a Dell E6420 i have setting her
16:46:30 <Eighth_Doctor> Southern_Gentlem: it should be in the bug itself
16:48:20 <Eighth_Doctor> the new file is available from the UEFI forum, via LVFS, and from Ubuntu
16:48:38 <adamw> #info we are still waiting for the re-signed shim here. pjones is working on it
16:48:41 <Eighth_Doctor> there are a few ways to trigger this update now and brick Fedora systems if you want :(
16:48:50 <cmurf> well it's still embargoed by LVFS
16:49:18 <cmurf> my vague understanding is ubuntu has a way to randomize rollouts of some updates and this is one of them
16:49:32 <cmurf> and i just didn't get "lucky" in my test
16:49:36 <Eighth_Doctor> yeah
16:50:18 <cmurf> the uefi link to the dbx clearly says it's for testing
16:50:20 <adamw> do ya feel lucky, punk
16:50:31 <cmurf> and i guess ubunut is randomly testing *sigh*
16:50:38 * adamw asking pjones what the chances of having this fixed in the next day or two are
16:50:39 <Eighth_Doctor> cmurf: I know, I'm just pointing out that it's now available from multiple sources
16:50:51 <cmurf> yeah it's been in the wild for a while
16:51:37 <Eighth_Doctor> Southern_Gentlem: the reason this is a problem is that Linux reviewers would see this and unfairly blame Fedora for a broken release
16:51:58 <Eighth_Doctor> that is pretty damaging from a reputation point of view
16:54:39 <adamw> no reply yet
16:54:50 <adamw> so...the risk here is we don't get the new shim in time to sign off on thursday
16:54:58 <adamw> fesco folks, i'm assuming in that case we would want to slip another week, not waive?
16:55:29 <sgallagh> adamw: I'd vote to slip
16:55:38 <adamw> <pjones> adamw: very low
16:55:44 <adamw> so, that's good news. :|
16:55:59 <Eighth_Doctor> unfortunately, I'd probably say slip too
16:56:09 <Eighth_Doctor> I hate this because it ruins our record :(
16:56:47 <cmurf> not really our fault
16:56:53 <sgallagh> Eighth_Doctor: It doesn't ruin it. It sets the record so we can beat it next time!
16:56:57 <adamw> heh
16:57:01 <adamw> lower that bar!
16:57:05 <Eighth_Doctor> hahah
16:57:12 <cmurf> prior agreement was to keep the dbx under wraps
16:57:32 <sgallagh> cmurf: How open can we be about the reasoning?
16:58:09 <Eighth_Doctor> we've been talking about it in bugs and public meetings
16:58:16 <sgallagh> Because I think even Phoronix would understand slipping for "completely uninstallable because of issues outside our control"
16:58:19 <Eighth_Doctor> so... pretty open, I think
16:58:30 <adamw> i mean, the issue isn't exactly a secret...
16:58:43 <adamw> and if the dbx is publicly downloadable that doesn't seem terribly under wraps
16:59:03 <cmurf> yeah but applying it is not trivial
16:59:12 <cmurf> downloading it doesn't apply it
16:59:21 <adamw> #info pjones says getting the new shim build in the next couple of days is very unlikely, so we are probably looking at another slip here
16:59:33 <adamw> no, but the *fact that it's a thing* is apparently not a secret any more
16:59:38 <sgallagh> This feels like something that should maybe have a CommBlog article published about it to explain the situation.
16:59:53 <cmurf> sgallagh: agreed
17:00:00 <Eighth_Doctor> commblog, why not magazine?
17:00:02 <Eighth_Doctor> this is pretty much affecting everyone
17:00:05 <cmurf> and that suggests asking Ubuntu how this slipped through
17:00:19 <adamw> if we're going that far we should probably have Responsible Adults sign off on what gets written i guess
17:00:28 <cmurf> are they randomly updating some systems with an embargoed dbx? why?
17:00:36 <Eighth_Doctor> keep in mind, this will render all old-world systems unbootable
17:00:41 <Eighth_Doctor> including Fedora 32 and older
17:00:46 <cmurf> right
17:00:56 <cmurf> some systems have a way to clear the dbx others don't
17:01:01 <adamw> yeah, and we should be very sure of anything we write as a fact.
17:01:19 <cmurf> and it's not certain whether such an option to clear keys or the revocation list is even reliable
17:01:31 <Eighth_Doctor> none of my computers let me reset those things
17:01:36 <sgallagh> cmurf: Apparently they pushed out the update to ALL ubuntu repos and weren't willing to roll it back (this is secondhand information)
17:01:40 <Eighth_Doctor> which is why I'm not eager to try it
17:02:05 <nirik> you should be able to disable secure boot right?
17:02:07 <adamw> sgallagh: cmurf said he tested an ubuntu update and didn't get it, so that seems questionable
17:02:08 <Lailah> I'm back
17:02:11 <adamw> but anyhow
17:02:17 <cmurf> sgallagh: ok well a week ago i installed 20.04.1 with all updates and only got dbx version 77 which is not the embargoed one for BootHole that would cause the problem under discussion
17:02:19 <adamw> we probably don't need to go into *all* of this here, fesco could
17:02:28 * sgallagh nods
17:02:31 <cmurf> so i think it's random
17:02:38 <cmurf> or it got pulled
17:02:43 <cmurf> or it's a vendor update
17:02:45 <Eighth_Doctor> everything is weird with Ubuntu because debs can invoke snaps
17:02:58 <Lailah> Really?
17:02:59 <adamw> for blocker review purposes: we're working on it, likely not coming in time for this week signoff
17:03:09 <Eighth_Doctor> including install and updating them
17:03:27 <adamw> there is a new proposed FE (because I just proposed it) I want to circle back to
17:03:41 <Eighth_Doctor> sure
17:03:41 <adamw> #topic Proposed Final freeze exceptions
17:03:48 <adamw> #topic (1887928) Latest freeipa-client update removes UsePAM from ssh configuration
17:03:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1887928
17:03:48 <adamw> #info Proposed Freeze Exceptions, freeipa, ON_QA
17:03:58 <adamw> this is actually a bug i found (reported upstream) that someone else reported downstream
17:04:30 <adamw> freeipa got clever about sshd config recently, unfortunately not quite clever enough, in a way which can mean that when you upgrade a domain member it suddenly stops being ssh-accessible
17:04:34 <Eighth_Doctor> oh yikes
17:04:35 <pwhalen> +1 FE
17:04:39 <adamw> obviously if that's the *only* way you usually access it, that's a problem :)
17:04:52 <jsmith> Seems like an obvious +1 FE
17:05:14 <Eighth_Doctor> +1 FE
17:05:15 <frantisekz> +1 FE
17:05:19 <Lailah> +1 FE
17:05:28 <adamw> i had to get into the affected systems via libvirt, in other cases this could possibly involve digging out old side channel credentials or, you know, getting in a car with a monitor in the back seat :P
17:05:30 <bcotton> +1 fe
17:05:32 <lruzicka2> +1fe
17:05:34 <coremodule> +1 FE
17:06:09 <adamw> proposed #agreed 1887928 - AcceptedFreezeException (Final) - this is accepted as an FE to avoid potentially severe inconvenience on upgrade to the broken version
17:06:16 <coremodule> ack
17:06:17 <bcotton> ack
17:06:20 <lruzicka2> ack
17:06:21 <Lailah> ack
17:06:32 <adamw> #agreed 1887928 - AcceptedFreezeException (Final) - this is accepted as an FE to avoid potentially severe inconvenience on upgrade to the broken version
17:06:35 <adamw> okay
17:06:44 <adamw> we have no other late-breaking proposals, so
17:06:47 <adamw> #topic Open floor
17:06:49 <adamw> any other business, folks?
17:06:57 <Lailah> Not that I remember
17:07:12 <adamw> oh, i'm gonna say we make the KDE login bug a Final FE just in case we come up with a working fix while we're waiting for shim to show up
17:07:16 <adamw> assume that's OK for everyone?
17:07:20 <lruzicka2> yes
17:07:22 <bcotton> cool beans
17:07:32 <Lailah> yes, perfect
17:07:54 <bcotton> I would like to proceed over the next few days as if FESCo will lift the blocker on the shim issue. (iow, request an RC and test it as if we'll ship it)
17:08:26 <adamw> sure, we can build a candidate
17:10:36 <adamw> #info KDE login bug will be made a Final FE
17:11:01 <adamw> #info we'll build a candidate compose today without the re-signed shim, to provide the option of shipping that way at go/no-go if desired (assuming no other blockers found)
17:11:39 <Eighth_Doctor> ack
17:11:48 <Lailah> ack
17:11:56 <pwhalen> ack
17:12:02 <frantisekz> ack
17:12:25 <adamw> those were infos, you don't get to ack :P
17:12:51 <Eighth_Doctor> you can't tell me what I can or cannot ack :P
17:12:54 <frantisekz> I see people acking, I ack :D
17:13:01 <pwhalen> heh
17:13:21 <bcotton> ackity ack, don't talk back
17:13:26 <Lailah> We're all acking together!
17:13:37 <cmurf> General Ackbar, please
17:13:38 <lruzicka2> I there is a lack of ack, I ack not to lack acks
17:13:47 <adamw> okay this has gone far enough!
17:13:51 <adamw> thanks for coming everyone :)
17:13:51 <cmurf> IT'S A TRAP!
17:14:02 <frantisekz> thanks for the meeting
17:14:07 <lruzicka2> thank you for the meeting
17:14:11 <lruzicka2> have a nice time
17:14:13 <Eighth_Doctor> thank y'all
17:14:23 <Lailah> Thank you all and sorry for being more absent than present
17:14:57 <adamw> #endmeeting