Meeting started at 2026-02-17 18:00:23 UTC

The Meeting name is 'FESCo (2026-02-17)'

The Meeting Name is now fesco

!group members fesco

Members of fesco: Dave Cantrell, Fabio Valentini, Máirín Duffy, Jef Spaleta, Kevin Fenzi, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), salimma (@michel-slm:matrix.org, @salimma:fedora.im), Stephen Gallagher, Timothée Ravier, Zbigniew Jędrzejewski-Szmek

!hi

!hi

Fabio Valentini (decathorpe) - he / him / his

Zbigniew Jędrzejewski-Szmek (zbyszek)

will !hi work for us

!hi

Tomi Lähteenmäki (lihis)

!hi

Jaiden Riordan (jaidenriordan) - she / her / hers

!hi

madomado nuko (madomado)

morning

!hi

Owen Zimmerman (owensz)

!hi

!hi

Michel Lind (salimma) - he / him / his

No Fedora Accounts users have the @lleyton:fyralabs.com Matrix Account defined

!hi

Vít Smolík (smoliicek) - he / him / his

we'll get back once the topic gets to the npm part

thanks

!hi

Lleyton Gray (lleyton) - she / her / hers or he / him / his or they / them / theirs

i'm listening into the whole thing

... will wait a few more minutes for more members to show up

!hi

Jef Spaleta (jspaleta) - he / him / his

hello 👋

Stephen Gallagher: did you fall down a rabbit hole already?

!hi

Stephen Gallagher (sgallagh) - he / him / his

I got eaten by a fox

wow, managed to scrape together 5 members. what's going on?

I know it's Faschingsdienstag in central Europe but that shouldn't affect most people here ...

!hi

Neal Gompa (ngompa) - he / him / his

Neal spotted!

Timothee wrote that he's out for a few weeks!

whoa all the people

i thought you weren't coming

oh right

excited you're here though

I'm here to say I won't be here :)

and then there were 6! let's start then.

ah...

just for my own clarity... im listed as fesco member... but I am such in ex-officio capacity correct?

(I reflexively came when I wasn't going to...)

yes. honorary member :)

I will try to speed things along, there's a lot of things on the agenda for today.

Jef Spaleta: You're a FESCo member in FAS mostly so you have access to the secret clubroom ;-)

!fesco 3547

● **Assignee:** nimbinatus

● **Last Updated:** a day ago

**fesco #3547** (https://pagure.io/fesco/issue/3547):**Change: Using Konflux for bootc-Based Artifacts**

● **Opened:** a month ago by alking

I thought we approved this last time? I guess we didn't...

Timothée not here again, so ... punt to in-ticket voting?

ah, perhaps that was it.

Any objections to move back to in-ticket voting?

nope, sounds good. move on. ;)

going once, twice, sold

!fesco 3549

● **Last Updated:** a day ago

**fesco #3549** (https://pagure.io/fesco/issue/3549):**Change: FilterFedoraFlatpaksAtomicDesktopsv2**

● **Assignee:** jspaleta

● **Opened:** a month ago by alking

sigh

oh hello 👋

🍿and 🔥s

looks like at least the discussion has fizzled out, last post was 6 days ago.

to be honest I'm not sure I like *any* of the outcomes here, but - barring technical issues - filtering the Fedora Flatpak remote by default to apps that are preinstalled seems like a ~mostly acceptable~ middle ground?

For specific Atomic outputs that desire it... not for all outputs..

not if we'recoromoting 3rd party content over our own

not if we're promoting 3rd party content over our own

Fabio Valentini: That means "the default on the Software page will use Flathub if enabled *except* for the applications that happen to be on Live media"?

so ... TLDR ... if the specific Atomic output does not choose this, the default is the status quo

if they do then they can get filtered where they get Fedora artifacts for preinstalled apps and flathub by default for others

Sorry, I'm going to need a detailed description of the requested state here. The conversation has gone on too long for me to follow it all

that is the intent as stated. There is room to negotate around additional filter logic that addresses specific architecture support diffierences

I have some questions: 1. why is this proposal limited to Atomic outputs? I don't see a reason why e.g. Workstation or Sway spin couldn't make the same choice as some Atomic spin if we approve this.

I assume something with limited scope would be easier to approve.

Because I feel flatpak is materially and strategically important for the atomic desktops in way that it is not for the maturer package mode outputs

this is all based on a utopian view of flathub which does not reflect the reality

I don't think certain spins should be able to turn off or filter Fedora repositories, flatpak or otherwise. Would it be okay for a spin to add `excludepkgs=chromium` to yum repo confs because its maintainers think upstream Google Chrome provides a better experience?

Just in the interest of keeping this meeting moving - it looks like people still have questions that could / should get asked and answered async. Would you prefer to move this topic to next week, and everybody gets homework reading assignment?

and regardless of how this change is disposed of. I continue to have discussions with flathub about policy alignment and discussions about trying to further the federated capabilities of flatpak... this is a compromise that is actionable now.

and it seems contrarian to say that atomic is potentially the future which needs flatpaks more than ever and then downplay our own content

Do we have legal opinion that allows up to include upstream rpms?

Frankly, I think an awful lot of this is coming as a knee-jerk reaction to a single bad-press incident. I understand that we (Fedora) screwed up in that case. The response does not seem in line with the failure, to me.

2. Did we figure out what *subset* of flatpak would be presented to users? FLOSS, or verified floss, or all of flathub? The proposal text does not make this clear and there's been a lot of discussion and I'm not sure what the current proposal is.

I believe Google Chrome is a third party workstation repository that can be enabled just like Flathub

Ok, putting my foot down. Please ask those questions in the discussion thread.

which was peacefully resolved a year ago

Jef Spaleta: It doesn't have to be a legal issue to disagree with our historical philosophy.

And it provides translation and codecs and other services that IIRC chromium does not

!fesco 3567

In discussion.. i clarified that i expect it to be strictly verified floss... with an understanding that verified from flathub pov may have holes.. and i have a commitment from Gnome VP that we can work on that so the verified floss tag is accurate

● **Last Updated:** 3 hours ago

● **Assignee:** Not Assigned

● **Opened:** 5 days ago by owensz

**fesco #3567** (https://pagure.io/fesco/issue/3567):**Revert Node.js NPM Change**

But I don't think that's a valid reason to exclude our chromium package

Jef Spaleta But that needs to be part of the proposal!

It looks like improvements to the NodeJS packaging have landed in Fedora 44+. Were the concerns that people had about the status quo addressed?

i did not mean to imply that there isnt a disagreement here. But there is a difference in legal standing and it is material

In that I should amend the proposal?

Get a room, people, we need to move on, otherwise this meeting won't be done until tomorrow.

Jef Spaleta: The topic has moved on. Let's discuss elsewhere

I think the builds are in progress?

OK, I'll ask in the discussion thread. Sorry for not getting to that earlier.

sure, i look forward to you letting me know where you want that discussion to happen

if I have to generalise then i'd say we are currently at least a bit more happy with gotmax23 's solution if it works

I see no in-progress builds, the last nodejs22, nodejs24 changes have landed yesterday.

(thanks for that btw)

but I don't think we have a consensus over the naming of the subpackage yet

ok, so then what *is* the current status?

I believe the naming is being discussed with the FPC

Speaking as the former Node.js maintainer in Fedora, I want to take a moment to express my appreciation for jstanek and tjuhasz for taking over these packages. They are *immensely* complicated and it's really easy to get wrong.

I think (?) my and Miro's solution resolved the other problem, but as was pointed out, the ticket didn't really clearly articulate what it was trying to solve

IIUC, the current status is that the the packages with the symlinks are always installed, so the technical side of the problem is solved, and only the package naming issue remains, which is not urgent at all.

The overhaul they have been doing is a massive undertaking and some mistakes were inevitable.

Indeed

Sounds like the sharpest edges have been filed off then?

well we definitely want it not to be shipped into 44

if that's satisfied then yeah

I think so

define "it"?

madonuko can you also specify what problem you're trying to solve?

I prefer having the proper subpkg names and gotmax's solution in 44

as for the problem, we don't want it to break CI that disables weak deps and relies on npm

because the bin is not pulled in

I think it already is in f44

also, the naming is confusing

yeah. it looks like rawhide and f44 are currently in sync, so any fixes that have landed are available in both, and I assume that will continue to be the case for further changes

it, being the fix for weak deps

!hi

