#12743 Please add lua-cqueues and lua-basexx to epel10 tag
Closed: It's all good a month ago by jruzicka. Opened a month ago by jruzicka.

Hello,

as with every EPEL release there is no automatic mass rebuild (like on Fedora since dawn of time), so all contributors are forced to manually build all packages they maintain if they want them available from EPEL 10.

I did as I would in any other project / workflow:

git checkout rawhide
git pull
git checkout -b epel10
fedpkg mockbuild
git push
fedpkg build

but even though the push of epel10 branch was allowed by git, SOMETHING didn't happen which is obviously handled by fedpkg request-branch epel10 (which I always forget about because I don't understand why this is even needed) so now koji build fails with

BuildError: package lua-cqueues not in list for tag epel10.1-testing-candidate

When I try to redo the arcane process, I get error:

> fedpkg request-branch --no-git-branch epel10

Requested branch "epel10" already exists. Skipping the operation.

I did this for lua-cqueues and lua-basexx before I realized some arcane process is needed. I did the rest of lua-* packages with fedpkg request-branch epel10 and they built fine.

Would you please allow Koji epel10 builds to pass for lua-cqueues and lua-basexx or tell me howto undo my grave mistake of pushing epel10 branch into disgit?

bonus questions

Why does fedpkg request-branch refuse to work even with --no-git-branch argument? I just want it to do... whatever it needs to do (beyond branch creation) so I can build packages (even though the existence of epel10 branch in distgitis sufficient declaration of such intent).

Why doesn't pushing epel10 branch into distgit trigger whatever is needed to build packages for epel10?

Why is a arcane fedpkg request-branch invocation requiring pagure token even needed for unambiguous operation of creating well-named epel10 branch?

Why does distgit allow epel10 branch push when it results in a doomed state I wasn't able to recover from?

Why waste contributors time with requiring manual branch creation and manual fedpkg build while there is a well-tested automated system for Fedora branches? Maintainers should spend their time on fixing real packaging issues, not performing arbitrary infuriating processes to do what could be easily automated.

Cheers,
Annoyed Fedora/EPEL Contributor


Metadata Update from @james:
- Issue tagged with: low-gain, low-trouble

a month ago

Lots of questions. You might want to take a quick look at: https://fedoraproject.org/wiki/EPEL/FAQ#Questions_specific_to_existing_Fedora_contributors

I've read that before, it almost answers one of my questions.

These were meant as a feedback for the record. tl;dr it's silly that just pushing epel10 branch isn't enough to start building.

Anyway, something happened somewhere and

fedpkg build

worked today. What exactly happened remains a mystery, but I'm closing this.

Chaos Reigns

Metadata Update from @jruzicka:
- Issue close_status updated to: It's all good
- Issue status updated to: Closed (was: Open)

a month ago

Just to add some info here:

"as with every EPEL release there is no automatic mass rebuild (like on Fedora since dawn of time)"

New RHEL releases happen every 3 years. (used to vary, but it's 3 years now). In 3 years... lots of things change. Mass branching everything in epel9 for epel10 would be a lot of wasted effort as some packages no longer exist, or need different things, or maintainers don't want to commit to maintaining them for another 10 years. So, it's opt in.

new branches should be made with fedpkg request-branch. Even for Fedora. If you have a new fedora package it only gets a rawhide branch by default and you need to request others. That process adds the actual package to koji so it can be built. The no-git-repo thing you did most likely triggered that process (even if it didn't happen instantly).

New RHEL releases happen every 3 years

Yeah and because I never need to request fedoraX branches I always forget that I need to fedpkg request-branch epelX in those 3 years time. I use lots of different systems and workflows across distros and I just always feel shot in the foot when I can't build after pushing the new epelX branch I created and pushed manually as I would do in any other git-based system, for example Debian Salsa (gitlab).

But no, there's special command I need to re-discover that requires special pagure token that I always need to renew just for this purpose.

The no-git-repo thing you did most likely triggered that process (even if it didn't happen instantly).

It refused to do anything due to branch already existing or so it reported, I even hand-crafted a query in hopes to trigger it.

I hit similar doom state with knot-resolver some time ago and then it magically fixed itself after some time... I thought there is some process in the background fixing these failures, but maybe the fedpkg request-branch re-run triggered it (tagging I assume) even though the bot reports error. Truly mysterious, magical even.

Anyway, I'm just saying pushing epelX branch should trigger the same thing(s) that fedpkg request-branch does and enable koji build. Maintainer pushing epelX branch is clear intent and commitment to build for that branch in koji.

This would make the process easier for contributors, eliminating a needless step with a needless token and an opportunity to shoot oneself into foot.

Just my 0.02 CZK

Aight, hopefully I remember for RHEL 11

Yeah, the way it works is that the scm-request ticket emits messages on our message bus and the process that adds packages listens to that.
So, even though it didn't look like it did anything, just filing that ticket caused it to get a message about that package and fix things.
There's also a daily runner that syncs everything up, it might be that is whats causing the delay.

In any case, yes, it could be better. In some kind of world where we have lots of people/time we could make it better... I'm not sure this is going to be very high on the priority list tho.

Log in to comment on this ticket.

Metadata