packages that FTBFS twice in a row ...

[Andreas Beckmann]

Hi,

here are my observations after analyzing a few pbuilder --twice failures
in experimental. I only did full (source+arch+indep) builds.


The command sequence being tested is roughly:

1. debian/rules clean
2. dpkg-source
3. debian/rules build binary
4. debian/rules clean
5. dpkg-source
6. debian/rules build binary

1.-3. are utilized by regular builds and tested by normal archive-wide
rebuilds, therefore I'll only consider packages passing these steps.

Possible failure scenarios for the second build:

4. debian/rules clean
   There are bugs related to make distclean and debian/rules clean, they
   usually don't show up during 1. since the source tree is not in a
   configured state (no Makefile?) and the debian/ tree is not in a
   built state.

   a) make distclean may fail, probably an upstream bug
  * #884898, icu/experimental, parallel distclean race

   b) passes, but leaves new/modified files in the source tree
  * This is the majority of bugs, usually generated filed don't get
deleted properly. The subsequent error from dpkg-source is
pretty obvious.

   c) passes, but leaves new/modified in the debian/ tree
  * #884419, #884815: override_dh_clean does not run dh_clean
resulting in debian/$PKG/ package build directories and
debhelper logfiles being left in the tree. Subsequent
dpkg-source will choke on unknown binary files under debian/
There is a lintian check coming: #884817 "lintian: check for
override_dh_clean target missing call to dh_clean".
  * there may be text-only changes in debian/ that don't trigger
errors, but cause differing source package to be built in 2./5.

   d) passes, but deletes files that cannot be regenerated
  * #884706, #884813, #884819, #884889
This passes the subsequent dpkg-source (since it will just warn
on deleted files by default, which is very convient to get rid
of generated files that are shipped in the upstream tarball),
but will fail during the following build

5. dpkg-source

   a) may fail as a consequence of 4.b), 4.c)

   b) may build a source package that differs from the one built in 2.
  Testing for these bugs easily may need some new features in
  pbuilder, e.g. a --one-and-a-half option :-)
  A possible candidate is git/experimental 1:2.15.1+next.20171214-1
  which should add a 'debian/git-core/usr/share/doc/git-core -> git'
  symlink (#884890).

6. debian/rules build binary

   a) may fail as a consequence of 4.d)


How could we check for these bugs?

I think the interesting failures to look for are 4.a), 5.b), 6.a)
(leaving out the probabe majority 5.a)), since they may make working
with the packages difficult by failing in non-obvious ways. I would also
consider these as RC.

We would probably need some enhancements for pbuilder to allow testing
points 4. and 5. without doing a full --twice run. Also I don't know
whether it is easily possible to classify pbuilder --twice failures to
the command that failed and whether it was first or second build.

Given proper pbuilder support (deliver build result from the first build
even if 4. debian/rules clean failed), testing for 4.a) should be
trivially possible to do for reproducible builds with only marginal
computation time requirements.

Does the reproducible build effort currently test for reproducibility of
source packages? In that case testing for 5.b) could hopefully be done
with reproducible builds as well, it would just require another
dpkg-source call. Failures for 5.a) could be filtered out unless someone
volunteers for the bug filing.

Testing for 6.a) effectively doubles the compute power needed for a
rebuild test, so maybe that should be rather left to infrequent
specialized archive-wide rebuilds.


Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#877473: diffoscope: crashes on malformed fonts-humor-sans_1.0-2_all.deb: IndexError: string index out of range

[Andreas Beckmann]

Package: diffoscope
Version: 78
Severity: important

