Hi,
On Wed, Mar 30, 2016 at 02:19:02AM -0400, Daniel Kahn Gillmor wrote:
> No one is arguing for dropping the build path from .buildinfo files.
ok, cool. Thanks (to you both) for clarifying!
--
cheers,
Holger
signature.asc
Description: Digital signature
Hi!
On Mon, 2016-03-28 at 20:18:11 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2016-03-28 19:51:57 -0400, Guillem Jover wrote:
> > I was thinking about the other language flags that dpkg-dev currently
> > supports, namely: OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS and
> > FCFLAGS. As I think all tho
Hi!
On Tue, 2016-03-29 at 21:52:53 -0400, Holger Levsen wrote:
> On Tue, Mar 29, 2016 at 09:36:00PM -0400, Daniel Kahn Gillmor wrote:
> > This isn't fun-spoiling, it's a useful reality check. But if we were
> > required to get all the way to 100% before we made any progress, then
> > reproducible
On Tue 2016-03-29 21:52:53 -0400, Holger Levsen wrote:
> it's surely progress on the gcc/clang side of things but dropping the
> build path from the .buildinfo files would be a huge step *backwards*
> for reproducibility…
No one is arguing for dropping the build path from .buildinfo files.
As we
Hi,
On Tue, Mar 29, 2016 at 09:36:00PM -0400, Daniel Kahn Gillmor wrote:
> This isn't fun-spoiling, it's a useful reality check. But if we were
> required to get all the way to 100% before we made any progress, then
> reproducible builds wouldn't have gotten off the ground at all.
it's surely pr
On Tue 2016-03-29 20:58:32 -0400, Holger Levsen wrote:
> not wanting to spoil the fun, but…
>
> On Mon, Mar 28, 2016 at 06:33:49PM -0400, Daniel Kahn Gillmor wrote:
>> > Ah great! And one less way to leak local information.
>> yep :)
>
> I *believe* it's not enough (for reproducible builds in arbit
Hi,
not wanting to spoil the fun, but…
On Mon, Mar 28, 2016 at 06:33:49PM -0400, Daniel Kahn Gillmor wrote:
> > Ah great! And one less way to leak local information.
> yep :)
I *believe* it's not enough (for reproducible builds in arbitrary
pathes) if gcc+clang can now cope. IIRC there are other
On Mon 2016-03-28 19:51:57 -0400, Guillem Jover wrote:
> I was thinking about the other language flags that dpkg-dev currently
> supports, namely: OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS and
> FCFLAGS. As I think all those should produce DWARF debugging symbols,
> they would benefit from the optio
Hi!
On Mon, 2016-03-28 at 18:33:49 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2016-03-28 17:26:17 -0400, Guillem Jover wrote:
> >> The attached patch adds a "normalizedebugpath" feature to the
> >> "reproducible" feature set, which appends -fdebug-prefix-map=CWD=.
> >> (where CWD is the actual cur
Hi Guillem--
On Mon 2016-03-28 17:26:17 -0400, Guillem Jover wrote:
> Ah great! And one less way to leak local information.
yep :)
>> The attached patch adds a "normalizedebugpath" feature to the
>> "reproducible" feature set, which appends -fdebug-prefix-map=CWD=.
>> (where CWD is the actual cu
Hi!
On Thu, 2016-03-24 at 13:40:00 -0400, Daniel Kahn Gillmor wrote:
> Package: dpkg-dev
> Version: 1.18.4
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> Compilers tend to inject the current path of the filesystem into the
> debug sy
Package: dpkg-dev
Version: 1.18.4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
Compilers tend to inject the current path of the filesystem into the
debug symbols, so that the debugger can find the sourcecode. But this
isn't actually useful f
12 matches
Mail list logo
