Meeting started at 2025-02-25 17:00:36 UTC

The Meeting name is 'FESCO (2025-02-25)'

The Meeting Name is now fesco

Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @fale:fale.io, @dcantrell:fedora.im, @decathorpe:fedora.im, @salimma:fedora.im

!hi

!hi

Zbigniew Jędrzejewski-Szmek (zbyszek)

Fabio Alessandro Locati (fale) - he / him / his

I'm around but might not be in a continuous way

!hi

Neal Gompa (ngompa) - he / him / his

!hi

Michel Lind (salimma) - he / him / his

morning

We have 5, let's start.

!fesco 3364

!fesco 3364

● **Opened:** a week ago by amoloney

● **Last Updated:** an hour ago

● **Assignee:** Not Assigned

**fesco #3364** (https://pagure.io/fesco/issue/3364):**F42 Incomplete Changes Report**

Multi-line paste seems to be still (again?) broken :(

I'll go one by one

KTLS implementation for GnuTLS

!hi

Stephen Gallagher (sgallagh) - he / him / his

please add any info on that to https://pagure.io/fedora-infrastructure/issue/12181

My network connection is a bit flaky today, so sorry if I’m slow to respond

> Status update: The preliminary testing looks good, we need to add a new error message type introduced by the rekey kTLS patch which shouldn't take long.

> The change was in checked into rawhide in time I suppose we are postponing to f43

so that seems easy to resolve... move it to F43?

yeah, is there any urgent need to have this in F42?

+1 to move to F43

+1

+1

IIRC Aoife pinged every bug already so if the maintainer does not proactively answer I guess it's not urgent :)

It's unclear to me whats left to do...

s/maintainer/change owner

but sure if they are ok moving to f43 thats fine with me

I'm impressed they have bug 2,130,000

Fale?

+1 on moving for f43

> Latest Information: The change owner has not responded to any comments on the tracker bug in ~9 months on current status, and the work does not seem to have moved from the initial x3 PRs. Its looking unlikely that this change is being worked on anymore.

I think we should drop this.

yeah

I think so too

yep

this one has been a... misguided change proposal from the beginning I think

+1 to drop the change

+1 to drop

(the person doing it does not have systemd expertise, most of the people who have to review the PRs don't either)

+1

@fale?

Fale?

nirik?

+1 to drop

I'm fine to drop and ask them to resubmit if they want to move forward again. Sure, +1

I tried to incorporate a bit of additional info. I hope that's OK.

This one is mine. I set it to ON_QA now.

There is still some ongoing work, but at this point, I don't think we're going to back this out.

Two bugs open.

Any comments?

!hi

David Cantrell (dcantrell) - he / him / his

If not, I'll move to the next one.

sorry I'm late, was in the lunch line

Hi David.

How many of those pr's are still open? a bunch?

No PRs. There's one bug about sendmail, which might be some confusion, and a general issue about alternatives, which so far has been worked around by not moving those files.

OK, actually there's a pull request from 1.5 months ago…

Ah, no. That was merged.

I think we can revisit next week, but at this point there isn't much to do.

(The sendmail builds with the PR failed, but it seems the logs have been rotated already.)

OK, let's move on.

This is basically done modulo the last thing about X11 desktops

but that has an upstream PR open

That PR is from yesterday…

Punt for now, revisit next week?

I'm ok with that

reasonable I guess... the go/no go it next week....

hi -sorry, lost track of time trying to beat koji into submission

> Latest Information: There are a very small amount of packages still failing to build with this new release of python-etup tools, but the majority of packages have been updated (approx 9/134 left).

That sounds fine.

fine with me

!bugzilla 2319698

!bug 2319698

RHBZ#2319698 (https://bugzilla.redhat.com/2319698): [python-pyemd]: python-pyemd fails to build with setuptools 74+

It's in ON_QA state.

I think there's nothing to do here.

yeah, looks fine

yep.

Meh, that phrasing is unclear. But I don't think it matters.

Fabio Valentini: since you're here

I'm here!

> Latest Information: There are x3 packages still affected, with PRs still open on each notifying maintainers of this change, and the change is non-blocking for releases with the contingency deadline set to final freeze.

this is now 100% done as far as I can tell: both nmstate and squeekboard are using zbus v5 in fedora 42+ now, and libslirp-helper was retired

so zbus v1 is retired and nothing needs it any longer

> Latest Information: This change had a community test week in November 2024, and has implemented the solution proposed and approved by FESCo and is/has been working with Fedora QA on integrating their upstream test suite to test the new UI.

Does anyone here knows what the latest status is?

I do not

I haven't needed to install F42+ yet and I'm not looking forward to it 😆

I saw there were a bunch of proposed test plans for it...

I think we should get some ack from QA that it's in working state. But I don't think we can figure this out here.

yeah, we should probably invite QA next time?

when Adam isn't on vacation :)

and/or ask them to update the ticket. ;)

The part that was planned for F42 is implemented and seems to work fine.

But the scope shifted a bit: I figured out that it's feasible to do pull requests to convert all packages to actually use the new scheme. 40% of ~350 PRs have been merged.

But that part is targeted at F43.

I forgot, did the PRs mention that merging those changes back to <f42 wouldn't work? or does it?

The change is in ON_QA state.

The PRs say that they are compatible with F42+.

I think there's nothing to do here.

they didn't in any of the PRs I got, so I don't think so

Hmm, OK, indeed. Many of the PRs just redirect to the Change page.

But the Change page is very explicit that this requires new rpm functionality.

@fale?

Fale?

it's in both f42/43...

did the FTBFS doom due to new "vet" failures get resolved?

[@alexsaezm:fedora.im](https://matrix.to/#/@alexsaezm:fedora.im) is working on isn't afaik

*is

So, I would say this is done and just more cleaning up to be done? or do we want to wait and revisit?

Most likely. But it'd be better if the Owner updated the status.

I set NEEDINFO on the bug.

> Latest Information: The bodhi update adding compat Tcl/Tk packages and Tcl/Tk 9.0, it also contains builds for packages ported to Tcl/Tk 9.0: https://bodhi.fedoraproject.org/updates/FEDORA-2025-814b83576d was pushed. There are still a number of open bugs against this change, but the change owner has noted that the majority are build failures which will resolve once they are ported to Tck/Tk 9, or an explicit need for the Tcl/Tk 8.6 compat devel packages to be added to build. The contingency plan is beta freeze, and this change is not release blocking.

sounds good to me

yep

https://bugzilla.redhat.com/show_bug.cgi?id=2346758 reports an installation bug

*FTI

But I think it's work is being done.

I think we should gather more info and revisit this next week.

WDYT?

I suppose. I think it's probibly fine and just fixing issues/bugs found...

As usual, this should come in late. I'd ignore it for now.

+1

yep. +1. All systems normal.

+1

+1 sigh

I prefer waiting, but I won't hold anything back. If the masses want +1, I'

ll be a +1

Pff, there's a lot of changes yet.

Do we want to go through all of them today?

well... next thursday is the beta go/nogo... so hopefully we will have a beta rc early next week... so next tuesday is kinda late to run a contengincy plan on something that requires that at beta.

I guess we have to go through them all

are there any in that list that are likely to need that?

these kind of meetings are always long, no?

OK, I'll try to go faster.

Returning to the change

> Latest Information: Latest comment on the bz tracker indicates infra support was needed to enable this change. Status is unknown right now (by me, others might know more). This does not seem to be release blocking.

nirik do you have more info?

I was on pto... so not really. I do know they were trying to get things working with new mock chroot and having issues... but I am not sure the state of the plugin.

So, I would say punt this one and get more info from change owners.

It should be pretty transparent to switch it in.

I second punting

OK.

I added NEEDINFO.

OK, now self-contained.

no idea where this one is. ;(

No idea. I don't even know where to check.

this one sounds like something that we can keep punting until it's done?

yeah, seems like it would be gradual. But it does need to reach some kind of milestone or something I would hope

I didn't even know this was a change

which is kind of bad 😅

We have `CONFIG_DRM_PANIC=y` in kernel config…

This I think is done? (although it was anoying to me the other day)

you also need FONT_TER16x32

I think

for HiDPI displays

yeah, easy to fix up, but the feature is essentially enabled

none of the recent rawhide kernels boot for me. They fail to find the rootfs. It pops up a nice drmpanic with a tux and the last line of the messages. :( Had to pass some things to get a qrcode or kmsg

anyhow, it's implemented. ;)

next!

I wonder if we can have a fedora logo instead of tux

but otherwise yay

The FEX change is done

so it can be set to ON_QA

It's yours, so please update the status.

We seem to have an update in bodhi, so it seems to be done.

it's done

it should already be ON_QA?

> Latest Information: The bz tracker was only added to this change on 17-Feb. I have reached out to the change owner via email to get a status update for the change, however it is not release blocking with no contingency plan or deadline associated with the change, nor is it release-blocking.

punt

poke and punt

> Implemented in edk2-20241117-14.fc{42,43}

peek, poke, then punt

So I think this actually done.

I'm the reviewer on the package review request, and it's 90% ready but stalled.

This can go in at any time, since it's new stuff, so I'd punt for now.

> Fixed In Version: ibus-1.5.32~beta2-3.fc42

OK, so this seems fine. Change is in ON_QA state.

ibus-libpinyin-1.16.0-1.fc42 was built…

So I think this is done.

`sudo dnf install cockpit-navigator` gives me `cockpit-files` on F42, so I think this is done.

+1 yeah

Not sure the status here...

I have no idea what's going on there

I added NEEDINFO.

I don't see the new ghc being built…

WDYT?

ghc9.8-9.8.4-14.fc42 was built 18/1/2025.

it's there: https://src.fedoraproject.org/rpms/ghc9.8

Yeah, but the plan was to update ghc to be the main version.

yeah, looks like that part hasn't happend yet

a lot of Haskell modules are catching up to 9.8, so that may be part of the delay

Punt?

find with me

This one is mine. It's stalled.

!Info Retarget to F43.

No idea about this one.

No idea either.

The bug is misassigned.

I tried to fix it, but the bugzilla email address doesn't work.

*the email address doesn't work in bugzilla.

Sorry, it's been a long meeting.

OK, fixed.

> Only outstanding feature work is to get the systemd presets defined to start on boot, so should be ON_QA soon. See linked BZ for fedora-release.

> Latest Information: A build has been pushed to the F42 stable repo - FEDORA-2024-5814c2fd6d (bpfman-0.5.4-2.fc42).

So… good?

seems like...

From the change page Scope: Other developers: https://copr.fedorainfracloud.org/coprs/g/ebpf-sig/bpfman-next/ migrate these packages from copr to Fedora alongside proposal owners

But I don't know what those "other packages" are.

OK, so that's it.

I think jednorozec said that he can do next week.

If nothing, I'll close in a minute.