#346 task-abicheck compares exactly the same builds on rawhide
Opened 7 years ago by kparal. Modified 6 years ago

If you look at any abicheck checks run on rawhide packages, you'll see that it downloads the same RPMs twice, and compares them. Of course no change is found. Example (compare the numbers):

* No ABI change between RPM packages libarchive-3.2.0-3.fc25.x86_64.rpm and libarchive-3.2.0-3.fc25.x86_64.rpm

https://taskotron-dev.fedoraproject.org/artifacts/all/b3718694-1b2b-11e6-8617-525400571835/task_output/libarchive-3.2.0-3.fc25.log

The reason is that there is only one repo on rawhide. Packages are build in koji directly into the rawhide tag (f25 tag at the moment). When the koji directive is asked to download the koji build, and the latest stable build, both points to the same packages, because the latest build immediately superseeded the previous build.

There is one exception, though. If packages are built into a side-tag, the comparison is performed correctly (the build in a side-tag against the build in rawhide repo). Example here:

* No ABI change between RPM packages openldap-2.4.44-1.fc25.x86_64.rpm and openldap-2.4.44-2.fc25.x86_64.rpm

https://taskotron-dev.fedoraproject.org/artifacts/all/3968d842-1a55-11e6-a41e-525400571835/task_output/openldap-2.4.44-2.fc25.log

As you can see [[http://koji.fedoraproject.org/koji/buildinfo?buildID=763294 | in koji]], the latest openldap build is in f25-perl koji tag, instead of f25. That seems helpful, but it might actually be a bug. I assumed we're listening for new koji builds only for the releases/tags supported by us, but we seem to be listening for much more. We need to decide whether we want that.

Overall, running abicheck on rawhide builds seems currently to be pointless, except for some very specific cases (side tags). We either should fix it somehow, or stop running it on rawhide. I'll talk to @sinnykumari about this, I imagine she assumed we would be able to compare the latest koji build with the previous koji built even on rawhide. Or not, let's ask.

Fixing this on rawhide means we have to reimplement our koji directive somehow. It should probably know, that for rawhide, it can't look into the specific koji tag and pick the build, but it has to look into the tag history, find the previous build, and pick that one. Of course, at that point of time, such a build can be already deleted. Much fun to be had.

For the moment, it probably makes sense to stop scheduling abicheck for rawhide, until we resolve this.


After talking to @sinnykumari and @dodji yesterday, the easiest way forward seems to be comparing the new rawhide build with the previous rawhide build we find in koji (but no longer in the repo/koji tag).

See this ticket#12972, @sinnykumari says this might be fixed. But I have no idea what the reason would be, we should look into it.

Login to comment on this ticket.

Metadata