[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#783210: glibc: please make the package build reproducibly



Aurelien Jarno:
> [..]
> 
> It would be nice to have an explanation why the changes from your patch
> are needed. See my comments below.
> 
> 
>> diff -Nru glibc-2.24/debian/rules glibc-2.24/debian/rules
>> --- glibc-2.24/debian/rules	2016-11-25 21:59:04.000000000 +0000
>> +++ glibc-2.24/debian/rules	2016-11-15 18:03:37.000000000 +0000
>> @@ -45,6 +45,7 @@
>>  
>>  DEB_SOURCE_PACKAGE := $(strip $(shell egrep '^Source: ' debian/control | cut -f 2 -d ':'))
>>  
>> +SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -STimestamp)
>>  DEB_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' ')
>>  GLIBC_VERSION = $(shell echo $(DEB_VERSION) | sed -e 's/.*://' -e 's/[+-].*//')
> 
> You told above that SOURCE_DATE_EPOCH is already set by
> dpkg-buildpackage, so why do we need to do that?
> 

It is not strictly necessary, but it allows one to build reproducibly even when not using dpkg-buildpackage, e.g. when trying to re-run a specific part of the build via `debian/rules build` or something else. This is helpful to save time when debugging.

>> diff -Nru glibc-2.24/debian/rules.d/build.mk glibc-2.24/debian/rules.d/build.mk
>> --- glibc-2.24/debian/rules.d/build.mk	2016-11-25 12:02:24.000000000 +0000
>> +++ glibc-2.24/debian/rules.d/build.mk	2016-11-15 18:03:37.000000000 +0000
>> @@ -316,18 +316,16 @@
>>  $(stamp)source: $(stamp)patch
>>  	mkdir -p $(build-tree)
>>  	cd .. && \
>> -	       find $(GLIBC_SOURCES) -depth -newermt '$(DEB_BUILD_DATE)' \
>> -			-print0 | \
>> -               xargs -0r touch --no-dereference --date='$(DEB_BUILD_DATE)'
>> -	cd .. && \
>>  		find $(GLIBC_SOURCES) -print0 | \
>>  		LC_ALL=C sort -z | \
>>  		tar -c -J --null -T - --no-recursion \
>>  			--mode=go=rX,u+rw,a-s \
>> +			--clamp-mtime --mtime "@$(SOURCE_DATE_EPOCH)" \
>>  			--owner=root --group=root --numeric-owner \
>>  			-f $(CURDIR)/$(build-tree)/glibc-$(GLIBC_VERSION).tar.xz
>>  	mkdir -p debian/glibc-source/usr/src/glibc
>>  	tar cf - --files-from debian/glibc-source.filelist \
>> +		--clamp-mtime --mtime "@$(SOURCE_DATE_EPOCH)" \
>>  	  | tar -x -C debian/glibc-source/usr/src/glibc -f -
> 
> Why do we need to change this, what doesn't work in the current code? The current code
> has been provided by Jérémy Bobbio in the current bug.
> 

Yes, it doesn't work. but also it was not applied correctly:

1. The original patch had a mistake in: we need "@$(unix_timestamp)", the '@' tells GNU find/tar/date/etc to interpret the subsequent value as a UNIX timestamp. Otherwise these tools will complain about an invalid date, but silently use a different value.

2. The original patch was not applied fully/correctly either - nowhere in the current glibc packaging is DEB_BUILD_DATE actually set. The original patch set this, instead of my previous hunk that sets SOURCE_DATE_EPOCH, however this is not present in the current glibc packaging.

3. Since the original patch was written, we got the --clamp-mtime feature into GNU tar, and this allows us to make the patch smaller and the resulting code is neater. (It also avoids writing directly to the filesystem.)

>>  	touch $@
>> diff -Nru glibc-2.24/debian/rules.d/debhelper.mk glibc-2.24/debian/rules.d/debhelper.mk
>> --- glibc-2.24/debian/rules.d/debhelper.mk	2016-11-25 22:08:30.000000000 +0000
>> +++ glibc-2.24/debian/rules.d/debhelper.mk	2016-11-15 18:03:37.000000000 +0000
>> @@ -77,8 +77,7 @@
>>  		-exec chmod a+x '{}' ';'
>>  	dh_makeshlibs -Xgconv/ -p$(curpass) -V "$(call xx,shlib_dep)"
>>  	# Add relevant udeb: lines in shlibs files
>> -	chmod a+x debian/shlibs-add-udebs
>> -	./debian/shlibs-add-udebs $(curpass)
>> +	sh ./debian/shlibs-add-udebs $(curpass)
>>  
>>  	dh_installdeb -p$(curpass)
>>  	dh_shlibdeps -p$(curpass)
> 
> Why do we need this change?
> 

This is not strictly necessary, but it helps one perform reproductions in the same source tree, by running dpkg-buildpackage twice. Otherwise, glibc-source has -x for that file in the first build and +x for that file in the second build.

Yes, our testing infrastructure does not run builds twice in the same source tree and neither does debrepro nor reprotest, however doing this is useful for debugging purposes, to save time and avoid having to re-run the whole build againg.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git


Reply to: