public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org, 783210@bugs.debian.org,
	Aurelien Jarno <aurelien@aurel32.net>,
	Ximin Luo <infinity0@debian.org>
Subject: Re: [PATCH] nscd_stat.c: make the build reproducible
Date: Mon, 01 Aug 2016 04:52:00 -0000	[thread overview]
Message-ID: <20160801045215.GS6702@vapier.lan> (raw)
In-Reply-To: <dfc1aba1-1788-6b73-602e-3ffd6936c14d@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

On 28 Jul 2016 15:15, Florian Weimer wrote:
> On 03/09/2016 05:30 PM, Mike Frysinger wrote:
> > would it be so terrible to properly marshall this data ?
> 
> Ximin Luo and I discussed this and I wonder if it is possible to read 
> out the libc.so.6 build ID if it is present.  It should indirectly call 
> all the layout dependencies and be reasonably easy to access because it 
> is in an allocated section (and we might want to print it from an 
> libc.so.6 invocation, too).
> 
> We still need the time-based approach if the build ID is not available, 
> but I expect most distributions will have something like it.
> 
> The Debian bug is:
> 
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783210
> 
> (Also Cc:ed)

agreed that build-id should be an acceptable replacement for what the
code is doing today, but in order to pull that off, i guess you'd have
to have to do a configure test to see if build-id is active ?  if you
leave the logic to runtime, you'd still need to include the datetime
stamp in the object which would still make the build unreproducible.

this also doesn't really cover the quoted idea of marshalling the data
between client & server :).
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2016-08-01  4:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 17:06 Aurelien Jarno
2016-03-08 23:37 ` Mike Frysinger
2016-03-09  7:54   ` Aurelien Jarno
2016-03-09 22:30     ` Mike Frysinger
2016-07-28 19:33       ` Florian Weimer
2016-07-29 13:30         ` Ludovic Courtès
2016-08-01  4:52         ` Mike Frysinger [this message]
2016-11-04 17:54           ` Ximin Luo
2016-11-04 18:14             ` Ximin Luo

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-all from there: mbox

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

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

  git send-email \
    --in-reply-to=20160801045215.GS6702@vapier.lan \
    --to=vapier@gentoo.org \
    --cc=783210@bugs.debian.org \
    --cc=aurelien@aurel32.net \
    --cc=fweimer@redhat.com \
    --cc=infinity0@debian.org \
    --cc=libc-alpha@sourceware.org \
    /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.
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).