[Reproducible-builds] Bug#824384: clearsilver: FTBFS: /usr/share/cdbs/1/class/python-module.mk:54: *** unterminated call to function 'strip': missing ')'. Stop.
Source: clearsilver Version: 0.10.5-1.6 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, clearsilver fails to build from source in unstable/amd64: [..] dh_testdir dh_testroot dh_prep dh_testdir dh_testroot dh_install dh_installdocs dh_installchangelogs dh_compress dh_fixperms dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'clearsilver-build-deps' in '../clearsilver-build-deps_0.10.5-1.6_all.deb'. The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! Selecting previously unselected package clearsilver-build-deps. (Reading database ... 23080 files and directories currently installed.) Preparing to unpack clearsilver-build-deps_0.10.5-1.6_all.deb ... Unpacking clearsilver-build-deps (0.10.5-1.6) ... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies... Done The following additional packages will be installed: cdbs libexpat1-dev libpython-all-dev libpython-dev libpython2.7 libpython2.7-dev python-all python-all-dev python-dev python2.7-dev zlib1g-dev The following NEW packages will be installed: cdbs libexpat1-dev libpython-all-dev libpython-dev libpython2.7 libpython2.7-dev python-all python-all-dev python-dev python2.7-dev zlib1g-dev 0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 29.5 MB of archives. After this operation, 46.5 MB of additional disk space will be used. Get:1 http://httpredir.debian.org/debian sid/main amd64 python-all amd64 2.7.11-1 [936 B] Get:2 http://httpredir.debian.org/debian sid/main amd64 libpython2.7 amd64 2.7.11-9 [1068 kB] Get:3 http://httpredir.debian.org/debian sid/main amd64 libexpat1-dev amd64 2.1.1-1 [126 kB] Get:4 http://httpredir.debian.org/debian sid/main amd64 libpython2.7-dev amd64 2.7.11-9 [27.8 MB] Get:5 http://httpredir.debian.org/debian sid/main amd64 libpython-dev amd64 2.7.11-1 [19.6 kB] Get:6 http://httpredir.debian.org/debian sid/main amd64 libpython-all-dev amd64 2.7.11-1 [952 B] Get:7 http://httpredir.debian.org/debian sid/main amd64 python2.7-dev amd64 2.7.11-9 [278 kB] Get:8 http://httpredir.debian.org/debian sid/main amd64 python-dev amd64 2.7.11-1 [1116 B] Get:9 http://httpredir.debian.org/debian sid/main amd64 python-all-dev amd64 2.7.11-1 [956 B] Get:10 http://httpredir.debian.org/debian sid/main amd64 cdbs all 0.4.132 [79.1 kB] Get:11 http://httpredir.debian.org/debian sid/main amd64 zlib1g-dev amd64 1:1.2.8.dfsg-2+b1 [206 kB] Fetched 29.5 MB in 0s (86.0 MB/s) Selecting previously unselected package python-all. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23084 files and directories currently installed.) Preparing to unpack .../python-all_2.7.11-1_amd64.deb ... Unpacking python-all (2.7.11-1) ... Selecting previously unselected package libpython2.7:amd64. Preparing to unpack .../libpython2.7_2.7.11-9_amd64.deb ... Unpacking libpython2.7:amd64 (2.7.11-9) ... Selecting previously unselected package libexpat1-dev:amd64. Preparing to unpack .../libexpat1-dev_2.1.1-1_amd64.deb ... Unpacking libexpat1-dev:amd64 (2.1.1-1) ... Selecting previously unselected package libpython2.7-dev:amd64. Preparing to unpack .../libpython2.7-dev_2.7.11-9_amd64.deb ... Unpacking libpython2.7-dev:amd64 (2.7.11-9) ... Selecting previously unselected package libpython-dev:amd64. Preparing to unpack .../libpython-dev_2.7.11-1_amd64.deb ... Unpacking libpython-dev:amd64 (2.7.11-1) ... Selecting previously unselected package libpython-all-dev:amd64. Preparing to unpack .../libpython-all-dev_2.7.11-1_amd64.deb ... Unpacking libpython-all-dev:amd64 (2.7.11-1) ... Selecting previously unselected package python2.7-dev. Preparing to unpack .../python2.7-dev_2.7.11-9_amd64.deb ... Unpacking python2.7-dev (2.7.11-9) ... Selecting previously unselected package python-dev. Preparing to unpack .../python-dev_2.7.11-1_amd64.deb ... Unpacking python-dev (2.7.11-1) ... Selecting previously unselected package python-all-dev. Preparing to unpack .../python-all-dev_2.7.11-1_amd64.deb ... Unpacking python-all-dev (2.7.11-1) .
[Reproducible-builds] SORCE_DATE_EPOCH_TEX_PRIMITIVES
Hi. The support of SOURCE_DATE_EPOCH added in pdftex/dvipdfm-x is great, and does a very good job at building reproducible binary software packages. SOURCE_DATE_EPOCH allows to fix the metadata timestamps in the compiled document, and when SOURCE_DATE_EPOCH_TEX_PRIMITIVES is set to 1, the tex primitives \year, \month etc. are also fixed, so that for example \today refers to the date given by SOURCE_DATE_EPOCH. The SOURCE_DATE_EPOCH environment variable is always used to get reproducible builds, and in this context, SOURCE_DATE_EPOCH_TEX_PRIMITIVES is always set to 1. This is fine when working with tex documents only. However in a more general context, for example debian reproducible build effort [1] (which has equivalents for other distributions [2]), the need to set another tool-specific environment variable has been criticized: adding such tool-specifc envvar handling in general package-building tools is considered to be endless and so discarded. Therefore, I would like to support a solution where the default value of SOURCE_DATE_EPOCH_TEX_PRIMITIVES is set to to 1. It has already been mentioned by Norman Gray [3]. The only drawback is that we brake backward-compatibility in a situation where someone already uses SOURCE_DATE_EPOCH for another task, and don't set SOURCE_DATE_EPOCH_TEX_PRIMITIVES. In this situation, the default value 0 of SOURCE_DATE_EPOCH_TEX_PRIMITIVES allows this user to get the same content in the compiled document. I do think this situation is very unlikely. Another solution is to drop SOURCE_DATE_EPOCH_TEX_PRIMITIVES as if it is always set to 1, but I understand that it has to be kept if someone thinks it can be useful. Whatever will be your answer, I thank you again for your welcome regarding reproducibility questions. Regards, Alexis Bienvenüe. [1] https://wiki.debian.org/ReproducibleBuilds/ [2] https://reproducible-builds.org/ [3] https://www.tug.org/pipermail/tex-k/2016-May/002703.html ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Python-modules-team] Bug#824266: mkdocs: Please support SOURCE_DATE_EPOCH specification for build time stamps
Hi Brian, Brian May wrote: > Axel Beckert writes: > > mkdocs integrates build time stamps into the documentation it is > > generating. This makes at least unburden-home-dir no more reproducibly > > building because it now uses mkdocs to generate HTML documentation at > > build time. > > Is this something that should be forwarded upstream? The Reproducible Builds folks definitely would be happy if this could be incorporated upstream, yes. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] SORCE_DATE_EPOCH_TEX_PRIMITIVES
(I ask that everyone spend some undisturbed and unpressured time to read and
digest what I'm about to write. Hopefully this way we can avoid unnecessary
redundant replies that don't contribute new information and only risk adding
fuel to any potential flamewars.)
Alexis Bienvenüe:
> Therefore, I would like to support a solution where the default value of
> SOURCE_DATE_EPOCH_TEX_PRIMITIVES is set to to 1.
If I understand correctly, tex-k are pointing out that there is a semantic
difference between:
1. implicit timestamps in .tar/.pdf that nobody explicitly told tar/pdf to write
2. explicit calls to time()-equivalents in Turing-complete languages, such as
\today in TeX
Yes, we did not explore this issue in enough depth when we originally wrote the
SOURCE_DATE_EPOCH spec. Indeed, #2 is exactly why we don't simply patch time(2)
ourselves in glibc and be done with it - it does indeed break some use-cases of
Turing-complete languages. For example it breaks make(1) which is a very
important part of our build ecosystem. I can understand being cautious, when
you are parsing a Turing-complete language where #2 *might* have unsafe
corner-cases; you don't want to potentially break things that are
time-sensitive.
However, in the scenarios that are relevant to PDF generators, we at R-B
believe that #2 is *always safe* . Even if your input-language is
Turing-complete, whenever you are generating some output data from some input
data in a build process, *this should not be time-sensitive or require a "real"
clock*. In other words, even if TeX-as-a-general-programming-language may need
to be cautious about how it interprets \today, in the context of
parsing-a-TeX-file-to-generate-PDFs, this cautiousness is unnecessary and leads
to overcomplexity.
Based on this reasoning, our current preferences for pdftex behaviour are:
# Proposal 0 ("ideal" solution for the R-B team)
Use SOURCE_DATE_EPOCH unconditionally for case #2 [*], for the reason in the
previous paragraph - i.e. that pdftex will never need to interpret \today in a
time-sensitive context, even if TeX in general might need to do that.
[*] i.e. as well as case #1 which is uncontroversial
# Proposal 1
Default SOURCE_DATE_EPOCH_TEX_PRIMITIVES to 1 as Alexis suggested, so that case
#2 defaults to honouring SOURCE_DATE_EPOCH, and people doing reproducible
builds don't need to learn a new flag/envvar for every new tool.
To allow time-sensitive TeX programs to safely handle corner cases arising out
of case #2, you can do it like this:
a. the tex interpreter libraries could have an internal "use-SDE-as-\today"
option that defaults to being "no"
b. the pdftex *program* knows that it is using TeX purely in a
document-building context which is *not* time-sensitive, and can set this
internal option as "yes" by default, even if SOURCE_DATE_EPOCH_TEX_PRIMITIVES
is not present. If the user set SOURCE_DATE_EPOCH_TEX_PRIMITIVES=0 explicitly,
then it can set the internal option back to "no".
# Proposal 2
If you are unwilling to have case #2 above use SOURCE_DATE_EPOCH by default,
then my suggestion is to rename SOURCE_DATE_EPOCH_TEX_PRIMITIVES to a more
generic name like USE_CLOCK_SOURCE_DATE.
This is just my personal preference and we the R-B team haven't reached
consensus on this yet. My motivation for this name is that it mirrors the POSIX
clock id constants CLOCK_REALTIME, CLOCK_MONOTONIC etc. You can read it
colloquially as "use CLOCK_SOURCE_DATE [instead of CLOCK_REALTIME]", where
CLOCK_SOURCE_DATE can be thought of as a fake constant clock that always
returns SOURCE_DATE_EPOCH. (Of course this is not actually in the POSIX
standard, but the other clocks are.)
For more context see `man 2 clock_gettime` or
http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_getres.html.
X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#824413: binutils: please make the build reproducible
Source: binutils Version: 2.26-9 Severity: wishlist Tags: patch X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi, Whilst working on the "reproducible builds" effort [0], we noticed that binutils could not be built reproducibly. Patch attached that makes the existing sed calls case-insensitive. [0] https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/debian/rules b/debian/rules index ec9d67c..2d211df 100755 --- a/debian/rules +++ b/debian/rules @@ -1279,7 +1279,7 @@ binary.%: stamps/install.% install ifeq ($(with_check),yes) : # remove user and date from test-summary for reproducible builds - sed -i -e '/Test Run By/d' test-summary-$* + sed -i -e '/Test Run By/Id' test-summary-$* $(install_file) test-summary-$* \ $(D_CROSS)/$(PF)/share/doc/$(P_CROSS)/test-summary gzip -9nf $(D_CROSS)/$(PF)/share/doc/$(P_CROSS)/test-summary @@ -1444,7 +1444,7 @@ endif ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) ifeq ($(with_check),yes) : # remove user and date from test-summary for reproducible builds - sed -i -e '/Test Run By/d' $(pwd)/test-summary + sed -i -e '/Test Run By/Id' $(pwd)/test-summary $(install_file) $(pwd)/test-summary $(d_bin)/$(PF)/share/doc/$(p_bin)/ endif endif ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#824420: python-phply: Building with DEB_BUILD_OPTIONS="nocheck" causes parsetab.py not to be included
Package: python-phply Version: 0.9.1-3 Severity: minor User: reproducible-builds@lists.alioth.debian.org Usertags: randomness Dear Maintainer, While checking this package with the reproducible builds[1] tool chain, I noticed that building the package with DEB_BUILD_OPTIONS="nocheck" set causes the file parsetab.py not to be included in the final .deb, because the tests are what cause parsetab.py to be generated. Another PLY-based package, pycparser, has a specific file _build_tables.py[2] that's called by setup.py and by the debian version's rules[3] to build the parse tables during installation, so a similar solution would probably work for python-phply. [1]: https://wiki.debian.org/ReproducibleBuilds [2]: https://github.com/eliben/pycparser/blob/master/pycparser/_build_tables.py [3]: https://anonscm.debian.org/viewvc/python-modules/packages/pycparser/trunk/debian/rules?revision=34279&view=markup -- System Information: Debian Release: jessie/sid APT prefers wily-updates APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), (100, 'wily-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-35-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
