Meeting started at 2026-06-22 15:00:03 UTC

The Meeting name is 'RELENG (2026-06-22)'

!chair nirik jnsamyak patrikp

The Meeting Name is now releng

0/ I'm here, sorry for the slow day today, I'm still struggling to think what did I eat, to have this nasty stomach bug :/

Hi. 👋

morning

I see folks are back from flock, I hope all had nice time

I'm almost done reworking the end of life SOP. The changes are a little more extensive than originally anticipated. I will open a PR very soon and ask for review.

I have a couple of quick points for init.

After this my highest priority will be the scm-requests migration.

And I will very likely be on PTO July 2nd to 7th.

Oh please have the migration is priority

Oh please have the migration at priority; docs can be reviewed, pagure is getting decomissioned soon :(

Yup, I wanted to ask for a couple of pointers. I want to get it done this sprint.

!releng 13369

● **Last Updated:** a week ago

**releng/tickets #13369** (https://forge.fedoraproject.org/releng/tickets/issues/13369):**[ fedora-scm-requests ] - Update fedpkg**

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

● **Assignee:** patrikp

Could more context be given for this? Here's the repo:

https://forge.fedoraproject.org/packaging/fedpkg

But I'm unsure what things need to be taken into consideration.

Second thing, gotmax raises a good point about Forgejo actions and I was wondering if you had any thoughts on it:

https://forge.fedoraproject.org/releng/tickets/issues/13370#issuecomment-823064

right now fedpkg files tickets/requests in pagure.io... it needs to file in forge, but... it's also tricky because you can't just change it unless you have the new processing all working... and then you have to wait for maintainers to update...

Yeah we could it testing it in staging no? But yeah needed to be done anyways before pagure goes away

BTW, we also have https://forge.fedoraproject.org/releng/tickets/issues/13108 so perhaps we should close one as a dupe? or are they different levels?

i think the majority of this migration is updating fedpkg

I think the one you linked is a "user story" and the other ones are the actionable tasks. It is done this way on purpose.

if that is done, we can get others things done

I'm not sure about the actions thing. I kinda agree with gotmax23 on that... thats jednorozec's plan... so he would be the one to advocate for it.

This is an EPIC, and we have creates short actionable items in terms of those tickets

ok, fair enough

This is an EPIC, and we have created short actionable items in terms of those tickets

Yeah gotmax requests seems valid, it is not set in stone, we can always bring and work on better solutions if it is there.

actions seemed to be a quick solution to it while filing that ticket

What other options are there that could be explored?

sure, but adjusting the toddler could work too... and then it's more isolated.

just modify the toddler to process both pagure.io and forge ones, get it all working, then switch fedpkg, then drop pagure.io handling.

toddlers

↓

DistGit

↓

Ticket Created

↓

Fedora Messaging Event

Instead of

Ticket Created

↓

Forgejo Action

↓

DistGit API

We Could do:

nirik: thoughts?

yeah, basically the same as it is now with pagure, just adjusting the toddler.

Might be easier. Dunno.

yes should be a good approach

https://forge.fedoraproject.org/apps/toddlers/src/branch/main/toddlers/plugins/scm_request_processor.py

Is it this one?

we could always move it to actions later if there were advantages there.

yep.

OK, thanks for the idea, I'll look at it. In any case, that's all I had for init. Anything else?

Yeah but I think jednorozec wanted to minimize toddlers depdendency on thr process

but this also works

Well the biggest advantage is to not depend on toddlers...

But yeah migration priority before any ops.

well, moving it to actions means actions are critical path now, and have to be up all the time. ;)

well, we depend on toddlers for a lot already?

And my plan is to slowly get rid of the dependencies

ok, but we need to be careful that whatever is gotten rid of is at least as reliable/secure as what it's replacing.

Let's move on?

I might be shifting that day so might be on PTO

I can take it and I'll be away the Monday after that.

You want July 6th?

hehe i can do that one

sure

Mass rebuild is approaching. We discussed with Samyak that I could be the one to take responsibility for it this cycle, if that's OK with everyone.

release process starting soon

yeah go ahead, we will be there in background

in case stuff happens

sounds good. Happy to help out any way I can

Nice, thanks. I'll prepare the ticket in advance so that we will know it's planned work at the time of sprint planning.

