Meeting started at 2025-02-13 20:00:40 UTC

The Meeting name is 'ELN SIG 13 Feb'

The Meeting Name is now eln

!hi

Troy Dawson (tdawson)

!hi

Michel Lind (salimma) - he / him / his

!hi

Davide Cavalca (dcavalca) - he / him / his

Neil Hanlon Conan Kudo Johnny Hughes are you around?

!hi

Neal Gompa (ngompa) - he / him / his

let's get started

Davide Cavalca Michel Lind 🎩 UTC-6 the new ncdu 2.x version is unbuildable in ELN Extras, wondering if it can be dropped? (details in ticket)

yeah let's drop it for now

thanks, I'll get that merged

this is related old business, but I'll rebase and fix my PR after you land that

merged!

!hi

Michel Lind 🎩 UTC-6 that would be great, thanks

Neil Hanlon (neil) - he / him / his

Thanks for the ping i neglected to fix my calendar...

anyone else have new business to discuss?

unfortunately it seems that build fixes are slowing down

huh... gtk2? and... koji

IDK about other people, I feel like I'm just starting to ramp up again after all the conference travels

yeah, in Extras

and having to split stuff doing internal non-open-source work as well as chasing F42 feature work

is there an easy way to trace who needs gtk2?

i'm ashamed to admit i'm only now looking at my _own_ f42 ftbfs...

that might be ... a candidate for dropping. it's 2025 :)

https://tiny.distro.builders/view-rpm--view-eln-extras--gtk2.html

heh I sometimes skip the ftbfs where I'm the primary assignee but it's a hard problem and help clean up packages I comaintain first

ooh nice

leafpad, in Troy Dawson's workload

not having gtk2 in EPEL 11 might be a worthy goal, but not sure who is going to *drive* it

I wonder how feasible it is to have a Fedora change proposal to ... deprecate gtk2 :)

not drop, just deprecate

at least we stop new dependencies and signal we'll eventually remove it. then we can drive the cleanup later

there must be.. unpatched security issues affecting gtk2 by now right?

Wait ... leafpad wants gtk2 .... *sigh* ... ok, I'll have to find something else small to put in there.

not sure who would drive that, given that we still have glib/gtk+ 1.x in fedora 🤦‍♂️

last release of leafpad is 2022

https://download.savannah.gnu.org/releases/leafpad/?C=M&O=D

I'm trying to find its source repo but have not found ityet

technically it says "GTK+ >= 2.0.0 so ... lewer code _should_ work? **ducks**

http://savannah.nongnu.org/cvs/?group=leafpad

There are roughly 200 packages in Fedora that want gtk2

oh boy CVS

Ya know ... I could probrubly just drop my whole extras person list, I only put it in there originally as an example.

nope, source repo is empty, they just have tarballs

yeah I think we won't remove it as a first step, totally unrealistic. just marking it deprecated (e.g. python-mock has been deprecated for multiple Fedora releases, and I've been trying to actually remove it for the past 3 releases on and off :P)

https://github.com/tarot231/leafpad found this ?

koji sounds like we might want to fix it

perhaps...

yeah probably a good idea 🙂

oh thanks

Ya, koji needs to be fixed, at least the client side.

ftr for the most part I've just been leaving F42FTBFS to the maintainers, and focusing on ELN failures

yeah

but we're at +3 weeks since already and it's slowing down, so it's probably time to step in and move things along

plus I'm starting to work on f42 flatpaks as well, and already encountered a couple of these

the golang ones are a bit intractable this time - I think I have one or two packages where it's not clear how to fix it

I'll follow up and get bugs filed upstream at least so upstream is aware

it also does not help that iirc golang 1.24 is not *officially* out yet

the joys of being First, but somebody has to do it

yeah. let's hope Fabio's proposal for slowing down toolchain changes get traction

it's one thing to be first, it's another to drop a change without scoping out the potential breakage first - "oh we didn't have time to check the rebuild failrues"

it's one thing to be first, it's another to drop a change without scoping out the potential breakage first - "oh we didn't have time to check the rebuild failures"

not sure if it's going to be slowing down so much as preempting failures through copr testing first etc.

the gold standard will be how Python does it really

except ... need to talk to the python folks, the local rebuilding instructions have been failing for a while so it's hard to test. but anyway, not directly relevant :)

I have a particular interest in this timing because two years from now we're due to branch RHEL 11 from Fedora 46, and from experience I can tell you that two weeks (between mass rebuild and branching) to fix *all* the failures is INTENSE

sort of related to this topic, Troy Dawson have you (or KDE SIG) made plans for qt5 in EPEL 11? I'm wondering if we should just start dropping things from the KDE workload that haven't migrated yet

*except* that vlc is still on qt5, although work is underway upstream to backport qt6 support to vlc 3

which tells you something about the state of vlc 4...

vlc is not part of... oh is KDE using vlc?

There are still quite a few things on qt5. My opinion is give it another year, and at that point, take out whatever hasn't moved over yet.

just ffmpeg, right?

https://tiny.distro.builders/view-rpm--view-eln-extras--qt5-qtbase.html

looks like ksnip, mallit-keyboard, and vlc

*maliit-keyboard

Oh ya ... maliit-keyboard

yeah I think there's already a KDE SIG ticket on that one

There is work on a new keyboard.

oh it's a phone thing

Not totally phone, but yes, it pops up if you don't have a keyboard present.

ksnip can probably be... dropped right?

in favor of spectacle?

ksnip ported to qt6 some time ago

just not released

Um ... it already has been. I guess we need to go through the list again.

https://github.com/ksnip/ksnip/pull/1101

ok so there's hope for it still

Troy Dawson what about delisting the qt5-qt* packages and just let them be pulled in as deps until things have been ported? that would at least cut down the breadth of the stack until it goes away entirely?

and better express the wish not to have them at all in EPEL 11?

I'm good with that.

can I leave that to you to submit the PR?

Yep

anything else on this topic?

ok then we have a few minutes to look at older tickets

Davide Cavalca this was yours, but not sure exactly what you're looking for?

Basically when a workload (say, the meta one) fails currently the only way to tell is to look at the dashboard or notice that packages are missing

It'd be good to expose this in some machine relatable way alongside the compose

So one can make an informed choice whether to ingest it or not

that sounds like a form of compose gating?

That would be orthogonal. This is just about recording as part of the compose artifacts which workloads were part of it and if they failed or not

yeah

because if you don't care about a particular workload you can still consume the workload

You could definitely then consume this as signal for gating among other things

the compose I mean

ok I think I see what you're saying now

no idea how that would be implemented though 🤷‍♂️

if you could clarify that for future reference, we'll have to leave it in the backlog for now but I'm hoping we'll be getting more help with tooling in the near future

Yeah I'll comment in the yicket

Yeah I'll comment in the ticket

thanks, it sounds like a good idea and is probably doable, but not in the next few weeks I suspect

one more I wanted to get to today:

Oh, did anyone send an email about that?

last week we agreed to open for desktop artwork submissions, and hold a vote in three weeks hence (now two weeks)

Oh, awesome! I will share this around 😃

(If that's OK)

it was in the meeting minutes sent to devel@ but I didn't send a specific email about it

Yes, please

and... trade 🙂 https://forums.rockylinux.org/t/rocky-linux-10-wallpaper-contest/17501

anything else on this point?

not from me . hoping to contribute more in 2025 than 2024.

looking forward to it!

4 minutes left, anything else to discuss today?

Nothing from me.

seeing none, in that case, thank you all for your participation today