Meeting started at 2026-07-23 16:00:17 UTC

The Meeting name is 'fpc'

!hi

Fabio Valentini 🌈: Fabio Valentini (decathorpe) - he / him / his

Hello.

Hey

!hi

gotmax23: Maxwell G (gotmax23) - he / him / his or they / them / theirs

!hi

Michel Lind ☘ UTC+1: Michel Lind (salimma) - he / him / his

oh gosh it's my previous meeting that ran long

All the meetings ;)

Not sure if someone wants to fix this, or we could say "please do a PR"?

so... one person discovered this and one person reported it and now a third person needs to do a PR : P

Couldn't even provide a link.....

!hello

x3mboy: Eduard Lucena (x3mboy) - he / him / his

ok I'm going to keep up with this from my phone for the next 10 mins or so

I'd say I'd fix it except that I'm still trying to find what is broken.

I think it's the links here?

https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_current_list_of_enableddisabled_services

indeed, three of those five links are broken.

I'm sort of thinking that that whole section just shouldn't be there at all.

!hi

Carl George: Carl George (carlwgeorge) - he / him / his

It's just links into the source tree for fedora-release.

There's no reasonable way that can ever be considered stable.

can we just say "the list of enabled-by-default services is defined in the fedora-release package", go look there? :)

yeah

Yes, perhaps with slightly more explanation.

can we just say "the list of enabled-by-default services is defined in the fedora-release package, go look there"? :)

do we want to be more prescriptive? isn't that the only place they're *allowed* to be defined.

Eve if the links are fixed now, they'll just break again when the package forge changes.

Yeah preferably with something you can run and get that list

And what would you run to get that list that is somehow more stable than a bunch of links into the source tree?

I don't think that's prescribed right now. but we might want it to be?

"go look at the fedora-release package" (no links provided)?

or ask the docs team for a magic asciidoc macro like ::pkg::fedora-release:: that always resolves to the correct thing ™️ ? :D

I would like a betting line on how many weeks/months that works before being broken.

/me wonders how antora was approved for use in the first place

the mind boggles

Everyone loves the pipelines.

there's still no good way to build a full docsite locally with patched changes. the FESCo docs have some broken xrefs that I have not bothered to try to fix since I can't test anything locally.

Anyway, I'll try to make a simple PR.

gotmax23 gave a cookie to tibbs. They now have 109 cookies, 1 of which were obtained in the Fedora 44 release cycle

I do try to occasionally check and fix warnings when the guidelines are generated, but it's actually surprisingly difficult to do.

I did have it running completely clean at a couple of different points over the past few years.

the problem is when there are xrefs to other docs repos

the PgM docs were renamed to operations which then broke a bunch of things

anyway, let's wrap up Festivus

I think this is fine to merge now, but figured we all might as well look while we're here :)

Lots of "-", not too many "+".

I did not have a chance to look at this in full

Some parts looked potentially concerning

Assuming this is all what that sig wants, seems fine by me

I think the `%clean` thing was removed?

Note that this is still marked as a draft.

Yeah, not sure it's ready to merge yet

Did they want it merged as is or were they still working on it?

Indeed, we could say "once the sig signs off remove the wip"

We should get the example spec pulled out of the document like many other guidelines are done, but I wouldn't ask them to do that as a prerequisite.

Yeh, fair enough ... I'll ask them to remove the WIP.

But this seems OK, though I'd have to read through the generated document to be sure.

Which means I'd have to generate the document. Maybe one day we can get that automated for PRs.

the example spec is a bit scary, is it... common to go all the way to Source127 and Source128 ?

(if those are just skipping a lot of numbers to give space for additional sources/patches, I expect a jump to a fixed high number like 1000, or just make the bundled licenses be a fixed low number)

No, I think the idea is that each bundled library is a separate source tarball

Instead of one vendor archive like other ecosystems have

also what's AutoReq: no AutoProv: no for? ...

ah... and ugh... yikes

this smells very claude-ish

```

npm install --offline --cache %{_builddir}/%{npm_cache_dir} --package-lock false --omit optional --install-strategy shallow %{npm_name}@%{version}

#nothing to do

%build

```

should this not be a macro? ...

should this not be a macro? ...

```

npm install --offline --cache %{_builddir}/%{npm_cache_dir} --package-lock false --omit optional --install-strategy shallow %{npm_name}@%{version}

%build

```

(The Erlang Guidelines draft was also AI generated)