Soon enough there will also be "F47 keys are added to fedora-repos and are available in updates-testing" and mass re-signing.

I hope to work on deploying the new siguldry in staging soon... not sure it will be in prod by then, but we will see...

Anything else that needs to be said about upcoming actions?

Long term FTBFS is coming up soon. I see https://src.fedoraproject.org/rpms/pesign is in that list.

Oh, and I see the scm requests thing was already discussed, didn't see i was mentioned

ha, fun.

But yeah, moving it to Forgejo Actions seems questionable

I wouldn't mind skipping the tickets section and hearing what you have to say about it.

To me it kind of sounds like we should decide it before commencing the actual migration, or?

What I have to say about SCM requests?

Yes, in general, or specifically about the Forgejo actions, CI, toddlers.

odd. There's no FTBFS bug?

Maybe SRPM build failed?

But re. scm requests, am I missing some context here? Is this "there's something wrong with toddlers" or is it "we just want to try out Forgejo Actions?"

jednorozec had this to say regarding toddlers. I would be glad to hear more about the reasoning too.

From my perspective, storing secrets in Forgejo Actions is less secure than the current approach and it sounds like switching to it would be more work than just adjusting the existing toddler code to react to Forgejo ticket messages?

The distgit admin token that would need to be stored in the repo's secrets to create projects on distgit has a lot of power

So if someone exfiltrated it, that would be quite bad...

To me, these sound like words of reason.

Let's move on?

Nobody else has something to say? What is your take on this Samyak? Not sure the migration can move forward without this being decided.

I was hoping for some more discussion on it because I'm unsure about how to approach it.

I could give advice on how to avoid the worst security issues (linting with zizmor, avoiding unsafe usage of `${{ }}` templating in shell code, managing permissions to the repository that has the workflow, etc.) but it'd probably better to stick with the current system if possible

I could give advice on how to avoid the worst security issues (linting with zizmor, avoiding unsafe usage of `${{ }}` templating in shell code, managing permissions to the repository that has the workflow, etc.) but it'd probably be better to stick with the current system if possible

re: pesign... I filed https://bugzilla.redhat.com/show_bug.cgi?id=2491392 on it. It really does fail to build. I wonder if it wasn't filed because it's a package we explicitly exclude from mass rebuilds.

I think there are a lot of moving parts to this, and not just this. Firstly, we covered toddlers vs actions above, and the fedpkg changes need to be addressed first. And yeah, the toddler seemed to be a more reliable solution - but we can discuss it further tomorrow and try to research more; there should be a way to mitigate things through actions as well.

I think there are a lot of moving parts to this, and not just this. Firstly, we covered toddlers vs actions above, and the fedpkg changes need to be addressed first. And yeah, the toddler seemed to be a more reliable solution - but we can discuss it further tomorrow and try to research more insteading of finding solution on meeting we need to weigh in what can be a better solution; there should be a way to mitigate things through actions as well.

In general toddlers was basically "missing pagure features" fix. We are pulling together a bunch of functionaly into yet another app and codebase that needs to be maintained.

THere have been multiple issues with us forgeting to update something in toddlers...

well, toddlers was 'operate on message bus messages' really.

I am not saying that actions will fix everything. But When we have the chance, especially in this case where ticket is the source of action. Why not?

I mean if you want to get rid of toddlers, this could be re-written as a Forgejo webhook also

there's a bunch of things toddlers does...if we are talking about getting rid of it, we need a larger conversation, it's not just doing releng stuff.

It can be replaced in multiple ways, yeah. i am okey with keeping it as it is, its just unecessary dependency and maintanance.

Yes there is a bunch of things, but when you look at the codebase scm-requests is becomming the biggest in there.

sure, likely because we do a lot of checks to make sure the request is proper...

Yup, and that was why I mentioned it migh be a good idea to "just" reuse the codebase and put it into the actions.

since we are time constrained, it might be best to just adjust the toddler for now and look at actions after?

And we dont have to replace it, this was just an idea because the migration has to happen. And I put it in the backlog some time ago...

so sure, if updating toddlers is the easiest way to do the migration...

I like the sound of this. Does anybody strongly disagree?

yeah, I don't know if thats easiest, but it seems like it might be...

Thanks for the input.

A ticket or two? Open floor? Wrap?

not much time left...

Yup.