In case any of the source files changed, openSUSE Build Service rebuilds the dependent packages regardless of whether that particular modification affects the dependency. This makes our resources footprint bigger (and the electrical power bills higher). It also affects users, because every new package build causes the package manager to include that package in the next update thus consuming network bandwidth and resources of users' computers.
Current OBS controls for package rebuild triggers
It is possible to control dependent packages build triggers on a per repository basis (see OBS build scheduling strategies). You will find an explanation on that page that any setting other than the default, which is "always rebuild", is not safe and should not be used if the packages are to be distributed. Apparently, the concern is more of a "this repository is official/testing" kind.
Which modifications justify rebuilding
First, we need to define the modifications which justify rebuilding the dependencies. This is a list which should be amended by the more knowledgeable on software builds:
new library versions or binary API changes (the latter should always cause the former?)
changes in
#includesfiles (in case of library development packages); it is preferable to verify if the dependencies can build with these modifications sooner rather than later
Possible improvements
Extend the checkin command
I suppose that this is a hard problem to solve automatically, so it is good to start small with some infrastructure to allow managing the dependencies rebuild process. We could add the "don't rebuild/must rebuild dependencies" option to the checkin command.
Make builds reproducible
There are ongoing efforts to get reproducible builds, that is if the source has not changed, then the built package should be exactly equal to the previous build too.
According to osc triggerreason on several packages in the openSUSE Build Service reference instance, quite a few rebuilds were due to md5 sum not matching. If more builds were reproducible that would obviously reduce the total number of builds. More, a reproducible build would (almost) completely remove transitive builds (see the build project attribute).
See the following pages for more information:
Reproducible builds in Fedora (security reasons are discussed more)
Questions
Is there a facility in OBS similar to the Debian's
dh_buildinfo? Would that be useful in OBS? Is there a way to keep that information within the existing infrastructure?How are md5 sums produced?
Resources
osc triggerreason --helposc jobhistory --help
Looking for hackers with the skills:
This project is part of:
Hack Week 10 Hack Week 11
Activity
Comments
Similar Projects
obs-service-vendor_node_modules by cdimonaco
Description
When building a javascript package for obs, one option is to use https://github.com/openSUSE/obs-service-node_modules as source service to get the project npm dependencies available for package bulding.
obs-service-vendornodemodules aims to be a source service that vendors npm dependencies, installing them with npm install (optionally only production ones) and then creating a tar package of the installed dependencies.
The tar will be used as source in the package building definitions.
Goals
- Create an obs service package that vendors the npm dependencies as tar archive.
- Maybe add some macros to unpack the vendor package in the specfiles
Resources
Research openqa-trigger-from-obs and openqa-trigger-from-ibs-plugin by qwang
Description
openqa-trigger-from-obs project is a framework that OSD is using it to automatically sync the defined images and repositories from OBS/IBS to its assets for testing. This framework very likely will be used for the synchronize to each location's openqa include openqa.qa2.suse.asia Beijing local procy scc scc-proxy.suse.asia(although it's not a MUST to our testing) it's now rewriting requests to openqa.qa2.suse.asia instead of openqa.suse.de, the assets/repo should be consistent the format Beijing local openQA is maintaining an own script but still need many manually activities when new build comes, and not consistent to OSD, that will request many test code change due to CC network change
Goals
Research this framework in case it will be re-used for Beijing local openQA, and will need to be setup and maintained by ourselves
Resources
https://github.com/os-autoinst/openqa-trigger-from-obs/tree/master https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin
beijing :rainbow machine
Bootstrap openSUSE on LoongArch by glaubitz
Description
LoongArch is a new architecture from China which has its roots in the MIPS architecture. It has been created by Loongson and is already supported by Debian Ports, Gentoo and Loongnix.
Upstream support for LoongArch is already quite complete which includes LLVM, Rust, Golang, GRUB, QEMU, LibreOffice and many more. In Debian Ports, where the port is called "loong64", more than 95% of the whole Debian archive have been successfully built for LoongArch.
QEMU support is rather complete and stable such that packages can be built in emulated environments. Hardware can also be requested by Loongson on request for free. Access to real hardware is also provided through the GCC Compile Farm.
Goals
The initial goal should be to add LoongArch to OBS and build a minimal set of packages.
Resources
- Introduction to LoongArch: https://docs.kernel.org/arch/loongarch/introduction.html
- LoongArch community on Github: https://github.com/loongarchlinux
- Debian Ports repository for loong64: http://ftp.ports.debian.org/debian-ports/pool-loong64/main/
- Gentoo stage3 for loong: https://www.gentoo.org/downloads/#loong
Results
- An initial set of packages for openSUSE loongarch64 has been successfully bootstrapped
- An OBS project has been set up to build packages for openSUSE loongarch64 with more than 3000 packages being built already
- A work-in-progress guide on how to bootstrap a new openSUSE port from Debian has been created
- A work-in-progress guide on how to add a new target to the openSUSE toolchain has been created
Acknowledgements
- Thanks to Adrian Schröter and Rüdiger Oertl for the help with setting up the FTP space and OBS project
- Thanks to Dirk Müller for the input on how to get started with a new port
- Thanks to Richard Biener for quickly accepting my submit requests to add loongarch64 support to the toolchain
Git CI to automate the creation of product definition by gyribeiro
Description
Automate the creation of product definition
Goals
Create a Git CI that will:
- automatically be triggered once a change (commit) in package list is done.
- run tool responsible to update product definition based on the changes in package list
- test the updated product definition in OBS
- submit a pull request updating the product definition in the repository
NOTE: this Git CI may also be triggered manually
Resources
- https://docs.gitlab.com/ee/ci/
- https://openbuildservice.org/2021/05/31/scm-integration/
- https://github.com/openSUSE/openSUSE-release-tools
Automation of ABI compatibility checks by ateixeira
Description
ABI compatibility checks could be further automated by using the OBS API to download built RPMs and using existing tools to analyze ABI compatibility between the libraries contained in those packages. This project aims to explore these possibilities and figure out a way to make ABI checks as painless and fast as possible for package maintainers.
Resources
https://github.com/openSUSE/abi-compliance-checker
https://github.com/lvc/abi-compliance-checker
https://sourceware.org/libabigail/
Create object oriented API for perl's YAML::XS module, with YAML 1.2 Support by tinita
Description
YAML::XS is a binding to libyaml and already quite old, but the most popular YAML module for perl. There are two main issues:
- It uses global package variables to influence behaviour.
- It didn't implement the loading of types like numbers and booleans according to the YAML spec (neither 1.1 nor 1.2).
Goals
Create a new interface which works object oriented. Currently YAML::XS exports a list of functions.
- The new API will allow to create a YAML::XS object containing configuration influencing the behaviour of loading and dumping.
- It keeps the libyaml parser and emitter structs in memory, so repeated calls can save the creation of those structs
- It will by default implement the YAML 1.2 Core Schema, so it is compatible to other YAML processors in perl and in other languages
- If I have time, I would like to add the merge
<<key feature as an option. We could then use it in openQA as a replacement for YAML::PP to be faster.
I already created a proof of concept with a minimal functionality some weeks before this HackWeek.
Resources
- Work is currently happening on the oop branch
- Experimental release waiting for user feedback: https://github.com/perlpunk/yaml-libyaml-pm/releases
- Diff