No Fedora Accounts users have the @roachy:fyralabs.com Matrix Account defined

Naming is a matter of opinion and I do not think it's a valid reason to punt or revert this change

And it's being discussed by the FPC

thought it got branched off like a week ago? but ok regardless of that that's great to know

But I don't think the current naming is *wrong*

So not sure what else FESCo has to do here

Proposal: Reject the request to invoke the contingency mechanism, based on the fact that the issue is being worked on and the sharpest edges have already been addressed.

Makes sense

With my FESCo hat on: naming is the prerogative of the packager doing the work and we should not deign to overrule them

(Exceptions for offensive terminology rulings)

As long as it doesn't go against the Fedora Naming Guidelines, which this definitely does not

So let's take that off the table and focus on the practical issues if there are any left

To Fabio Valentini: +1

I'm holding off on my vote for Fabio's proposal a little longer because we still haven't gotten a clear answer whether *technical* issues remain here.

To Stephen Gallagher: I don't think this is so black-and-white. We occasionally do need to get involved in naming. And we do have a bunch of very specific rules for some cases.

(Also, I don't like needing to vote in favor of *not* doing something.)

Stephen Gallagher I was thinking that you might say that, so I made an effort to vote -1 in the ticket.

Personally I'm happy with the current discussed changes if users can install nodejs-npm and get a working NPM install (including npm binary) in CIs (AKA without weak deps). The biggest issues were users who disabled weak deps and CIs.

I think -unversioned-command is a better name for these types of packages however, Fedora doesn't have the same naming conventions as Arch, true, but in this particular case I would say -bin was rather confusing since in this case it was not just the bins for the package in general, but the unversioned ones. That's where it was particularly confusing.

Stephen Gallagher: I thought we want to have active voice in proposals? :P

I'm thinking like is naming not a technical issue if it's misleading? But I mean, if you guys really think the naming works then I guess we don't really have control over that

I do want to respect the maintainer so

Fabio Valentini: I always ask that proposals describe what we are *changing* so that if we don't get to +5, there's no ambiguity about the outcome

Package Naming is a Packaging Committee issue, not a FESCo issue, and there's already an open ticket for that.

Stephen Gallagher: but I don't want to make a Proposal to invoke the contingency mechanism, because I would not agree with that ;)

a bit off topic, any quick pointers on how packaging committee works?

Fabio Valentini: So you make the proposal and self -1 it. That's what I do

madonuko: file a ticket and if it's not processed quickly, show up at a meeting and ask about it

they meet weekly and vote, just like us

(bi-weekly but yes)

Oh right

anywhere I can see the ticket in concern?

https://pagure.io/packaging-committee/pull-request/1526

Anyway, I agree that `dnf install nodejs-npm` producing a usable `npm` command is at least the minimal level of expectation here. So if that works now, I'm disinclined to ask for the Contingency Plan.

Updated Proposal: Invoke the contingency mechanism for the NodeJS / NPM swappable alternatives Change Proposal for Fedora 44.

That works.

-1

-1

-1

-1

ok, I think we have a middle ground here anyway, so i'm good with taking back our fesco ticket

we're at -4 ... who are we missing?

Mi.ʃɛl Lɪnd, Neal Gompa (Fedora) vote?

Gilver any opinions?

oh oh having connectivity issues with matrix ...

yeah, federation seems bursty.

Aside from the naming I believe our CI and user experience concerns were mostly addressed (assuming that an npm command is now a hard dependency, which I believe is now the case). And the name isn't a FESCo issue.

sorry, one sec

-1

I am so sorry it's taking me so long to type Matrix connectivity is awful right now.

Proposal: We switch back to IRC for the next meeting.

(was sporadic just now since I had to squeeze in dinner time)

In agreement as well, we can further the name discussion with the packaging committee. Thanks all!

Just as a general note: It would have been great to get feedback like this on the Change Proposal when it was first discussed 6 months ago. Having a last-minute request to revert the changes could have been avoided.

Thank y'all for coming ;)

The temptation to plus one this.

Unfortunately, I just threw out my 14.4k modem

well, can't quick do that unless we read every proposal

we figured this out when our CIs broke anyway

soo yeah unfortunately

!fesco 3568

● **Opened:** 3 days ago by carlwgeorge

**fesco #3568** (https://pagure.io/fesco/issue/3568):**Fedora GNOME bugzilla auto-response and bug monitoring expectations**

● **Last Updated:** 23 hours ago

● **Assignee:** Not Assigned

yeah we probably need to be better and checking who should be alerted (or ideally involved as co-owners) in CPs

This was filed only a few days ago, maybe it makes sense to discuss elsewhere before we take actions (if any)?

This is honestly just recognizing the GNOME policy of the last fifteen years (or more)

They've always ignored downstream bugs and been quite clear that they do.

The one problem I have with this: The template explicitly says that downstream issues should remain open - but nobody looks at the bugs *period*

yeah, it would probibly make sense to close the downstream ones unless they are needed for fedora tracking purposes.

Now, *better* automation would be for them to auto-file the bugs upstream, but this is better than the historical approach of just ignoring them without telling the submitter that's what's happening.

but also, perhaps some new thing will be able to deal with this better than bugzilla does currently

Even auto-closing the bugs and telling people to reopen downstream-specific issues would be better

is the new GNOME oncall supposed to look at this?

nope

I'd honestly like to suggest that we consider changing our downstream bug policy rather than address GNOME's approach here.

Because GNOME is just being honest about ignoring the policy, but they're far from the only group that does so

It seems Gnome's approach is in direct conflict with the policy?

"s/GNOME/Workstation WG in Red Hat/" but yes

(See the discussion about CVE bugs in Fedora as well)

It seems Gnome's approach is in direct conflict with the current policy?

s/in Red Hat/in Fedora/ ?

nirik: in this case, no, I wrote Red Hat specifically. GNOME packages are maintained by Red Hat. for better or worse.

A policy that is widely ignored is not an effective policy.

There are non RH folks on the workstation working group... and even some of them discussed/approved this in the historical ticket

but I guess thats a sidetrack, sorry.

I think this needs wider discussion probibly.

Packager Duty rotation is Red Hat only though.

Widely ignored by who?

I prefer to track Go tooling bugs all in Gitlab.com/fedora, but nobody told me I can completely ignore Bugzilla

gotmax23: "Widely" != "Universally"

Well in this case, it seems we're only talking about GNOME

Proposal: Start a thread on discussion.fp.o about Package Maintainer Responsibilities like monitoring bug reports where this can be discussed async, keep the ticket open for now for tracking purposes.

+1 👍

+1

sure, +1

But honestly, I think it's worth considering dropping the downstream tracker more or less entirely and recommending that people file issues upstream

It seems bad that someone spends their time filing a bug and then gets told by a bot it's going to be ignored

And just having some Forgejo issue trackers for things that are uniquely Fedora issues (like compose generation)

↑ this should be a post on that discussion thread

if forgejo supports disabling per-repo issue trackers, then that might be a nicer approach to people wasting their time filing

gotmax23: Maybe we spend some time writing an AI chatbot that guesses the correct upstream to file a ticket to?

Well, we need somewhere to track packaging bugs

if it's a packaging bug upstream likely doesn't care? or a dep issue or ...

But I can save the rest of my comments for the discussion post...

I'll contribute to a Discussion if someone starts one

But you may not want me starting it :)

