Meeting started at 2025-05-27 17:00:25 UTC

The Meeting name is 'FESCO (2025-05-27)'

The Meeting Name is now fesco

!group members fesco

Members of fesco: David Cantrell, Fabio Valentini, Fabio Alessandro Locati, Tomáš Hrčka, Kevin Fenzi, Matthew Miller, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), Michel Lind, Stephen Gallagher, Zbigniew Jędrzejewski-Szmek

~hi

!hi

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

!hi

David Cantrell (dcantrell) - he / him / his

!hi

Michel Lind (salimma) - he / him / his

morning

!hi

Kevin Fenzi (kevin) - he / him / his

!hi

Stephen Gallagher (sgallagh) - he / him / his

we have the quorum :). Let's wait a couple minutes to see if other appears

!hi

Fabio Valentini (decathorpe) - he / him / his

!fesco 3410

● **Last Updated:** 4 hours ago

● **Opened:** 2 weeks ago by buckaroogeek

**fesco #3410** (https://pagure.io/fesco/issue/3410):**Update moby-engine/docker-cli rpm version for F42 and F41**

● **Assignee:** Not Assigned

!hi

Neal Gompa (ngompa) - he / him / his

this should be an easy one, but I see not many people voted on this

we only have +4

I thought I voted on this, I just added my +1

I do remember reading it

why was this tagged for meeting?

ah, I thought I did too... but I guess not.

+4 over one week is enough to approve it in ticket

!hi

yeah

Zbigniew Jędrzejewski-Szmek (zbyszek)

I lost track of time.

:/ sorry for that. I was sure it was +5 in a week

eh, it doesn't really matter *where* it's approved :)

+3 over a week is the minimum bar

(with no -1)

we are +6, so I guess we can count it as approved

!fesco 3412

● **Assignee:** Not Assigned

**fesco #3412** (https://pagure.io/fesco/issue/3412):**Removal of packages with invalid license**

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

● **Last Updated:** 4 hours ago

zbyszek: left the only comment on this. Do we want to discuss it?

I fixed libieee1284 and iscan-firmware.

And we can drop scapy-doc as a subpackage trivially.

I was waiting to hear an update from the reporter

Yeah, I was waitning for a reply on it...

Proposal:

Yeah, I was waiting for a reply on it...

!hi

Tomáš Hrčka (humaton) - he / him / his

Sorry I am late

The only package that still needs work is 'scapy'. We ask one of the maintainers or msuchy to drop the scapy-doc subpackage.

(wording suggestions welcome. I hope the intent is clear.)

+1 to what zbyszek proposed

sure, sounds fine to me. +1

+1

+1

+1

+1

+1

!fesco 3414

● **Last Updated:** 4 hours ago

**fesco #3414** (https://pagure.io/fesco/issue/3414):**LLVM-20 Change Proposal: Revert Install Prefix Changes**

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

● **Assignee:** Not Assigned

yeah I don't think there's a good way around this (other than to disable i686 arch on F42 after the fact 😄)

Tom Stellard replied to Stephen Gallagher ask, but no more comments on this

I guess this would be reverted in f42+ then?

Sorry, I forgot to reply after you answered.

I agree, if it's not ready, roll it back and try again another time

The revert sounds reasonable.

I think it is sensible for ow, until a better solution is figured out

Maybe something better can be figured out later, yeah.

+1

if reverting works due to symlink -> directory or whatever replacement not working in dnf, then sure ...

nirik: Can today be that day? Please?

well, if we just say 'sorry wine users, do something else' it could be?

:D

there's an open PR to enable "new WoW64 mode" in wine

which is basically the only blocker that I know ofd

which is basically the only blocker that I know of

nirik: At this point in history, I suspect that a plurality of wine users are using Flatpaks

I'm sure it will affect some people, but... things move on.

Well, there's also the question of using Fedora as a 32-bit development environment. I do this, FWIW.

Stephen Gallagher: would wine in flatpak work without i686 in the base os?

it does

Fale: As I understand it, yes.

sidebar... can we get metrics on that right now from package downlod metrics?

no

Oh, wow, new FPL.

I would doubt this.

I don't think so - systems only identify by host architecture, and i686 packages are only used on x86_64 hosts

It's either native RPM, CrossOver RPM, or Steam

and Hi Jef Spaleta! :)

Conan Kudo: even if they are not, it can be suggested as work around, if we go that route

hi Jef Spaleta :)

Hi Jef Spaleta

There is no "wine flatpak"

oh hey there is

we can't get stats for packages. We just give users mirrorlists and they download from mirrors. So, not too much way to tell currently

nevermind

it ships winetricks as a flatpak wrapping wine itself

steam was the other holdout... but there I do think lots of people have moved to the flatpak

👋 didnt mean to derail.. first meeting i could lurk in, with all the onboarding firehose over the last couple of weeks

