5 ms·

Assuming you're referring to Debian, you've missed the mark. Debian is more committed to open source, in the RMS 'free software' sense, than any other distro I

by blihp 8y ago

Assuming you're referring to Debian, you've missed the mark. Debian is more committed to open source, in the RMS 'free software' sense, than any other distro I'm aware of... it's the foundation of the distro. Any Debian user can absolutely rebuild from source any[1] part of the system. The problem that reproducible builds is attempting to solve is that my build, while being 100% functional, might not be bit identical to yours or what shipped with the distro for any number of valid reasons.[2] The problem this creates given the current world of increasingly sophisticated malware is that I can't prove a given build is identical to what was intended based on the binaries. So it's an issue of 'we've always been giving you the source, now we're going to ensure that it's possible to create bit-identical binaries' rather than 'we were giving you free binaries, now we're giving you the source'. If your argument is that one should always build from source, reproducible builds is part of getting to the same effective result without the overhead and headache that the vast majority of users are not willing to deal with. [1] In the cases when this turned out not to be possible, holy hell tends to get raised... see things like the Chromium BLOB issues (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909) etc. These issues tend to have a lot of noise made and get resolved very quickly since it goes against the very core of what Debian is intended to be. In cases where you have things that are binary-only such as proprietary GPU drivers, these get segregated into a separate repo with the general advice from Debian of 'you shouldn't use these'. This doesn't tend to be realistic advice for many users given the state of many of the open source drivers... but they've tried their best to steer people away while not making the distro unusable for those who insist on using them. [2] A trivial example would be baking the build date/machine name into the binary... there's no expectation that one would ever reproduce that build again even on the same machine.

mjw1007 8y ago
I think the gripe is that it's never been as easy as it could be to say "OK, I'm going to make a change in this here source file, then run the result on my machine while keeping everything else the same". For example if I'm reporting a bug and I have a proposed patch, it would be nice to be able to say "I've been running with this patch for the last month and it's been fine". Ideally there'd be a coherent way to download the source for a particular package, rebuild it, and have the system use the rebuilt result. Bonus marks if it did something useful when a newer version of the package came along. I think https://packages.debian.org/sid/dgit https://packages.debian.org/sid/dgit is an attempt to make the download-and-rebuild part look more uniform, but I think there's still work to be done to make it easy to substitute the result for the distro package.
- michaelmrose 8y ago
  This is trivial on funtoo/gentoo you just make a private tree of ebuild files containing only the packages that you care about modifying with the patches located in the same directory tree and applied by adding the patch to the ebuild. You can also host this somewhere so others can run/test your modified version easily. No real special infrastructure required they can sync this directory via git. There are of course downsides. The annoyance of building updates and discovering bugs not discovered by others by some unique set of patches / build time options.
- blihp 8y ago
  That's a valid complaint (I too wish it were simpler) but am not sure how feasible that is given the myriad of ways upstream packages are managed and the varying degrees to which they do or don't support distros in general, let alone a specific one like Debian. I think that's part of the reason Debian has become such a popular upstream distro: it converts an incoming Tower of Babel collection of source repos into a reasonably coherent and standardized set of packages.
- viraptor 8y ago
  What's missing from: "apt-get source the-package", add patches, "pbuilder build the-package.dsc" ? (I'm assuming that pbuilder was already configured to work)
  - EE84M3i 8y ago
    FWIW As someone that touches debian package building once in a blue moon, it seems like there's wide variability into which is the "right way" to do the actual build step and that everyone has their own artisanal preference. pbuilder, debuild, debootstrap, dpkg-buildpackage, sbuild, fakeroot all leave me scratching my head.
    - viraptor 8y ago
      If we're taking about the reproducible packages, then I believe only pbuilder is a valid answer here. (maybe sbuild, I haven't used that one) debootstrap / fakeroot / dpkg are part of the pbuilder system, not full solutions. But yeah, I noticed that Debian is not going out of its way to advertise one blessed solution.
groestl 8y ago
> baking the build date/machine name into the binary This I find especially moronic. A deterministic build would have provided a perfect way to trace back a binary to it's sources/source commit, but let's give that up and trade it for a date and the hostname of the build machine :/
- shawnz 8y ago
  Reproducible builds were already infeasible for other reasons at the time when people thought this was a good idea. So in that context, it wasn't so dumb
  - groestl 8y ago
    Yes, to some extend I understand where this is coming from. I'm also more talking about the sisyphean situation than the person actually doing it: it's like placing a cherry on top of a mountain of dirt.

by blihp 8y ago

mjw1007 8y ago

I think the gripe is that it's never been as easy as it could be to say "OK, I'm going to make a change in this here source file, then run the result on my machine while keeping everything else the same". For example if I'm reporting a bug and I have a proposed patch, it would be nice to be able to say "I've been running with this patch for the last month and it's been fine". Ideally there'd be a coherent way to download the source for a particular package, rebuild it, and have the system use the rebuilt result. Bonus marks if it did something useful when a newer version of the package came along. I think https://packages.debian.org/sid/dgit https://packages.debian.org/sid/dgit is an attempt to make the download-and-rebuild part look more uniform, but I think there's still work to be done to make it easy to substitute the result for the distro package.

michaelmrose 8y ago
This is trivial on funtoo/gentoo you just make a private tree of ebuild files containing only the packages that you care about modifying with the patches located in the same directory tree and applied by adding the patch to the ebuild. You can also host this somewhere so others can run/test your modified version easily. No real special infrastructure required they can sync this directory via git. There are of course downsides. The annoyance of building updates and discovering bugs not discovered by others by some unique set of patches / build time options.
blihp 8y ago
That's a valid complaint (I too wish it were simpler) but am not sure how feasible that is given the myriad of ways upstream packages are managed and the varying degrees to which they do or don't support distros in general, let alone a specific one like Debian. I think that's part of the reason Debian has become such a popular upstream distro: it converts an incoming Tower of Babel collection of source repos into a reasonably coherent and standardized set of packages.
viraptor 8y ago
What's missing from: "apt-get source the-package", add patches, "pbuilder build the-package.dsc" ? (I'm assuming that pbuilder was already configured to work)
- EE84M3i 8y ago
  FWIW As someone that touches debian package building once in a blue moon, it seems like there's wide variability into which is the "right way" to do the actual build step and that everyone has their own artisanal preference. pbuilder, debuild, debootstrap, dpkg-buildpackage, sbuild, fakeroot all leave me scratching my head.
  - viraptor 8y ago
    If we're taking about the reproducible packages, then I believe only pbuilder is a valid answer here. (maybe sbuild, I haven't used that one) debootstrap / fakeroot / dpkg are part of the pbuilder system, not full solutions. But yeah, I noticed that Debian is not going out of its way to advertise one blessed solution.

groestl 8y ago

> baking the build date/machine name into the binary This I find especially moronic. A deterministic build would have provided a perfect way to trace back a binary to it's sources/source commit, but let's give that up and trade it for a date and the hostname of the build machine :/

shawnz 8y ago
Reproducible builds were already infeasible for other reasons at the time when people thought this was a good idea. So in that context, it wasn't so dumb
- groestl 8y ago
  Yes, to some extend I understand where this is coming from. I'm also more talking about the sisyphean situation than the person actually doing it: it's like placing a cherry on top of a mountain of dirt.