[opensuse-factory] verifying OBS builds
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, now that my efforts in reproducible builds for openSUSE have come pretty far [1], I tried to reproduce the official Factory binaries. This already found https://bugzilla.opensuse.org/show_bug.cgi?id=1100488 However, I already encountered one major difficulty. E.g. when building zypper locally and comparing it to the official binary I get Comparing zypper-1.14.6-1.1.x86_64.rpm to zypper-1.14.6-1.1.x86_64.rpm comparing the rpm tags of zypper - -libzypp 12 17.3.1 +libzypp 12 17.4.0 plus some related asm diffs. The problem comes from 'osc meta prj openSUSE:Factory' having <repository name="standard" rebuild="local"> [2] says, this means that when zypper was checked in 15 days ago, it was built with the then-current libzypp-17.3.1 . When libzypp was updated 10 days ago, zypper was not rebuilt. But there are no libzypp-17.3.1 packages available anymore in OBS, so reproducing the original zypper rpm from 15d ago is impossible. What would be the downsides of a rebuild="direct" ? Probably more Factory package rebuilds, more updated rpms shipped to Tumbleweed users using more bandwidth. Not so desirable. Another approach would be to keep old rpms around like with the tumbleweed snapshots from boombatower, but using those in a local osc build is currently hard. And we probably will need to use the _buildenv files to find out the exact versions used for the official build. I could also try to have my scripts rebuild packages that were just updated, so that differences in build dependencies are small. But that is not so much in the spirit of reproducible builds allowing to get identical build output at any time (and on any machine). Are there other ways to approach this? TIA for your input on this topic. Ciao Bernhard M. [1] https://www.suse.com/c/reproducible-builds-in-opensuse-and-sle/ [2] https://en.opensuse.org/openSUSE:Build_Service_Concept_build_scheduling_ strategies -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQRk4KvQEtfG32NHprVJNgs7HfuhZAUCW0AybQAKCRBJNgs7Hfuh ZPvBAKC3xRUzLm6STYZwsFH7zB8hH7dB7ACgxJXxwLMODGrHjZ9lUEOIINEFkrQ= =sF8P -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-07-07 05:24, Bernhard M. Wiedemann wrote:
now that my efforts in reproducible builds for openSUSE have come pretty far [1], I tried to reproduce the official Factory binaries.
However, I already encountered one major difficulty.
The problem comes from 'osc meta prj openSUSE:Factory' having <repository name="standard" rebuild="local">
[...]
Are there other ways to approach this?
I went for another way, that is testing official openSUSE Leap 15.0 binary builds and found that only 403 / 11520 local builds had significant differences (via build-compare). Those bad packages are listed in http://rb.zq1.de/leap/15.0/build-compare-differed-builds-nachbau.txt Most of them were already known to not build reproducibly. I reviewed the remaining ones which found several bugs https://bugzilla.opensuse.org/show_bug.cgi?id=1100488 https://bugzilla.opensuse.org/show_bug.cgi?id=1100520 https://bugzilla.opensuse.org/show_bug.cgi?id=1100677 https://bugzilla.opensuse.org/show_bug.cgi?id=1101262 Then I also had many unsubmitted patches. Some of them were stuck upstream for a year. Many of those are now SRed and linked in https://reproducible-builds.org/blog/posts/168/ The remaining list of diffs that I did not fully understand contains binutils gd (20 bytes at offset 645 in ELF) grabpng (dito) kdoctools (some man/translations diff with 'meinproc5') openssh (.hmac differed - probably from build-id) perl-Wx piglit (probably output depending on CPU-type) python-pyside rustfmt strongswan (.hmac differed - probably from build-id) Of course any of the known-bad monster packages like openjdk, libreoffice or firefox can contain more issues. Alas, those issues are hard to see within the mess. So far, I have not found any traces of backdoors inserted into binaries during the OBS build process. And that is good news. Ciao Bernhard M.
participants (1)
-
Bernhard M. Wiedemann