← Revision 9 as of 2020-05-15 06:50:26
bls code migrated to salsa
|Deletions are marked like this.||Additions are marked like this.|
|Line 4:||Line 4:|
|Line 12:||Line 13:|
|Line 20:||Line 22:|
|Line 24:||Line 27:|
|Line 28:||Line 31:|
For aeons, build logs were solely under the evil yoke of the buildd admins. Now we want to share the fun, mostly with automatic string processors. So, what can we do with build logs? Per default, they can be splitted into two separate categories:
Success is great, but sometimes it's the wrong kind of success, so we might want to add a bit of automatic checking here. There were some efforts to change this (for example http://people.debian.org/~dannf/check-implicit-pointer-functions), but there are still some things on the todo list:
- Check for other compiler-warnings that are sure signs of a problem
- Check the list of changes at the end of the build log if any "weird" changes popped up, best done by comparing the build log to the .debs in the archive)
- Check builds in dirty chroots (like Sesse suggested), possibly doing one build in a dirty and one in a clean chroot on the Grid5000 by Lucas and then diff the Depends line
- Check for -lstdc++, suggest using g++ as a linker instead.
Failure is also great, otherwise the Ubuntu people wouldn't look so happy. So, what can we do with failed build logs?
- Filter out ICEs, so that we can either kick the buildd admin to update the installed gcc or file bugs against gcc
- Check logs for signs of a broken chroot (missing /proc, can't create new devices, ...)
- Filter out those packages that fail due to an uninstallable (but available) build-dep. Then couple the list of uninstallable packages with the EDOS installability data and get a free list of give-back candidates
- Filter out linking issues.
At the moment, filtering the failed builds is almost done. Some code is still needed to determine give-back candidates from edos, expect it soonish.
Build log linting is implemented and running here:
Code is available here: