sox-devel@lists.sourceforge.net unofficial mirror
 help / color / mirror / code / Atom feed
From: Chris Bagwell <chris@cnpbagwell.com>
To: sox-devel@lists.sourceforge.net
Subject: Re: Reproducible builds and SoX
Date: Tue, 24 Feb 2015 21:02:52 -0600	[thread overview]
Message-ID: <CAGzDe_bH-Op03nO6Y0Aux+=ShsFB+OMMSrcXOnwSs=QbO51BrQ@mail.gmail.com> (raw)
In-Reply-To: <CAJNNDmmfwvT=shm+f7KXn0=7yEbea0L2JKbNVxorUoesBOW3wg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1904 bytes --]

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


On Fri, Feb 13, 2015 at 12:06 PM, Pascal Giard <evilynux@gmail.com> wrote:

> 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
> --
>

[-- Attachment #1.2: Type: text/html, Size: 2675 bytes --]

[-- Attachment #2: Type: text/plain, Size: 441 bytes --]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

  reply	other threads:[~2015-02-25 20:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13 18:06 Reproducible builds and SoX Pascal Giard
2015-02-25  3:02 ` Chris Bagwell [this message]
2015-02-26 14:05   ` Pascal Giard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.sourceforge.net/lists/listinfo/sox-devel

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGzDe_bH-Op03nO6Y0Aux+=ShsFB+OMMSrcXOnwSs=QbO51BrQ@mail.gmail.com' \
    --to=sox-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/sox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).