[SoX-devel] Reproducible builds and SoX

[Pascal Giard]

Hi guys,
Some work in Debian is pushing toward reproducible builds [1] and
that work is advancing quite well. At the moment, 83%+ of the whole
archive passes.

SoX isn't one of those packages though as it uses timestamps macros
[2]. These timestamps macros are only use to tell users/coders about
the date/time at which SoX or libsox were built.

It is suggested/recommended that the use of such macros be dropped
altogether [3]. While I haven't received any pressure to make a move
yet, I'm sure that'll come sooner than later.

I'm therefore asking for your opinion on this. Do you see a problem in
removing the use of those macros in SoX (thus removing that
information from sox_version_info) ? I personally don't see that
information bringing much to the table. My hunch is that it was added
in the first place because others were doing it as well. I might be
wrong tho.

Thanks,

-Pascal
[1] https://wiki.debian.org/ReproducibleBuilds/About
[2] https://reproducible.debian.net/rb-pkg/sox.html
[3] https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros

[Chris Bagwell]

I've come to not like compile time timestamp showing up in output as well.
Complicates CI tests checking for behavior regressions, defeats rsync's
--hard-link option if one uses that to keep backups of past CI builds, etc.

In short term and to prevent breaking our ABI, I suggest changing that
field to be NULL in both git and patch against debian. sox.c looks for
NULL and handles gracefully.

In longer term, I think a better plan is to output something like 'gcc -v'
outputs; the exact list of options pasted to configure script. That, I
think, is main intent of these timestamps; simple way to help detect 2
binaries reporting same version # but compiled with different
options/behavior.

Chris

Post by Pascal Giard
Hi guys,
Some work in Debian is pushing toward reproducible builds [1] and
that work is advancing quite well. At the moment, 83%+ of the whole
archive passes.
SoX isn't one of those packages though as it uses timestamps macros
[2]. These timestamps macros are only use to tell users/coders about
the date/time at which SoX or libsox were built.
It is suggested/recommended that the use of such macros be dropped
altogether [3]. While I haven't received any pressure to make a move
yet, I'm sure that'll come sooner than later.
I'm therefore asking for your opinion on this. Do you see a problem in
removing the use of those macros in SoX (thus removing that
information from sox_version_info) ? I personally don't see that
information bringing much to the table. My hunch is that it was added
in the first place because others were doing it as well. I might be
wrong tho.
Thanks,
-Pascal
[1] https://wiki.debian.org/ReproducibleBuilds/About
[2] https://reproducible.debian.net/rb-pkg/sox.html
[3] https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros
--

[Pascal Giard]

Post by Chris Bagwell
I've come to not like compile time timestamp showing up in output as well.
Complicates CI tests checking for behavior regressions, defeats rsync's
--hard-link option if one uses that to keep backups of past CI builds, etc.
In short term and to prevent breaking our ABI, I suggest changing that field
to be NULL in both git and patch against debian. sox.c looks for NULL and
handles gracefully.

Debian is actually frozen until the release of Jessie so I can wait
for the next minor revision.
If that does not come before unstable gets unfrozen, I'll proceed as
you suggest.

Post by Chris Bagwell
In longer term, I think a better plan is to output something like 'gcc -v'
outputs; the exact list of options pasted to configure script. That, I
think, is main intent of these timestamps; simple way to help detect 2
binaries reporting same version # but compiled with different
options/behavior.

Sound good. To be continued...

-Pascal