16:07:41 #startmeeting F39-blocker-review 16:07:41 Meeting started Mon Aug 28 16:07:41 2023 UTC. 16:07:41 This meeting is logged and archived in a public location. 16:07:41 The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:07:41 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:07:41 The meeting name has been set to 'f39-blocker-review' 16:07:42 #meetingname F39-blocker-review 16:07:42 The meeting name has been set to 'f39-blocker-review' 16:07:42 #topic Roll Call 16:07:55 ahoyhoy, who's around for some exciting f39 blocker revieW? 16:08:11 .hello geraldosimiao 16:08:12 geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' 16:08:16 .hello2 16:08:17 coremodule: coremodule 'Geoffrey Marr' 16:08:31 * coremodule is here, and welcomes the first one of the cycle! 16:08:34 * kparal is here 16:08:44 * coremodule is also willing to act as secretary. 16:09:23 thanks coremodule 16:09:32 #chair geraldosimiao coremodule 16:09:32 Current chairs: adamw coremodule geraldosimiao 16:11:15 alrighty, let's get going 16:11:26 boilerplate alert 16:11:31 #topic Introduction 16:11:32 Why are we here? 16:11:32 #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:11:32 #info We'll be following the process outlined at: 16:11:32 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:11:33 #info The bugs up for review today are available at: 16:11:35 #link http://qa.fedoraproject.org/blockerbugs/current 16:11:37 #info The criteria for release blocking bugs can be found at: 16:11:39 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:11:41 #link https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria 16:11:43 #link https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria 16:11:52 thanks to everyone's awesome work at tracker voting, we have: 16:12:05 for Beta: 16:12:06 #info 2 Proposed Blockers 16:12:06 #info 6 Accepted Blockers 16:12:12 #info 2 Proposed Freeze Exceptions 16:12:12 #info 36 Accepted Freeze Exceptions 16:12:25 and for Final: 16:12:27 #info 5 Proposed Blockers 16:12:27 #info 3 Accepted Blockers 16:12:47 oh dear, I should have done more #info there, it'll look a bit weird in the logs. never mind 16:13:12 it was a speedrun... all this proposed bugs 16:15:18 yeah, sorry for the churn 16:15:36 #info many thanks to folks for doing a lot of ticket voting 16:15:43 #info coremodule will secretarialize 16:15:52 okay, let's get rolling with: 16:16:13 #topic Proposed Beta blockers 16:16:29 #topic (2234466) crash after clicking Reset All in Blivet partitioning (in GTK installer) 16:16:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=2234466 16:16:30 #link https://pagure.io/fedora-qa/blocker-review/issue/1189 16:16:30 #info Proposed Blocker, anaconda, NEW 16:16:30 #info Ticket vote: BetaBlocker (+0,0,-1) (-frantisekz) 16:16:42 this one is accepted as Beta FE and Final blocker already, but has also been proposed as Beta blocekr 16:17:25 I don't see any criterion referenced 16:17:36 ah, "This might violate https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning even though the reset button is not explicitly specified there" 16:18:19 hmm, I think on a strict reading i'd be -1 blocker per that criterion. you don't *need* to hit the Reset All button to accomplish anything listed there. 16:18:51 if you can configure everything properly on your first try :) 16:18:58 yeah 16:18:58 it's a challenge! 16:19:02 we like to keep folks entertained 16:19:15 I don't have a strong opinion here 16:19:18 okay, to be fair, i can see a black belt criteria judo justification for this as beta blocker 16:19:28 but...I dunno, it's a stretch. 16:19:35 but doesn't ir violate this? Remove existing storage volumes 16:19:35 Assign mount points to existing storage volumes 16:19:35 Reject or disallow invalid disk and volume configurations without crashing. 16:19:57 thats what reset does, or? 16:19:58 i'd say not strictly, no. the button is basically an "oops i messed up, let me start over" button 16:20:07 ok 16:20:11 no, it resets the partitioning tool to the state it had when you started 16:20:21 it's just undo, basically 16:20:26 i.e. the actual current state of the disks (since we don't apply any changes till after you leave the tool) 16:20:48 it's definitely a bad experience for it to crash everything, no question. 16:21:28 i guess the least stretchy part of the criterion is "Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table" 16:21:35 because, I mean, it can do that...*once*. :D 16:22:11 there's a case for making this a conditional violation, the case being you ask it to 'interpret' the layout twice (by pressing the button). 16:22:15 .hi naraiank 16:22:16 TheExorcist: Sorry, but user 'TheExorcist' does not exist 16:22:31 .hello naraiank 16:22:32 TheExorcist: naraiank 'Naraian K' 16:22:35 hiii! 16:23:02 Hi Adam. 16:23:38 anyone have an opinion/vote here? 16:24:11 oh, well, I think I could agree with a beta blocker on this 16:24:18 Frantisek is already -1 16:24:21 buts its not a strong opinion 16:25:06 I'm fine with -1 16:25:06 im reading/thinking 16:25:11 it's beta... 16:25:17 yeah 16:25:27 it surely is a final blocker 16:25:38 but beta?... meh. 16:26:41 kparal: ooh, hey. this is a libsoup3 crash? 16:26:55 yeah, my interpretation as written is that this is *not* a violation without some criterion judo. I'm -1 based off my interpretation. 16:27:06 its the sort of beta blocker that one could waive on the last blocker review meeting prior to the beta release if its the only betablocker standing 16:27:09 i don't necessarily need a full backtrace, but can you at least post the partial one from coredumpctl on netinst? 16:27:25 geraldosimiao: yeah, that's a good point, I can see us doing that 16:27:28 I'm not sure.. I would say, if there is difficulty in installing, should that be a beta blocker or not... 16:27:30 "we'll just tell people not to push the button!" 16:27:46 the button is a lie. 16:28:19 adamw: does this help? https://bugzilla-attachments.redhat.com/attachment.cgi?id=1985073 16:28:25 lol, don't trsut the button 16:28:30 trust 16:28:37 libsoup crash, you're correct 16:28:45 ah, but it's libsoup2... 16:29:01 i was wondering if it's the same as this other libsoup crash i've been dealing with, but probably not. 16:29:09 i guess i'll reproduce and backtrace it on my own time. 16:29:19 bad ingredients in a soup, but a different soup, it seems 16:30:00 proposed #agreed 2234466 - RejectedBlocker (Beta) - we agreed this doesn't quite violate the Beta criteria. Note it is already accepted as Beta FE and Final blocker. 16:30:16 ACK 16:31:09 ack 16:31:47 .hello2 16:31:48 frantisekz: frantisekz 'František Zatloukal' 16:32:31 ack 16:32:38 #agreed 2234466 - RejectedBlocker (Beta) - we agreed this doesn't quite violate the Beta criteria. Note it is already accepted as Beta FE and Final blocker. 16:33:09 #topic (2234518) webUI: allows you to enter an encryption passphrase in non-ASCII characters with no warning 16:33:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=2234518 16:33:10 #link https://pagure.io/fedora-qa/blocker-review/issue/1193 16:33:10 #info Proposed Blocker, anaconda, ASSIGNED 16:33:10 #info Ticket vote: BetaBlocker (+5,0,-1) (+geraldosimiao, +imsedgar, +tflink, +nielsenb, +lruzicka, -kparal) 16:33:12 #info Ticket vote: BetaFreezeException (+1,0,-0) (+adamwill) 16:33:25 so this theoretically has enough votes to accept, but as the proposer I'm holding back due to the details 16:34:23 I assume people initially mostly voted regarding the crash, and not just the warning UI element 16:34:31 as i mentioned, the more important bugs here seem to be the g-i-s layout problem (already a beta blocker), and the libblockdev crash (already a beta FE). if both those are fixed, anaconda's behaviour is rather less important 16:34:58 i guess there's a case for upgrading the libblockdev crash to a blocker 16:35:43 I completely missed that it's not a blocker 16:36:07 we should discuss as least a final one 16:36:09 i'll propose it... 16:36:30 I didn't get it. You are saying that if the two other bugs are fixed, so this here don't happen? 16:36:33 anyway, regarding the warning UI element, I guess we can't just say "it has to be there!". We have to show that without it, bad things would happen 16:37:27 without the warning people could get a non functioning installation? 16:37:47 depending on wich keyboarde they have? 16:38:14 geraldosimiao: I'm not actually sure about that. but it wouldn't be too different from oldUI either way 16:38:39 the only difference between oldUI behaviour and newUI behaviour here is that oldUI shows you a quite weak warning if you enter a non-ASCII character in a passphrase 16:39:03 (it just adds a bit more text in the middle of the dialog, it's actually quite easy to miss unless you're looking for it - it doesn't show as a 'standard' anaconda warning bar, or make you click twice to confirm, or anything) 16:39:30 so is the lack of that quite-weak warning, in itself, a release blocker? 16:39:33 I wouldn't honestly block on a missing warning, not the beta milestone 16:40:23 frantisekz has a good point, this definitely doesn't feel Beta 16:40:55 OK, again, its most positively a Final blocker, I think. 16:41:48 yeah, but, beta... don't know. must think more on this, I'm not really sure. 16:43:24 https://bugzilla.redhat.com/attachment.cgi?id=1985679 is the warning that oldUI shows 16:44:03 the bit between the two text boxes. the warning at the bottom is always present (in oldUI). 16:44:14 In fact there are two wharnings 16:44:55 for me its a good warning 16:45:12 with a warning icon too 16:45:15 ! 16:46:18 yeah, but it's all just a black text wall, and there's no "reconfirm" mechanism. anyhoo 16:46:30 so...seems like we're a bit uncertain about this 16:46:46 well, franta and kparal sound like -1 16:46:46 so, I propose -1 for beta, and we can talk about final when we can showcase whether this actually breaks something or not 16:46:51 i think i'm -1 too, on the warning specifically 16:47:15 ok, -1 too 16:47:42 ok, let me recount votes 16:47:50 and I think whe must propose and discuss this latter as a final blocker 16:48:21 i don't think we have the votes to reject this as things stand 16:48:28 i think we have: 16:48:45 I think we could call revote in the ticket? 16:48:49 +1 imsedgar tflink nielsenb lruzicka 16:49:06 -1 adamwill frantisekz geraldosimiao kparal 16:49:11 so it's +4/-4 atm 16:49:26 so exciting :D 16:50:17 proposed #agreed 2234518 - punt (delay decision) - as things stand, votes are +4 / -4, with the remaining +1s from earlier ticket votes. We will describe the situation more clearly in the ticket and ask if anyone who voted +1 wishes to change their vote 16:50:25 ack 16:50:37 ack 16:50:38 ack 16:51:15 #agreed 2234518 - punt (delay decision) - as things stand, votes are +4 / -4, with the remaining +1s from earlier ticket votes. We will describe the situation more clearly in the ticket and ask if anyone who voted +1 wishes to change their vote 16:51:46 okay, let's take the new proposed blocker 16:52:19 #topic (2234928) Crashes on encryption passphrases with non-ASCII characters 16:52:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=2234928 16:52:42 #link https://pagure.io/fedora-qa/blocker-review/issue/1200 16:52:52 #info Proposed Blocker, libblockdev, ASSIGNED 16:53:41 when does this crash, after installation starts or before? Just judging the impact 16:53:52 so yeah, thinking about it again, it does seem like there's a solid case for blocking Beta on this. seems like a conditional violation of the "Encrypt newly-created storage volumes", in the case that you enter a non-extended-ASCII character in the passphrase, which is easy enough to do even if we fix g-i-s. 16:54:11 after install starts, so it's the worse case 16:54:25 you probably wind up with partially-done partitioning 16:54:56 ok in that case I'd be in favor of +1 beta blocker 16:55:04 https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning 16:55:05 ok 16:55:10 BetaBlocker +1 16:55:17 BetaBlocker +1 16:56:22 BetaBlocker +1 16:57:38 proposed #agreed 2234928 - AcceptedBlocker (Beta) - this is accepted as a conditional violation of the Beta requirement "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: ... Encrypt newly-created storage volumes", in the case that you include a non-ASCII character in the passphrase (which is easy to do). we note that the crash occurs during the install 16:57:39 process, which makes its impact worse 16:57:41 grr 16:57:53 proposed #agreed 2234928 - AcceptedBlocker (Beta) - this is accepted as a conditional violation of the Beta requirement "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: ... Encrypt newly-created storage volumes", in the case that you include a non-ASCII character in the passphrase (which is easy to do). 16:57:57 let's skip the footnote 16:57:59 ahoy, neal 16:58:02 yo! 16:58:04 ack 16:58:09 * Son_Goku grumbles about IRC again... 16:58:29 ack 16:58:34 ack 16:58:38 we're in a meeting, I guess 16:58:41 .hello ngompa 16:58:42 Son_Goku: ngompa 'Neal Gompa' 16:59:28 yes we are! 16:59:33 #agreed 2234928 - AcceptedBlocker (Beta) - this is accepted as a conditional violation of the Beta requirement "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: ... Encrypt newly-created storage volumes", in the case that you include a non-ASCII character in the passphrase (which is easy to do). 17:00:04 okay, let's move on to: 17:00:10 #topic Proposed Beta freeze exception issues 17:00:30 #topic (2235392) libva-nvidia-driver should replace the nvidia-vaapi-driver rpmfusion package 17:00:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=2235392 17:00:30 #link https://pagure.io/fedora-qa/blocker-review/issue/1221 17:00:30 #info Proposed Freeze Exceptions, libva-nvidia-driver, MODIFIED 17:01:34 I'd say +1 FE , but you know me with FEs... 17:01:52 I think the only argument for taking this in is the upgrade path case 17:02:09 yeah 17:02:11 but I'm not sure how much they tested it and it might need further tweaks 17:02:28 overall it doesn't feel like a strong case for FE to me 17:02:38 just imagine woh many nvidia users on fedora userbase complaining... 17:02:41 i guess the case is 'we should make sure the upgrade path is working the way it's meant to at beta' 17:02:53 but yeah, it seems a bit...unclear 17:03:04 we could ask for more info on why it's important to do this during freeze and vote in ticket/ 17:03:11 this only affects people with this package already installed from rpmfusion, IIUIC 17:03:24 and they don't get anything new, just rpmfusion package swapped for a fedora one 17:04:54 i guess the problem is, what happens if they have it installed, we *don't* do that, and they try to upgrade? will they get dep issues because there isn't an updated version in fusion? or will the current package still be fine? 17:05:14 if the only impact is they have to wait till after beta release for the swap to happen, meh 17:06:48 rpmfusion will adjust according to the current state 17:07:12 if we don't let it in, they'll keep it for longer, I imagine 17:07:57 ok, so do we want to punt or reject-without-prejudice? 17:08:21 Son_Goku already tested it on bodhi, what do you think about this Neal? 17:09:13 it is "stable by karma" set to 1 17:09:32 how is the rpmfusion package named? I can't find it 17:09:53 the whole justification is very barebones 17:10:03 * kparal grumbles 17:10:14 nvidia-vaapi-driver ? 17:10:42 https://koji.rpmfusion.org/koji/packageinfo?packageID=647 17:10:48 thanks 17:12:04 so there's nvidia-vaapi-driver-0.0.10-2.fc39 in rpmfusion-nonfree 17:12:19 proposed #agreed 2235392 - RejectedFreezeException (Beta) - there really isn't sufficient justification provided for why this should happen during freeze. We're happy for this to be re-proposed with more justification. 17:12:41 that's interesting, nonfree, and now we have it in fedora, allegedly the same thing 17:13:23 good point 17:13:24 ack 17:13:29 ack 17:13:38 (I have some insight into these things, I'd say that having a non-complete solution is allright in fedora, there has to be some broken link - which would be part of nvidia's binary blob in this case) 17:13:48 ack 17:14:46 #agreed 2235392 - RejectedFreezeException (Beta) - there really isn't sufficient justification provided for why this should happen during freeze. We're happy for this to be re-proposed with more justification. 17:15:12 #topic (2155256) pyodbc fails to build with Python 3.12: error: PyUnicode_FromUnicode was not declared in this scope 17:15:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=2155256 17:15:13 #link https://pagure.io/fedora-qa/blocker-review/issue/1215 17:15:13 #info Proposed Freeze Exceptions, pyodbc, MODIFIED 17:15:26 note, this is fails-to-install, not just fails-to-build (anything that fails to build with python 3.11 is now fails-to-install) 17:15:43 mhm, auto +1 FE for FTI 17:15:46 so this is an obvious +1 per convention (which i've now written into the guidelines) 17:17:01 right, FE +1 17:17:02 +1 if it's FTI 17:17:25 proposed #agreed 2155256 - AcceptedFreezeException (Beta) - this is accepted as a fails-to-install bug, which we accept as FEs to ease the upgrade path unless there are any complications. 17:17:27 but I might be confused here 17:17:40 doesn't FTI mean that there's no package version in a repo? 17:17:54 there already is one for this package 17:18:40 nope, it would mean that a version of the package in the repo is not installable 17:18:53 so those RPMs can't be installed, it fails the rpm transaction? 17:19:02 it usually fails dep resolve 17:19:21 yes. 17:19:32 which would mean, in this case, that it requires python3.11, and py packages built against 3.11, we have 3.12 in the repos only 17:20:09 how come this might ever happen? shouldn't it be built against 3.12 during mass rebuild? 17:20:18 it failed the mass rebuild 17:20:19 it happens when that fails. 17:20:28 ah 17:20:31 which happens quite a lot, because new python versions make backwards-incompatible changes. 17:20:52 we (by which I mean "mainly churchyard") had to fix hundreds of these so far for python 3.12, it was quite a big one. 17:21:05 but, didn't this here build for py 3.12 https://bodhi.fedoraproject.org/updates/FEDORA-2023-c0fdf45a54 17:21:35 the changelog there is a lie 17:21:40 ohhh 17:21:49 like the reset button on blivet gui 17:21:49 go to the actual package build and check root.log: 17:21:50 https://koji.fedoraproject.org/koji/buildinfo?buildID=2213636 17:21:50 ack 17:21:55 https://kojipkgs.fedoraproject.org//packages/pyodbc/4.0.39/2.fc39/data/logs/x86_64/root.log 17:22:02 and you will see that build actually ran against 3.11 17:22:17 don't know how that happened, but that's what happened :) 17:22:17 don't trust a changelog ever agian... 17:22:18 I can confirm the old package version fails because of a python dep 17:22:36 so 17:22:37 ack 17:22:41 geraldosimiao: trust, but verify :D 17:22:47 koji is super slow for me, but you can also chek deps of the resulting rpms via koji web interface, py3.11 should be noted there (info link next to an rpm) 17:23:15 one more ack? 17:23:18 ack 17:23:33 ack 17:23:45 geraldosimiao note to myself: only use the changelog as a guideline... 17:24:38 #agreed 2155256 - AcceptedFreezeException (Beta) - this is accepted as a fails-to-install bug, which we accept as FEs to ease the upgrade path unless there are any complications. 17:25:06 ok, let's move on to: 17:25:10 #topic Proposed Final blockers 17:25:34 #topic (2232398) [webui] Mount point assignment reports "Duplicate mount point." after deleting mapping 17:25:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=2232398 17:25:34 #link https://pagure.io/fedora-qa/blocker-review/issue/1177 17:25:34 #info Proposed Blocker, anaconda, POST 17:25:34 #info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +kparal) 17:25:36 #info Ticket vote: BetaFreezeException (+3,0,-0) (+tflink, +nielsenb, +geraldosimiao) 17:26:43 shouldn't we punt this one, and let it get fixed by pulling in the PR? #me_lazy 17:27:03 well, that's the lazy option. :D 17:27:09 if we can't agree we can do that 17:27:30 i'm probably a weak +1 on this as a conditional violation of one of the custom partitioning criteria (also we need to rewrite those criteria to cover webUI properly...) 17:27:45 the condition being "you make a mistake and have to redo a mount point" 17:28:23 or just change your mind, or try different layouts, or... 17:28:45 I'll say +1 on this one 17:29:43 right. 17:29:44 well I tjonk this can fit under: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." 17:29:52 I think 17:29:58 +1 for me 17:31:53 proposed #agreed 2232398 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration", read as applying to webUI's mount point assignment interface, in the case you need to re-do a mount point. 17:32:03 ack 17:32:13 ack 17:33:36 ack 17:34:46 #agreed 2232398 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration", read as applying to webUI's mount point assignment interface, in the case you need to re-do a mount point. 17:34:57 #topic (2189899) Blivet-GUI: A btrfs partition can't be reformatted 17:34:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=2189899 17:34:57 #link https://pagure.io/fedora-qa/blocker-review/issue/1157 17:34:57 #info Proposed Blocker, blivet-gui, NEW 17:34:57 #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb) 17:36:01 my thoughts: https://pagure.io/fedora-qa/blocker-review/issue/1157#comment-871144 17:36:39 no strong opinion here 17:37:23 ugh. seems like kind of a mess. 17:37:31 i'm not super sure about this one either. 17:37:41 maybe we should punt and ask anaconda/blivet devs what they think? 17:37:47 wfm 17:37:50 yep 17:38:10 I think that now, with btrfs on fedora for a good time, and with webUI using blivet-gui mostly, whe should fix this bug for final release 17:39:32 but, yeah, feedback from the anaconda team +1 on this 17:39:57 I mean, I agree with this 17:40:44 proposed #agreed 2189899 - punt (delay decision) - this is a complex area and we're really not too sure how to handle this. it's an awkward experience but it is possible to work with it, and we don't know how practical it is to 'fix' this on the development side. so we'll delay the decision and ask anaconda/blivet devs to provide input on that part 17:41:14 ack 17:41:14 ack 17:41:23 ack 17:42:57 #agreed 2189899 - punt (delay decision) - this is a complex area and we're really not too sure how to handle this. it's an awkward experience but it is possible to work with it, and we don't know how practical it is to 'fix' this on the development side. so we'll delay the decision and ask anaconda/blivet devs to provide input on that part 17:43:09 #topic (2215739) Decimal separator on keypad doesn't respect regional formatting under Wayland 17:43:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=2215739 17:43:09 #link https://pagure.io/fedora-qa/blocker-review/issue/1162 17:43:09 #info Proposed Blocker, plasma-desktop, NEW 17:43:09 #info Ticket vote: FinalBlocker (+0,0,-3) (-nielsenb, -geraldosimiao, -kparal) 17:43:20 -1 17:43:25 well, we have -3 already...make that -4...:D 17:45:01 kparal: you say we don't have a criterion, but we kinda do 17:45:21 "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ..." at final 17:45:34 but this is not about a particular layout 17:45:37 okay, in a sense the layout is configured, but it's also not really being 'used' if a key doesn't produce the right character... 17:45:48 hmm, i guess... 17:46:09 it's just the decimal point key producing a different than expected character, but the layout is correct 17:46:36 I tried to reproduce this, but didn't get it. I have a keypad on my acer notebook and the VMs used it corretcly on F39 KDE, decimal works 17:46:46 and I somewhat always assumed this is specific to the application being used? e.g. gedit vs libreoffice calc? 17:47:05 at least in czech, we also have a decimal comma, and I think it works differently in different apps 17:47:08 but I might be wrong 17:47:12 proposed #agreed 2215739 - RejectedBlocker (Final) - we agree this is an annoying bug that should be fixed, but it doesn't really violate any release criterion, can be worked around by using the other key, and has already been the case for a while 17:47:57 ack 17:47:58 ack 17:48:02 ack 17:48:14 #agreed 2215739 - RejectedBlocker (Final) - we agree this is an annoying bug that should be fixed, but it doesn't really violate any release criterion, can be worked around by using the other key, and has already been the case for a while 17:48:25 #topic (2187858) sddm-wayland-plasma does not respect keyboard layout variant 17:48:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=2187858 17:48:25 #link https://pagure.io/fedora-qa/blocker-review/issue/1158 17:48:25 #info Proposed Blocker, sddm, NEW 17:48:25 #info Ticket vote: BetaBlocker (+1,0,-0) (+geraldosimiao) 17:48:26 #info Ticket vote: FinalBlocker (+2,0,-0) (+geraldosimiao, +nielsenb) 17:49:18 I couldn't reproduce this with F38, but I haven't tried yet with F39 17:49:39 my understanding was that this is not a general issue, but only happens in certain cases (not sure which ones) 17:50:41 note that the word "variant" has a specific meaning here which i'n not sure everyone commenting/trying to reproduce understands 17:51:10 "variant" is not "layout". layouts have variants. if you want to use a given layout with a specific variant, and you instead get the layout with no variant, that can be a very different and broken experience 17:51:26 (this is xkb terminology) 17:52:05 this probably needs someone to invest time and try to reproduce it in multiple cases 17:52:11 e.g. the neo thing referred to in the bug is https://en.wikipedia.org/wiki/Neo_(keyboard_layout) , implemented as a variant in xkb 17:52:19 if you want that layout but you get a standard 'de' layout, that's rather different 17:52:48 let me check what the installer allows you to actually pick...i kinda want to say you can't specify variants in the installer 17:55:16 I'd say punt and try to figure out which layouts/variants it actually affects 17:55:47 +1 on this 17:55:51 * kparal needs to go 17:56:43 oh, no, the installer does let you pick variants 17:56:49 e.g. "German (Neo 2)" is in the list 17:57:00 which is the Neo variant referred to in the bug report 17:57:05 I'd be annoyed if it didn't 17:57:17 the default czech variant is qwertz, that's horrible 17:57:20 oh yeah, you like a non-default czech one, right>? 17:57:54 and after install sddm-wayland-plasma doesn't show variants too. only the maisn language layouts, it seems 17:58:09 the main layouts 17:59:16 i kinda lean +1 on this, but probably best to punt and try to reproduce it definitively 18:01:44 both work for me 18:02:39 * kparal is here intermittently 18:03:27 proposed #agreed 2187858 - punt (delay decision) - this potentially looks like a blocker, but we would like to try and reproduce it definitively on Fedora 39 with a clear understanding of the distinction between "layouts" and "variants" 18:04:03 ack 18:06:58 ok, let's go with reduced acks mode since people are leaving 18:07:01 #agreed 2187858 - punt (delay decision) - this potentially looks like a blocker, but we would like to try and reproduce it definitively on Fedora 39 with a clear understanding of the distinction between "layouts" and "variants" 18:07:08 that was the last proposed blocker 18:07:32 as for accepted blockers, I will attempt to work those after the meeting. the general state is that they all need work. 18:07:51 particularly good old https://bugzilla.redhat.com/show_bug.cgi?id=2113005 we may have to waive *again* :( 18:07:51 ok 18:08:09 ohh, the shim one? 18:08:33 this is getting more complex 18:09:20 as it affects now RHEL as I read on the ticket. don't? 18:20:30 adamw any other topic? 18:51:12 ah whoops sorry 18:51:20 yeah, let's close this out, i forgot 18:51:24 thanks for coming, everyone! 18:51:28 #endmeeting