This was the primary reason I filed that issue

Fabio Valentini: I try not to throw AI at every problem, but that actually does seem like a place where an AI could handle triage.

I partially disagree with the view that something terrible is happening here. A bug should be a dialogue between the reporter and the maintainer and possibly other interested parties. And the reporter needs to be ready to spend time on following up. So if a reporter gets a clear message that the bug should be reported in a different place, all they need to do is select the text, go to the new location, paste the text and open the new bug. This is nothing obnoxious and you only need to do it once. The second time you report a bug you'll most likely already know to go to the second place.

Note that that somewhat would happen if we just had the ability to disable bugs for specific sets

!fesco 3563

**fesco #3563** (https://pagure.io/fesco/issue/3563):**F44 Incomplete Changes Report**

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

● **Last Updated:** a day ago

● **Assignee:** Not Assigned

*let the bonanza begin* 🪇

I updated the table ~24 hours ago, it should be mostly up-to-date

so, shall we go through all the non ON_QA ones?

I propose that we go through changes that are *not* ON_QA or CLOSED

Hmm, the ones that were requested to be reassigned to F46 are still listed here.

and !action somebody to verify that the ones that *are* ON_QA or CLOSED outside of the meeting

and !action somebody to verify that the ones that _are_ ON\_QA or CLOSED are done outside of the meeting

