#7288 Request permissions to untag packages
Closed: Fixed 3 months ago by mohanboddu. Opened 2 years ago by tibbs.

So I know I used to be able to untag a package but now that fails due to me not having autosign permissions (and probably other things).

Today I merged a PR against redhat-rpm-config but wasn't able to test it sufficiently locally due to my local rawhide box not having received gcc 8 yet. I foolishly built it anyway and immediately broke all of rawhide. 100% my fault. It's a one line fix, but I can't untag it and nobody is online with permissions to do so.

Since as of late I have been doing a number of changes to that and other related packages which can potentially break all of rawhide/fedora/epel, it would be useful for me to be able to untag in case something goes wrong.

Edit: I'm guessing that this is a releng thing. I have trouble knowing what's releng and what's infrastructure.


Today I merged a PR against redhat-rpm-config but wasn't able to test it sufficiently locally due to my local rawhide box not having received gcc 8 yet. I foolishly built it anyway and immediately broke all of rawhide. 100% my fault. It's a one line fix, but I can't untag it and nobody is online with permissions to do so.

If you can't verify the changes you're making you should probably be doing a PR in pagure so others that know can review your changes rather than blindly pushing changes, that's why the mechanism was added.

Well, uh, that's exactly what happened. This was actually someone else's PR that I merged. And it had 21 days of review by several people and somehow none of us caught it. I did attempt to verify but it seems that I only noticed the gcc < 8 conflict. I did verify the actual code changes contained within the PR, but missed that one dependency added to the specfile even though of course I did verify that the file being depended upon exists. It was a /bin vs. /usr/bin problem.

So to the matter at hand (the permission request): Should I take that as a no? We did manage to work around the issue because i seems that f28-build has different privilege requirements than f28, so tagging the previous build into f28-build let us build the new package. But it wasn't me who did that, and I'm not sure if I even have sufficient privileges to tag into f28-build (and certainly don't want to randomly test it).

FWIW, I am happy to grant tibbs perms for this. Or create a new perm perhaps and grant it to select folks.

@tibbs I am not sure if you will get the permissions or not, but if I am in your shoes I will just fix the issue and do a spec bump and do a new build but it depends on how small or big of a fix that is.

Yes, of course, if what you say was actually possible then I certainly would have done it and not bothered with worrying about untagging the bad build. But there is a class of errors which prevent you from doing a new build. Perhaps gcc is broken and now cannot rebuild itself. Or perhaps there is an error in a dependency which prevents one of the buildroot packages from being installed. In these cases, you need to be able to tag and untag things.

Certainly more careful testing would help here, but this is rendered more difficult when rawhide as a whole has other issues or hasn't composed in a long time.

In any case, there was a workaround (tagging an old version of the package into f28-build in order to build a new version of the package). I am not sure if that workaround is blessed by releng as a proper way to deal with this, and I'm also not sure what permissions are needed to tag into each of the various tags.

Metadata Update from @syeghiay:
- Issue assigned to mohanboddu

10 months ago

@mohanboddu will talk to koji team to see if something can be done.

Metadata Update from @syeghiay:
- Issue tagged with: meeting

4 months ago

Closing this ticket as there is an alternative to tag older build or rebuild it again with reverting the change.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.

Metadata