linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jeremy A. Puhlman" <jpuhlman@mvista.com>
To: John Kacur <jkacur@redhat.com>
Cc: williams@redhat.com, linux-rt-users@vger.kernel.org
Subject: Re: [rt-tests][PATCH] rt-tests: make manpages builds reproducible
Date: Wed, 26 Feb 2020 09:40:22 -0800	[thread overview]
Message-ID: <3688e9ae-69b9-7237-59e8-9c1f316b5fa8@mvista.com> (raw)
In-Reply-To: <alpine.LFD.2.21.2002261217460.9967@planxty>



On 2/26/2020 9:18 AM, John Kacur wrote:
>
> On Tue, 25 Feb 2020, Jeremy A. Puhlman wrote:
>
>> From: Jeremy Puhlman <jpuhlman@mvista.com>
>>
>> Add -n to gzip call to make the build output
>> of the manpages reproducible.
>>
>> Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
>> ---
>>   Makefile | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 8747971..1b37ba7 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -181,7 +181,7 @@ ssdd: $(OBJDIR)/ssdd.o $(OBJDIR)/librttest.a
>>   	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS) $(RTTESTLIB)
>>   
>>   %.8.gz: %.8
>> -	gzip -c $< > $@
>> +	gzip -nc $< > $@
>>   
>>   %.8.bz2: %.8
>>   	bzip2 -c $< > $@
>> -- 
>> 2.20.1
>>
>>
> Could you explain to me how this makes the build output of manpages more
> reproducible?

gzip adds the name of the file(not really an issue) and the modification 
time into the header of the
gzipped archive.  Different modification times can cause the archives to 
have different md5sums even
though the content is identical.  Adding -n causes the archives to 
always be identical regardless of when
they are built so long as the content is identical. Its less of an 
issue(provided the build system in question
doesn't touch or modify the man pages) when you are building from 
released tarballs, but if you build
from git, the modification time of the file is when the file was checked 
out.

Tools like rpm will object to the files being installed(like say 
multilib versions of the same packages) together
due different md5sums and the fact that they are not elf binaries, even 
though the files are the same.


-- 
Jeremy A. Puhlman
jpuhlman@mvista.com


  reply	other threads:[~2020-02-26 17:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-25 23:42 [rt-tests][PATCH] rt-tests: make manpages builds reproducible Jeremy A. Puhlman
2020-02-26 17:18 ` John Kacur
2020-02-26 17:40   ` Jeremy A. Puhlman [this message]
2020-02-27 18:29     ` John Kacur

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=3688e9ae-69b9-7237-59e8-9c1f316b5fa8@mvista.com \
    --to=jpuhlman@mvista.com \
    --cc=jkacur@redhat.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=williams@redhat.com \
    /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 NNTP newsgroup(s).