16:01:23 <coremodule> #startmeeting F39-blocker-review
16:01:23 <zodbot> Meeting started Mon Oct  2 16:01:23 2023 UTC.
16:01:23 <zodbot> This meeting is logged and archived in a public location.
16:01:23 <zodbot> The chair is coremodule. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:01:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:23 <zodbot> The meeting name has been set to 'f39-blocker-review'
16:01:23 <coremodule> #meetingname F39-blocker-review
16:01:23 <zodbot> The meeting name has been set to 'f39-blocker-review'
16:01:23 <coremodule> #topic Roll Call
16:01:40 <coremodule> Hello all, who is around today for a blocker meeting?
16:01:46 <kparal> .hello2 kparal
16:01:47 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:03:20 <thebeanogamer> .hello thebeanogamer
16:03:21 <zodbot> thebeanogamer: thebeanogamer 'Daniel Milnes' <daniel@daniel-milnes.uk>
16:03:34 <amoloney> .hello
16:03:34 <zodbot> amoloney: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:03:46 <amoloney> .hello amoloney
16:03:47 <zodbot> amoloney: amoloney 'Aoife Moloney' <amoloney@redhat.com>
16:07:44 <coremodule> hmmm, we're running a bit thin on attendance
16:08:02 <kparal> Frantisek should be here in 30 minutes
16:08:13 <coremodule> That doesn't help us now...
16:08:27 <amoloney> is there enough here to make decisions? or should this be rescheduled?
16:08:45 <kparal> we have 3+ people, so we meet the minimum requirement
16:08:49 <kparal> of course more people is better
16:09:12 <coremodule> with the current attendance, I'm inclined to adjourn for today with a caveat that we'll vote on these in the blockerbugs app
16:09:58 <kparal> I'll shout out in the qa channel
16:10:03 <coremodule> thanks kparal
16:10:13 <coremodule> let's wait for a few more minutes before making a call.
16:10:48 <amoloney> it would be a shame to waste a chance to discuss the bugs so hopefully a few more folks wander in :) Im good to wait a bit too
16:14:07 <kparal> coremodule: if you don't want to vote, we can still at least discuss the proposed blockers, and then ask people to cast their votes in blocker tickets
16:14:44 <tflink> sorry for being late
16:14:50 <coremodule> amoloney, is there a bug you're here for in particular?
16:15:08 <coremodule> tflink is here!
16:15:32 <coremodule> I didn't want to start with such low attendance and have people drop mid-meeting leaving us stuck or causing the meeting to hit the time limit
16:15:33 <amoloney> not one, all of them :) Im here to listen and learn how things are generally discussed and decided on
16:15:40 <coremodule> alright, lets go
16:15:51 <coremodule> #topic Introduction
16:15:51 <coremodule> Why are we here?
16:15:51 <coremodule> #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:15:51 <coremodule> #info We'll be following the process outlined at:
16:15:52 <coremodule> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:15:53 <kparal> coremodule: btw use #chair, just in case you get a disconnect
16:15:53 <coremodule> #info The bugs up for review today are available at:
16:15:55 <coremodule> #link http://qa.fedoraproject.org/blockerbugs/current
16:15:59 <coremodule> #info The criteria for release blocking bugs can be found at:
16:16:01 <coremodule> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:16:03 <coremodule> #link https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria
16:16:05 <coremodule> #link https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria
16:16:16 <coremodule> #chair kparal tflink
16:16:16 <zodbot> Current chairs: coremodule kparal tflink
16:16:19 <coremodule> #info 6 Proposed Blockers
16:16:19 <coremodule> #info 5 Accepted Blockers
16:16:19 <coremodule> #info 0 Accepted 0-day Blockers
16:16:19 <coremodule> #info 0 Accepted Previous Release Blockers
16:16:20 <coremodule> #info 5 Proposed Freeze Exceptions
16:16:21 <coremodule> #info 2 Accepted Freeze Exceptions
16:16:35 <coremodule> #topic Proposed Blockers
16:16:43 <coremodule> #topic (2241632) Netinstall ISO renders a black screen when using kickstart install (bare metal and VM)
16:16:43 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2241632
16:16:43 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/1354
16:16:43 <coremodule> #info Proposed Blocker, anaconda, NEW
16:16:43 <coremodule> #info Ticket vote: FinalBlocker (+4,0,-0) (+nielsenb, +nixuser, +geraldosimiao, +kparal)
16:17:10 <coremodule> ah, who will secretarialize this meeting?
16:17:12 <kparal> not sure why ngompa doesn't see it in a VM, I see it every time
16:17:48 <amoloney> Im happy to do that part coremodule
16:17:52 <kparal> I can try to secretarialize on the fly, but I'm not sure if I can stay the whole time
16:18:41 <kparal> amoloney: do you know the basics?
16:18:43 <coremodule> thanks amoloney, have you done it before?
16:18:48 <coremodule> https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Secretary_Duty
16:19:06 <coremodule> kparal, I don't think that doc mentions anything about the blockerbugs part of the process
16:19:20 <amoloney> no, Ive lurked a few times and will try pick it up as we go
16:19:24 <coremodule> I'll add it to the list of things to update
16:20:01 <amoloney> I did one go/no-go meeting so I assume its not too different from that - summarise the proposed outcome, and post whats agreed
16:20:37 <coremodule> #info amoloney will act as secretary.
16:20:41 <coremodule> So.
16:20:44 <coremodule> Thoughts on this bug?
16:20:55 <kparal> amoloney: ideally with a link to the meeting, which is https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2023-10-02/
16:21:11 <coremodule> it's already +4, does anyone have a dissenting opinion?
16:21:29 <amoloney> thank you both1
16:21:30 <kparal> so for me, this is a clear blocker. It's easy to reproduce (for me), and completely kills the process
16:21:43 <coremodule> okay. I'm +1 blocker here
16:21:53 <tflink> +1 blocker
16:22:31 <kparal> amoloney: the comment in bugzilla should also link to the blocker review ticket (the second #link above), thanks
16:22:43 <frantisekz> .hello2
16:22:45 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:22:55 <kparal> frantisekz: evening!
16:23:15 <thebeanogamer> +1 blocker
16:25:11 <coremodule> proposed #agreed 2241632 - AcceptedBlocker (Final) - This is accepted as a violation of the following criterion: "The installer must be able to complete an installation using all supported interfaces." as the user cannot reasonably complete installation using the supported kickstart+graphical interface.
16:25:28 <coremodule> hi frantisekz
16:25:34 <kparal> ack
16:25:40 <coremodule> would you be willing to help amoloney with secretary duty if he has any questions?
16:26:07 <frantisekz> sure sure
16:26:14 <frantisekz> I'll take that coremodule
16:26:16 <coremodule> frantisekz, thank you!
16:26:23 <frantisekz> thanks for leading the meeting!
16:26:50 <kparal> coremodule: I think it's "she"
16:26:59 <kparal> but feel free to correct us amoloney :-D
16:27:17 <amoloney> I am a 'she', but I've been called worse so no offence taken :-D
16:28:02 <coremodule> frantisekz, amoloney already offered to take the secretary duty, but feel free to work it out with her
16:28:17 <coremodule> sorry amoloney, not intentional
16:28:26 <amoloney> frantisekz if you want to secretarialize this first bug, then I can go in and see the format you used and can do the next/another bug if that suits?
16:28:28 <coremodule> okay, we need two more 'ack's here
16:28:49 <frantisekz> sure sure, works for me amoloney
16:28:55 <amoloney> thank you
16:29:08 <frantisekz> will ping you of meeting room once it's secretalized :)
16:29:15 <tflink> ack
16:29:38 <kparal> amoloney: now you basically add some intro text like "after discussion at [blocker review ticket link] and at the blocker review meeting [link] this was accepted as a blocker: [copy #agreed text]" to bugzilla, and add AcceptedBlocker to the Whiteboard
16:29:44 <frantisekz> the 2241632 is the first bug dealt with here?
16:29:53 <coremodule> frantisekz, yes
16:29:56 <frantisekz> ty
16:30:12 <coremodule> amoloney, I can email you the template that I use for secretary duty, it makes it a whole lot easier
16:30:44 <amoloney> that would be very helpful, thank you - amoloney@redhat.com
16:30:55 <kparal> amoloney: we'll need to update the blocker review ticket ourselves, because you don't have permissions to use AGREED at the moment, but we can change that in the future, if you plan to participate more often ;-)
16:31:06 <amoloney> :)
16:31:09 <frantisekz> these are my notes for it: https://paste.centos.org/view/c96a672e
16:31:15 <frantisekz> including the template
16:32:07 <kparal> am I the only one writing it manually every time? :-D
16:32:30 <kparal> frantisekz: I'd like if you template always contained a link to the blocker-review ticket, even if the final agreement is done in the meeting
16:32:53 <coremodule> amoloney, sent!
16:32:54 <kparal> perhaps we should add the "best template" to the wiki :)
16:33:06 <frantisekz> we should make it automatic...
16:33:18 <amoloney> we should finish the first bug .... :-P
16:33:20 <kparal> can't disagree on that
16:33:33 <coremodule> kparal, yes, I have a template and I never do it on-the-fly so that the meeting logs can be shared as well
16:33:40 <coremodule> anyway
16:33:43 <coremodule> ONE MORE ACK
16:33:55 <frantisekz> kparal: for the discussion link, I've made a blockerbugs PR for that about a year ago...
16:34:12 <frantisekz> does mine count coremodule? :)
16:34:13 <frantisekz> ack
16:34:24 <coremodule> #agreed 2241632 - AcceptedBlocker (Final) - This is accepted as a violation of the following criterion: "The installer must be able to complete an installation using all supported interfaces." as the user cannot reasonably complete installation using the supported kickstart+graphical interface.
16:34:28 <kparal> frantisekz: I know! very appreciated :D
16:34:30 <coremodule> frantisekz, consider it counted
16:34:39 <coremodule> #topic (2241761) cancelling partition editing by Esc doesn't cancel, but CONFIRMS the dialog
16:34:39 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2241761
16:34:39 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/1358
16:34:39 <coremodule> #info Proposed Blocker, blivet-gui, NEW
16:34:58 <kparal> this is a facepalm one I discovered today
16:35:02 <coremodule> oof
16:35:04 <kparal> when debugging a different bug, as always
16:35:25 <coremodule> I don't like this
16:35:45 <kparal> now we don't have an exact criterion here :-) but I think we can agree this is extremely bad :-D
16:36:07 <tflink> yeah, it's bad but I was trying to figure out the criteria violation
16:36:14 <kparal> we have this one: https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Data_corruption
16:36:18 <kparal> it's close enough I think
16:36:49 <kparal> or we can target some of the installer criteria, saying it doesn't work as expected when partitioning
16:37:11 <kparal> https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning
16:37:28 <tflink> "it works if you don't screw up" is ... not the best look
16:37:30 <kparal> any of those fail if you cancel the dialog with Esc, they do a different thing than instructed
16:37:44 <tflink> does it work if you click on cancel instead of hitting esc?
16:37:52 <kparal> yes, that cancels fine
16:38:40 <tflink> definitely +1 FE
16:38:51 <kparal> +1 blocker from me
16:39:37 <tflink> debating the "would this slip release if it was the last unresolved blocker" test and having some trouble
16:39:38 <kparal> just a note, not verified, but I assume this is not a new bug
16:39:56 <coremodule> I would say that if the Cancel button works, but the ESC key doesn't, it's not *as* bad in my mind, but still probably a blocker
16:40:02 <kparal> I'd still be +1 even as the last blocker
16:40:06 <tflink> do we have any idea if it is the same behavior in F38?
16:40:13 <kparal> I can check
16:40:56 <kparal> but still, even if it hsa been present all along, I'm still +1. This is just bad.
16:41:26 <kparal> yes, it's present in F38
16:41:38 <coremodule> Yeah, I think regardless, I'm +1 blocker on a loose interpretation of the Data Corruption criterion
16:41:55 <frantisekz> -1 for me, +1 FE
16:42:04 <kparal> it was just a pure luck that I spotted this. If I actually had data on that partition, I'd be furious.
16:42:38 <tflink> but the criterion says "must be fixed or documented". if it's been around for at least a release and nobody has raised a stink about it, I'm inclined to say not a blocker even if it is bad
16:43:15 <kparal> when you reformat a partition in blivet-gui, you don't see it marked in any way. The display doesn't change. So if you don't look at the pending log closely, you just don't know
16:43:23 <kparal> people won't spot it
16:43:30 <thebeanogamer> I would be curious to know how long this one has been in there
16:43:35 <kparal> "fixed or documented" is our choice, I believe
16:43:41 <thebeanogamer> It's bad, but if it's not new then should it actually block?
16:44:03 <kparal> that's a recurring question and I believe the answer is "it depends" in general, and "yes" in this case
16:44:12 <coremodule> kparal, are you spinning up an f38 machine to test?
16:44:18 <tflink> it sounds like he already did
16:44:19 <kparal> I already did
16:44:30 <coremodule> ah, okay
16:44:30 <kparal> it's present in F38
16:45:13 <tflink> -1 blocker, +1 FE - it's bad but it's not new and I have trouble seeing it pass the "would it block release if it was the last unresolved blocker" test
16:45:34 <kparal> can't be fixed with an update
16:46:10 <coremodule> to tflink's point, if present in f38, it does show that it's not been reported, so potentially not been found up to this point.
16:46:28 <tflink> or just anyone who hit it effectively rage quit Fedora
16:46:31 <kparal> well we haven't heard about it
16:46:33 <thebeanogamer> I think I agree with -1 blocker, +1 FE
16:46:39 <kparal> doesn't mean it didn't eat users data
16:46:40 <frantisekz> well, it can be fixed for blive-gui usage on an installed system at least, can't it?
16:46:45 <coremodule> kparal, right, why I said hasn't been reported
16:47:05 <kparal> frantisekz: I care about the installation use case here. Blivet-gui itself is not blocking.
16:47:09 <kparal> as a standalone app
16:47:26 <kparal> coremodule: might have been, I didn't see it :)
16:47:42 <kparal> anyway, what's the count?
16:47:50 <kparal> sounds like I haven't convinced you
16:47:54 <coremodule> +2/-3 as it stands
16:47:59 <tflink> if you were installing a linux distro and it ate your data, would you take the time to report it or just never use that distro again and switch to something else? I'm still -1 blocker but I can easily see someone not reporting it if they hit the bug, other than rant on social media
16:48:08 <kparal> so +1FE currently and punt the blocker decision?
16:48:14 <coremodule> tflink, that would be my approach, for sure
16:48:56 <tflink> yeah, sounds like we don't have enough votes to decide blocker, punt to ticket
16:49:01 <tflink> or next week
16:49:34 <thebeanogamer> I'd also be interested to see how quickly they can turnaround a fix
16:49:47 <kparal> this should be trivial to fix
16:51:12 <kparal> coremodule: writing the proposal?
16:51:25 <coremodule> does it make sense to take this as an FE if it can't be fixed with an update?
16:51:34 <kparal> of course
16:51:38 <frantisekz> sure sure
16:51:38 <coremodule> why?
16:51:40 <frantisekz> fe is for that
16:51:40 <kparal> the freeze is tomorrow
16:51:51 <kparal> if there's a fix, it has to have an FE to go through
16:52:02 <frantisekz> just "blocker - light, zero sugar variant"
16:52:13 <coremodule> FE is for fixes that can be fixed with an update, not a tracker for what could be potentially a blocker?
16:52:19 <coremodule> okay
16:52:49 <kparal> FE is universally agreed and it means we can take it in even if we don't agree whether to block the release on it
16:52:52 <frantisekz> fe is for not bad enough to block the release, but still good to be fixed for the release
16:53:03 <tflink> FE is for stuff that we'd allow through freeze but doesn't hit release criteria, no?
16:53:11 <kparal> yes
16:53:19 <frantisekz> especially for stuff that can't be fixed post release and/or affects live media/installation process/etc.
16:53:46 <kparal> right
16:53:53 <coremodule> proposed #agreed 2241761 - punt (delay decision) AcceptedFreezeException (Final) - While we see this a bad issue, it's presence in F38 tempers our ability to make an outright decision at the moment. We do grant it FE status.
16:54:13 <kparal> ack
16:54:32 <tflink> patch - make it clearer that we're punting on blocker "punt blocker (delay decision"
16:55:03 <coremodule> proposed #agreed 2241761 - punt blocker (delay decision) AcceptedFreezeException (Final) - While we see this a bad issue, it's presence in F38 tempers our ability to make an outright decision at the moment. We do grant it FE status.
16:55:06 <tflink> but that's just my pedantic side coming through, I suppose
16:55:08 <tflink> ack
16:55:21 <frantisekz> ack
16:55:29 <coremodule> #agreed 2241761 - punt blocker (delay decision) AcceptedFreezeException (Final) - While we see this a bad issue, it's presence in F38 tempers our ability to make an outright decision at the moment. We do grant it FE status.
16:55:38 <coremodule> #topic (2239128) pop-up screen is stuck when try to  format a partition
16:55:38 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2239128
16:55:38 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/1342
16:55:38 <coremodule> #info Proposed Blocker, gnome-shell, ASSIGNED
16:55:38 <coremodule> #info Ticket vote: FinalBlocker (+3,0,-3) (+imsedgar, +kparal, +lnie, -lruzicka, -nielsenb, -geraldosimiao)
16:56:14 <kparal> another divisive one ;-)
16:56:26 <kparal> I actually didn't want to block on it until I tried it myself today
16:56:55 <kparal> my comment is in the ticket
16:57:51 <frantisekz> -1 Blocker, +1 FE (racy enough not to block for me)
16:58:06 <kparal> I'd also like to say that this is nothing compared to the Esc bug. This one at least doesn't eat data.
16:58:31 <kparal> but might make you end up in a messy state, if you try to kill the installer because it seems stuck
16:59:59 <kparal> frantisekz: I'd argue with that. It's not "racy enough". It's extremely common. If this happened once in 10 or 50 times, that would be a sad race. But in this case you basically are guaranteed to hit it, if you format multiple partitions.
17:00:23 <kparal> at least in my and Lili's experience
17:00:24 <coremodule> lnie is offering to do more testing on baremetal if we can wait until she's back before next meeting. I'm inclined to be punt blocker, +1 FE here
17:00:36 <kparal> and Lukas and Vojtech confirmed the likelihood as well
17:00:52 <kparal> coremodule: I don't think it makes sense to wait for more data
17:01:04 <kparal> we have enough data from at least 4 people
17:01:58 <coremodule> kparal, did you test on baremetal?
17:02:19 <kparal> the minimum reported occurrence is somewhere around 25%, the maximum at 100% (Lili)
17:02:27 <kparal> coremodule: no, just VM
17:02:38 <coremodule> it seems that lnie is the only one who did, and in all three attempts, it showed 100% failure rate.
17:02:38 <kparal> there was no time to test bare metal, sadly
17:03:18 <kparal> yes, it seems so
17:03:42 <kparal> for me, even 25% is good enough to +1 blocker from me
17:04:10 <coremodule> yeah, you know what, I think I agree with you
17:04:17 <coremodule> I'm going to amend my vote to +1 blocker
17:04:31 <kparal> it's always important to remember that races produce wildly different numbers. Even if we test it a lot, it might behave completely differently on a different hardware or just at a different time
17:04:52 <coremodule> well yes, but that can go the other way too :)
17:05:21 <coremodule> any other votes?
17:05:22 <kparal> yes. But we're concerned about the bad case :)
17:06:05 <coremodule> we're at +5/-4
17:06:24 <tflink> I'm definitely +1 FE, will defer to folks who have been more active in the blocker process in recent releases for blocker - +0
17:06:25 <kparal> looks like we're going to do the FE+punt dance again
17:06:38 <tflink> +0 blocker / +1 FE
17:07:57 <coremodule> proposed #agreed 2239128 - punt blocker (delay decision) AcceptedFreezeException (Final) - This does appear bad, but we can't reach a consensus. We're going to punt for now and perhaps have more testing done in the meantime. We do grant it FE status.
17:08:06 <kparal> ack
17:08:09 <tflink> ack
17:08:10 <frantisekz> ack
17:08:17 <coremodule> #agreed 2239128 - punt blocker (delay decision) AcceptedFreezeException (Final) - This does appear bad, but we can't reach a consensus. We're going to punt for now and perhaps have more testing done in the meantime. We do grant it FE status.
17:08:25 <coremodule> #topic (2241274) initial-setup text fails on hardware
17:08:25 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2241274
17:08:25 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/1353
17:08:25 <coremodule> #info Proposed Blocker, initial-setup, ASSIGNED
17:08:25 <coremodule> #info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +nixuser)
17:08:53 <kparal> doh, I should've seen this comment earlier: "Adam Willamson: I vote for whatever kparal votes for"
17:08:57 <kparal> I have 2 votes now!
17:09:01 <kparal> :-D
17:09:40 <kparal> looks like a clear-cut blocker to me
17:09:47 <coremodule> agreed
17:10:09 <coremodule> +1 blocker, also looks like mkolman is working on it
17:10:18 <frantisekz> +1 blocker
17:10:25 <kparal> the criterion is hit exactly, +1 blocker
17:10:30 <tflink> it's weird that it doesn't show up in automation
17:10:44 <tflink> but that's an issue for not this process
17:10:49 <tflink> +1 blocker
17:11:17 <coremodule> proposed #agreed 2241274 - AcceptedBlocker (Final) - We accept this a blocker as it violates the following criterion: "Release-blocking ARM disk images must boot to the initial-setup utility."
17:11:24 <frantisekz> ack
17:11:24 <kparal> ack
17:11:28 <tflink> ack
17:11:31 <coremodule> #agreed 2241274 - AcceptedBlocker (Final) - We accept this a blocker as it violates the following criterion: "Release-blocking ARM disk images must boot to the initial-setup utility."
17:11:39 <coremodule> #topic (2240490) Using shift lock on character with accent produces lower case character with accent
17:11:39 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2240490
17:11:39 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/1350
17:11:39 <coremodule> #info Proposed Blocker, mutter, NEW
17:11:40 <coremodule> #info Ticket vote: FinalBlocker (+0,1,-2) (nielsenb, -lruzicka, -geraldosimiao)
17:11:41 <coremodule> #info Ticket vote: FinalFreezeException (+1,1,-0) (+augenauf, nielsenb)
17:12:05 <kparal> so this is a fun one, which I assume EN-based people will have just a fuzzy idea about
17:12:21 <tflink> it seems pretty straight forward
17:12:27 <tflink> but which criterion does it hit?
17:12:28 <kparal> but even though currently it has -1s, I think we should consider +1 blocker
17:12:46 <kparal> this one is somewhat related: https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Keyboard_layout_configuration
17:12:53 <kparal> but not really well
17:13:23 <kparal> we don't have a criterion for "keyboard must work", because it's such a basic thing that we haven't really specified it
17:13:56 <coremodule> I see this as bad if a user has a password with an accented character in it.
17:14:06 <kparal> however, if you want to input a long text in capital letters, FOR WHATEVER REASON, it's extremely unpleasant when half of your letters don't work
17:14:13 <kparal> well, produce a lowercase letter
17:14:29 <tflink> yeah, that's the case that concerns me the most - breaking disk encryption
17:14:41 <kparal> coremodule: that's probably not a problem, actually, if he can see what he's typing
17:14:52 <kparal> and also it's unlikely that people have their passwords all in uppercase
17:14:58 <kparal> so that they would use capslock
17:15:04 <coremodule> as in see the keyboard as he types, or see the input on the screen?
17:15:33 <frantisekz> dis encrypt - you mean on bootup?
17:15:34 <kparal> if you type a single letter, you don't have this problem. Because you use Shift to make the accented letter uppercase, and that works
17:15:41 <frantisekz> disk*
17:15:49 <kparal> this problem is only when you want to use capslock to write a longer text in uppercase
17:16:01 <coremodule> ahhh
17:16:04 <kparal> which is not common, but still I think it should be a baseline that just must work
17:16:20 <coremodule> kparal, what did you say at the beginning about EN keyboard users not really knowing what's going on here? :D
17:16:31 <kparal> only with capslock on, the accented letters are written in lowercase when they should be in uppercase
17:16:49 <kparal> so the workaround is to use Shift a lot, and write them individually
17:17:09 <tflink> for the non-encryption case, it could be solved post-release with an update? no?
17:17:17 <kparal> sure
17:18:19 <tflink> the case that worries me the most is passwords and disk encryption, even if using caps/shift lock for those isn't likely
17:18:20 <kparal> I think you can imagine that for an EN keyboard, one line of letters would produce lowercase, the rest uppercase
17:18:26 <kparal> would that be a blocker?
17:18:50 <kparal> (with capslock on. Shift would work as expected)
17:19:20 <frantisekz> I mean I would always check the password used for encryption, and it a worst case, you could reinstall the OS, it wouldn't eat data or so
17:19:22 <tflink> while annoying, I'm not sure it's a blocker for the general case
17:19:24 <frantisekz> I am -1 Blocker here
17:19:42 <tflink> I'm onboard with blocking due to the possible issue with encryption password or login password
17:20:04 <kparal> I'm not concerned about that, because I don't believe anyone logs in with caps lock on intentionally
17:21:06 <tflink> I've seen people use caps as shift - "CAPS LOCK + letter + CAPS LOCK" but I acknolwedge that it's very rare
17:21:34 <coremodule> kparal, what's your vote?
17:21:39 <tflink> but then again, I don't use caps lock. it's remapped on the keyboards I use frequently
17:22:05 <tflink> -1 blocker, +1 FE
17:22:15 <kparal> I'm a bit more towards +1, just because I think these things shouldn't be compromised on, but I do agree that the severity here is not that high
17:22:39 <kparal> so if you're -1, I won't cry :)
17:23:06 <coremodule> so I think we're -6/+2
17:23:17 <coremodule> +1 FE here
17:23:19 <tflink> FWIW, I think I'd  be -1 blocker for something like 'caps lock doesn't work at all' as well
17:23:23 <kparal> who's the second +1?
17:23:43 <tflink> adam?
17:23:44 <frantisekz> adam...
17:23:45 <frantisekz> :D
17:23:46 <kparal> heh
17:23:54 <coremodule> :)
17:23:58 <kparal> alright, let's close this as rejected
17:24:19 <coremodule> do we want it as an FE?
17:24:27 <kparal> definitely
17:24:30 <coremodule> I feel like that's fair
17:24:32 <tflink> +1 FE
17:24:39 <frantisekz> +1 FE
17:25:02 <coremodule> proposed #agreed 2240490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - After mulling it over, we find that the severity of this bug is low enough to not warrant blocking the release. We grant it FE status.
17:25:17 <kparal> ack
17:25:24 <coremodule> sorry
17:25:25 <coremodule> patch
17:25:26 <coremodule> proposed #agreed 2240490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - After mulling it over, we find that the severity of this bug is low enough to not warrant blocking the release on it. We grant it FE status.
17:25:44 * kparal plays spot 5 differences
17:25:44 <coremodule> just added "on it"
17:25:54 <kparal> ok
17:26:00 <tflink> thanks, I was looking for the change
17:26:00 <frantisekz> ack
17:26:02 <tflink> ack
17:26:14 <coremodule> #agreed 2240490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - After mulling it over, we find that the severity of this bug is low enough to not warrant blocking the release on it. We grant it FE status.
17:26:23 <coremodule> #topic (2239121) the second part of btrfs volume is shown as not-mounted
17:26:23 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2239121
17:26:23 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/1335
17:26:23 <coremodule> #info Proposed Blocker, util-linux, NEW
17:26:23 <coremodule> #info Ticket vote: FinalBlocker (+0,0,-3) (-kparal, -nielsenb, -geraldosimiao)
17:26:47 <kparal> this is not going to make Lili's happy, but I'm still -1 here
17:26:48 <coremodule> this already has -3 in blockerbugs, but we're here, let's talk about it one last time
17:27:17 <kparal> this is the problem in the whole stack, from lsblk all the way up to gnome-disks and blivet-gui
17:27:30 <kparal> and it worked like this for ages
17:28:03 <kparal> and unlike the other bug in blivet-gui we talked about, I think the chance to accidentally lose data here is much lower
17:28:36 <coremodule> kparal, I just like the part where lnie called you the "picky revenge monster"
17:28:46 <kparal> because if you installed btrfs on two drives, you probably remember that you did it and don't just erase partition on one of them without thinking about it
17:29:28 <kparal> not sure why I earned that :-D
17:30:30 <kparal> iow, the fact that the partition is not shown as mounted doesn't imply it can be simply deleted, you probably still want to examine its contents first. So I don't think the data loss scenario is that likely here.
17:31:01 <tflink> -1 blocker, -1 FE
17:31:02 <kparal> and realistically, a lot would have to change in the stack to make it display differently, I think
17:31:27 <tflink> it's a problem, for sure but it's about post-install behavior and could be fixed with an update
17:31:28 <frantisekz> -1 Blocker
17:33:19 <coremodule> proposed #agreed 2239121 - RejectedBlocker (Final) - We find this to be a more advanced use case where the user would have a reason for having two btrfs drives, and would probably remember why they did it, thus making this bug moot. We also acknowledge that a lot would probably have to change in the stack to fix it.
17:33:39 <kparal> tflink: well Lili complains about the installer too
17:34:05 <kparal> coremodule: those are just my theories :)
17:34:21 <kparal> but I don't mind, ack
17:34:56 <coremodule> kparal, yes, but I agree, at least with the part about it being a more advanced use case than a basic user who is new would ever run into
17:35:15 <tflink> I wouldn't go so far as to render the bug moot - it's still a bug and a problem but it does seem less likely that someone with multiple disks would go blindly deleting partitions without confirming that they're unused first
17:35:36 <coremodule> moot in that context, but i can make it read differently
17:35:53 <coremodule> proposed #agreed 2239121 - RejectedBlocker (Final) - We find this to be a more advanced use case where the user would have a reason for having two btrfs drives, and would probably remember why they did it, thus making this bug less of an issue in this context. We also acknowledge that a lot would probably have to change in the stack to fix it.
17:36:36 <tflink> I might just be slow but I don't understand how this bug affects the install process
17:36:54 <tflink> ack
17:37:05 <kparal> I think Lili removed one partition of an installed system by accident
17:37:16 <kparal> because it was not shown as belonging together
17:37:33 <coremodule> one more ack?
17:37:49 <kparal> frantisekz: poke
17:37:58 <tflink> sure but if you're in anaconda, the existing partitions aren't going to be mounted. in order to act on the bad information, you'd have to be in the machine after install, no?
17:38:55 <tflink> it's a rough equivalent of doing a 'sudo rm -rf /home' in the example case
17:39:15 <kparal> I think you're right, Lili's just talking about the case of booting into the installed system
17:39:20 <kparal> and then cleaning up partitions
17:39:35 <coremodule> frantisekz, thebeanogamer, amoloney, one more ack?
17:40:26 <kparal> coremodule: you can vote too
17:40:48 <coremodule> I can vote, but can I ack? seems like a conflict of interest
17:40:52 <frantisekz> ack
17:40:56 <coremodule> #agreed 2239121 - RejectedBlocker (Final) - We find this to be a more advanced use case where the user would have a reason for having two btrfs drives, and would probably remember why they did it, thus making this bug less of an issue in this context. We also acknowledge that a lot would probably have to change in the stack to fix it.
17:41:08 <coremodule> #topic Proposed Freeze Exceptions
17:41:14 <kparal> I don't think it's conflict of interest
17:41:15 <tflink> but the point of the ack is to verify that the summary is OK. presumably the author would be OK with it or wouldn't have written it in the first place
17:41:39 <kparal> I'll have to leave now
17:41:44 <coremodule> I'm just saying that I agree with what I wrote... which is a given right?
17:41:45 <tflink> but we're descending into true pedantry :)
17:41:52 <coremodule> yes, absolutely, let's move on
17:41:53 <coremodule> #topic (2172684) F39FailsToInstall: python3-condor, condor
17:41:54 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2172684
17:41:54 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/1355
17:41:54 <coremodule> #info Proposed Freeze Exceptions, condor, ON_QA, depends on other bugs
17:41:54 <coremodule> #info Ticket vote: FinalFreezeException (+1,0,-0) (+geraldosimiao)
17:41:59 <kparal> and we don't have Adam here, for pedantry
17:42:01 <coremodule> bye kparal, thanks for being here
17:42:27 <kparal> thanks, see you, I have to take care of the kids now
17:42:30 <frantisekz> bye
17:42:53 <thebeanogamer> This one is odd, the F38/39 fix has been submitted, but Bodhi seems unhappy with the state of the F40 one https://bodhi.fedoraproject.org/updates/FEDORA-2023-e63ddbf9d6
17:43:12 <tflink> I'll defer to others on this one - I think that accepting something like this as FE is silly and a waste of the process. there's no difference between the FE and a 0day update other than closing the update faster
17:43:16 <thebeanogamer> Jumping forward 15 versions probably hasn't helped
17:43:41 <thebeanogamer> I don't really see how this package is a release blocker
17:44:00 <tflink> it isn't but IIRC, we've been taking stuff like this as FE so that they're not stuck until post release
17:44:20 <frantisekz> I mean, if it s FTI bug
17:44:33 <frantisekz> it'll stay and remain fti in the base repository forever
17:44:41 <thebeanogamer> I don't really mind taking it as an FE, but I don't know if the RPM is actually up to standard ( https://artifacts.dev.testing-farm.io/dcbe46bf-5153-41e0-bff4-ba179e183cdb/ )
17:45:02 <frantisekz> some tooling/scripts take the base repo for some things only, there might e other reasons we generally accepted FTIs
17:45:04 <thebeanogamer> And it does have at least one unsolvable dependency
17:46:58 <coremodule> votes?
17:48:02 <tflink> I'm abstaining or sticking at +0 - my issue is with the process here and here is not the place to make that argument
17:48:24 <thebeanogamer> IRC on mobile really is painful
17:50:06 <coremodule> +1 FE
17:50:14 <thebeanogamer23> Ok I think I have to give up, maybe tonight I finally build that IRC bouncer. Sorry all
17:50:23 <frantisekz> +1 FE
17:50:26 <coremodule> no problem, thanks thebeanogamer23
17:50:41 <frantisekz> I am not sure if we shouldn't leave the exceptions for tickets?
17:50:46 <frantisekz> not many people are around
17:50:59 <coremodule> so we're at +3/0 with the in-ticket votes
17:51:08 <coremodule> you mean call it and finish in the tickets?
17:51:16 <frantisekz> yep
17:51:22 <coremodule> I'm good with that. tflink ?
17:51:39 <tflink> WFM
17:52:07 <coremodule> #info We will call the meeting now for low attendance and finish any votes in the blockerbugs tickets.
17:52:14 <coremodule> thanks everyone
17:52:19 <coremodule> #endmeeting