Just did some quick testing using reprotest to see if the various MNT Reform firmwares are #reproducible and sure enough, they are!
With an eye to someday doing more thorough testing, I put together some initial packaging for Debian:
To package for Debian, it would be nicer if firmware were in a separate git repository...
Now I just need to actually *test* these firmwares on my mnt/reform!
@vagrantc Side question: why do Debian source packages copy the upstream source tree and add a debian subdirectory inside it, instead of having a link to source tatball (or git repo) and downloading it during the build, like Arch's PKGBUILDs, Alpine's APKBUILDs and RPM specs do?
Partly historical, the #debian packaging workflow evolved from source tarball plus a .diff, the requirements for #gpl compliance suggested it was best to keep a copy of your sources to ensure you could provide them, and since then Debian as a community has developed a wide range of interesting ways to modernize packaging workflows, e.g. #VCS or #git driven (#dgit FTW!). What was your favorite VCS in the early 90s? If Debian were to start today, it would look very different.
Btw., downloading during build would require an internet connection, which is not allowed by Debian policy. Not depending on the internet, esp. not on resources outside of Debians control, is a good thing. Otherwise, many problems arise from temporary or permanent network failures, changes of source code with good or bad intent etc.
I guess if I were to do it, I'd set up an official mirror of upstrean source tarballs, and have packages refer to that, with a separate download step in the build process thag can be done ahead of time, or replaced with a local copy of upstrean tarballs.
Maybe even have an automated job thay scans the repo with package control files for upstream tarball URLs and adds them all to the mirror
And obviously put that mirror on CD
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).