that sound like a plan?

Yep.

sure

ok, no objections, so let's roll with that

Not the change owner but just marked the Golang bug as ON_QA...

It needs some testing but yeah, it's all lined up

this one or the previous one?

sorry, that was for dtb.

pesky federation lab

pesky federation lag

UBLU looks not in progress

Timothée Ravier (travier) is out... so, not sure here.

dustymabe: you have any info ^

Note: This Change was originally filed for Fedora 42 and has been postponed twice already.

https://github.com/coreos/bootupd/issues/927 is still open

Proposal: The Change is rejected for Fedora 44. Change Owners are welcome to re-submit an updated proposal for Fedora 45.

I suppose so... perhaps also encourage to land in f45 now/soon so as to avoid last minute problems

I wonder if we still have quorum, or if federation lag is hitting me.

↑ my proposal was to get the Change filed and discussed again, not to move it to F45

ah true

sure, +1

Hmm, so this change _is_ partially implemented. E.g. the file moves in grub2 and shim were done, afaict.

But the bigger part, i.e. the installer thingy, is not.

Hmm. I don’t have any context off the top of my head, but could try to look into it

In the light of this, I think it's too late to try for F44.

Yes, beta freeze has started today.

+1

(E.g., rpm -qlvv shim-x64 says that /boot/efi/EFI/BOOT/BOOTX64.EFI is %ghost, and the actual file is in /usr/lib/efi/shim/16.1-5/EFI/BOOT/BOOTX64.EFI. But I think that was just the preparatory step.)

Looks like we lost quorum though.

Michel Lind UTC, Stephen Gallagher : still here?

yeah

+1

Sorry, got pulled away

Reading backlog now

TL;DR: Change looks not done, was already moved to F++ twice, and it is already quite late now (beta freeze started)

+1

this one does not seem problematic if it's done a bit late, right?

From what I've read, this should be purely additive, yes.

Proposal: Ask for updates and revisit this Change next week.

yeah. they should ask for a .. oh they don't even need a FE

+1

Also, we only approved it last week.

+1

true

+1

+1

I think Cristian Le was working on getting the remaining / missing PRs rebased and merged?

Yep, have a list compiled

The CMake change itself has landed though

can you update https://bugzilla.redhat.com/show_bug.cgi?id=2376114 with this information please, and set it to MODIFIED (and to ON_QA once the PRs are done)?

Michel Lind UTC: you are up

hello!

I hardly recognize you with the new hat!

so all the dependencies are in, I'm about to submit the package itself for review. sorry for the delay - chased a red herring on selenium dependencies before realizing we don't even run Django's selenium tests

this is the hat that's on my profile since... 2024? I don't take it to conferences since I'm afraid I'll break it in the suitcase :)

Ok, please update the tracking bug and mark the package review as blocking the tracker bug.

will do, thanks

(I meant: FESCo hat -> Change owner hat)

I must be tired. I'm a dad and I missed a dad joke

erlang-26.2.5.16-2.fc44 is the latest build

salimma has already given cookies to decathorpe during the F43 timeframe

Looks like this is not happening for F44.

I see no activity related to erlang v27, no pull request, no update on the tracking bug

and this was already moved from F43 to F44.

also note that the latest upstream seems to be erlang 28.3 now.

yeah, so ask them to resubmit when ready?

yup - Proposal: The Change is rejected for Fedora 44. The Change owners are asked to update the proposal (possibly for erlang 28 or 29) and (re-)submit it when ready.

+1

+1

+1

Stephen Gallagher: I thought we said "no rabbit holes today"?

+1

Sorry, I'm trying to split my attention between two important things. It's not going well.

yeah, sorry for pinging people, but with only 5 members present, it's difficult :(

Please do continue pinging. I genuinely appreciate it.

The requested clarification about the version of gcc (16.1 or 16.0.1) hasn't been answered, but I think this is otherwise on track.

This looks mostly done. Was gcc 16.1 even released yet?

