[Reproducible-builds] Bug#796949: piuparts: Missing Build-Depends on python-lzma
Source: piuparts
Version: 0.65
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Dear Maintainer,
piuparts fails to build from source in unstable/amd64 due
to missing Build-Depends on python-lzma:
[..]
==
ERROR: Failure: ImportError (No module named lzma)
--
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 420, in
loadTestsFromName
addr.filename, addr.module)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47,
in importFromPath
return self.importFromDir(dir_path, fqname)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94,
in importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File "/tmp/buildd/piuparts-0.65/tests/test_pkgsummary.py", line 8,
in
import piupartslib.pkgsummary as pkgsummary
File "/tmp/buildd/piuparts-0.65/piupartslib/__init__.py", line 22,
in
import lzma
ImportError: No module named lzma
--
Ran 5 tests in 0.111s
FAILED (errors=5)
Makefile:149: recipe for target 'check' failed
make[1]: *** [check] Error 1
make[1]: Leaving directory '/tmp/buildd/piuparts-0.65'
dh_auto_test: make -j1 check returned exit code 2
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
[..]
The full build log is attached or can be viewed here:
https://reproducible.debian.net/logs/unstable/amd64/piuparts_0.65.build1.log.gz
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Tue Aug 25 07:35:51 GMT+12 2015
I: pbuilder-time-stamp: 1440531351
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
-> Attempting to satisfy build-dependencies
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (>= 9.20120909~), python (>= 2.7), python-debian,
python-apt, python-distro-info, python-nose, python-debianbts, python-yaml,
python-mox3, asciidoc, git, xmlto
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20247 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring
anyway as you requested:
pbuilder-satisfydepends-dummy depends on python (>= 2.7); however:
Package python is not installed.
pbuilder-satisfydepends-dummy depends on python-debian; however:
Package python-debian is not installed.
pbuilder-satisfydepends-dummy depends on python-apt; however:
Package python-apt is not installed.
pbuilder-satisfydepends-dummy depends on python-distro-info; however:
Package python-distro-info is not installed.
pbuilder-satisfydepends-dummy depends on python-nose; however:
Package python-nose is not installed.
pbuilder-satisfydepends-dummy depends on python-debianbts; however:
Package python-debianbts is not installed.
pbuilder-satisfydepends-dummy depends on python-yaml; however:
Package python-yaml is not installed.
pbuilder-satisfydepends-dummy depends on python-mox3; however:
Package python-mox3 is not installed.
pbuilder-satisfydepends-dummy depends on asciidoc; however:
Package as
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
The following NEW packages will be installed:
asciidoc{a} ca-certificates{a} distro-info-data{a} docbook-xml{a}
docbook-xsl{a} git{a} git-man{a} libapt-inst1.7{a} libcurl3-gnutls{a}
liberror-perl{a} l
[Reproducible-builds] Bug#796935: crash while comparing wine-development. ValueError + OSError
Package: diffoscope
Version: 31
Seen on jenkins.d.n:
Those test files are still available between the artifacts. Haven't try them
myself.
Tue Aug 25 00:22:10 UTC 2015 - diffoscope 31 will be used to compare the two
builds:
+ timeout 30m schroot --directory /srv/reproducible-results/tmp.gHrIy1mBop -c
source:jenkins-reproducible-unstable-debbindiff -- sh -c 'export
TMPDIR=/srv/reproducible-results/tmp.gHrIy1mBop/dbd-tmp-V49jUfP ; debbindiff
--html
/srv/reproducible-results/tmp.gHrIy1mBop/wine-development_1.7.50-1.debbindiff.html
--text
/srv/reproducible-results/tmp.gHrIy1mBop/wine-development_1.7.50-1.debbindiff.txt
/srv/reproducible-results/tmp.gHrIy1mBop/b1/wine-development_1.7.50-1_amd64.changes
/srv/reproducible-results/tmp.gHrIy1mBop/b2/wine-development_1.7.50-1_amd64.changes'
Exception in thread Thread-7641:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/lib/python2.7/dist-packages/diffoscope/difference.py", line 59, in
parse
self._action = self._action(line.decode('utf-8'))
File "/usr/lib/python2.7/dist-packages/diffoscope/difference.py", line 70, in
read_headers
raise ValueError('Unable to parse diff headers: %s' % repr(line))
ValueError: Unable to parse diff headers: u'diff: error while loading shared
libraries: libc.so.6: cannot open shared object file: No such file or
directory\n'
Traceback (most recent call last):
File "/usr/bin/debbindiff", line 117, in
sys.exit(main())
File "/usr/bin/debbindiff", line 102, in main
parsed_args.file1, parsed_args.file2)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py",
line 66, in compare_root_paths
return compare_files(FilesystemFile(path1), FilesystemFile(path2))
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py",
line 79, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 75, in wrapper
return original_method(self, other, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 175, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 148, in _compare_using_details
details = [d for d in self.compare_details(other, source) if d is not None]
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 75, in wrapper
return original_method(self, other, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/debian.py",
line 148, in compare_details
differences.extend(my_container.compare(other_container, source))
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/debian.py",
line 112, in compare
diffoscope.comparators.compare_files(my_file, other_file, source=source))
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py",
line 79, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 75, in wrapper
return original_method(self, other, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 175, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 148, in _compare_using_details
details = [d for d in self.compare_details(other, source) if d is not None]
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 75, in wrapper
return original_method(self, other, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/deb.py", line
86, in compare_details
differences.extend(my_container.compare(other_container, source))
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/utils.py", line
177, in compare
my_file, other_file, source=name))
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py",
line 79, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 75, in wrapper
return original_method(self, other, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 175, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 148, in _compare_using_details
details = [d for d in self.compare_details(other, source) if d is not None]
File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py",
line 75, in wrapper
return original_method(self, other
[Reproducible-builds] Bug#796930: pyzmq: FTBFS with several tests error
Source: pyzmq
Version: 14.4.0-1
Severity: serious
User: reproducible-builds@lists.alioth.debian.org
Usertag: ftbfs
Dear maintainer, your package FTBFS in current sid.
The full build log can be seen on
https://reproducible.debian.net/logs/unstable/amd64/pyzmq_14.4.0-1.build1.log.gz
The actual errors are below.
Thanks for maintaining pyzmq.
make[1]: Entering directory '/pyzmq-14.4.0'
dh_auto_test
pybuild --test --test-nose -i python{version} -p 2.7 --dir .
I: pybuild base:170: cd /pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build; python2.7
-m nose --with-doctest
EEFFE..S..SS.
==
ERROR: Failure: ImportError (No module named cffi.vengine_cpy)
--
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 420, in
loadTestsFromName
addr.filename, addr.module)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
"/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/backend/cffi/__init__.py", line
10, in
import cffi.vengine_cpy
ImportError: No module named cffi.vengine_cpy
==
ERROR: Failure: ValueError (_type_ 'v' not supported)
--
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 420, in
loadTestsFromName
addr.filename, addr.module)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
"/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/platform/windows.py",
line 7, in
import ctypes.wintypes
File "/usr/lib/python2.7/ctypes/wintypes.py", line 23, in
class VARIANT_BOOL(_SimpleCData):
ValueError: _type_ 'v' not supported
==
ERROR: Failure: ImportError (No module named gevent)
--
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 420, in
loadTestsFromName
addr.filename, addr.module)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File "/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/green/__init__.py", line
33, in
from zmq.green.core import _Context, _Socket
File "/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/green/core.py", line 24,
in
from .poll import _Poller
File "/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/green/poll.py", line 2,
in
import gevent
ImportError: No module named gevent
==
FAIL: Doctest: zmq.eventloop.minitornado.util.import_object
--
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 2226, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
zmq.eventloop.minitornado.util.import_object
File
"/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py",
line 18, in import_object
--
File
"/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py",
line 24, in zmq.eventloop.minitornado.util.import_object
Failed example:
import tornado.escape
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
File "", line 1,
in
import tornado.escape
ImportError: No module named tornado.escape
--
File
"/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py",
line 25, in zmq.eventloop.minitornado.util.import_object
Failed example:
import_object('tornado.escape') is tornado.escape
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
[Reproducible-builds] I`m a banker. I want to transfer an abandoned US$5.5Million to your Account for us to share it 40% for you while 60% for me. reply me SOON.
___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Fwd: [patch] Make.rules: sort capabilities with LANG=C
Hi, FYI :) cheers, Holger -- Forwarded Message -- Subject: [patch] Make.rules: sort capabilities with LANG=C Date: Dienstag, 25. August 2015 From: Christian Boltz To: appar...@lists.ubuntu.com Hello, this patch changes Make.rules to sort capabilities using LANG=C. This is needed to make building apparmor.vim reproducable - otherwise the sorting depends on the locale. Found by the Debian reproducible project, https://reproducible.debian.net/rb-pkg/unstable/amd64/apparmor.html [ make-rules-sort-capabilities.diff ] === modified file 'common/Make.rules' --- common/Make.rules 2015-01-30 21:15:53 + +++ common/Make.rules 2015-08-25 17:00:00 + @@ -82,7 +82,7 @@ # = # emits defined capabilities in a simple list, e.g. "CAP_NAME CAP_NAME2" -CAPABILITIES=$(shell echo "\#include " | cpp -dM | LC_ALL=C sed -n -e '/CAP_EMPTY_SET/d' -e 's/^\#define[ \t]\+CAP_\([A- Z0-9_]\+\)[ \t]\+\([0-9xa-f]\+\)\(.*\)$$/CAP_\1/p' | sort) +CAPABILITIES=$(shell echo "\#include " | cpp -dM | LC_ALL=C sed -n -e '/CAP_EMPTY_SET/d' -e 's/^\#define[ \t]\+CAP_\([A- Z0-9_]\+\)[ \t]\+\([0-9xa-f]\+\)\(.*\)$$/CAP_\1/p' | LANG=C sort) .PHONY: list_capabilities list_capabilities: /usr/include/linux/capability.h Regards, Christian Boltz -- > Ansonsten: Ich sage nur "Diwasserstoffmonoxid". Ja, ein äußerst schädliches Zeugs, vor allem wenn es in guten Malt gerät. [A. Schreiber und R. Döblitz] --- signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
Le mardi 25 août 2015 à 12:20 +0200, Andreas Bießmann a écrit : > On 08/25/2015 11:55 AM, Vagrant Cascadian wrote: > > On 2015-08-25, Andreas Bießmann wrote: > >> On 07/28/2015 05:00 PM, Tom Rini wrote: > >>> On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: > In order to achieve reproducible builds in U-Boot, timestamps that are > defined > at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH > environment > variable allows setting a fixed value for those timestamps. > > Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of > targets can be > built reproducibly. This is the case for e.g. sunxi devices. > > However, some other devices might need some more tweaks, especially > regarding > the image generation tools. > > Signed-off-by: Paul Kocialkowski > >>> > >>> Applied to u-boot/master, thanks! > >> > >> This commit breaks build on non GNU hosts (like OS X and persumably > >> other *BSD hosts). Before, those hosts where supported, so for me this > >> has to be fixed for 2015.10 > >> > >> We need a) some mechanism to search for the GNU date variant or b) some > >> wrapper to provide the correct output on those host machines. > >> > >> I vote for a), it is acceptable to have the GNU date available but we > >> should error on 'no GNU date available'. Furthermore we need to have the > >> date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. > > > > There was a proposed patch which only uses the GNU date extensions if > > SOURCE_DATE_EPOCH environment variable is set, would this sufficiently > > address your concerns, at least for the short term? > > > > Message-Id: <1438337042-30762-1-git-send-email-judge.pack...@gmail.com> > > http://lists.denx.de/pipermail/u-boot/2015-August/221429.html > > thanks for the pointer, normal builds work with that change. I think we should get that patch merged so that it doesn't affect regular builds on non-GNU hosts. It is also relevant for the purpose it serves initially, too. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] SOURCE_DATE_EPOCH must not be linux only... (was Re: [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH)
Hi, (just stating the (IMHO) obvious here…) On Dienstag, 25. August 2015, Vagrant Cascadian wrote: > There was a proposed patch which only uses the GNU date extensions if > SOURCE_DATE_EPOCH environment variable is set, would this sufficiently > address your concerns, at least for the short term? there also should be a solution which works on BSD in the not so long term if we want the SOURCE_DATE_EPOCH specification to take off..! (and this probably also affects other software where we want to (or did) introduce SOURCE_DATE_EPOCH!) cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [U-Boot] [PATCH v3 1/2] Makefile: Use correct timezone for U_BOOT_TZ
On 08/13/2015 08:08 AM, Chris Packham wrote:
> When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
> building normally the timezone is taken from the build machine's locale
> setting.
>
> Signed-off-by: Chris Packham
> Tested-by: Bin Meng
> Tested-by: Paul Kocialkowski
This also re-enables normal building on *BSD style hosts.
Tested-by: Andreas Bießmann
> ---
>
> Changes in v3:
> - None
>
> Changes in v2:
> - Collect some tested-by tags
> - Remove reference to f3f431a71272 in the commit message
> - Drop Ccs that were erroneously added when submitting v1, remaining Ccs
> are from the original mailing list thread
>
> Makefile | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ad51e60..3ff063a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1279,10 +1279,16 @@ define filechk_version.h
> endef
>
> define filechk_timestamp.h
> - (SOURCE_DATE="$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}"; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_DATE "%b %d
> %C%y"'; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TIME "%T"';
> \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TZ "%z"' )
> + (if test -n "$${SOURCE_DATE_EPOCH}"; then \
> + SOURCE_DATE="@$${SOURCE_DATE_EPOCH}"; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b
> %d %C%y"'; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME
> "%T"'; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ
> "%z"'; \
> + else \
> + LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
> + LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
> + LC_ALL=C date +'#define U_BOOT_TZ "%z"'; \
> + fi)
> endef
>
> $(version_h): include/config/uboot.release FORCE
>
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 08/25/2015 11:55 AM, Vagrant Cascadian wrote: > On 2015-08-25, Andreas Bießmann wrote: >> On 07/28/2015 05:00 PM, Tom Rini wrote: >>> On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: In order to achieve reproducible builds in U-Boot, timestamps that are defined at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment variable allows setting a fixed value for those timestamps. Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can be built reproducibly. This is the case for e.g. sunxi devices. However, some other devices might need some more tweaks, especially regarding the image generation tools. Signed-off-by: Paul Kocialkowski >>> >>> Applied to u-boot/master, thanks! >> >> This commit breaks build on non GNU hosts (like OS X and persumably >> other *BSD hosts). Before, those hosts where supported, so for me this >> has to be fixed for 2015.10 >> >> We need a) some mechanism to search for the GNU date variant or b) some >> wrapper to provide the correct output on those host machines. >> >> I vote for a), it is acceptable to have the GNU date available but we >> should error on 'no GNU date available'. Furthermore we need to have the >> date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. > > There was a proposed patch which only uses the GNU date extensions if > SOURCE_DATE_EPOCH environment variable is set, would this sufficiently > address your concerns, at least for the short term? > > Message-Id: <1438337042-30762-1-git-send-email-judge.pack...@gmail.com> > http://lists.denx.de/pipermail/u-boot/2015-August/221429.html thanks for the pointer, normal builds work with that change. Andreas ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On Thu, Jul 30, 2015 at 11:54 PM, Bin Meng wrote: > This commit breaks the following commit: > > commit f3f431a712729a1af94d01bd1bfde17a252ff02c > Author: Chris Packham > Date: Sun May 10 21:02:09 2015 +1200 > > Makefile: Add U_BOOT_TZ and include in version > > Define U_BOOT_TZ alongside U_BOOT_TIME and U_BOOT_DATE and use it to > include the timezone in the version output. > > Acked-by: Simon Glass > Signed-off-by: Chris Packham > > Before this commit I have: > U-Boot 2015.07-00345-g9c57487 (Jul 31 2015 - 10:49:31 +0800) > > After this commit I have: > U-Boot 2015.07-00346-gf3f431a (Jul 31 2015 - 02:50:54 +) > > As you see: the timezone information is missing, and U-Boot's > timestamp is now GMT+0 (the correct one should be GMT+8) > > Is this intended behavior? Or if not, please fix it. I notice the same behavior here and I agree it would be nice to fix this. Thanks ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 2015-08-25, Andreas Bießmann wrote: > On 07/28/2015 05:00 PM, Tom Rini wrote: >> On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: >>> In order to achieve reproducible builds in U-Boot, timestamps that are >>> defined >>> at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH >>> environment >>> variable allows setting a fixed value for those timestamps. >>> >>> Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets >>> can be >>> built reproducibly. This is the case for e.g. sunxi devices. >>> >>> However, some other devices might need some more tweaks, especially >>> regarding >>> the image generation tools. >>> >>> Signed-off-by: Paul Kocialkowski >> >> Applied to u-boot/master, thanks! > > This commit breaks build on non GNU hosts (like OS X and persumably > other *BSD hosts). Before, those hosts where supported, so for me this > has to be fixed for 2015.10 > > We need a) some mechanism to search for the GNU date variant or b) some > wrapper to provide the correct output on those host machines. > > I vote for a), it is acceptable to have the GNU date available but we > should error on 'no GNU date available'. Furthermore we need to have the > date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. There was a proposed patch which only uses the GNU date extensions if SOURCE_DATE_EPOCH environment variable is set, would this sufficiently address your concerns, at least for the short term? Message-Id: <1438337042-30762-1-git-send-email-judge.pack...@gmail.com> http://lists.denx.de/pipermail/u-boot/2015-August/221429.html live well, vagrant signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 07/28/2015 05:00 PM, Tom Rini wrote: > On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: > >> In order to achieve reproducible builds in U-Boot, timestamps that are >> defined >> at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH >> environment >> variable allows setting a fixed value for those timestamps. >> >> Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets >> can be >> built reproducibly. This is the case for e.g. sunxi devices. >> >> However, some other devices might need some more tweaks, especially regarding >> the image generation tools. >> >> Signed-off-by: Paul Kocialkowski > > Applied to u-boot/master, thanks! This commit breaks build on non GNU hosts (like OS X and persumably other *BSD hosts). Before, those hosts where supported, so for me this has to be fixed for 2015.10 We need a) some mechanism to search for the GNU date variant or b) some wrapper to provide the correct output on those host machines. I vote for a), it is acceptable to have the GNU date available but we should error on 'no GNU date available'. Furthermore we need to have the date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. Andreas ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
