Hi all,
Last year, discussion happened around "Checking the ABI of
packages submitted
to the updates-testing Fedora repository" on Fedora devel ML [1].
We felt that taskotron[2] will be the best place to run automatic ABI
checks
for a new package update pushed in bodhi for testing against latest stable
package. If any ABI incompatibility is detected, we will provide package
maintainer feedback to review ABI changes, similar to how rpmlint feedback
is given. This will help to ship stable ABI for Fedora packages, reduced
build failures which is seen later in packages depending on it.
I have created a libabigail [3] taskotron task which can be
integrated in
taskotron to perform automatic ABI checks for new bodhi updates. Right now,
this task downloads all rpms with debuginfo for specified package update and
corresponding latest stable package available for that release. Further, it
runs libabigail's abipkgdiff tool for ABI checks. It tells PASSED if no ABI
change occurred, otherwise FAILED and ABI changes log can be reviewed to
ensure changes are ok to go or not.
Source code of libabigail taskotron task can be accessed from
github[4].
Some sample output of libabigail task run on my local machine:
*
http://fpaste.org/349740/
*
http://fpaste.org/349741/
*
http://fpaste.org/349761/
It will be great if someone can review libabigail task and provide
feedback.
Also, I would love to know further steps required to integrate it with
taskotron?
Thanks,
Sinny
Hello Sinny,
thanks for your work and sorry for late response. I'll review your taskotron task and
let you know if there's something that should be changed or not. Afterwards, we will
start mirroring your git repo on our taskotron servers, and patch our taskotron-trigger to
know about task-libabigail. We can then execute it on every new Koji build (or Bodhi
update, your choice). Your task will probably be the first one that we will execute
regularly while not being written and maintained directly by us, so if there are any rough
edges in the process, I apologize in advance :-)
You'll need to have two branches in your git:
master - this will be used on our production server
https://taskotron.fedoraproject.org/
develop - this will be used on our dev and staging server
http://taskotron-dev.fedoraproject.org/ and
https://taskotron.stg.fedoraproject.org/
We will regularly pull your repo, probably with a cron job for now. The cron job is not
yet written and the periodicity is not yet decided, but you can track it here:
https://phab.qadevel.cloud.fedoraproject.org/T767
You need to decide whether it is better to run libabigain against every new Koji build, or
just against every new Bodhi update. From a quick look, I think it makes more sense to run
libabigail on every new Koji build, so that people can see the results even before
creating the update (that requires looking into ResultsDB manually at the moment). If we
run it on every Koji build, the results will still show up in Bodhi - Bodhi should query
ResultsDB and show the results for those particular builds present in the update. (We
might need to teach Bodhi about libabigail existence, I'm not sure). Ultimately
it's your choice, what makes more sense for your check.
Please also create a wiki page at
https://fedoraproject.org/wiki/Taskotron/Tasks/libabigail similar to these
https://fedoraproject.org/wiki/Taskotron/Tasks/depcheck
https://fedoraproject.org/wiki/Taskotron/Tasks/upgradepath
linked from
https://fedoraproject.org/wiki/Taskotron/Tasks .
We try to have at least some basic documentation and FAQ for our checks in there.
Currently it's not very discoverable (we should link to it at least from ResultsDB,
which we currently don't) and the location can change, but at least it's a link we
can give to people when asking basic questions about one of our tasks. Also, since
you're going to maintain the task and not us, please include some "Contact"
section where to post feedback or report bugs (e.g. github issues page). If people ask us
about the task and we don't know the answer, we will point them to that wiki page.
Can we please continue this discussion in qa-devel [1] mailing list? We can discuss more
implementation details in there, and I'll post my review findings in there as well.
Thanks,
Kamil
[1]
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraprojec...