16:00:38 <adamw> #startmeeting F34-blocker-review
16:00:38 <zodbot> Meeting started Mon Apr 19 16:00:38 2021 UTC.
16:00:38 <zodbot> This meeting is logged and archived in a public location.
16:00:38 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:38 <zodbot> The meeting name has been set to 'f34-blocker-review'
16:00:43 <adamw> #meetingname F34-blocker-review
16:00:43 <zodbot> The meeting name has been set to 'f34-blocker-review'
16:00:48 <adamw> #topic Roll Call
16:00:54 <frantisekz> .hello2
16:00:55 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:00:57 <adamw> morning, folks, who's around for some blocker review fun?
16:00:59 <lruzicka[m]> .hello lruzicka
16:01:00 <zodbot> lruzicka[m]: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:01:53 <bcotton> .hello2
16:01:54 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:16 <coremodule> .hello2
16:02:17 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:02:25 * coremodule willing to act as secretary!
16:02:44 <adamw> thanks coremodule
16:03:58 <Eighth_Doctor> .hello ngompa
16:03:59 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:04:05 <Eighth_Doctor> murrgh
16:04:06 <Eighth_Doctor> hey all
16:04:54 <geraldosimiao> .hello geraldosimiao
16:04:55 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:07:21 <adamw> alrighty
16:07:25 <adamw> let's get goin'
16:07:31 <adamw> #chair coremodule conan_kudo
16:07:31 <zodbot> Current chairs: adamw conan_kudo coremodule
16:07:56 <Eighth_Doctor> oh noes, I have responsibility?
16:08:06 <adamw> #topic Introduction
16:08:12 <adamw> very small responsibility. you'll be fine
16:08:18 <adamw> Why are we here?
16:08:23 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:08:30 <adamw> #info We'll be following the process outlined at:
16:08:36 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:39 <adamw> #info The bugs up for review today are available at:
16:08:44 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:50 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:55 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:01 <adamw> #link https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria
16:09:06 <adamw> #link https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria
16:09:09 <adamw> #info for Final, we have:
16:09:17 <adamw> #info 3 Proposed Blockers
16:09:17 <adamw> #info 4 Accepted Blockers
16:09:21 <adamw> #info 3 Proposed Freeze Exceptions
16:09:21 <adamw> #info 7 Accepted Freeze Exceptions
16:10:04 <adamw> #info coremodule will secretarialize
16:10:09 <adamw> so let's get going with...
16:10:12 <adamw> #topic proposed Final blockers
16:10:20 <adamw> #topic (1951072) pipewire 0.32.5-1
16:10:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1951072
16:10:29 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/361
16:10:34 <adamw> #info Proposed Blocker, pipewire, NEW
16:10:39 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+adamwill)
16:10:43 <adamw> #info Ticket vote: FinalFreezeException (+1,0,-0) (+geraldosimiao)
16:10:57 <adamw> so the bug topic here isn't the best, apparently the deal is 0.32.5 fixes audio on several bluetooth devices
16:11:09 <adamw> which is good! not sure if it's blocker material, but i'm at least +1 FE (as voted)
16:11:12 <Eighth_Doctor> I didn't realize this wasn't already on the media
16:11:18 <frantisekz> hmm, I think I'd prefer the FE path
16:11:28 <bcotton> point of order: you voted it for Beta ;-)
16:11:29 <Eighth_Doctor> it's immaterial at this point, since the update exists
16:11:45 <bcotton> yeah, i nominated it as a blocker on the assumption we'd at least make it an FE
16:11:58 <Eighth_Doctor> +1 Blocker +1 FE
16:12:09 <bcotton> it's moot, unless that update turns out to not be as fixy as advertised
16:12:10 <Eighth_Doctor> having broken audio in GA is pretty frickin' bad
16:12:35 * Eighth_Doctor uses Bluetooth exclusively for audio
16:12:51 <lruzicka[m]> I would like to know how the audio is broken, I have not had any audio issue for 1.5 months.
16:12:52 <bcotton> yeah, i don't think bluetooth is an edge case in the year twenty and twenty one
16:13:19 <adamw> well, it wasn't all bluetooth devices, was it?
16:13:33 <Eighth_Doctor> it was audio devices attempting to use high-quality codecs, IIRC
16:13:49 <Eighth_Doctor> for me, LDAC broke and then got fixed in 0.3.25
16:13:52 <lruzicka[m]> there are some known issues with bluetooth devices, but definitely not all of them
16:14:38 <geraldosimiao> that proposal came form this user report at dev list, by Garrett LeSage:
16:14:40 <lruzicka[m]> yeah, the codecs
16:14:40 <geraldosimiao> Several weeks ago, while running Fedora 34 pre-beta, I had a bunch of PipeWire issues preventing me from successfully doing video conferences and listening to music. I reported the issues upstream. The problems included using Bluetooth headphones (at all), codecs for the headphones, switching outputs, and issues when doing video calls. It was a mess, multiple times a day.
16:14:40 <geraldosimiao> I'm happy to say they were all fixed with the latest release of pipewire-0.3.25-1.fc34 and my system has been mostly problem-free with audio since upgrading.
16:14:40 <geraldosimiao> However, after two weeks, this bugfix version is still in testing... and doesn't like it will make it for Fedora 34 at this moment:
16:15:04 <geraldosimiao> Garrett's words
16:15:27 <Eighth_Doctor> I had no idea that this hadn't been pushed through for at least FE a week ago
16:15:30 <lruzicka[m]> I am using this version and I can confirm, that it is ok with anything -> also with third party professional audio plugins
16:15:46 <lruzicka[m]> so, I am bold enough to say, that we can put it in
16:16:26 <lruzicka[m]> It has been never so easy to do audio recording ever (as with F34).
16:16:34 <bcotton> so if we're not sold on blocker status, let's go with FE (which there seems to be consensus for) and if it breaks, we can revisit
16:16:42 <lruzicka[m]> However, I am not a fan of Bluetooth. I like wires.
16:16:49 <bcotton> i don't think we need to spend a ton of time discussing this one
16:16:58 <geraldosimiao> ACK
16:17:04 <lruzicka[m]> +1FE
16:17:05 <Eighth_Doctor> freenode_lruzicka[m]: I use BT because my audio jack has been busted for years :P
16:17:10 <frantisekz> yeah, +1 FE
16:17:29 <lruzicka[m]> conan_kudo[m]: I am using a  USB external device
16:17:40 <geraldosimiao> Already voted on the ticket +1FE
16:17:55 <bcotton> +1 Blocker +1 FE from me
16:18:42 <lruzicka[m]> Ben Cotton: how does a blocker help if it is +1fe?
16:20:02 <frantisekz> lruzicka: we won't release Fedora 34 without that fixed, the FE status doesn't guarantee it'll be pulled in
16:20:34 <frantisekz> or, it might not fix the bug (which is currently not the case, the build is either pulled in or not ofc)
16:20:38 <lruzicka[m]> frantisekz: yeah, but there are still other blockers in the way, so I believe this will be pulled in with their fixes
16:21:11 <lruzicka[m]> So ... I am the stupid one here, but what is the bug that needs fixing?
16:21:49 <Eighth_Doctor> nobody specifically filed a BZ on it, just reported feedback in bodhi and mailing lists
16:21:50 <adamw> let's just take it as an FE and move on
16:21:59 <Eighth_Doctor> Yup
16:22:10 <Eighth_Doctor> we've got quite a few to go through today
16:22:17 <lruzicka[m]> Because if some BT devices do not work with their best possible codec, they still do with the basic one.
16:22:26 <adamw> proposed #agreed 1951072 - AcceptedFreezeException (Final) - there wasn't a clear blocker vote on this, but there's a strong consensus for FE and the fix is already tested and ready, so we will just take that and move on
16:22:31 <lruzicka[m]> so this is not a violation imo
16:22:35 <lruzicka[m]> ack
16:22:38 <frantisekz> ack
16:22:51 <geraldosimiao> ack
16:23:00 <bcotton> ack
16:23:02 <Eighth_Doctor> ack
16:23:11 <adamw> #agreed 1951072 - AcceptedFreezeException (Final) - there wasn't a clear blocker vote on this, but there's a strong consensus for FE and the fix is already tested and ready, so we will just take that and move on
16:23:35 <adamw> #topic (1903294) plasma-discover doesnt refresh metadata
16:23:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1903294
16:23:45 <Eighth_Doctor> ugh
16:23:49 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/352
16:23:54 <adamw> #info Proposed Blocker, plasma-discover, ON_QA
16:24:00 <adamw> #info Ticket vote: FinalBlocker (+2,0,-2) (+geraldosimiao, +carlis, -raphgro, -lukc)
16:24:05 <adamw> #info Ticket vote: FinalFreezeException (+3,0,-0) (+adamwill, +raphgro, +lukc)
16:24:24 <adamw> this is kinda similar, i guess, we have split feelings on blocker but consensus on fe (i've marked it accepted FE already)
16:24:34 <Eighth_Doctor> isn't this already landing because of FE status?
16:24:40 <adamw> i was inclined to -1 blocker as i thought the refresh button always worked around it, but ben says not always
16:24:41 <adamw> yes
16:24:57 <lruzicka[m]> similar proposal has been already rejected as a blocker
16:24:59 <adamw> but it may be more important to make a blocker determination in case that fix turns out to not work 100% or have issues
16:25:47 <Eighth_Doctor> the patch to use force refresh brings us in line with plasma-pk-updates, and at least Rex and myself seem to no longer see the issue with that
16:26:14 <Eighth_Doctor> there _is_ a problem with PackageKit, but I don't know how to fix it yet so that `pkcon refresh` (without `force`) works as expected
16:26:43 <Eighth_Doctor> right now, PK defaults cache-age to UINT_MAX
16:27:00 <Eighth_Doctor> which, uhh, a lot of seconds
16:27:32 <geraldosimiao> So, with that new patch applied discover updates fine? If so, its just FE for me too.
16:27:58 <Eighth_Doctor> yeah
16:28:14 <geraldosimiao> so +1 FE
16:28:33 <bcotton> that there's a working fix in place doesn't make it not a blocker. it makes it a resolved blocker
16:28:51 <bcotton> but again, this is academic at this point, so i'm happy to move on since it's already been granted FE status
16:30:25 <adamw> fwiw i'd probably be +1 blocker with your report that the refresh button doesn't always solve things, bcotton.
16:30:53 <geraldosimiao> yes, you're right Ben Cotton
16:32:06 <lruzicka[m]> is there an acceptable workaround? because I might be ok with just Common Bugs record ...
16:32:47 <lruzicka[m]> or is "dnf update" acceptable enough?
16:32:47 <bcotton> lruzicka: even better, there's a "fix"
16:32:56 <lruzicka[m]> Ben Cotton: yeah but for the classification ...
16:33:22 <Eighth_Doctor> `pkcon refresh force` is the workaround
16:33:34 <Eighth_Doctor> prior to this "fix"
16:34:03 <lruzicka[m]> ok, then I believe that this is not very blockery to me and I would be +1 FE
16:34:15 <frantisekz> +1 FE
16:34:19 <adamw> it's already accepted fe
16:34:23 <adamw> we're only voting on blocker
16:34:30 <lruzicka[m]> so -1 FB
16:34:46 <lruzicka[m]> +1 Common Bugs if fix not enough
16:34:49 <frantisekz> let's accept it again as a FE, does FE ^ 2 mean it's blocker?
16:35:18 <frantisekz> -1 Blocker
16:36:49 <adamw> proposed #agreed 1903294 - punt (delay decision) - there isn't a clear consensus on blocker status here. It is already accepted as a freeze exception issue and a fix is prepared, so we expect that will resolve it shortly
16:36:57 <Eighth_Doctor> ack
16:37:02 <lruzicka[m]> ack
16:37:13 <frantisekz> ack
16:37:21 <bcotton> ack
16:37:52 <adamw> #agreed 1903294 - punt (delay decision) - there isn't a clear consensus on blocker status here. It is already accepted as a freeze exception issue and a fix is prepared, so we expect that will resolve it shortly
16:38:08 <adamw> #topic (1950258) USB flash disk cannot be mounted into a virtual machine.
16:38:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1950258
16:38:18 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/358
16:38:22 <adamw> #info Proposed Blocker, virt-manager, NEW
16:38:27 <adamw> #info Ticket vote: FinalBlocker (+1,0,-3) (+bcotton, -geraldosimiao, -raphgro, -lukc)
16:38:29 <frantisekz> -1 Blocker
16:38:32 <adamw> i'm pretty -1 on this one, honestly
16:38:40 <adamw> annoying bug? sure. blocker? nah. the criteria judo does not convince me. :D
16:39:07 <Eighth_Doctor> -1 Blocker +1 FE
16:39:08 <lruzicka[m]> The severity of this is exactly the same as the bug before, or the pipewire thing. It is nasty but could be lived with.
16:39:28 <Eighth_Doctor> we don't have criteria for VM guests, which is probably bad
16:39:33 <lruzicka[m]> So I should be consistent and say +1FE, -1FB
16:39:48 <lruzicka[m]> conan_kudo[m]: do we want them?
16:40:00 <frantisekz> I am also not sure about FE, maybe let's wait and see how big of a fix it'd be?
16:40:09 <frantisekz> if it grows like the gjs one...
16:40:14 <lruzicka[m]> also true
16:40:15 <Eighth_Doctor> I think that since we ship guest agents for VMware, VBox, and KVM, we probably should make sure that it works
16:41:01 <Eighth_Doctor> I've caught several VMware guest bugs over the course of this cycle and ramming them through with FEs is tricky
16:41:17 <Eighth_Doctor> when we have no accepted validation criteria for validating Fedora as a guest, that's a problem
16:41:20 <adamw> i would be against that
16:41:32 <adamw> it's enough of a pain guaranteeing our own virt stack works
16:41:42 <geraldosimiao> Oh it works, one can mount a USB drive on the VM, but once removed it do not automount again
16:41:45 <adamw> i do not want to be stuck guaranteeing everything works on two other virt stacks maintained by third parties
16:41:54 <adamw> but anyway, that's out of scope here
16:42:00 <Eighth_Doctor> we don't even validate KVM guest agents
16:42:02 <lruzicka[m]> geraldosimiao: I could not even mount it.
16:42:19 <lruzicka[m]> when I proposed this bug
16:42:20 <lruzicka[m]> not even the first time
16:42:20 <geraldosimiao> not even adding manually at virt-manager?
16:42:21 <Eighth_Doctor> even if we wave away VMware, VirtualBox, and Hyper-V, we don't even do that for KVM
16:42:33 <lruzicka[m]> geraldosimiao: no, nothing really worked
16:42:42 <adamw> @conan
16:42:44 <adamw> grrr
16:42:44 <geraldosimiao> strange, because it works for me
16:43:18 <adamw> conan_kudo[m]: in general i'd say the normal criteria apply to VM guests. but for this specific bug it's a bit more complex since it's kind of a different situation between a VM and a bare metal machine
16:43:26 <Eighth_Doctor> hmm
16:44:03 <lruzicka[m]> geraldosimiao: It did not work for Kamil either.
16:44:17 <lruzicka[m]> But of course, it can be something on the host, too
16:44:47 <lruzicka[m]> geraldosimiao: a USB printer could be passed through with no issued, but the flash disk did not mount
16:45:57 <RaphGro> well, what about a webcam maybe?
16:46:25 <RaphGro> usb3 or usb2?
16:46:33 <geraldosimiao> and the sad thing is that just last month automount worked fine here too (at virt-manager), I know because I tested several VMs with that in mind.
16:46:49 <geraldosimiao> but now automount doesn't work anymore
16:47:08 <lruzicka[m]> yeah, therefore I noticed that, because it would always work with no problems.
16:47:32 <geraldosimiao> I tested only with a usb 3 pendrive
16:47:33 <adamw> anyway. yeah. i'm -1.
16:49:33 <geraldosimiao> but, again: virtualization even isn't shipped by default on the spins, and when is installed one can run a F34 vm there. So why call it a FB?
16:49:37 <adamw> i think we're -5 at this point
16:49:48 <lruzicka[m]> geraldosimiao: what are Boxes then?
16:49:49 <adamw> yeah, freeze exception seems like it wouldn't achieve a whole lot
16:49:53 <adamw> assuming the bug is server side
16:50:00 <Eighth_Doctor> geraldosimiao[m]: virtualization is default on Workstation
16:50:03 <adamw> yeah, we ship boxes
16:50:05 <geraldosimiao> Boxes come in workstation, I said spins
16:50:10 <adamw> but you're not really supposed to run VMs in a live install :D
16:50:15 <adamw> er
16:50:17 <adamw> live boot, sorry
16:50:22 <adamw> i mean, i guess you could? eh.
16:50:34 <Eighth_Doctor> Workstation Edition is a spin, just a special-ish one
16:50:41 <copperi> but unlikely ?
16:50:54 <Eighth_Doctor> you don't have space to make a VM in a live environment
16:50:55 <bcotton> so let's call it RejectedBlocker and move on?
16:50:59 <Eighth_Doctor> it'd crash long before you'd get there :)
16:51:09 <Eighth_Doctor> due to the way we setup the livefs
16:51:33 <Eighth_Doctor> anyway, let's call it rejected and move on
16:51:33 <geraldosimiao> ok, so all features of virtualization must be supported as FB?
16:51:51 <geraldosimiao> <bcotton "so let's call it RejectedBlocker"> ack
16:51:51 <Eighth_Doctor> well, everything Boxes exposes
16:51:58 <Eighth_Doctor> which admittedly, is nota lot
16:52:02 <Eighth_Doctor> * which admittedly, is not a lot
16:52:13 <lruzicka[m]> ack, one can live with it until the fix
16:52:30 <copperi> ack
16:52:33 <Eighth_Doctor> ack
16:52:36 <geraldosimiao> ack
16:53:02 <adamw> i was waiting to see if there's a consensus on FE, but eh
16:53:29 <frantisekz> ack
16:53:30 <lruzicka[m]> I think Franta has made a point
16:53:33 <geraldosimiao> FE is fine
16:53:40 <geraldosimiao> FE+1
16:53:50 <lruzicka[m]> maybe we should wait to see what the fix is like?
16:53:52 <adamw> proposed #agreed 1950258 - RejectedBlocker (Final) - we agreed that this does not really violate the criteria as they stand. It's an annoying bug but doesn't really need to block the release
16:54:00 <bcotton> ack
16:54:02 <lruzicka[m]> ack
16:54:03 <Eighth_Doctor> ack
16:54:19 <copperi> acl
16:54:41 <geraldosimiao> ack
16:55:23 <frantisekz> ack
16:56:09 <adamw> #agreed 1950258 - RejectedBlocker (Final) - we agreed that this does not really violate the criteria as they stand. It's an annoying bug but doesn't really need to block the release
16:56:21 <adamw> ok, moving on to:
16:56:27 <adamw> #topic proposed Freeze Exception issues
16:56:35 <adamw> #topic (1951062) Cockpit-storaged  is not fully usable as currently included in Fedora Server Edition
16:56:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1951062
16:56:45 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/360
16:56:49 <adamw> #info Proposed Freeze Exceptions, comps, ASSIGNED
16:56:56 <adamw> #info Ticket vote: FinalFreezeException (+1,0,-0) (+adamwill)
16:57:02 <bcotton> +1 FE
16:57:04 <adamw> as voted on ticket, I'm +1 for this just so it works as intended ootb.
16:57:19 <geraldosimiao> that I think is a FB don't?
16:57:20 <lruzicka[m]> +1fe
16:57:28 <copperi> +1 fe
16:57:51 <frantisekz> +1 FE
16:58:10 <Eighth_Doctor> +1 FE
16:58:58 <adamw> proposed #agreed 1951062 - AcceptedFreezeException (Final) - this is accepted as Cockpit is a key feature of Server and it would be good to make sure it works as intended out of the box.
16:59:01 <frantisekz> ack
16:59:10 <Eighth_Doctor> ack
16:59:15 <lruzicka[m]> ack
16:59:17 <copperi> ack
16:59:53 <adamw> #agreed 1951062 - AcceptedFreezeException (Final) - this is accepted as Cockpit is a key feature of Server and it would be good to make sure it works as intended out of the box.
17:00:07 <adamw> #topic (1941982) [abrt] gjs: ObjectInstance::~ObjectInstance()(): gjs-console killed by SIGTRAP
17:00:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1941982
17:00:19 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/343
17:00:23 <adamw> #info Proposed Freeze Exceptions, gjs, POST
17:00:29 <adamw> #info Ticket vote: FinalFreezeException (+1,1,-0) (+adamwill, kalev)
17:00:34 <Eighth_Doctor> +1 FE
17:00:46 <adamw> this is kind of awkward, as it's a bad bug that it'd be nice to fix, but the fix is about a bazillion lines long
17:01:03 <adamw> i'm trying to get a more targeted backport done, but it's getting a bit late at this point
17:01:10 <adamw> might be safer for it to be an update
17:01:12 <frantisekz> I think it didn't change since the last time too much, still a huge change, but also, I don't understand C, so...
17:01:56 <frantisekz> adamw: any idea of an ETA for the reduced change to be backported?
17:02:20 <bcotton> 0 FE. i'm hoping that it's about to be too late to matter, but yeah, this seems like a big change
17:02:35 <adamw> frantisekz: not really, no.
17:03:01 <frantisekz> also, looking into the bug, it seem lots of people are hitting this
17:03:46 <adamw> i think it happens when you exit more or less any app that uses gjs (so, 'native' gnome apps)
17:04:01 <adamw> but it's not a very 'impactful' crash, it just...looks bad
17:06:19 <frantisekz> adamw, there are two cherry-picks mentioned ( https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/593#note_1083061 )
17:06:21 <frantisekz> wdyt?
17:07:04 <frantisekz> ptomato seems happy with that
17:08:18 <adamw> ptomato's reply to that comment isn't about the backports but about the mr review
17:08:36 <adamw> i'm not really comfortable with us just grabbing two commits for a downstream backport with how complex the change is
17:08:54 <adamw> marco is going to prepare a backport branch, per later comments, but it's not done yet
17:09:12 <adamw> i'd rather have something upstream to follow than do this purely downstream
17:10:02 <frantisekz> oh, okay
17:10:32 <frantisekz> so, let's punt again then
17:10:41 <adamw> yeah i was gonna say the same :d
17:10:46 <frantisekz> :D
17:10:55 <adamw> i don't think i'd want to pull this in for a PR intended to be signed off on thursday at all
17:11:05 <adamw> but if we wind up slipping again, again we have a window to look at pulling it in
17:11:07 <frantisekz> if we're no go and fix for backport is ready before the next go/no-go, we can re-evaluate
17:11:10 <frantisekz> yeah :D
17:11:25 <bcotton> there is no no-go. only go. :-D
17:12:20 <adamw> proposed #agreed 1941982 - punt (delay decision) - this is a bug we'd like to fix, but the current fix is far too big and complex to pull in. we would consider a reduced backport, but one is not yet ready and it's too close to go/no-go to safely pull one in this week. however, if the release slips, there may be a window to pull in a backport before next week, so we will leave our options open
17:12:57 <geraldosimiao> ack
17:12:57 <bcotton> ack
17:13:17 <frantisekz> ack
17:13:20 <copperi> ack
17:13:21 <lruzicka[m]> ack
17:13:29 <adamw> #agreed 1941982 - punt (delay decision) - this is a bug we'd like to fix, but the current fix is far too big and complex to pull in. we would consider a reduced backport, but one is not yet ready and it's too close to go/no-go to safely pull one in this week. however, if the release slips, there may be a window to pull in a backport before next week, so we will leave our options open
17:13:48 <adamw> #info we will skip #1950788 as it is actually already accepted as a blocker via ticket vote
17:13:51 <adamw> but there is a new proposed FE:
17:13:58 <adamw> #topic (1951101) Include firefox-87.0-12.fc34 in Fedora 34 to fix Widevine playback
17:14:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1951101
17:14:08 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/362
17:14:12 <adamw> #info Proposed Freeze Exceptions, firefox, NEW
17:14:27 <frantisekz> this is mine, so +1 FE :P :D
17:14:29 <lruzicka[m]> +1FE, this breaks Netflix and other stuff
17:14:38 <lruzicka[m]> plus the fix works ok
17:14:46 <lruzicka[m]> the new version
17:15:08 <geraldosimiao> +1 FE
17:15:10 <bcotton> +1 FE. seems like a legitimate use of a live environment :-)
17:15:26 <copperi> +1 fe
17:16:33 <adamw> compared to -7, -12 also has a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1936071
17:16:49 <adamw> other changes all seem to be to the unit tests, not actual user-facing bits
17:17:14 <adamw> so, +1 i guess
17:18:00 <adamw> proposed #agreed 1951101 - AcceptedFreezeException (Final) - this seems like a use case we would want to have fixed for live environments and use immediately after installation
17:18:09 <frantisekz> ack
17:18:17 <lruzicka[m]> ack
17:18:56 <geraldosimiao> ack
17:18:56 <copperi> ack
17:19:05 <adamw> #agreed 1951101 - AcceptedFreezeException (Final) - this seems like a use case we would want to have fixed for live environments and use immediately after installation
17:19:45 <adamw> #topic Accepted blocker revie
17:19:48 <adamw> #undo
17:19:48 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f25b2fade10>
17:20:05 <adamw> #topic Accepted blocker review
17:20:21 <adamw> #info as a reminder, in this section we check in on the status of accepted blockers, we are not re-voting them (unless we specifically decide to do that)
17:20:26 <adamw> #topic (1929643) logout after switch returns the user to console instead of sddm
17:20:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1929643
17:26:06 * King_InuYasha waves from IRC
17:26:17 <bcotton_> RIP Matrix bridge, i guess
17:26:39 <frantisekz> good that I am still on IRC :P
17:27:17 <bcotton_> so what I was trying to say (apart from multi user workstations being a passing fad) is that i don't feel like this one is particularly fixed, but i think it'd qualify for the "we tried. it's too hard" exception at the go/no-go meeting
17:27:41 <King_InuYasha> yeah
17:27:44 <frantisekz> yep
17:28:42 <bcotton_> just to make neal sad, i'll note that switching back to X11 as Plasma's default would eliminate this blocker. the question is "is that worth it?"
17:29:27 <King_InuYasha> and to be clear, upstream is working on a lot of things around it and merged the X11 rootless patch upstream this morning
17:31:16 <King_InuYasha> we're trying to get this properly fixed upstream, and rdieter is planning on spinning a build with the improvements today
17:31:33 <happyassassin> durn bridge
17:32:00 <happyassassin> so, new build today? that'd be good.
17:32:47 <King_InuYasha> rdieter is of the opinion that we don't fully support fast user switching right now with sddm
17:33:08 <King_InuYasha> though we're trying to get this functionality in better shape
17:33:12 <marcdeop> FI: we are discussing this topic in the KDE SIG meeting
17:33:53 <happyassassin> the position in the criteria is basically that if the desktop presents it as an option it has to work
17:34:02 <happyassassin> so just patching it out is another viable resolution
17:34:16 <happyassassin> are there still issues that affect "regular" log out / log in as another user scenarios?
17:34:25 <happyassassin> or are the remaining issues strictly with fast user switching?
17:34:35 <King_InuYasha> pretty much fast user switching
17:34:40 <King_InuYasha> if you log out and log in, it's fine
17:34:57 <King_InuYasha> at least it is on my machine and Rex's
17:36:07 <King_InuYasha> there's also work upstream to introduce a pure wayland greeter, which should make this VT dance stuff go away
17:36:24 <King_InuYasha> but I don't know when that is going to land, but it is planned for the next release of SDDM
17:36:48 <King_InuYasha> the PR exists though: https://github.com/sddm/sddm/pull/1379
17:37:23 <happyassassin> okay, so patching out fast user switch is also an option here, i guess.
17:37:40 <happyassassin> i do think we need a 'better fix' for final, though. is anyone of the opinion that we could release with the current one?
17:37:44 <frantisekz> or backporting that PR .... :D
17:38:27 <bcotton_> could? yes. should? ehhhhh. i can live with it, but i wouldn't like it
17:41:04 <happyassassin> okay.
17:41:20 <happyassassin> uh, can someone #chair me under this name? or take over #info duties?
17:42:20 * bcotton_ looks at coremodule
17:42:33 <coremodule> #chair happyassassin
17:42:33 <zodbot> Current chairs: adamw conan_kudo coremodule happyassassin
17:43:21 <happyassassin> #info the current update only partially fixes things here, clear issues remain. there is apparently a plan to try and do a new improved fixed build today. we note that patching out fast user switching would also be an option here.
17:44:20 <happyassassin> #topic (1938630) include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them
17:44:27 <happyassassin> #link https://bugzilla.redhat.com/show_bug.cgi?id=1938630
17:44:33 <happyassassin> #link https://pagure.io/fedora-qa/blocker-review/issue/310
17:44:36 <happyassassin> #info Accepted Blocker, shim, POST
17:44:41 <happyassassin> #info Ticket vote: FinalBlocker (+3,0,-0) (+chrismurphy, +churchyard, +bcotton)
17:44:54 <lruzicka[m]> I am afraid, I need to go now, bed time for the children. Sorry.
17:45:01 <happyassassin> so we are still in more or less the same state here: the initial fix had bugs, we have fixes for the bugs but are waiting for a signed build with the fixes
17:45:02 <lruzicka[m]> Have a nice time everyone and thanks a lot.
17:45:04 <happyassassin> cya lruzicka!
17:45:11 <happyassassin> thanks for coming
17:45:21 <happyassassin> i pinged pjones this morning but have not heard bac kyet
17:45:26 <happyassassin> anyone else have news?
17:45:56 <bcotton_> from what i eavesdropped, a shim has been sent to Microsoft for signing
17:46:03 <bcotton_> javier was going to ping them this morning
17:46:20 <Eighth_Doctor> ugggh
17:49:53 <happyassassin> #info we are still waiting for a signed build with fixes for the issues identified with the previous build
17:49:56 <happyassassin> <javier__> happyassassin: not yet, I've pinged some folks @ MSFT but they haven't answered yet
17:49:59 <happyassassin> (that's from right now)
17:51:25 <adamw> tap tap
17:51:35 <happyassassin> ...aaaand we're back! okay.
17:51:52 <adamw> so, this is a bit of a bind
17:51:59 <Eighth_Doctor> ?
17:52:01 <adamw> if we have fixes for everything else, do we keep waiting for the new build?
17:52:09 <Eighth_Doctor> we kind of have to
17:52:10 <adamw> if we don't get it by tomorrow, do we slip?
17:52:39 <bcotton> i suppose that depends on how much testing of the signed shim you'd need to feel comfortable with it
17:53:16 <bcotton> like if we did an RC tomorrow and tested everything and then got a signed shim on wednesday, could you feel ready by thursday at 1700 UTC
17:53:21 <adamw> i don't think it needs a whole ton, but we need to actually have it
17:53:35 <adamw> i'm not ever super happy spinning an rc on wednesday for signoff on thursday
17:53:49 <adamw> never mind whatever specific change goes in it, something could always go wrong
17:55:08 <bcotton> The Fedora Motto!
17:55:18 <adamw> heh
17:56:24 <adamw> #info we'll have to play this one by ear, depending on when other fixes arrive and when this one does
17:56:40 <adamw> #topic (1946278) latest uboot fails to load the dtb
17:56:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1946278
17:56:51 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/322
17:56:57 <adamw> #info Accepted Blocker, uboot-tools, MODIFIED
17:57:06 <adamw> so happily pbrobinson submitted the fix for this today
17:57:11 <adamw> it just needs testing and pulling in
17:57:20 <adamw> #info the fix for this is now submitted, we just need to test it and pull it into composes
17:57:25 * pwhalen is testing it
18:00:06 <adamw> #info pwhalen is testing the fix now
18:00:08 <adamw> thanks pwhalen!
18:00:10 <adamw> okay, moving on, then
18:00:32 <adamw> #topic (1950788) Include xorg-x11-server-1.20.11 and xorg-x11-server-Xwayland-21.1.1-1.fc34 into Fedora 34 to fix CVE-2021-3472
18:00:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1950788
18:00:44 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/359
18:00:49 <adamw> #info Accepted Blocker, xorg-x11-server, NEW
18:00:55 <adamw> #info Ticket vote: FinalBlocker (+3,0,-0) (+bcotton, +kparal, +adamwill)
18:01:18 <adamw> so this one is fairly straightforward, the builds are done, just need an update (if it doesn't alrteady exist)
18:01:28 <adamw> #info this just needs an update to be prepared or marked as fixing the bug, and tested
18:01:33 <adamw> i'll check into that today
18:01:53 <frantisekz> update exists already
18:01:57 <frantisekz> is pending f34 stable
18:03:09 <frantisekz> https://bodhi.fedoraproject.org/updates/FEDORA-2021-112d542766 and https://bodhi.fedoraproject.org/updates/FEDORA-2021-0e2981e013
18:03:45 <adamw> ah k, great.
18:03:51 <adamw> just needs editing then.
18:04:03 <frantisekz> yep
18:04:05 <adamw> so, in that case...
18:04:07 <adamw> #topic Open floor
18:04:10 <adamw> any other business, folks?
18:05:00 <frantisekz> I'll keep my fingers crossed for a successful RC compose and get ready for testing, hoping we'll just shuffle shim before Thursday
18:05:27 <adamw> i'll aim to do at least a compose today
18:05:37 <frantisekz> adamw++
18:05:38 <zodbot> frantisekz: Karma for adamwill changed to 13 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:05:51 <frantisekz> also, thanks adamw for leading the meeting!
18:06:30 <copperi> adamw++
18:06:30 <zodbot> copperi: Karma for adamwill changed to 14 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:06:36 <coremodule> thanks adamw for leading this meeting, as always
18:06:40 <coremodule> adam++
18:06:40 <zodbot> coremodule: Karma for adam changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:06:45 <coremodule> adamq++
18:06:48 <coremodule> adamw++
18:06:48 <zodbot> coremodule: Karma for adamwill changed to 15 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:08:07 <Southern_Gentlem> adamw++
18:08:07 <zodbot> Southern_Gentlem: Karma for adamwill changed to 16 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:08:23 <Southern_Gentlem> coremodule++
18:08:45 <adamw> #endmeeting