bit-by-bit reproducible and no need for superuser privileges
Hi,
I think I can adapt mkimage.sh to work without root and to produce bit-by-bit reproducible output between multiple runs. If this is not something you are interested in, then please just close this issue.
The remaining obstacle to achieve this is the software compiled in mkuserland2.sh. Since those are compiled without the environment as set up by Debian package builds and without Debian patches, they produce a source of unreproducibility (by including timestamps or other randomness). I'd thus like to evaluate the software that is but in mkuserland2.sh:
- libdrm -- you use branch 2.4.106 while Debian unstable has 2.4.108. You don't patch the code and just build the etnaviv component. Why?
- mesa -- Debian unstable now has 21.2.6. Is it still necessary to build our own? Maybe because of the configuration options?
- xorg -- you build it with a patch to glamor. It seems that this is a workaround for a bug in the etnaviv driver and it would be too costly performance wise to apply this patch for all drivers, so we probably have to keep building a patched xorg?
- wlroots -- you build 0.13.0 while Debian unstable ships 0.14.1. Is there a problem with the Debian build?
- sway -- you use version 1.6 and Debian ships 1.6.1. Same question as above.
- waybar -- you use version 0.9.7 and Debian ships 0.9.8. Same question as above.
- wayvnc -- will soon be part of Debian: https://ftp-master.debian.org/new/wayvnc_0.4.1-1.html
- neatvnc -- will soon be part of Debian: https://ftp-master.debian.org/new/neatvnc_0.4.0%2Bdfsg-1.html
- cage -- will soon be part of Debian: https://ftp-master.debian.org/new/cage_0.1.4-1.html
All of the packages above that are in Debian (so all except wayvnc, neatvnc and cage) are cross buildable. Is there a reason why you build them "natively" via qemu user emulation instead of cross compiling them? The advantage would be faster build times and less build dependencies installed in the system image.
Thanks!