On Tue, 2018-07-31 at 10:40:08 +0800, Vagrant Cascadian wrote:
> On 2018-07-31, Guillem Jover wrote:
> > On Tue, 2018-07-31 at 08:29:33 +0800, Vagrant Cascadian wrote:
> > And yeah, I also kind of understand gcc's upstream position, that if
> > you unconditionally embed all build flags into your resulting objects,
> > then they are really bound to be unreproducible, and as such that's
> > arguably a bug to fix there probably.
>
> I get that argument, though I fear that becomes an eternal game of
> whack-a-mole.
Right. I guess there's also an argument there, that if you are using a
blacklist then maybe you are doing it wrong? Or doing it at all? Dunno
really. :)
> > --- a/scripts/Dpkg/Vendor/Debian.pm
> > +++ b/scripts/Dpkg/Vendor/Debian.pm
> > @@ -100,6 +100,7 @@ sub _add_build_flags {
> > },
> > reproducible => {
> > timeless => 1,
> > + fixfilepath => 0,
> > fixdebugpath => 1,
> > },
> > sanitize => {
>
> So by default, it would be disabled initially, and then we could
> explicitly enable this for the reproducible builds test framework? After
> it proves to be working and useful and not disruptive, I presume we
> would enable it by default?
Yeah. That was at Mattia's request too. I'm not sure I'd mind much
setting it by default from the get go. But it might be wiser to let
the repro buildds crunch on this for a bit in case unrelated things
break. :)
Thanks,
Guillem
_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