$ debsnap -d . -a all fonts-humor-sans 1.0-1
$ debsnap -d . -a all fonts-humor-sans 1.0-2
$ diffoscope fonts-humor-sans_1.0-1_all.deb fonts-humor-sans_1.0-2_all.deb
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 412, in main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 384, in 
run_diffoscope
difference = compare_root_paths(path1, path2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
65, in compare_root_paths
return compare_files(file1, file2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
104, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 351, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 306, in _compare_using_details
details.extend(self.as_container.compare(other.as_container, 
no_recurse=no_recurse))
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 169, in compare_pair
difference = compare_files(file1, file2, source=None, 
diff_content_only=no_recurse)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
104, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 351, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 306, in _compare_using_details
details.extend(self.as_container.compare(other.as_container, 
no_recurse=no_recurse))
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 169, in compare_pair
difference = compare_files(file1, file2, source=None, 
diff_content_only=no_recurse)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
104, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 351, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 306, in _compare_using_details
details.extend(self.as_container.compare(other.as_container, 
no_recurse=no_recurse))
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 169, in compare_pair
difference = compare_files(file1, file2, source=None, 
diff_content_only=no_recurse)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
104, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 351, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 297, in _compare_using_details
details.extend(self.compare_details(other, source))
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 
157, in compare_details
self.path, other.path, source="line order")]
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 224, in 
from_text_readers
**kwargs
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 182, in 
from_feeder
unified_diff = diff(feeder1, feeder2)
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 252, in diff
return run_diff(fifo1_path, fifo2_path, fifo1.end_nl_q, fifo2.end_nl_q)
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 209, in 
__exit__
self.join()
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 242, in join
raise self._exception
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 233, in run
end_nl = self.feeder(fifo)
  File "/usr/lib/python3/dist-packages/diffoscope/feeders.py", line 58, in 
feeder
end_nl = buf[-1] == '\n'
IndexError: string index out of range


I noticed this in a stretch(+ some buster) system, and verified it in a sid 
chroot
(the traceback is from sid).

fonts-humor-sans_1.0-2_all.deb seems to have a malformed md5sums file
(at least a piuparts helper script failed to parse it.)


Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] second i386 build performed on amd64 host without using linux32

[Andreas Beckmann]

Hi,

I just analyzed the FTBFS of libpfm4 in unstable/i386:
https://tests.reproducible-builds.org/rb-pkg/unstable/i386/libpfm4.html

[...]
 dh_auto_build
make -j1
-make[2]: Entering directory '/build/libpfm4-4.7.0'
-Compiling for 'i386' target
+make[2]: Verzeichnis „/build/libpfm4-4.7.0“ wird betreten
+Compiling for 'x86_64' target
 Compiling for 'Linux' system
[...]

The build system uses 'uname -m' to determine which CPUs are the target,
and obviously in the i386 chroot for the second build this returns
'x86_64'. I had the same problem when building in i386 pbuilder on an
amd64 host, but explicitly running it under 'linux32' fixed this for me.

Using 'uname -m' might not have been the best choice for upstream to
detect the architecture ...

This was only a problem in the second build, so that pbuilder seems to
configured differently than the first one.

The buildds obviously don't show this problem, so seem to run under
linux32 on an amd64 host.

Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] wrong recipe for FileOrderInTarballs

[Andreas Beckmann]

https://wiki.debian.org/ReproducibleBuilds/FileOrderInTarballs

suggests

find|sort | tar --null -T - --no-recursion -cf archive.tar

but the --no-recursion is applied at the wrong place - it must come
before the file list.

This was "fixed" in tar 1.28 (in stretch/sid):
2014-01-10  Sergey Poznyakoff  

Fix the use of --no-recursion and --recursion options.

Each option remains in effect until cancelled by the next
ocurrence
of its counterpart, as stated in the documentation.

so that recipe should probably be

find|sort | tar --no-recursion --null -T - -cf archive.tar


Now let me find all packages where I applied this ...

http://codesearch.debian.net/results/--no-recursion%20path%3Adebian%2Frules/page_0

Hmm, not that helpful ...


Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] reproducibility of precompiled headers (*.pch)?

[Andreas Beckmann]

Hi,

did anyone look into generating precompiled headers in a reproducible
way? I've now found a second package being unreproducible due to this:

* beignet - in the archive:
https://reproducible.debian.net/rb-pkg/unstable/amd64/beignet.html
* oclgrind - about to be packaged:
git://anonscm.debian.org/pkg-opencl/oclgrind.git


Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used

[Andreas Beckmann]

[ please keep me Cc:ed ]

Hi,

I'm just looking into reproducibility of fglrx-driver/non-free and saw
some toolchain issue resulting in unreproducible packages:


debdiff b1/amd-clinfo_15.5-2_amd64.deb b2/amd-clinfo_15.5-2_amd64.deb
(manually wrapped for better readability)

File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends:
  libc6 (= 2.3.3),
  libgcc1 (= 1:4.1.1),
  ocl-icd-libopencl1 | amd-libopencl1 | libopencl1,
  ocl-icd-libopencl1 (= 1.0) | amd-libopencl1 | [-libopencl-1.2-1,-]
{+libopencl-1.1-1,+}
  ocl-icd-libopencl1 (= 1.0) | amd-libopencl1 | [-libopencl-1.1-1-]
{+libopencl-1.2-1+}


