Meeting started at 2025-08-25 16:00:20 UTC

The Meeting name is 'F43-blocker-review'

!hi

Agustín P (snowyyd) - he / him / his

hi!

!hi

Peter Boy (pboy)

!hi

Derek Enz (derekenz)

!hi

!hi

Adam Williamson (adamwill) - he / him / his

Neal Gompa (ngompa) - he / him / his

impending boilerplate alert!

Why are we here?

does anyone want to secretarialize?

ok, guess I'll do it

!hi

Christopher Boni (boniboyblue)

let's get started with:

does the screencast work for anyone else?

Yeah - I can see it.

huh, doesn't work here.

The direct link, if anyone is interested: https://bugzilla-attachments.redhat.com/attachment.cgi?id=2103997

yeah, i got it now

mmm. well, this is probably the whole 'plan then apply' design, right? the raid set isn't really *gone* yet...

Wondering about the UI, looks not like the Blivet I remember form my yesterday install

looks like normal 'advanced custom' blivet-gui to me

in the advanced UI I had a left column with all the devices condigured so far.

It looks like the custom conf

i guess we might want someone else to experiment with this

I can do this, I'll have to do it for server anyway

i will too

proposed !agreed 2389105 - punt (delay decision) - we're going to punt this one for other folks to test and see if they can reproduce, and if it's new in f43

Upstream seems to have MR with a fix: https://github.com/storaged-project/blivet-gui/pull/502

oh, well spotted

ah, and that mentions "MD arrays created directly on top of disks", which may be significant

that is, arrays created directly on disks, not created from disk *partitions*

Yeah, that's a new feature

so, do we want to go with the punt or accept this as a blocker or fe based on the understanding from the proposed fix?

I think we should accept it for now and look after it, when the fix is applied.

well, we need votes :D

+1 for accept :-)

+1

I agree, +1

ok

+1

+1

proposed !agreed 2389105 - AcceptedBlocker (Beta) - this is accepted as a violation of the Beta criterion "When using both the installer-native and the blivet-gui-based custom partitioning flow on the GTK-based installer, and the Cockpit-based "storage editor" flow on the webui-based installer, the installer must be able to: ... Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"

say 'ack' if the proposal looks accurate, 'nack' or 'patch' if not - this is meant to be a correctness check, since there were times in the past when i made booboos :D

That criterion says specifically that the raid arrays consist of ext4 partitions; but that isn't the case here right?

ack

other way around - it's limiting the *contents of the raid array itself* to ext4 partitions

Then: ack :)

ack

ack

i.e. a bug that only affects raid arrays with xfs partitions or something isn't a blocker

(i don't remember why we say that, oh well)

may be it's old wording. Defaults are now btrfs or xfs

it was an attempt to limit the RAID requirements from being overbroad iirc, but yeah, we might wanna revisit it

anyhow, not an issue here

ok, so this one is pretty much a subjective judgment call under the criteria

openvpn 2FA doesn't work if your password has 'unusual' characters (i'm not satisifed we have a precise definition - upstream said 'wide', but I don't think that's right, it might be 'any non-ASCII' or something) in it

do we think that's beta blocker? final blocker? not a blocker at all?

the criterion footnote says "As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker."

so that's where we are, using our best judgment

I think it is a security related bug, i guess it is worth to block.

Or do we have an alternative VPN that works?

As someone with non-ascii characters in my passphrase I'd consider this a beta blocker. Upstream seems to have the patch ready to go for it.

Agree

there are many VPN systems, but the larger point here is that the person connecting to the VPN doesn't *usually* control the configuration of the server

for me since it requires both 2FA *and* a non-ASCII(?) password i'd probably be willing to let it go at beta and make it a final blocker

i've seen too much. :P

If upstream is already working on it, we should agree to block. Se we are sure they have good time.

It does seem a patch is on the way: https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/99

I personally don't think it's worth a BetaBlock but I would FinalBlocker +1

Peter Boy that's not how this process works

Yeah, I know !

the blocker process is only concerned with whether a bug is significant enough to block the release. "let's block so upstream has time to write a fix" isn't a valid decision basis

that's best judgment

note, btw, it's already accepted as a Beta FE

so we can already put the fix in Beta

we're only deciding whether to *block* Beta on it (if the fix doesn't work or breaks something else, or whatever)

I think it's probably reasonable given how common non-English passwords are

Conan Kudo so is that a +1?

yes +1

ok, well that gives it +3

so

proposed !agreed 2388442 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.", our judgment is that 2FA + non-ASCII(?) password is a 'typical' enough configuration to block Beta on

ack

I think it's not specifically about the password itself; but the prompt.

ack

ack

ack

ah, i was wondering about that

oh, yeah, the russian means "enter the code"

patch...

proposed !agreed 2388442 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.", our judgment is that 2FA + non-ASCII(?) 2FA prompt is a 'typical' enough configuration to block Beta on

ack

ack

ack

ack

Isn't it more accurate to say "password prompt"?

no, i think it's the prompt for the 2FA code, not for the password

ok, let's move on to:

so...I don't know all the background here, but ctrl+shift isn't the documented switch combo for gnome, that's super+space

possibly ctrl+shift is one that was known to work for russian or all languages before. I don't know. I don't know how many people might expect it to work, or why it broke

ctrl+shift is what Windows does, perhaps they had a tweak that no longer works/is applied?

ctrl+shift+(something) is used a lot in other apps so it feels like a weird thing to use

