Learn more about these different git repos.
Other Git URLs
There is obviously something wrong in this process.
Probably it affected other tickets as well.
Looks like the script thinks "rawhide" is a modular branch and refuses to do anything without "sls" field. fedpkg in fedora was updated to submit request-repo tickets with "rawhide" as branch name already, which breaks things ...
Note that I am not aware that rawhide branch would work. So the tickets should not be processed yet (until something was already changed that I am not aware of): Instead, fedpkg needs to request master for the time being.
I've karmed down all the fedpkg updates, but the f33 one was already pushed after just 3 days in testing, sigh :(
There is a fedpkg feature, that was recently released and the issue is related to this, obviously.
I understood, that it should have been released before Jan 27th:
But I presumed that fedora-scm-requests is prepared for it. Was or wasn't it? Or is there just an issue with SLS?
The switch has not happened yet, so the requested branch should be "master" until the switch is made.
I was able to get my request through by manually editing the "branch" value in the JSON from "rawhide" to "master" and reopening the ticket.
So it looks like the script handling fedora-scm-requests is definitely not ready for "rawhide as default" yet, and probably shouldn't be, until the switch is made.
In the meantime, if you are hit by this, you can edit the request to say "branch": "master" instead of rawhide and reopen it.
Ok, so what I can do now is to make a patch for f33 reverting the last change.
And next, who could tell me the info when releasing the feature is safe?
I'm not sure reverting it again is a good idea either. Maybe fedscm-admin script can be adapted to change "rawhide" to "master" automatically, and make the switch on the "creation" side only, once everything is ready?
I also assume the "master" -> "rawhide" switch will be done only after the mass rebuild is done, so Jan. 27 sounds unrealistic to me.
I have no problem agreeing with you, @decathorpe. Changing the branch name on "server" side looks easier to me than on a client-side. But heavily depends on how fedscm-admin maintainers are looking at it.
Are you involved in it?
I reported this here:
Metadata Update from @mohanboddu:
- Issue tagged with: dev, high-gain, high-trouble
Yes, please don't revert fedpkg changes, we will get fedscm-admin able to handle both and switch when we are ready on the server end.
@kevin, I didn't touch fedpkg updates.
As I already mentioned in https://pagure.io/fedscm-admin/issue/57, I am sorry that I rushed. I like the "server" solution.
After the fix in fedscm-admin is applied, I will try to renew the process of releasing the rest fedpkg packages in Bodhi (some has negative karma now).
I'll revert my negative karma once ready.
@onosek I'd also like to kindly ask whether you could do future fedpkg updates in latest stable Fedora with a higher karma limit than 3. Fedpkg is a tool used by packagers, they are more likely to test and provide karma, usually there is no rush to ship new fedpkg fast. I suggest 8+. Thanks
@churchyard Ok, I understand. I will try not to forget on it during the next upgrade onwards. The latest update was approved very quickly.
This update should fix it in f33 https://bodhi.fedoraproject.org/updates/FEDORA-2021-de40e02568
Is @limb running Fedora 33?
I am. Shall I upgrade and resume processing?
Let's give it a try. We can edit https://pagure.io/releng/fedora-scm-requests/issue/31905 to say rawhide, that should give us a hint whether it works.
Invalid body, missing required field: sls
I'll revert my negative karma once ready.
@churchyard May I ask you for reverting karma? It seems it is the right time.
My latest request used 'master' and worked, but it forgot to add the package to the right tags so it could be built on Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=61159250
Requests for other branches worked correctly and are building right now.
We had a 'event' with our rabbitmq cluster, so the process that listens for new packages and syncs them to koji wasn't working. I have done a manual sync and restarted that process. So that build should work fine now.
Metadata Update from @churchyard:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
to comment on this ticket.