Meeting started at 2026-07-20 15:03:47 UTC

The Meeting name is 'RELENG (2026-07-20)'

!chair nirik jnsamyak patrikp

The Meeting Name is now releng

Hello.

morning

!hi

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

So, mass rebuild has finished. There are a couple things left to do that I'm trying to take care of. The problematic builds Adam mentioned should be untagged and we should be good to run the script.

So, mass rebuild has finished. There are a couple things left to do that I'm trying to take care of. The problematic builds Adam mentioned should be untagged and we should be good to run the mass tagging script.

Which is correct, I actually don't have that permission and usually use the --force flag when tagging/untagging builds.

I tried doing so, but I get this error:

ERROR: User patrikp lacks f45 access permission. Reason: tag requires autosign permission

cool. ;)

ah yeah, due to perms on the f45 tag you will need that permission.

So, may I get that perm? Or shall we somehow rework the script so it's possible to pass --force flag?

I'd rather just get the perm but it's always a little bit weird asking for more power.

yes, go ahead and add that permission... or I can...

0/

I can add it for myself? I suppose because I have some powers because of sysadmin-releng?

yes just add perms

you have perms because you have admin perms in koji. ;)

Haven't considered that.

Targets that build into this tag:

```

Inheritance:

Groups: appliance-build, build, kiwi-build, livecd-build, livemedia-build, srpm-build

Required permission: 'autosign'

Tag options:

mock.new_chroot : 1

mock.package_manager : 'dnf5'

Current repo: no active repo

f45-kiwi (f45-kiwi-build, repo#6676898: 2026-07-20 06:06:30.758433+00:00)

f45-image-builder (f45-image-builder-build, repo#6676928: 2026-07-20 12:43:27.538512+00:00)

you can always check with:

```

Tag: f45 [128147]

Arches: None

admin allows you to add/remove permissions.... from anyone. Including yourself

That'd be `koji grant-permission autosign patrikp`?

yep

That seems to have done the trick and the mass tagging script appears to be running. Woooo. 🎉

excellent.

cool

Once it finishes I'll send out the final email. Also, thank you kindly to both for feedback on the SOP, I incorporated it and left a few more questions, once those are out of the way we can get it merged.

That is all for init from me. Does anybody else have anything?

nothing from me

Moving on...

Any volunteers for next week's chairing duties?

mostly on pto for next monday

I should be around and this is no problem for me, I can take it again then.

F47 keys are added to fedora-repos and are available in updates-testing

So, after the rebuild which will hopefully be wrapped up soon, next on the agenda is:

I can make those, or jnsamyak can...

then we need package updates.

We already have a ticket for this.

https://forge.fedoraproject.org/releng/tickets/issues/13407

It's also already added to the next sprint and Samyak already assigned himself. So we should be good.

on me dont worry

ok, cool. Let me know if I can help with anything.

But I don't think we have a ticket for that yet and I also don't see an SOP.

Re-sign F44 content with F45 key, scheduled for Tue 2026-08-04

I also see:

it is already in mass-branching sop

and that seems off by one

I thought so too.

it might be good if it was a seperate doc, because it's done before the other stuff.

file that for aiofe!

file that for aoife!

Ah, right.

https://docs.fedoraproject.org/en-US/infra/release_guide/sop_mass_branching/#_mass_re_signing_one_week_before_branching_day

I am +1 on this being a separate SOP.

I can take it out to another document, no biggie. Any other use case to mention?

hopefully before too long if we can ever get siguldry installed this will just be a lot easier. Just modify config and wait

Use case?

https://github.com/fedora-infra/siguldry/issues/199 if anyone has more input on it.

As in, task?

Wanted to check if anything worth mentioning one use case of that being mass branching etc

i forgot that reminds me i had two reviews for init:

- https://forge.fedoraproject.org/apps/toddlers/pulls/429 (test check can be ignored)

- https://forge.fedoraproject.org/releng/tooling/pulls/13029 (waiting for +1 on this, need to merge and close out the issue)

I'm not sure I follow? I meant that it would be nice to be seperate so you know it's the next step/thing to do and don't go to the mass rebuild and say 'oops, should have done that a week or two ago'

on the toddlers thing... we need to coordinate that right? we shouldn't merge it until we have fedpkg sending to forge and such... otherwise if we merge it, it will stop processing the old place? or does it do them both?

Also, the sidebar in our docs is now chronologically ordered, it makes sense that each release schedule action/task has a corresponding entry there. For future onboarding too.

On the composeinfo... it seems fine, but it's a lot of code, so I haven't reviewed it closely. ;)

so, probibly ok to just merge and fix if it blows up...

yeah it is more of a wrapper copied from internal redhat folks compose file

and tweaked for our needs

that's all

okayy

make sense, sorry slow net here, govt is playing tricks here

no problem. I'm low on coffee here. ;)

correct but still want to have reviews done before so i can just merge and test it out once fedpkg changes are in. scm is rewritten for new forge

so it should stop that support

so it should stop that support (pagure one)

ok, fair enough

hum, it's anoying how messy this is going to be

i see mass tagging script ran, so my changes were alright after all! tagging script was reporting some error last time we ran it

oh well, we have to have a flag day I guess...

I can only imagine

yes I want to do that once, I have an optimistic prs reviewed at both ends

I guess we can't schedule the flag day until we know when fedpkg will update...

yeah

I am hoping to have the PR ready for review relatively soon.

That's all I can say for now.

sure, thanks

I was thinking about how messy it's going to be yesterday at night in bed when trying to fall asleep.

has to be: land fedpkg changes, update/build all the fedora packages for it. Schedule flag day, on flag day, push all fedpkg fedora packages to testing and ask maintainers to update and hopefully push to stable soon, swich toddlers over, close old one so it errors...

or something like that

yeah around that, I can make a more concrete plan, once lets get out changes

I need to go feed cats real quick, back in a few.

Sounds like a reasonable plan to me. 👍️

i suppose it will be one good day of getting it right like mass branching but that should be it;

As reasonable as can be expected.

We can put a thing about it to status.fpo and hopefully get it ironed out.

only fedpkg chage takes a lot of time to put to a release, we need to talk to maintainer to be ready to patch things up that day if needed

Is there anything else for upcoming actions?

not from me

thanks for running the meeting today - 3 percent left not sure enough to squeeze to the end

I had a thought while feeding cats:

If we want to have the old data from the pagure scm-requests repo, what we should do it not migrate it until everything is using the new one and then migrate it over and archive it. Otherwise we run into more sync issues...

We talked about this with Samyak. We have the repo already migrated (set to private) for testing purposes, but the plan is, once everything is in place and confirmed working, to delete it and migrate again. Is that what you had in mind?

hmm so one question we migrate the older one in an archived- name?

yeah, delete that and migrate again and just archive it.

or -pagure in the name or something I guess?

sure can be done but as soon as we merge toddler changes and deploy it the pagure one will ayways be obsolete

yep.

it would just be for history in case we need to look up some request or something...

Pagure is eventually supposed to be turned off completely? Is there a timeline?

can be done sure

it's supposed to be read-only at the end of the month, but yeah, should be around for a while after that, but someday it will go away probibly.

just nicer to have everything moved we care about if we can

OK, I think that is all that we had on the agenda for today. Any objections to closing this out a few minutes early?

sounds fine to me.

sounds good

and hey my thinkpad didnt dissapoint

nice