that said, Wine is supposed to be working on a reverse thunking thing for 64-bit POSIX to 32-bit Windows

HGL uses Wine-GE, Steam uses its own Proton stuff ...

Steam itself is 32-bit POSIX

anyhow, this is kind of a derail?

yes, that's what I referred to by "new WoW64 mode" :)

Yeah, my fault. Sorry about that.

and the RPM outstrips the Flatpak because of usability issues with Flatpak

(the wine pr has a comment from the maintainer that they would merge it if it was reworked for the current version... 3 months ago)

it looks like some wow stuff was added in 10? https://src.fedoraproject.org/rpms/wine/c/11b57cc76c536a899a830c883c400e44e298f384?branch=rawhide

for reference: https://src.fedoraproject.org/rpms/wine/pull-request/19

(and it's been open over a year)

Let's get back on track?

+1

oops, sorry, missed the past few mins

so, +1 to the revert, it seems like the way for now even though it's not ideal

Michel Lind UTC-6: Good timing for those minutes

+1 on the revert for now

+1 for the revert

should they do change proposal?

for a change on F42? I hope not

No, because it's for F42.

jednorozec: For most practical purposes, this is a late, partial invocation of the contingency plan

Oh sorry, my confusion was that it was a change for f42 should we somehow document it for f43 that its not the case anymore?

hmm yeah, if it's a late revert that means the release notes are wrong... maybe we need a concept of erratas

I think a note should be added on the Change page.

Because I as a user expect changes that ocured in 42 to be in 43

Let's be pragmatic about htis.

I am fine with any docs on this.

Note is just fine, but something...

I think a note on the change is probibly good...

Oh and I am +1 for the revert

its interesting this conflict wasnt caught.. which suggests the 32bit packages weren't being tested by anyone in the run up when the contingency should have fired?

So far I have Michel Lind UTC-6 , nirik, Fale, dcantrell, jednorozec +1. Is this correct?

Jef Spaleta: I think 32bit is a niche today

+1 too

Almost as if 32-bit is a shambling corpse, ready to be laid to rest permanently... :)

Fale: I was +2 also

Fale: I voted +1 above.

Fale: I was +1 also

Neal Gompa (Fedora): ?

that may be generally true, but this feature seems to be bound up around the use case of 686 enablement...unless im misunderstanding the feature

Yes, but also upgrades of existing systems and such.

yeah, I doubt we can drop i686 in F43

+1

definitely not F42 but F43? we can hope

probably not F43 either

!agreen APPROVED (9, 0, -0)

typo :)

32-bit is basically not niche as long as it's a hard dependency for video games

We greenlighted the proposal, hence 'agreen'.

it kind of it, if there is a real workaround, imho

no

that's not how "niche" works

if it was niche, we could turn it off in the kernel by default

we know it's not niche, so we aren't doing that

I think we do not have the data to say if it really niche or not

'niche' is like what is an Indy band.. depending on the question and the time... everyone has a different definition

next topic?

any takers?

I thought we wanted to skip next week?

I will be on a plane next week at this time

yes, the week after that :D

I'll be running to catch a train around that time next week.

Yeah, we decided last week to skip the next meeting

the week after that will have new fesco members :)

I can do it.

I have one for open floor

fale has already given cookies to zbyszek during the F42 timeframe

So we are making forgejo rpm for fedora.

We are struggling with compiling assets for the web app. Is there a way to ship upstream compiled assets?

Should we ask for exception from fesco or someone else?

have you asked the Go SIG? I don't remember seeing this question in the #golang:fedoraproject.org channel

yup

SOme people also commented on the review

Didn't we pass an general exception?

let me find the link

"compiled assets" being ... what? minified JS / CSS?

I thought so but was unable to filter it in the tracker

yes its "compiled"

yeah I think we passed an exception for those

Yes, we did

Let me find the ticket.

https://pagure.io/fesco/issue/3269 is the CSS one

https://pagure.io/fesco/issue/3177 for JavaScript

thank you Stephen Gallagher

we might get forgejo rpm for flock ;)

jednorozec: Basically, it should be regenerated if it reasonably can be

But not doing so is not blocking

https://pagure.io/packaging-committee/c/82155a1

That is all I have. Thanks!

is that am upstream discussion opportunity? to see if working upstream to provide pre-compiled assets as code is something that can be worked on?

Jef Spaleta: What do you mean?

There's nothing inherently wrong with them providing the pre-compiled assets

sorry misread the problem statement

cockpit and a few other things already do this

so it's been "allowed" for a while when it is infeasible to rebuild the assets

(there is probably a topic in itself about what constitutes reasonable infeasibility)

I'd like to share with everyone https://github.com/coreos/rpm-ostree/issues/5365 . There are issues in ostree-rpm land with users. No decisions to be made from FESCo side, but simply an FYI.

are there other things in the open floor?

nothing here

I guess we can close if in 1 mintue there is no taker :)

nothing from me