(I'd appreciate someone else to do a second review on those)

oh that's disappointing. I didn't expect that for... Erlang

I didn't mean to say it *was* - the commits don't have "Assisted-by" tags either

I will try to do a proper review of the new npm one, but my impression was a bit yikes from the spec example

also a bit hard to review due to the large diff ...

I also see a link to https://forge.fedoraproject.org/nodejs/npm2rpm that is 404

ah yes, the second commit in particular https://forge.fedoraproject.org/packaging/guidelines/pulls/1543/commits/7ed5ab84b166e9e2e2baa903d3d03a9f1336ad8f

I guess follow up on the npm PR and ask for a status update and then we can do another review?

And also ask nodejs maintainers to take a look if they want?

Anything else anyone wants to talk about?

I got reminded this week that we lack specific guidelines for pre-release snapshots, which has been on my todo list for a while now

/me still likes the half-joke idea of just specifying a BNF grammar

I raise you an AGENTS.md ... oh wait, no I don't

Maybe I need to shoehorn it into my sprint at work to allocate some time for it

We sort of have guidelines for pre-release snapshots.

At least, versioning them.

I came up an interpretation (`~^`) that I think is literally correct based on a combination of the rules, but it's not laid out explicitly so some folks have been confused

yeah, I think the issue is more Carl's ~^ preference does not have an explicit example

and we don't want Carl to have to explain it to each of us one by one

That's fair; the language in the versioning guidelines is very clunky.

And I think in all the edits that a section got lost at some point.

For clarity, what I mean is that we a must for snapshots to use `^`, and say to use `~` to sort before, but mention of what the combination should look like

To me it's semi-obvious from a strict reading, not just a preference

We do have an example using that.

yes, and as far as I know, the "MUST" for ^ is a mistake that happened when the guidelines for ^ were initially added.

"1.0.0~rc2^20210101gf00fabd"

sure, in that case, it's obvious

but would you do `1.0.0~^20210101gf00fabd` ?

That rc2 example is a post-pre-release snapshot

6.6~^_^~6 ;)

The near part of `~^` is that it sorts cleanly to `~beta1`

what format are you proposing Carl?

I have a vague recollection of having discussed this way back when.

I think ~^ is what we intended.

Yeah we talked about it here and I said I'd work on a PR. Said PR is about 40% written.

But I can't remember if there were any downsides to doing that.

`~^` is technically correct if you anticipate there to be actual tagged pre-releases (like beta1) but the ^ is not necessary if you know that there won't be a tagged pre-release.

Oh, I see, you want to make sure the pre-release snapshot sorts _before_ the pre-release versions?

yeah, like 1.0.0~^snapshot < 1.0.0~beta.1^snapshot.

You can't know that there won't be tagged pre-releases because you can't predict the future, unless you are somehow the upstream and are making a promise.

But even then, is that reason just to just have one clear rule?

Basically the combination of what's already there, a snapshot where a future version has been declared but not tagged, with no pre-release tags either. Based on a strict reading of the current rules that works out to say `5.0.0~^1.abcdefg`

also note that unless your version is bumped you can't move from a snapshot without ~^ to one with it

0~10 > 0~^11

```

❯ rpmdev-vercmp 0~10 0~^11

```

it's too late by that time

I believe the MUST for using '^" was quite intentional.

so - maybe note - if you can, start this way, it's easy to remove the caret later. if you already are using ~%{date} then don't change it until the next version bump

yes, I see enough people messing up sorting for pre-release versions as-is ...

Oh I fully anticipate this will be "adopt over time" seeing as we still have stuff using the legacy snapshot stuff overloading release

Well, sure, we still have EPEL8, too.

it pained me to see a package ending in .fc45.2

I was about to say that's fine but then I realized it doesn't make sense in rawhide

Yeah, you can just bump the release in rawhide.

I like to remain in my fantasy-land where it's already 🪦

yeah but rpmdev-bumpspec choke on weird release tags

Now just imagine a time when we were still supporting EPEL on RHEL4.

I invite people to check koji for openocd

with CVS, right? :P

It's dead to me

luckily for those USians you can walk into the other kind of CVS and get aspirin for that

I didn't hate CVS. It was what we had.

I would not use it today if you paid me.

Man, rhel4 was released 21 years ago ... 👴

On that note ... anything else for the last 5 minutes?

let's talk about... subversion! ;)

Not from me. I'll work on swapping my knowledge back in to get that minor PR done.

Hello

I hope I'm not late. I have a package, I submitted it, it got reviewed

And now?

https://bugzilla.redhat.com/show_bug.cgi?id=2368652

This meeting is about to end, but also isn't the right meeting for you ;)