Reproducing Trisquel

3 respuestas [Último envío]
jas
jas
Desconectado/a
se unió: 08/21/2018

Hi. I have been working on reproducible builds of Trisquel aramo, and were wondering if others would like to help on this? I now get a number of successful 100% reproducible builds, so at least there is something working here. There are also a bunch of unreproducible build logs with diffoscope output for anyone to investigate further...

https://gitlab.com/debdistutils/reproduce-trisquel

Happy hacking,
/Simon

PublicLewdness
Desconectado/a
se unió: 03/15/2020

I'm no coder but I'll share the link on social media. Good luck regardless.

quidam

I am a member!

I am a translator!

Desconectado/a
se unió: 12/22/2004

Hi Simon, this sounds very interesting and something that we should do as part of the project self-review. I suggest you put the repository in our own gitlab instance, to get that process going. We could also set up a jenkins task to do these tests in our own build servers when they are idle. would you want to work on that?

What environment do you use to run the build tests? For the packages that fail, do they also fail upstream or is it a problem we are introducing?

Thanks for looking into this!

jas
jas
Desconectado/a
se unió: 08/21/2018

Hi - thanks for invitation! I'm happy to work on this "within" the project too. It is nice to have external independent reproducability too, though.

The projects consumes around 7GB of gitlab.com storage quota, which is growing continously (for various reasons), and a lot of shared gitlab runners right now (approaching 10.000 CPU minutes already). My plan was to setup my own gitlab-runner builder on own hardware, but I haven't done so yet because the shared runners were working so well. Eventually we shouldn't rely on gitlab.com though. Is this okay to move to gitlab.trisquel.org? The project is rapidly moving, so I'd like to continue develop things on gitlab.com for a while, but expect that this will go into maintenance mode soon, and could be moved to gitlab.trisquel.org then as an "official" project.

The build is running in a docker-container derived from trisquel: https://gitlab.com/debdistutils/reproduce-trisquel/-/blob/main/trisquel-aramo/Dockerfile

The tooling is launched from .gitlab-ci.yml: https://gitlab.com/debdistutils/reproduce-trisquel/-/blob/main/.gitlab-ci.yml

The build-package.sh script is responsible for downloading sources, building and running diffoscope: https://gitlab.com/debdistutils/reproduce-trisquel/-/blob/main/build-package.sh

What I've noticed is that Trisquel does not publish *.buildinfo -- I find some traces of them in jenkins (and managed to get 'initramfs-tools' reproducible as a result), but they seems to expire from jenkins fairly quickly. Could trisquel publish them somewhere stable? Just e-mailing them to a mailing list is sufficient, but stable URLs even better. I believe this would fix many problems, at least libgpg-error and all packages that only has NT_GNU_BUILD_ID modifications like this: https://debdistutils.gitlab.io/reproduce-trisquel/diffoscope/libgpg-error/1.43-3+11.0trisquel0/index.html

I'm not rebuilding any Ubuntu packages, only the added/modified trisquel packages and comparing them against trisquel archive. It would be interesting to ALSO rebuild the upstream Ubuntu packages for all packages that trisquel MODIFY. Then we can compare results on the binary packages as well. Added: https://gitlab.com/debdistutils/reproduce-trisquel/-/issues/11

Thanks for feedback!