I noticed on the packager dashboard that I have a package that was failing for EPEL 7[1] and I have since fixed it, but I don't need to build a new package and Koschei hasn't attempted a rebuild since 6/29.
While I could just ignore it, I was wondering if there was a way to force a rebuild? I see the priority field but I don't have any reference for what a good value would be, it's not particularly intuitive.
Thanks, Richard
[1] https://koschei.fedoraproject.org/package/OpenColorIO?collection=epel7
On Sun, Sep 4, 2022 at 3:27 PM Richard Shaw hobbes1069@gmail.com wrote:
I noticed on the packager dashboard that I have a package that was failing for EPEL 7[1] and I have since fixed it, but I don't need to build a new package and Koschei hasn't attempted a rebuild since 6/29.
While I could just ignore it, I was wondering if there was a way to force a rebuild? I see the priority field but I don't have any reference for what a good value would be, it's not particularly intuitive.
You can set an arbitrarily high number for the "Manual priority" to have the package move to the top of the rebuild queue. This value is automatically reset to "0" when the next scratch build is triggered by koschei.
Fabio
On Sun., Sep. 4, 2022, 9:27 a.m. Richard Shaw, hobbes1069@gmail.com wrote:
I noticed on the packager dashboard that I have a package that was failing for EPEL 7[1] and I have since fixed it, but I don't need to build a new package and Koschei hasn't attempted a rebuild since 6/29.
Koschei builds from the last srpm, not from dist-git, so there's no point in triggering it if you haven't done a build.
https://github.com/fedora-infra/koschei/issues/276
While I could just ignore it, I was wondering if there was a way to force a rebuild? I see the priority field but I don't have any reference for what a good value would be, it's not particularly intuitive.
Thanks, Richard
[1] https://koschei.fedoraproject.org/package/OpenColorIO?collection=epel7
-- Elliott
On Sun, Sep 4, 2022 at 2:11 PM Elliott Sales de Andrade < quantum.analyst@gmail.com> wrote:
On Sun., Sep. 4, 2022, 9:27 a.m. Richard Shaw, hobbes1069@gmail.com wrote:
I noticed on the packager dashboard that I have a package that was failing for EPEL 7[1] and I have since fixed it, but I don't need to build a new package and Koschei hasn't attempted a rebuild since 6/29.
Koschei builds from the last srpm, not from dist-git, so there's no point in triggering it if you haven't done a build.
Well that makes Koschei far less useful than I thought. I read through the ticket so I somewhat understand the issues, but it really needs to be "fixed".
Thanks, Richard
I was able to fix my EPEL 7 package and performed a successful build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2058266
So I forced a Koschei build to clear the error, but it still built the PREVIOUS SRPM: https://koschei.fedoraproject.org/build/13643482
???
Thanks, Richard
On Mon, Sep 5, 2022 at 6:00 PM Richard Shaw hobbes1069@gmail.com wrote:
I was able to fix my EPEL 7 package and performed a successful build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2058266
So I forced a Koschei build to clear the error, but it still built the PREVIOUS SRPM: https://koschei.fedoraproject.org/build/13643482
IIUC, koschei takes the latest SRPM from the *buildroot*. So if you didn't file a buildroot override for the successful build, it cannot see it until it is pushed to stable.
Fabio
On Mon, Sep 5, 2022 at 11:18 AM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Sep 5, 2022 at 6:00 PM Richard Shaw hobbes1069@gmail.com wrote:
I was able to fix my EPEL 7 package and performed a successful build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2058266
So I forced a Koschei build to clear the error, but it still built the
PREVIOUS SRPM:
IIUC, koschei takes the latest SRPM from the *buildroot*. So if you didn't file a buildroot override for the successful build, it cannot see it until it is pushed to stable.
Ahh... Oh well, I think I'll just ignore it then and it will eventually fix itself :)
Thanks, Richard