tibbs reported a new issue against the project: `releng` that you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
pbrobinson added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
tibbs added a new comment to an issue you are following: `` 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). ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
kevin added a new comment to an issue you are following: `` FWIW, I am happy to grant tibbs perms for this. Or create a new perm perhaps and grant it to select folks. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
mohanboddu added a new comment to an issue you are following: `` @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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
tibbs added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
The issue: `Request permissions to untag packages` of project: `releng` has been assigned to `mohanboddu` by syeghiay.
syeghiay added a new comment to an issue you are following: `` @mohanboddu will talk to koji team to see if something can be done. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
mohanboddu added a new comment to an issue you are following: `` Closing this ticket as there is an alternative to tag older build or rebuild it again with reverting the change. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288
The status of the issue: `Request permissions to untag packages` of project: `releng` has been updated to: Closed as Fixed by mohanboddu.
rel-eng@lists.fedoraproject.org
-
Jason ティビツ -
Kevin Fenzi
-
Mohan Boddu
-
Peter Robinson
-
Suzanne Yeghiayan