16:02:08 <adamw> #startmeeting F35-blocker-review
16:02:08 <zodbot> Meeting started Mon Oct 25 16:02:08 2021 UTC.
16:02:08 <zodbot> This meeting is logged and archived in a public location.
16:02:08 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:02:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:08 <zodbot> The meeting name has been set to 'f35-blocker-review'
16:02:12 <adamw> #meetingname F35-blocker-review
16:02:12 <zodbot> The meeting name has been set to 'f35-blocker-review'
16:02:15 <adamw> #topic Roll Call
16:02:17 <bcotton> .hello2
16:02:18 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:22 <pwhalen> .hello2
16:02:23 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
16:02:38 <cmurf[m]> .hello chrismurphy
16:02:39 <zodbot> cmurf[m]: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:02:53 <frantisekz> .hello2
16:02:54 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:03:34 <adamw> ahoyhoy folks
16:03:53 <Eighth_Doctor> .hello ngompa
16:03:54 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:04:11 <coremodule> .hello2
16:04:12 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:05:48 <lruzicka2> .hello lruzicka
16:05:49 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:07:32 * coremodule willing to secretarialize.
16:08:16 <adamw> thanks coremodule
16:09:54 <adamw> #chair frantisekz coremodule
16:09:54 <zodbot> Current chairs: adamw coremodule frantisekz
16:09:59 <adamw> boilerplate alert!
16:10:03 <adamw> #topic Introduction
16:10:07 <adamw> Why are we here?
16:10:10 <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:10:13 <adamw> #info We'll be following the process outlined at:
16:10:15 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:10:18 <adamw> #info The bugs up for review today are available at:
16:10:22 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:10:25 <adamw> #info The criteria for release blocking bugs can be found at:
16:10:28 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:10:32 <adamw> #link https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria
16:10:35 <adamw> #link https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria
16:10:38 <adamw> #info for Final, we have:
16:10:49 <adamw> #info 4 Proposed Blockers
16:10:52 <adamw> #info 4 Accepted Blockers
16:10:59 <adamw> #info 5 Proposed Freeze Exceptions
16:11:01 <adamw> #info 11 Accepted Freeze Exceptions
16:11:15 <adamw> #info coremodule will secretarialize
16:11:19 <adamw> let's get rolling, with:
16:11:22 <adamw> #topic Proposed Final blockers
16:11:30 <adamw> #topic (2016613) Anaconda in F35 does not switch keyboard layout correctly
16:11:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2016613
16:11:37 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/566
16:11:40 <adamw> #info Proposed Blocker, anaconda, NEW
16:11:46 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+ahmedalmeleh)
16:11:52 <adamw> so this is, uh, awkward.
16:13:13 <adamw> it's visible on lives. we have had issues with anaconda layout configuration on lives ever since we switched workstation to wayland - see https://bugzilla.redhat.com/show_bug.cgi?id=1389959 - and we haven't been blocking on that. but the behaviour does seem to have got a bit worse.
16:16:34 <lruzicka2> It can be worked around and I do not believe we are going to fix this this week
16:17:24 <adamw> how can it be worked around?
16:17:36 <adamw> aside from 'just do everything in us'
16:17:42 <bcotton> i'm mixed on this. it only affects the secondary configuration, right?
16:17:45 <adamw> (which is, practically speaking, what most people probably do, but still)
16:17:48 <adamw> Ben Cotton (he/him/his): yes.
16:18:10 <lruzicka2> adamw, do it in us and change from the installed system
16:18:15 <adamw> it basically means you can't type any character with the secondary layout that requires a modifier key. so, no capital letters.
16:18:29 <pwhalen> oof. And it only affects KDE?
16:18:53 <pwhalen> ah, I see WS too
16:18:59 <adamw> no, workstation too. though you're less likely to really notice it on workstation as you don't really type anything there typically, and anything you do type you would almost certainly want to type with the US layout.
16:19:00 <lruzicka2> pwhalen, no, it affects both according to kparal, but on gnome you do not need that layout until gis
16:19:04 <lruzicka2> and it works in gis
16:19:05 <bcotton> https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Keyboard_layout_configuration doesn't specify, but i'd naiively assume it would only apply to the primary layout (although I see the case for secondary, too)
16:19:30 <adamw> Ben Cotton (he/him/his): that should probably read "keyboard layout configuration", not "keyboard layout", for clarity.
16:19:47 <adamw> the intent of the criterion is that when a pair of layouts is default/needed, both, and switching, should work.
16:20:28 <bcotton> okay, well with that in mind call me
16:20:30 <bcotton> +1 blocker
16:20:38 <bcotton> (although i'd likely vote to waive)
16:20:39 <adamw> of course, the criterion doesn't actually *say* "in anaconda"
16:20:45 <bcotton> also true :-)
16:20:49 <adamw> which is probably an oversight, but hey. :P
16:21:01 <pwhalen> +1 blocker :(
16:21:28 <bcotton> oh, and the criterion i cited is in post-install
16:21:32 <lruzicka2> I think that we want to waive it, right? so I suggest to make it an F36 blocker already
16:21:50 <adamw> eh, there might be something we could do which might be sensible anyway
16:22:22 <adamw> although, hmm. we can hide the layout config spoke, but that wouldn't entirely hide the issue. hiding it completely is...more difficult.
16:23:18 <bcotton> so i guess my question is: do we not have a criterion that covers this because we meant to but didn't, or because we decided we shouldn't block on keyboard layout issues in the installer?
16:23:27 <bcotton> (i'm inclined to think the former)
16:23:29 <lruzicka2> I would recommend, if someone needs the two layouts, that they will make their national layout primary
16:24:12 <lruzicka2> bcotton, yeah, I think so too
16:24:25 <adamw> hum, that would probably work as a workaround specifically for typing stuff during install, though it's a bit icky
16:24:25 <frantisekz> that can be common bug, since Workstation is virtually unaffected, group of people that is going to hit this seems small
16:24:37 <adamw> i'm trying to think through what it would do post-install
16:24:48 <adamw> oh, it, uh, might cause unexpected results for the console layout configuration...
16:24:57 <lruzicka2> I also support CommonBugs, but make it an early blocker and make sure it gets fixed in 36
16:25:18 <lruzicka2> adamw, this does not happen on everything or server
16:25:31 <adamw> no, but you use the console on graphical installs too.
16:25:37 <adamw> (notably during boot. when you're unlocking things.)
16:27:00 <lruzicka2> adamw, I am using Czech as my primary layout and the console is in czech when booting, which is what i expect and believe others might too?
16:27:25 <lruzicka2> of course, they may have a different use case ...
16:27:32 <adamw> lruzicka2: we specifically don't configure things that way by default for switched layouts in general, at the request of multiple native users
16:27:44 <adamw> russian users want us by default, cyrillic on switching, for e.g.
16:29:19 <lruzicka2> adamw, well ... you know that better :D
16:30:01 <adamw> anyway, we can figure out commonbugs protocols later, doesn't need to be in this meeting
16:30:46 <adamw> to answer ben's question, honestly I think "in anaconda" missing from the criterion is an oversight
16:31:03 <adamw> so on conscience i kinda have to be +1 blocker on this. but might vote to waive it if it comes to that.
16:31:26 <adamw> (depending on what we figure out about why this suddenly started happening.)
16:32:10 <lruzicka2> ok, let's vote. I think all have been said.
16:33:59 <adamw> so i count +1 me, +1 ben, +1 pwhalen, +1 from the issue, we're at +4
16:34:00 <adamw> any other votes?
16:34:16 <lruzicka2> +1 fb (will vote for waive)
16:34:31 <coremodule> +1 blocker
16:34:39 <frantisekz> +1 blocker then
16:36:37 <adamw> ok
16:36:51 <Southern_Gentlem> +1 fb
16:37:06 <sumantro> +1 fb
16:37:48 <adamw> proposed #agreed 2016613 - AcceptedBlocker (Final) - this is accepted as a violation of the intent of the "If a particular keyboard layout has been configured for the system, that keyboard layout must be used:  ..." criterion - "in the installer" is not listed in that criterion, but we agree this is an oversight and it is intended to be covered (we will rectify this later)
16:37:57 <frantisekz> ack
16:38:03 <lruzicka2> ack
16:38:04 <bcotton> ack
16:38:29 <sumantro> ack
16:39:14 <adamw> #agreed 2016613 - AcceptedBlocker (Final) - this is accepted as a violation of the intent of the "If a particular keyboard layout has been configured for the system, that keyboard layout must be used:  ..." criterion - "in the installer" is not listed in that criterion, but we agree this is an oversight and it is intended to be covered (we will rectify this later)
16:39:49 <adamw> #topic (2017043) WS GIS aarch64 doesn't accept input from wireless keyboard
16:39:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2017043
16:39:57 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/568
16:39:59 <adamw> #info Proposed Blocker, gnome-initial-setup, NEW
16:40:49 <pwhalen> I was able to reproduce this on the RPi4 using a logitech keyboard. Same keyboard works on the Jetson Nano in GIS
16:41:06 <adamw> well this is wacky
16:41:09 <adamw> is rpi4 a supported device, though?
16:41:09 <frantisekz> if I recall correctly, the rpi4 is still unsupported anyway?
16:41:12 <pwhalen> Dug out another wireless keyboard by "IOGear" and it works Ok
16:41:37 <adamw> man, this one needs to go in the wacky bugs hall of fame
16:41:41 <coremodule> I also reproduced with a wireless Logitech keyboard... other keyboard (apple usb) works fine. tested on both rpi3 and rpi4 and same issue.
16:41:52 <ahmedalmeleh> ok
16:41:52 <pwhalen> frantisekz: right, I was concerned it was a general issue but it worked on the nano.. so I am -1Blocker
16:41:52 <adamw> oof, rpi3 is supported isn't it?
16:42:02 <coremodule> adamw, yes
16:42:11 <pwhalen> adamw: not for workstation, 1G ram won't cut it
16:42:16 <adamw> ah, k
16:42:22 <adamw> so on that basis...probably -1
16:42:32 <adamw> +1 WackyBugsHoF
16:42:41 <adamw> +1 FE, if it happens to be fixable
16:42:48 <bcotton> -1 blocker +1 WBHoF +1 FE
16:42:50 <pwhalen> +1FE if someone figures it out, logitech is likely what most people have
16:42:54 <frantisekz> the 3D is unaccelerated on rpi4, it's freezing like there is no tomorrow, impossible to use anyway with a DE; -1 Blocker
16:43:05 <coremodule> -1 blocker, +1 FE
16:43:13 <sumantro> +1 FE
16:43:14 <lruzicka2> ditto
16:43:15 <Southern_Gentlem> +1 fe
16:43:17 <pwhalen> frantisekz: it works better with xorg, but yea
16:43:37 <frantisekz> pwhalen: will try, thanks for the hint
16:44:48 <adamw> proposed #agreed 2017043 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as there doesn't seem to a be blocking scenario (hardware plus input device plus environment) which is affected, but accepted as an FE issue as it cannot be fixed with an update and would be good to fix for the non-blocking RPi4 case if possible
16:44:50 <pwhalen> the logitech keyboard works everywhere except the text boxes in GIS
16:45:05 <bcotton> ack
16:45:06 <pwhalen> ack
16:45:11 <frantisekz> ack
16:45:14 <coremodule> ack
16:45:17 <sumantro> ack
16:46:17 <ahmedalmeleh> ack
16:46:49 <lruzicka2> ack
16:46:59 <adamw> #agreed 2017043 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as there doesn't seem to a be blocking scenario (hardware plus input device plus environment) which is affected, but accepted as an FE issue as it cannot be fixed with an update and would be good to fix for the non-blocking RPi4 case if possible
16:47:14 <adamw> #topic (2011928) Fedora 35 aarch64 cloud image based openstack VM hangs
16:47:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2011928
16:47:20 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/525
16:47:24 <adamw> #info Proposed Blocker, kernel, NEW
16:47:28 <adamw> #info Ticket vote: FinalBlocker (+2,0,-0) (+bcotton, +ahmedalmeleh)
16:47:38 <adamw> so this continues to be a bit hard to grasp, right?
16:47:45 <bcotton> it does seem that way
16:47:59 <bcotton> i haven't removed my +1, but I'm not sure if i still feel that way
16:48:13 <jforbes> So glad F35 cloud images are a new F35 feature
16:48:27 <jforbes> err btrfs cloud images
16:48:33 <pwhalen> In my testing this only affects one piece of HW and it was the same in F34
16:49:19 <ahmedalmeleh> ok
16:49:27 <Eighth_Doctor> as far as I knew, it hasn't impacted AArch64 on AWS, which our only blocker in criteria right now
16:49:34 <ahmedalmeleh> maybe it should be fe than
16:49:54 <jforbes> It already is an FE, we just don't have a fix to push
16:49:57 <Eighth_Doctor> I don't have an AArch64 OpenStack to triage this in the first place, and it seems to be inconsistently reproducible
16:50:36 <ahmedalmeleh> I don't have AArch64 OpenStack either
16:51:39 <adamw> hmm
16:51:45 <adamw> so the criterion here would really be the basic one:
16:52:01 <adamw> "All release-blocking images must boot in their supported configurations. ... Release-blocking cloud images must boot in the Fedora OpenStack Cloud and in Amazon EC2."
16:52:07 <adamw> the "fedora openstack cloud" has not existed for a while
16:52:10 <adamw> but we never updated that
16:52:12 <Eighth_Doctor> we don't have an Fedora OpenStack Cloud
16:52:13 <Eighth_Doctor> yep
16:52:19 <davdunc[m]> Do we have an OpenStack implementation outside of the vexxhost where we have seen this issue?
16:52:51 <adamw> still, we're clearly communicating a basic intent that cloud images work on openstack, there.
16:52:55 * Eighth_Doctor wonders if Red Hat has a demo RHOSP on the various arches
16:53:06 <Eighth_Doctor> I don't know how we can support OpenStack without a way to test it
16:53:12 <Eighth_Doctor> reliably, that is
16:53:29 <ahmedalmeleh> I see your point I am pretty new to all this
16:53:41 <Eighth_Doctor> I've mostly been relying on AWS to assume that everything is gravy
16:53:49 <adamw> ahmedalmeleh: don't worry about it :)
16:53:53 <adamw> that's why we have multiple votes
16:55:12 <Eighth_Doctor> I haven't seen an issue on AWS, DavidDuncan have you?
16:55:34 <davdunc[m]> no delay similar to the one described on vexxhost.
16:55:59 <adamw> have we checked if this works without btrfs? that's kinda the thing giving me pause here
16:56:17 <Eighth_Doctor> someone said earlier that they saw it on F34 too
16:56:17 <adamw> if there is only one viable public aarch64 openstack cloud, and we don't work on it, and switching back off btrfs would make it work...
16:56:22 <pwhalen> Eighth_Doctor: nor I, I usually test AWS for release validation but really just kick the tires
16:56:27 <adamw> but that was with btrfs i think?
16:56:34 <Eighth_Doctor> nope
16:56:37 <Eighth_Doctor> F34 is ext4
16:56:43 <adamw> by default yeah
16:56:53 <adamw> but i thought in earlier discussion someone said that f34 case had involved btrfs somehow
16:57:01 <Eighth_Doctor> not that I knew of
16:57:14 <Eighth_Doctor> I could have missed something, but iirc, there's no way to convert to btrfs from cloud-init
16:58:24 <Eighth_Doctor> we could also try turning off compression and seeing whether that resolves the vexxhost issue
16:58:36 <Eighth_Doctor> the BZ seems to indicate the problem is with compressed extents
16:59:11 <bcotton> i recall the f34/btrfs connection, too, but i can't find it
16:59:34 <bcotton> but fwiw dusty said FCOS was seeing it without btrfs https://bugzilla.redhat.com/show_bug.cgi?id=2011928#c36
16:59:47 <bcotton> or at least something similar
17:00:01 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1949334 was the f34 bug with the same trace
17:00:05 <adamw> but that specifies btrfs
17:00:41 <cmurf[m]> Dusty Mabe mentioned a pretty boem that might be similar on FCIS which uses XFS
17:00:42 <Eighth_Doctor> https://github.com/coreos/fedora-coreos-tracker/issues/965
17:00:51 <adamw> dusty's issue is https://github.com/coreos/fedora-coreos-tracker/issues/965 , which is f34 and vexxhost, but not the same trace
17:01:10 <Eighth_Doctor> the common thread then would be CoW/reflinks, not btrfs or compression then
17:01:19 <Eighth_Doctor> because both btrfs and xfs are reflink/cow-enabled
17:01:26 <adamw> and his latest comment was "Since we are no longer seeing issues with FCOS I assume it's safe to say that the BZ and this issue are sufficiently unrelated."
17:01:38 <adamw> (where "the BZ" means "the one we're talking about now")
17:02:30 <Eighth_Doctor> dusty's response was 3 hours ago
17:02:33 <Eighth_Doctor> that's really recent
17:02:38 <cmurf[m]> pwhalen hit it in f34 with a 5.11 kernel, on Amberwing
17:02:52 <Eighth_Doctor> I don't think any of us tested Cloud on VexxHost in the last three hours
17:02:59 <cmurf[m]> But it might have been IoT with an Anaconda installation? Not sure
17:03:08 <Eighth_Doctor> "VexxHost got back to me in the ticket and said they updated their hypervisor's and kernel versions" -- Dusty
17:03:20 <cmurf[m]> Or maybe Workstation edition simce that's a block combo and btrgs is default
17:03:53 <pwhalen> cmurf[m]: the Amberwing bug was a default f34 installation
17:04:03 <pwhalen> with btrfs
17:04:24 <adamw> yeah. i linked to it. the traceback has btrfs in it. :D
17:04:42 <adamw> so, let's zoom out again
17:04:59 <cmurf[m]> I have been testing on vexxhost this whole morning
17:05:17 <cmurf[m]> It's definitely aarch64 only
17:05:23 <adamw> f35 cloud aarch64 status is: it works on ec2, which is realistically where people are most likely to use it. it doesn't work on vexxhost, which is the only(?) public openstack instance we know with aarch64 on it. we haven't tested it in any other cloud environments. yes?
17:05:33 <Eighth_Doctor> yep
17:05:39 <Eighth_Doctor> that's the sitch
17:05:52 <cmurf[m]> It mostly works on vexxhost, i only hit the problem occasionally
17:06:11 <adamw> okay. hmm.
17:06:13 <pwhalen> then it seems to have improved
17:06:41 <cmurf[m]> It's just a badly timed bug for us
17:06:50 <adamw> i guess i might be -1 blocker on this then, overall. we can document it as an ongoing issue we're trying to get resolved
17:07:09 <cmurf[m]> I smell a race. So does upstream
17:07:16 <adamw> how does deployment work on vexxhost? do they have the images for you to pick from, or do you provide your own?
17:07:25 <cmurf[m]> Its a bit Heisenbug too, the more we peer behind the curtain the less often it happens
17:07:33 <cmurf[m]> Not sure
17:07:35 <pwhalen> fun
17:07:43 <Southern_Gentlem> -1 fb
17:07:52 <cmurf[m]> dusty around?
17:08:33 <lruzicka2> -1 fb
17:09:08 <frantisekz> -1 Blocker
17:09:13 <Eighth_Doctor> -1 Blocker
17:10:47 <bcotton> change me to -1 blocker
17:11:24 <bcotton> if it's still around in f36 beta i might be +1, but at this point it's hard to be confident about blocking on it
17:11:52 <Eighth_Doctor> we also should get some OpenStack resources allocated to keep OpenStack on the blocker list
17:11:59 <adamw> proposed #agreed 2011928 - RejectedBlocker (Final) - this is a tough call as we cannot be sure if it specific to vexxhost's environment somehow, and if the problem lies there or in Fedora 35 itself. we agreed on current information to reject this as a blocker and document it as an ongoing situation with vexxhost which we will try to get resolved ASAP.
17:12:09 <bcotton> ack
17:12:13 <Eighth_Doctor> ack
17:12:16 <dustymabe> questions for me?
17:12:18 <cmurf[m]> It has been around for months as far as i can tell
17:12:21 <coremodule> ack
17:12:24 <pwhalen> ack
17:12:29 <lruzicka2> ack
17:12:30 <ahmedalmeleh> -1 blocker
17:12:32 <cmurf[m]> pwhalen first ran into it in April
17:12:41 <frantisekz> ack
17:12:59 <cmurf[m]> So now that there's a WTF moment and partial reproducer the problem will be found
17:13:53 <Eighth_Doctor> since we respin Cloud images every two weeks, we can resolve it post-GA too
17:13:59 <cmurf[m]> It'll just take some tediousness :P
17:14:10 <cmurf[m]> That too
17:14:11 <dustymabe> ehh. we never update the website
17:14:19 <Eighth_Doctor> :/
17:14:23 <dustymabe> there's really no good process for respinning our cloud images
17:14:24 <cmurf[m]> Oops
17:14:29 <cmurf[m]> Well that's fixable
17:14:54 <cmurf[m]> ruhroh
17:15:04 <Eighth_Doctor> uhhh
17:15:46 <ahmedalmeleh> I -1 the openstack blocker
17:16:24 <adamw> #agreed 2011928 - RejectedBlocker (Final) - this is a tough call as we cannot be sure if it specific to vexxhost's environment somehow, and if the problem lies there or in Fedora 35 itself. we agreed on current information to reject this as a blocker and document it as an ongoing situation with vexxhost which we will try to get resolved ASAP.
17:16:32 <adamw> #topic (2016253) wireplumber not enabled automatically
17:16:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2016253
17:16:39 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/567
17:16:43 <adamw> #info Proposed Blocker, wireplumber, MODIFIED
17:16:47 <adamw> #info Ticket vote: FinalFreezeException (+3,0,-0) (+frantisekz, +catanzaro, +lruzicka)
17:16:51 <adamw> #info Ticket vote: 0Day (+3,0,-0) (+kparal, +catanzaro, +bcotton)
17:18:20 <adamw> so, just as a refresher, a '0day' blocker is a special case where the update only needs to be stable on release day, not included in the compose
17:18:38 <adamw> upgrade bugs are like this as upgrades always use the repositories and include update packages (these days)
17:18:43 <Eighth_Doctor> there are other bugs that have been previously approved as FEs attached to this BZ
17:19:05 <adamw> if the problem is indeed as Conan Kudo thinks it is, i'm +1 0Day
17:19:24 <Eighth_Doctor> err attached to this update
17:19:59 <adamw> even if we can't immediately reproduce it with a default f34 install, since rpm package ordering is highly sensitive to all sorts of things, it's kinda impractical to rule out that it could possibly happen, the safe thing to do is fix it
17:20:13 <Eighth_Doctor> yeah
17:20:27 <cmurf[m]> +1 0day, +1 fb if it can't be fixed with an update
17:20:31 <Eighth_Doctor> https://bodhi.fedoraproject.org/updates/FEDORA-2021-3c4c454c98#bugs
17:21:32 <ahmedalmeleh> is a releaseblocker a one that needs an update?
17:21:44 <adamw> Conan Kudo: as a nitpick, the comments on the triggerun script could be better
17:21:59 <adamw> ahmedalmeleh: a normal release blocker needs the fix to be included *in the final compose*
17:22:17 <ahmedalmeleh> got it
17:22:18 <adamw> a bug being a 0day blocker essentially gives us a bit more time to fix it
17:22:30 <adamw> we can create the final compose without fixing it, then sort it out in the next few days
17:22:36 <ahmedalmeleh> I'm going to go
17:22:42 <adamw> thanks for coming!
17:23:09 <adamw> Conan Kudo: the line "# Initial installation" is  a lie, and the earlier comment could explain more comprehensively that it's a failsafe for when the ordering goes wrong
17:23:23 <Eighth_Doctor> oops
17:23:24 <ahmedalmeleh> I meant choose +1 0day, +1 fe
17:23:27 <adamw> Conan Kudo: what exactly does systemd-update-helper installer-user-units *do*?
17:23:29 <Eighth_Doctor> I copy-pasta'd it from %systemd_user_post
17:23:34 <adamw> ahmed: oh i see :D
17:23:39 <Eighth_Doctor> I just expanded that macro and pasta'd it
17:23:40 <adamw> Conan Kudo: yup, i saw that :D
17:23:59 <adamw> i'm just trying to consider any possibility it could do something unintended
17:24:01 <Eighth_Doctor> it's supposed to replicate the delayed activation thingy used for system units
17:24:06 <Eighth_Doctor> for user units
17:24:53 <Eighth_Doctor> so it marks the units to be enabled by the transaction trigger later in systemd
17:26:00 <adamw> yeah, i get the basic idea, what i'm trying to get at is, could it do something unexpected in a case other than the simple one we're fixing
17:26:12 <Eighth_Doctor> no
17:26:18 <adamw> on the whole i think, probably not, just trying to be sure
17:26:40 <Eighth_Doctor> it's basically the same trick I used for X->Wayland transition for Plasma for F34
17:26:59 <adamw> man, i remember when i was young and gave definite answers to things :P
17:27:02 <adamw> ok, so
17:27:10 <adamw> i think we have the votes for 0day, does anyone object?
17:27:27 <Eighth_Doctor> we also have the FE votes too, iirc
17:27:38 <pwhalen> +1 0day, +1 fe
17:27:47 <bcotton> no, but i'm curious as to how the logistics will work, but we can talk about that after the meeting
17:27:48 <adamw> yeah, i guess we can call it both.
17:27:56 <Eighth_Doctor> +1 FE, +1 0day
17:28:06 <adamw> Ben Cotton (he/him/his): well, practically speaking, the logistics are "we'll just include it in the rc anyway" :D
17:28:16 <bcotton> doesn't being a 0day blocker imply an FE?
17:28:50 <bcotton> adamw: oh yeah, there's already a fix. nevermind :-) (I'm wondering about the day when we have a 0day blocker but no fix)
17:29:18 <frantisekz> +1 0day, +1 fe
17:29:36 <adamw> proposed #agreed 2016253 - Accepted0Day (Final), AcceptedFreezeException (Final) - this is accepted as a conditional violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade...The upgraded system must meet all release criteria", as we hold it's sufficiently likely this could possibly happen in such a case to be worth blocking on. Also FE to fix it sooner.
17:29:43 <adamw> was that short enough for IRC?
17:29:49 <Eighth_Doctor> ack
17:29:56 <Eighth_Doctor> +1
17:30:03 <adamw> Ben Cotton (he/him/his): technically i think 0day doesn't actually imply FE, at least we haven't written that down anywhere
17:30:04 <Southern_Gentlem> ack
17:30:09 <coremodule> adamw, yes
17:30:10 <pwhalen> ack
17:30:15 <coremodule> ack
17:30:16 <bcotton> ack
17:30:24 <adamw> Ben Cotton (he/him/his): and the answer to "how does it work if we don't have the fix already?" is "we all pinky promise really hard to have the fix done by monday"
17:30:27 <lruzicka2> ack
17:30:34 <frantisekz> ack
17:30:44 <adamw> #agreed 2016253 - Accepted0Day (Final), AcceptedFreezeException (Final) - this is accepted as a conditional violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade...The upgraded system must meet all release criteria", as we hold it's sufficiently likely this could possibly happen in such a case to be worth blocking on. Also FE to fix it sooner.
17:31:12 <Eighth_Doctor> now the wireplumber update just needs +1 karma to mark to stable again
17:31:22 <Eighth_Doctor> (it was, but then I updated it, so...)
17:31:48 <ahmedalmeleh> ack
17:31:51 <adamw> we'll get to that
17:33:02 <ahmedalmeleh> does this look like a no-go
17:33:03 <ahmedalmeleh> ?
17:33:16 <frantisekz> that will be decided on thursday
17:33:44 <ahmedalmeleh> ok
17:33:50 <jforbes> A lot can happen between now and Thursday
17:34:16 <Eighth_Doctor> there's a whole 36 hours!
17:34:20 <bcotton> s/A lot/Kamil/
17:34:57 <frantisekz> :D
17:35:06 <adamw> okay, so
17:35:29 <frantisekz> we should talk with somebody from infra... to prevent kamil from logging in anywhere before thursday
17:36:00 <Southern_Gentlem> send the kamil squad out
17:36:38 <adamw> in the interests of time, i think we can skip the proposed FEs
17:36:53 <adamw> #topic Proposed Final freeze exceptions
17:37:05 <adamw> #info we'll skip this section, as time is running on and most of them have ticket votes
17:37:18 <adamw> #info please vote in the tickets if you want to vote on these, i will update them shortly after the meeting
17:37:27 <adamw> #topic Accepted Final blockers
17:37:43 <adamw> let's check where we are on the accepted blokcers
17:38:18 <ahmedalmeleh> we just need to vote the WS GIS aarch64 doesn't accept input from wireless keyboard
17:38:32 <adamw> #info 2015972 - this is verified
17:38:52 <adamw> oh, didn't we vote that earlier?
17:39:04 <adamw> we did, we accepted it
17:39:15 <adamw> #topic (2016310) The KDE LiveCD 35 RC does not boot in basic graphics mode.
17:39:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2016310
17:39:22 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/562
17:39:25 <adamw> #info Accepted Blocker, LiveCD - KDE, MODIFIED
17:39:54 <Eighth_Doctor> jlinton, marcdeop, and I have been talking about this in the SIG meeting
17:40:19 <adamw> we basically know what is going on here, it's just a question of finding a safe and appropriate fix
17:40:32 <adamw> i think jlinton's latest idea is probably okay, but it'd be nice to have more input, inc. from graphics experts
17:40:36 <Southern_Gentlem> let me check something
17:40:51 <jlinton> I'm here, if there are any questions/testing needed. I have an additional patch to remove the udev rule entirely i'm testing.
17:40:55 * Eighth_Doctor can't wait for simpledrm
17:41:08 <adamw> short version - the latest idea is to only enable KDE's wayland sessions if there's a /dev/dri/cardX
17:41:16 <Southern_Gentlem> worked as of friday on my respinss
17:41:20 <adamw> so we need to know if there are any cases where wayland works, but there is no /dev/dri/cardX
17:41:32 <Eighth_Doctor> KDE yes, but not on Fedora
17:41:40 <Eighth_Doctor> wayland is supposed to work with fbdev, it just doesn't on Fedora
17:42:10 <Eighth_Doctor> but we're okay with not supporting that right now
17:42:16 <Eighth_Doctor> since simpledrm will obsolete that entire codepath
17:43:10 <ahmedalmeleh> Well do we need to remove that blocker?
17:43:21 <Eighth_Doctor> so if there's no /dev/dri/cardX, we are fine with no wayland
17:43:53 <Southern_Gentlem> Eighth_Doctor, well i have kde iso i built on friday that basic video is booting
17:44:26 <ahmedalmeleh> Unless someone writes a whole new codepath and gets wayland working on fed kde in super fast time
17:44:31 <jlinton> There are a couple races in that code path, so it can fallback to X in cases somewhat randomly.
17:44:45 <Southern_Gentlem> https://drive.google.com/drive/folders/1x70jhY5S18TB6lXPI7QYjDFuWelLm6ov
17:44:47 <adamw> ahmedalmeleh: no, we are planning to fix it. we're just discussing the details of that atm.
17:45:17 <adamw> jlinton: that doesn't sound *great*. you mean we can get to sddm startup before the device nodes exist somehow?
17:45:29 <Eighth_Doctor> that's how this problem happens in the first place
17:46:09 <ahmedalmeleh> I hope we are able to fix it
17:46:23 <ahmedalmeleh> or last option we just keep kde x11 only
17:46:37 <jlinton> I'm not sure how it might get started before _any_ graphics.
17:47:23 <jlinton> Its more a question of whether the DRM driver has started, there was that logind race which can cause the seat to get created without logind
17:48:01 <jlinton> Those are what I'm trying to close.
17:49:38 <adamw> okay, so, anyway, we're working on this.
17:49:56 <adamw> #info we're actively working to get a usable fix for this, no specific action is needed to move it along
17:50:22 <ahmedalmeleh> right
17:50:24 <adamw> #info 2016510 is ON_QA and showing mostly positive results in testing so far, kparal is working on a subcase where steam doesn't always show up
17:50:53 <adamw> #info 2011322 is ON_QA because we need to confirm it keeps working over time, but the fix is pushed stable and we think it's good
17:50:57 <adamw> that's all the accepted blockers
17:50:59 <adamw> #topic Open floor
17:51:02 <adamw> any other business, folks?
17:51:50 * bcotton has nothing
17:51:52 <adamw> note i'll aim to spin another RC today or tomorrow, even if there are outstanding blockers if they look plausibly 'waivable'
17:53:13 <ahmedalmeleh> Ok
17:53:26 * lruzicka2 has the same as bcotton
17:53:28 <frantisekz> just a note, there is broken voting in https://pagure.io/fedora-qa/blocker-review/issue/447
17:53:39 <frantisekz> we can vote in here quickly, or I can try revote?
17:54:20 <adamw> lruzicka2: it's not exactly broken
17:54:24 <Eighth_Doctor> FinalFE +1
17:54:26 <adamw> it is already marked as accepted, but for no obvious reason
17:54:33 <adamw> er, that was for frantisekz, sorry
17:54:38 <adamw> https://pagure.io/fedora-qa/blocker-review/issue/447#comment-751676
17:54:40 <lruzicka2> adamw, you wanted to point that to frantisekz
17:55:18 <adamw> yes, although it was you who did it. :P
17:55:41 <adamw> please vote again, it should work now
17:55:49 <adamw> wow, you guys are fast
17:55:57 <ahmedalmeleh> any opinions on WS GIS aarch64 doesn't accept input from wireless keyboard?
17:56:13 <frantisekz> thanks!
17:56:13 <Southern_Gentlem> brand of wireless keyboard
17:56:17 <adamw> ahmedalmeleh: we already accepted it as FE earlier in the meeting
17:56:26 <ahmedalmeleh> ok
17:56:26 <adamw> it will be updated by coremodule after the meeting ends
17:57:45 <ahmedalmeleh> ok
17:57:52 <adamw> okay, i guess that's all?
17:58:09 <adamw> let's go work on the accepted blockers :) if anyone can help figure out the anaconda keyboard thing it'd be useful
17:58:18 <ahmedalmeleh> ok bye
17:58:36 <adamw> thanks for coming, everyone
17:58:42 <Eighth_Doctor> bye y'all
17:59:28 <adamw> #endmeeting