if you have ctrl+shift switching layouts, do you switch layouts every time you use ctrl+shift+r in a console? or ctrl+shift+t in many apps to open a tab?

You do, it's annoying :)

if you have ctrl+shift switching layouts, do you switch layouts every time you use ctrl+shift+r in a console? or ctrl+shift+t in many console apps to open a tab?

Anyhow, needs time to verify if it ever worked that way I guess?

i'm willing to believe it did, but...not sure it constitutes a blocker

might be a good idea to try and get input from the desktop team, i can ask

i'm willing to believe it did, but...not sure it constitutes an FE

i mean...I *guess* if gnome folks agreed this is a bug and provided a clean fix, FE would make sense...

kinda thing you'd want to work as intended on lives and first boot

Very weak FE then.

There are workarounds (clicking, other shortcuts) in the meantime.

any other votes?

+1 BetaFE +1 FB

i'm definitely not buying blocker on this, but we can save that for later :D

proposed !agreed 2381599 - AcceptedFreezeException (Beta) - this is accepted as an FE on the basis that, *if upstream agrees it's a bug and wants to fix it*, it would make sense to get the fix into Beta so it works as intended on live boots and first boots

ack

ack

ack

ack

ack

ack

hum. so the update is requested to fix a bug. why not just have the bug report be for the bug? oh well.

idk but +1 fe

i mean, i might prefer a backport of the fix rather than an entire new unstable vte release, during freeze...

ehh +1 FE

From what I read there's already a fixed version, but it's not in Fedora yet: https://gitlab.gnome.org/GNOME/vte/-/issues/2897#note_2528209

well, yes, that's why the bug is "update to this new version". but during freezes we're meant to backport fixes, not just slap in new releases.

Oh sorry I misunderstood.

technically we're not in freeze just yet though

sure, but we're voting on an FE

if they put in a new version before freeze, this discussion is moot

although, hum, a complicating factor is that most of the changes between 0.81 and 0.81.90 seem to be removing stuff that turned out to be unstable

anyhoo...i'm fine with an FE for the backspace problem, we can argue over the appropriate fix

proposed !agreed 2390745 - AcceptedFreezeException (Beta) - we grant a freeze exception *to fix the broken backspace key problem*, but not carte blanche for a version update for no reason. The fix for the bug should be minimal if landed during freeze. The new version may be an appropriate choice if the only changes between 0.81 and 0.81.90 are related, or reversions of unstable changes

ack

ack

ack

ack

ack

ack

let's move on to:

we support a second MBR?

not a second MBR on a single drive, i don't think

two MBR disks

see the "steps to reproduce"

this was reported back in april, so...we might want to reconfirm it?

We support this at least in RAID configs

I didn't think this was a thing we supported at all

I had this issue,too, but I remembver from my testings it is fixed now.

it's freakishly difficult to have multi-disk boot working correctly

MBR, OFW, and UEFI don't really have features for it

I have it working just fine with Win11 and Fedora :)

as in mirrored boot code that's updated with every bootloader update?

because I'm pretty sure that's not a thing

no, that sounds horrible :)

this isn't anything about multi-disk boot

it's just...installing to the second of two empty MBR disks

This is Anaconda/blivet getting very confused when installing onto two disks that both have an MBR already.

oh, this is a subcase of the broken multi-disk thing

both disks are selected, but the first disk isn't used

yeah

arguably just 'don't select the first disk', but eh

kamil might've had a more complex case where he actually did something with the first disk too, and simplified it down to this

It was previously Raid, you have to select both, otherwise Anaconka will not proceed

nothing to do with raid in the reproducer, afaics

there is not anything about was was on it before.

says "empty disks"

yes, empty after having deleting the partitions which were prrcviously part of a RAID. That was ti problem im my case.

Anyway, we don't know. And April is a long time ago. We should ask it it is still an issue.

i think kamil would have specified this.

Yeah, indeed.

Sorry, I have to leave now. It's evening in Europe and family dinner is calling ....

no problem, thanks for coming

we're nearly done

ok, reproduced with today's f43 workstation live

and i think yeah, this is a simplified reproducer, the 'real world' case would be where you wanted to put something else on the first disk, but /boot (and maybe sysroot? but just /boot might be enough to cause the problem) on the second disk

a removable boot disk is the reasonable conjecture

it's not super-common these days, but it is still a thing

it does feel a *bit* corner case-y to me

i kinda feel like punting this to a week where kparal is here and can argue it?

sure

proposed !agreed 2359710 - punt (delay decision) - we kicked this around a bit and reproduced it, but decided to punt the blocker discussion to a week where the reporter (kparal) is present to provide more info and background

ack

ack

ack

ack

ack

ok, last one

oh, we already kicked this around

yeah this was earlier today

but not as a final blocker

i'd be inclined to punt any blocker decision on further info from upstream

I do think it's probably not acceptable to have this broken in GNOME 49

but I don't know what we can do about it yet

i'm a lot less definite about it than that...but i think we just need to hear what gnome devs have to say about it

i did ask already

Punt?

we can punt

Ok

punt

proposed !agreed 2385199 - punt (delay decision) - we agreed to punt this one at least till we have further feedback from upstream

ack

ack

ack

alrighty, that's everythng

any other business, folks?

nope

Nothing from me.

nope

adamw: who is doing a secretary? am I?

Nothing from me. This meeting was really interesting!

Lukáš Růžička i put myself down, but feel free to take it if you like

I would take it. I want to study the process for the future.

ok

Thanks for running the meeting adamw :)

Btw, thank you Adam!

no problem no problem

thanks for coming, folks!