(I think they're doing weird releasening with the .1 being the first "stable" version?)

the gcc releases page doesn't even have 16 on it. ;)

yeah looks like 16 is not officially out yet. so 16.1 not being packaged makes sense.

would be nice if they call this 16.0.0~rc1 :p

based on the last few releases, 16.1 won't GA until April

oh, well then.

April, that's late target #8

I thought this landed, no?

yeah, me too

looks like it - https://bodhi.fedoraproject.org/updates/FEDORA-2026-4321bd08b4

right before freeze

I have the link but cute anime girl doesn't let me see the page

well, that, or bodhi is down ...

"stable" is all you need to know

loads fine here.

658 packages in that Bodhi update...

yep

"this is fine"

I marked it as ON_QA now.

loaded for me now too. finally

Michel Lind UTC: Well, it tells me we shouldn't have any problems with the new ELN batching :)

Looks like 1.5.34-beta.1 are available in F44+

and 1.5.34 is not released yet upstream. so this looks good to me.

yep. looks testable

OK, so this should be ON_QA

yes. somebody do the -> ON_QA please :)

I marked ibus as ON_QA.

We only recently approved this, right? And this can probably land independently of the freezes, since it's not installed / enabled by default?

4 days ago

Yeeah

Yeah

Or maybe one week ago, but the tracker bug was created 4 days ago.

Proposal: Ask for status update and revisit next week

+1

+1

+1

19 minutes, go go go

This has been shambling along since F38 (!)

brrrrainnsss...

Proposal: This change is rejected for F44. Change owners please submit an updated proposal if they want to have it land in a future release.

+1

wow older than the Python Mock change

🧟

+1

+1

Hmm, coudln't we just postpone it again as asked by the Owner? It seems that the implementation is in progress and things are happening, even if slowly.

does not seem very hopeful.

> hopefully I will have some space to work on it for the next release

If this was resubmitted tomorrow, I think we'd vote to approve it again.

zbyszek: If it's been this long, I'd really rather just ask for a new proposal when it's close to ready

If that turns out to be tomorrow... great!

OK, +1 then.

If nothing else, after so many years I'm sure the implementation looks little like it did when this was originally written

always late landing...

yeah

zbyszek looks like you asked this to get moved to F45?

(also your bugzilla account needs a refresher and / or you need a new one. :))

oh no the post-RH syndrome

that said, this has also been around since F39

My bugzilla account was always my own, I think. Let me check.

hm. the Assignee has a @redhat.com email address

Oh, that's interesting. I never used the RH account on bugzilla.

I didn't know there's another guy with my name.

:D

plot twist, when zbyszek is on PTO that guy voted in fesco meetings

Dunno, so some work in mkosi has been done for this, but the big part is to file a infra change request. So if this is rejected and needs to be voted again for F45, I can live with that.

I always did think it suspicious how productive zbyszek is...

yeah I have a hard stop in 8 mins

and it's almost 9 pm for Fabi

I'll close the meeting at :00, doesn't make much sense to run over 120 min

and it's almost 9 pm for Fabio

zbyszek: is the Change proposal text still accurate?

if yes, then I'm OK to just move it to F45

It is still accurate. About half of the stuff that is mentioned is done a long time ago, the rest remains TBD.

Proposal: This Change is moved to Fedora 45.

I'm ok voting to punt

+1

+1

+1

+1

if there's no volunteers ... I don't mind doing it again, I should be available next week

someone in the US ideally

I guess I could...

it's just at the end of hours of other meetings. ;)

I guess I haven't done it in a while

It sort of feels like the same four people circulate it most of the time though

happy to let Stephen Gallagher have it. ;)

but I can do it if needed.

yeah :(

perhaps we can try and work the rest of the incompletes in ticket over the next few days?

if we have a light week we can suggest one of the newcomers try it :)

(I will update the incomplete changes ticket with what we voted on, just not ... immediately)

BTW, Fabio Valentini how did you generate the table with change status in the ticket?

banging my sausage fingers against a keyboard

(yes it was hand-written)

what! no ai! for shame!

Oh, wow, it was great.

TIL Fabio called Claude "fingers"

yes, many kudos!

lol

I intend to keep it up-to-date, it's much easier to read than ... what was there before IMO

oh hey 01 past

note that it might be easier on forge...

it has more support for tables, etc.

correct, on both accounts.