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