The only difference is the ordering of the dependencies generated by
dh_shlibdeps (?).

The symbols file from amd-libopencl1 that is used to generate these
dependencies makes use of alternate dependency templates and more than
one of the alternate templates are needed for the final dependencies:

===
# snipped some paragraphs of comments
libOpenCL.so.1 ocl-icd-libopencl1 | #PACKAGE# #MINVER# | libopencl1
# symbols specific to this implementation - would forbid using alternate
implementations
| #PACKAGE# #MINVER#
# symbols conforming to the OpenCL standards - can use alternate
implementations
| ocl-icd-libopencl1 (= 1.0)   | #PACKAGE# #MINVER# | libopencl-1.1-1
| ocl-icd-libopencl1 (= 1.0)   | #PACKAGE# #MINVER# | libopencl-1.2-1
| ocl-icd-libopencl1 (= 2.2.0) | #PACKAGE# #MINVER# | libopencl-2.0-1
# As AMD uses versioned symbols, we use this information instead of
# listing all symbols.
 (symver|optional)OPENCL_1.0 0 2
 (symver|optional)OPENCL_1.1 0 2
 (symver|optional)OPENCL_1.2 0 3
 (symver|optional)OPENCL_2.0 1:14 4
===

Andreas

PS: As an additional reproducibility torturing measure I used the
pbuilder --twice option for the first build.

PPS: Similarly complex symbols files are used by ocl-icd-libopencl1
and nvidia-libopencl1, too.

PPPS: I haven't tried to see whether this unreproducibility is reproducible.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used

[Andreas Beckmann]

On 2015-07-09 18:38, Holger Levsen wrote:
 PPS: Similarly complex symbols files are used by ocl-icd-libopencl1
 and nvidia-libopencl1, too.
 are these both only in non-free too?
 ocl-icd is in main
 
 and reproducible when tested in our setup: 
 https://reproducible.debian.net/ocl-icd

no, you need to test something that uses both OpenCL 1.1 and OpenCL 1.2
functions, e.g. amd-clinfo, erlang-cl, python{,3}-pyopencl{,-dbg}. That
list is complete - all rdepends of the libopencl-1.2-1 virtual package.


The issue is nondeterministic - a first rebuild after partly fixing
another reproducibility issue has not shown this again.

Andreas


___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] checking that build succeeds in funny paths like .../1:2.3+4~5-6/...

[Andreas Beckmann]

(please keep me Cc:ed, I'm not subscribed)

Hi,

while your are doing rebuilds to check reproducibility, maybe you could
also check that the packages build in a path that contains all chars
that are allowed in version numbers. IIRC I had seen failures to do so
twice quite recently, one was beignet, the other I forgot.

You usually run into such problems when doing backports or stable
updates since the version number suddenly gains '+' and/or '~'.
And then you need to work around this for backports/stable 

As I understand you don't test reproducability with changing the build
directory (seems to be embedded in too many places), so this change
would need to be done for both rebuilds.

Putting something like this in an A hook script (after
reproduciblebuilds_user) seems to work fine with pbuilder:

mkdir -p /tmp/build
mv /tmp/buildd /tmp/build/pkg-1:2.3+4~5-6
ln -s build/pkg-1:2.3+4~5-6 /tmp/buildd

it does not break pbuilder's assumption to build in /tmp/buildd, but all
attempts to get the absolute buildroot path will contain 1:2.3+4~5-6


Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#779248: dh-strip-nondeterminism: format error: CRC or size mismatch while skipping data descriptor

[Andreas Beckmann]

Package: dh-strip-nondeterminism
Version: 0.005-2
Severity: normal

Hi,

just saw this while checking reproducability of nvidia-cuda-toolkit 6.5:

   dh_strip_nondeterminism
format error: CRC or size mismatch while skipping data descriptor 
 at /usr/share/perl5/File/StripNondeterminism/handlers/jar.pm line 90.
Can't write to /tmp/vWs6TadgEK.zip 
 at /usr/bin/dh_strip_nondeterminism line 79.
format error: CRC or size mismatch while skipping data descriptor 
 at /usr/share/perl5/File/StripNondeterminism/handlers/jar.pm line 90.
Can't write to /tmp/KRnR3oiouJ.zip 
 at /usr/bin/dh_strip_nondeterminism line 79.

The package ships jar files provided upstream, maybe they don't
conform to ones produced by Debian tools.


Andreas

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds