Re: Use lazy unmount for disorderfs on jenkins.debian.net

2016-11-15 Thread Holger Levsen
On Tue, Nov 15, 2016 at 11:59:08AM -0800, Vagrant Cascadian wrote:
> Using lazy unmount *might* allow the disorderfs filesystems to unmount
> if a file descriptor is held open but later releases... worst case is it
> shouldn't make anything worse.
> 
> available in "lazy-unmount" branch at:
> 
>   https://anonscm.debian.org/git/users/vagrant/jenkins.debian.net.git

thanks, deploying…!


-- 
cheers,
Holger


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

Use lazy unmount for disorderfs on jenkins.debian.net

2016-11-15 Thread Vagrant Cascadian
Retrying without the diff, since that got moderated...

Using lazy unmount *might* allow the disorderfs filesystems to unmount
if a file descriptor is held open but later releases... worst case is it
shouldn't make anything worse.

available in "lazy-unmount" branch at:

  https://anonscm.debian.org/git/users/vagrant/jenkins.debian.net.git

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

Help with SCALE 15x submission *today*

2016-11-15 Thread Vagrant Cascadian
Hi, Just heard about the SCALE CfP this weekend, and it's due *today*,
so am working on re-doing the talk I did at SeaGL, but could use help on
the long description. I've put up a pad for this with links to my SeaGL
slides:

  https://pad.riseup.net/p/1Q5KsaDJnnis

If anyone could help extending the summary into a longer description,
it'd be appreciated! Making sure to put in enough extra detail, but not
too much... if you've got some time today, ping me on irc and we can
start editing...

Thanks!


The short summary I have so far:

Introduction to Reproducible builds

The Reproducible Builds project creates infrastructure and fixes
upstream code so that binaries can be independently verified as the
result of compiling source code. Without verifying the connection
between source code and binary software, toolchains become a tempting
target to inject exploits.

This talk will demonstrate why reproducibility matters, common issues
and fixes, and tools used to identify and troubleshoot issues, moving
towards reproducibility as a set of best practices when developing and
improving software.

https://reproducible-builds.org


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

Bug#844433: libdr-tarantool-perl: Non-determistically FTBFS due to unreliable tests

2016-11-15 Thread Chris Lamb
Source: libdr-tarantool-perl
Version: 0.45-2
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,

libdr-tarantool-perl's testsuite appears to non-deterministically fail, causing 
itself to FTBFS.

Using wall-clock time is inherently unreliable.

  […]
  
  #   Failed test 'total time less than 1 second'
  #   at t/090-parallel-requests.t line 153.
  # '8.6400101184845'
  # <=
  # '1'
  # Looks like you failed 1 test of 48.
  t/090-parallel-requests.t ... 
  1..48
  ok 1 - use DR::Tarantool::LLClient;
  ok 2 - use DR::Tarantool;
  ok 3 - use File::Spec::Functions;
  ok 4 - use File::Basename;
  ok 5 - use AnyEvent;
  ok 6 - use DR::Tarantool::AsyncClient;
  ok 7 - directory with test data
  ok 8 - t/test-data/llc-easy2.cfg
  ok 9 - -d t/test-data
  ok 10 - -r t/test-data/init.lua
  ok 11 - An object of class 'DR::Tarantool::AsyncClient' isa 
'DR::Tarantool::AsyncClient'
  ok 12 - first call test_parallel: status
  ok 13 - return value
  ok 14 - id: 6
  ok 15 - delay minimum
  ok 16 - delay maximum
  ok 17 - id: 1
  ok 18 - delay minimum
  ok 19 - delay maximum
  ok 20 - id: 4
  ok 21 - delay minimum
  ok 22 - delay maximum
  ok 23 - id: 7
  ok 24 - delay minimum
  ok 25 - delay maximum
  ok 26 - id: 3
  ok 27 - delay minimum
  ok 28 - delay maximum
  ok 29 - id: 10
  ok 30 - delay minimum
  ok 31 - delay maximum
  ok 32 - id: 2
  ok 33 - delay minimum
  ok 34 - delay maximum
  ok 35 - id: 5
  ok 36 - delay minimum
  ok 37 - delay maximum
  ok 38 - id: 9
  ok 39 - delay minimum
  ok 40 - delay maximum
  ok 41 - id: 8
  ok 42 - delay minimum
  ok 43 - delay maximum
  ok 44 - id: 0
  ok 45 - delay minimum
  ok 46 - delay maximum
  ok 47 - total time
  not ok 48 - total time less than 1 second
  Dubious, test returned 1 (wstat 256, 0x100)
  Failed 1/48 subtests 

  […]

The full build log is attached or can be viewed here:


https://tests.reproducible-builds.org/debian/logs/unstable/amd64/libdr-tarantool-perl_0.45-2.build2.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


libdr-tarantool-perl.0.45-2.logs.unstable.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#844431: Packages should be reproducible

2016-11-15 Thread Chris Lamb
Package: debian-policy
Version: 3.9.8.0
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Policy maintainers,

Whilst anyone can inspect the source code in Debian for malicious
flaws, we distribute pre-compiled to end users. The motivation behind
the Reproducible Builds effort is to permit verification that no flaws
have been introduced — either maliciously or accidentally — during this
compilation process by promising identical results are always generated
from a given source, thus allowing multiple third-parties to come to a
consensus on whether a build was compromised.

Debian has been making great strides to make itself reproducible,
contributing 100s patches, not only within Debian itself but also to
upstream projects. We have also been running a comprehensive and non-
trivial CI framework to test for reproducibility of packages for quite
some time.

However, the recent arrival of the final pieces of the toolchain into
unstable encourages me to propose that we add a recommendation that
packages in Debian should be reproducible.

This would be act both as documentation of a modern best practice, but
also act as a "placeholder" so that we can increase its severity at some
future date.

[As a mild suggestion to streamline this; we should probably come to some
consensus on principle of this addition to Policy first and only then
move to the more difficult topic of defining exactly what reproducibility
means in a technical sense.]


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

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

Bug#817193: failing tests with v62: test_listing, test_diff test_gzip.py::test_metadata, test_ipk.py::test_metadata, test_java.py::test_diff

2016-11-15 Thread Zbigniew Jędrzejewski-Szmek
I noticed that I was missing ppudmp from my installation, so tests
were skipped.  Once it is installed, the ppu tests also fail. Looks
like a programming error, PpuFile is File, not FilesystemFile from a
quick look.

=== FAILURES ===
_ test_identification __

file1 = < 
/builddir/build/BUILD/diffoscope/tests/data/test1.ppu>

@skip_unless_tools_exist('ppudump')
def test_identification(file1):
>   assert isinstance(file1, PpuFile)
E   assert isinstance(< 
/builddir/build/BUILD/diffoscope/tests/data/test1.ppu>, PpuFile)

tests/comparators/test_ppu.py:46: AssertionError
__ test_diff ___

differences = []

@skip_unless_tool_is_older_than('ppudump', ppudump_version, '3.0.0')
def test_diff(differences):
>   print(differences[0].unified_diff)
E   IndexError: list index out of range

tests/comparators/test_ppu.py:58: IndexError
__ test_compare_non_existing ___

monkeypatch = <_pytest.monkeypatch.monkeypatch object at 0xf3f7c52c>
file1 = < 
/builddir/build/BUILD/diffoscope/tests/data/test1.ppu>

@skip_unless_tool_is_older_than('ppudump', ppudump_version, '3.0.0')
def test_compare_non_existing(monkeypatch, file1):
>   assert_non_existing(monkeypatch, file1, has_null_source=False)

tests/comparators/test_ppu.py:64: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

monkeypatch = <_pytest.monkeypatch.monkeypatch object at 0xf3f7c52c>
fixture = < 
/builddir/build/BUILD/diffoscope/tests/data/test1.ppu>
has_null_source = False, has_details = True

def assert_non_existing(monkeypatch, fixture, has_null_source=True, 
has_details=True):
monkeypatch.setattr(Config(), 'new_file', True)
assert Config().new_file, "didnt get patched"

difference = fixture.compare(NonExistingFile('/nonexisting', fixture))

output_html(difference, print_func=print)
output_text(difference, print_func=print)

assert difference.source2 == '/nonexisting'
>   assert not has_details or len(difference.details) > 0
E   assert (not True or 0 > 0)
E+  where 0 = len([])
E+where [] = .details

tests/comparators/utils.py:79: AssertionError

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


Re: Bug on builder of reproducible-builds?

2016-11-15 Thread Holger Levsen
On Wed, Nov 16, 2016 at 01:43:15AM +0900, Roger Shimizu wrote:
> I'm not sure what happened, but now much older version 20080615-16 is
> in incoming [0],

you need to talk to the ftpteam about this.

> and reproducible-builds still have error on the right side of first page [1].

thanks, I've removed the note now that #842835 is fixed. the page will
be updated in a few minutes.


-- 
cheers,
Holger


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

Bug#817193: failing tests with v62: test_listing, test_diff test_gzip.py::test_metadata, test_ipk.py::test_metadata, test_java.py::test_diff

2016-11-15 Thread Zbigniew Jędrzejewski-Szmek
=== FAILURES ===
_ test_listing _

differences = [, 
]

@skip_unless_tools_exist('cbfstool')
def test_listing(differences):
expected_diff = open(data('cbfs_listing_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   assert '@@ -1,3 +1,3...  31896\n' == '@@ -1,6 +1,3 ...  31896\n'
E - @@ -1,3 +1,3 @@
E ?   ^
E + @@ -1,6 +1,3 @@
E ?   ^
E + -32 kB, bootblocksize 0, romsize 32768, offset 0x0
E + -alignment: 64 bytes, architecture: x86
E + -
EName   Offset Type Size
E   -text   0x0raw  446
E   -(empty)0x200  null 32152
E   +text   0x0raw  671
E   +(empty)0x300  null 31896

tests/comparators/test_cbfs.py:79: AssertionError
 Captured stdout setup -
--- /tmp/pytest-of-zbyszek/pytest-1/test_listing0/coreboot1
+++ /tmp/pytest-of-zbyszek/pytest-1/test_listing0/coreboot2.rom
├── cbfstool {} print
│ @@ -1,3 +1,3 @@
│  Name   Offset Type Size
│ -text   0x0raw  446
│ -(empty)0x200  null 32152
│ +text   0x0raw  671
│ +(empty)0x300  null 31896
├── text
│ @@ -1,6 +1,12 @@
│ +A common form of lorem ipsum reads:
│ +
│  Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
tempor
│  incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
│  nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
│  Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore 
eu
│  fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt 
in
│  culpa qui officia deserunt mollit anim id est laborum.
│ +
│ +"Lorem ipsum" text is derived from sections 1.10.32--3 of Cicero's De finibus
│ +bonorum et malorum (On the Ends of Goods and Evils, or alternatively [About]
│ +The Purposes of Good and Evil).
╵
 Captured stderr setup -
Created CBFS (capacity = 32664 bytes)
Created CBFS (capacity = 32664 bytes)
__ test_diff ___

differences = []

@skip_unless_tools_exist('cd-iccdump')
def test_diff(differences):
expected_diff = open(data('icc_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   assert '@@ -1,20 +1,... [24 bytes]\n' == '@@ -1,20 +1,2... [24 bytes]\n'
E   @@ -1,20 +1,20 @@
Eicc:
EHeader:
E  Size = 14684 bytes
E  Version  = 4.3
E  Profile Kind = display-device
E  Colorspace   = rgb
E  Conn. Space  = xyz
E   -  Date, Time   = 2016-02-15, 21:02:09
E   +  Date, Time   = 2016-02-15, 21:03:22
E  Flags= Not embedded profile, Use anywhere
E  Dev. Attrbts = reflective, glossy
E  Rndrng Intnt = perceptual
E  Creator  = lcms
E   -  Profile ID   = 0x0477fa4b
E   +  Profile ID   = 0x06017f17
E
Etag 00:
E  sig  'desc' [0x64657363]
E  size 38
E  type 'mluc' [0x6d6c7563]
EText:
E -ne_SU:   sRGB [24 bytes]
E ? -  -
E +en_US:   sRGB [24 bytes]
E ?+  +

tests/comparators/test_icc.py:45: AssertionError
== 2 failed, 208 passed, 38 skipped in 41.30 seconds ===

test_differences, which was failing before, now passes.

Zbyszek

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

Re: Bug on builder of reproducible-builds?

2016-11-15 Thread Roger Shimizu
On Tue, Nov 15, 2016 at 11:40 PM, Holger Levsen  wrote:
>
> I've triggered rebuilds of wide-dhcpv6 on armhf for unstable+testing
> now, hoping the results will be clearer.

I'm not sure what happened, but now much older version 20080615-16 is
in incoming [0],
and reproducible-builds still have error on the right side of first page [1].

The latest version should be 20080615-18.

[0] https://incoming.debian.org/debian-buildd/pool/main/w/wide-dhcpv6/
[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wide-dhcpv6.html

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

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


Bug#844429: libpng1.6: FTBFS: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC

2016-11-15 Thread Chris Lamb
Source: libpng1.6
Version: 1.6.26-1
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,

libpng1.6 fails to build from source in unstable/amd64:

  […]

  checking whether gcc accepts -g... yes
  checking for gcc option to accept ISO C89... none needed
  checking whether gcc understands -c and -o together... yes
  checking for style of include used by make... GNU
  checking dependency style of gcc... none
  checking dependency style of gcc... none
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking for a sed that does not truncate output... /bin/sed
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for fgrep... /bin/grep -F
  checking how to print strings... printf
  checking for ld used by gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking how to run the C preprocessor... gcc -E
  checking for gawk... (cached) mawk
  checking whether ln -s works... yes
  checking whether make sets $(MAKE)... (cached) yes
  checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
  checking the name lister (/usr/bin/nm -B) interface... BSD nm
  checking the maximum length of command line arguments... 1572864
  checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
  checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
  checking for /usr/bin/ld option to reload object files... -r
  checking for objdump... objdump
  checking how to recognize dependent libraries... pass_all
  checking for dlltool... no
  checking how to associate runtime and link libraries... printf %s\n
  checking for ar... ar
  checking for archiver @FILE support... @
  checking for strip... strip
  checking for ranlib... ranlib
  checking command to parse /usr/bin/nm -B output from gcc object... ok
  checking for sysroot... no
  checking for a working dd... /bin/dd
  checking how to truncate binary pipes... /bin/dd bs=4096 count=1
  checking for mt... no
  checking if : is a manifest tool... no
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... yes
  checking for inttypes.h... yes
  checking for stdint.h... yes
  checking for unistd.h... yes
  checking for dlfcn.h... yes
  checking for objdir... .libs
  checking if gcc supports -fno-rtti -fno-exceptions... no
  checking for gcc option to produce PIC... -fPIC -DPIC
  checking if gcc PIC flag -fPIC -DPIC works... yes
  checking if gcc static flag -static works... yes
  checking if gcc supports -c -o file.o... yes
  checking if gcc supports -c -o file.o... (cached) yes
  checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
  checking whether -lc should be explicitly linked in... no
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
  checking whether to build shared libraries... yes
  checking whether to build static libraries... yes
  checking that AWK works... ok
  checking if we need to force back C standard to C89... no
  checking for ANSI C header files... (cached) yes
  checking for an ANSI C-conforming const... yes
  checking for size_t... yes
  checking whether struct tm is in sys/time.h or time.h... time.h
  checking for C/C++ restrict keyword... __restrict
  checking for working strtod... yes
  checking for memset... yes
  checking for pow... no
  checking for pow in -lm... yes
  checking for clock_gettime... yes
  checking for zlibVersion in -lz... yes
  checking for feenableexcept in -lm... yes
  checking for feenableexcept... yes
  checking if using Solaris linker... no
  checking if libraries can be versioned... yes
  checking for symbol prefix... 
  configure: pkgconfig directory is ${libdir}/pkgconfig
  configure: Extra options for compiler: 
  checking that generated files are newer than configure... done
  configure: creating ./config.status
  config.status: creating Makefile
  config.status: creating libpng.pc
  config.status: creating libpng-config
  config.status: creating config.h
  config.status: executing depfiles commands
  config.status: executing libtool commands
 dh_auto_build
make -j9
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20161115163604.PUXcS2E9fZ.db.libpng1.6/libpng1.6-1.6.26'
  rm -f pnglibconf.c pnglibconf.tf[45]
  mawk -f ./scripts/options.awk out=pnglibconf.tf4 version=search\
  ./pngconf.h ./scripts/pnglibconf.dfa\
 

Bug#844428: jetty9: FTBFS: Could not resolve dependencies for project org.eclipse.jetty:jetty-spring:jar:9.2.19.v20160908: The following artifacts could not be resolved: net.sf.jopt-simple:jopt-simple

2016-11-15 Thread Chris Lamb
Source: jetty9
Version: 9.2.19-2
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,

jetty9 fails to build from source in unstable/amd64:

  […]

  [INFO] Not copying test resources
  [INFO] 
  [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
javax-websocket-server-impl ---
  [INFO] Not compiling test sources
  [INFO] 
  [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ 
javax-websocket-server-impl ---
  [INFO] Tests are skipped.
  [INFO] 
  [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ 
javax-websocket-server-impl ---
  [INFO] Building jar: 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/jetty-websocket/javax-websocket-server-impl/target/javax-websocket-server-impl-9.2.19.v20160908.jar
  [INFO] 
  [INFO] --- maven-site-plugin:2.1:attach-descriptor (attach-descriptor) @ 
javax-websocket-server-impl ---
  [INFO]
 
  [INFO] 

  [INFO] Building Jetty :: Utility Servlets and Filters 9.2.19.v20160908
  [INFO] 

  [INFO] 
  [INFO] --- build-helper-maven-plugin:1.8:parse-version (set-osgi-version) @ 
jetty-servlets ---
  [INFO] 
  [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
jetty-servlets ---
  [INFO] Using 'UTF-8' encoding to copy filtered resources.
  [INFO] skip non existing resourceDirectory 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/jetty-servlets/src/main/resources
  [INFO] 
  [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
jetty-servlets ---
  [INFO] Changes detected - recompiling the module!
  [INFO] Compiling 25 source files to 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/jetty-servlets/target/classes
  [INFO] 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/QoSFilter.java:
 Some input files use unchecked or unsafe operations.
  [INFO] 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/QoSFilter.java:
 Recompile with -Xlint:unchecked for details.
  [INFO] 
  [INFO] --- maven-bundle-plugin:2.5.4:manifest (default) @ jetty-servlets ---
  [INFO] 
  [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
jetty-servlets ---
  [INFO] Not copying test resources
  [INFO] 
  [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
jetty-servlets ---
  [INFO] Not compiling test sources
  [INFO] 
  [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jetty-servlets ---
  [INFO] Tests are skipped.
  [INFO] 
  [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ jetty-servlets ---
  [INFO] Building jar: 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/jetty-servlets/target/jetty-servlets-9.2.19.v20160908.jar
  [INFO] 
  [INFO] --- maven-site-plugin:2.1:attach-descriptor (attach-descriptor) @ 
jetty-servlets ---
  [INFO]
 
  [INFO] 

  [INFO] Building Jetty :: Apache JSP Implementation 9.2.19.v20160908
  [INFO] 

  [INFO] 
  [INFO] --- build-helper-maven-plugin:1.8:parse-version (set-osgi-version) @ 
apache-jsp ---
  [INFO] 
  [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
apache-jsp ---
  [INFO] Using 'UTF-8' encoding to copy filtered resources.
  [INFO] Copying 2 resources
  [INFO] 
  [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ apache-jsp 
---
  [INFO] Changes detected - recompiling the module!
  [INFO] Compiling 3 source files to 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/apache-jsp/target/classes
  [INFO] 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/apache-jsp/src/main/java/org/eclipse/jetty/apache/jsp/JettyJasperInitializer.java:
 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/apache-jsp/src/main/java/org/eclipse/jetty/apache/jsp/JettyJasperInitializer.java
 uses unchecked or unsafe operations.
  [INFO] 
/home/lamby/temp/cdt.20161115163346.zMOxjTS6RM.db.jetty9/jetty9-9.2.19/apache-jsp/src/main/java/org/eclipse/jetty/apache/jsp/JettyJasperInitializer.java:
 Recompile with -Xlint:unchecked for details.
  [INFO] 
  [INFO] --- maven-bundle-plugin:2.5.4:manifest (generate-manifest) @ 
apache-jsp ---
  [INFO] 
  [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
apache-jsp ---
  [INFO] Not copying test resources

Re: Bug on builder of reproducible-builds?

2016-11-15 Thread Roger Shimizu
On Wed, Nov 16, 2016 at 12:08 AM, Holger Levsen  wrote:
>
> yes, it is a known bug, which sometimes happens. Just nobody had the
> time to fix it yet…

Good to know the bug got already catched.
So I'm relieved.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

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

Re: Bug on builder of reproducible-builds?

2016-11-15 Thread Holger Levsen
On Wed, Nov 16, 2016 at 12:05:32AM +0900, Roger Shimizu wrote:
> The rebuilds fixed my problem.

good.

> But I'm still wondering whether it's a bug on builder, which fetched
> old version to compile.

yes, it is a known bug, which sometimes happens. Just nobody had the
time to fix it yet…

> Triggering the rebuild only fixes my package, and it's better if we
> can fix the real problem.

yes… the day only has 24h though ;)


-- 
cheers,
Holger


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

Re: Bug on builder of reproducible-builds?

2016-11-15 Thread Roger Shimizu
Dear Holger,

Thanks for your response!

On Tue, Nov 15, 2016 at 11:40 PM, Holger Levsen  wrote:
>
> I've triggered rebuilds of wide-dhcpv6 on armhf for unstable+testing
> now, hoping the results will be clearer.

The rebuilds fixed my problem.

But I'm still wondering whether it's a bug on builder, which fetched
old version to compile.
Triggering the rebuild only fixes my package, and it's better if we
can fix the real problem.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

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


Bug#844420: FTBFS: tests fail on hosts without network access

2016-11-15 Thread Ximin Luo
Package: glibc
Version: 2.24-5
Severity: important
Tags: upstream patch
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826

Dear Maintainer,

posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
tests.reproducible-builds.org:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz

The attached patch should fix this; I gave a more detailed description in the 
upstream bug report.

It would be good if this were already applied to the Debian glibc so that we 
can begin to see diffoscope output again and work on its reproducibility.

Thanks,
X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Description: Don't condition failure of double-dot-FQDN on single-dot-FQDN
 Otherwise the test fails on systems that disable network access during build
 time, since getaddrinfo() fails in all cases and the test returns 2.
 .
 Normally, such systems can still resolve "localhost." via nsswitch/getent and
 getaddrinfo is not suppose to attempt resolution of "localhost." anyways.
Author: Ximin Luo 
Bug: TBD
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/posix/tst-getaddrinfo5.c
+++ b/posix/tst-getaddrinfo5.c
@@ -36,20 +36,6 @@
   size_t len = strlen (host);
   struct addrinfo *ai;
 
-  /* If the name doesn't resolve with a single dot at the
-	 end, skip it.  */
-  host[len-1] = 0;
-  if (getaddrinfo (host, NULL, NULL, &ai) != 0)
-	{
-	  printf ("resolving \"%s\" failed, skipping this hostname\n", host);
-	  continue;
-	}
-  printf ("resolving \"%s\" worked, proceeding to test\n", host);
-  freeaddrinfo (ai);
-
-  /* If it resolved with a single dot, check that it doesn't with
-	 a second trailing dot.  */
-  host[len-1] = '.';
   if (getaddrinfo (host, NULL, NULL, &ai) == 0)
 	{
 	  printf ("resolving \"%s\" worked, test failed\n", host);
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: Bug on builder of reproducible-builds?

2016-11-15 Thread Holger Levsen
Hi Roger,

On Tue, Nov 15, 2016 at 10:51:24PM +0900, Roger Shimizu wrote:
> Could you help to check/resolve the two issues above?

I've triggered rebuilds of wide-dhcpv6 on armhf for unstable+testing
now, hoping the results will be clearer.

Thanks for contacting us and caring about reproducible builds!


-- 
cheers,
Holger


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

Bug on builder of reproducible-builds?

2016-11-15 Thread Roger Shimizu
Dear Chris and Reproducible-Builds Maintainer,

I met an issue that maybe there's bug on builder of reproducible-builds.

My package wide-dhcpv6 recently report FTBFS error [0].
It had this issue on version 20080615-17, but I fixed it in version
20080615-18 [1].

Unstable build log [2] shows it started to build on '2016-11-02
01:30', and version was ‘wide-dhcpv6_20080615-18.dsc’ at the begining,
but it actually built by version 20080615-17 because I find the log in
the middle shows "I: copying [wide-dhcpv6_20080615-17.dsc]"

Another minor issue is testing build log [3] shows it built OK
(because it built by version 20080615-18), but the conclusion on the
left side of the page [0] still shows "FTBFS".

Could you help to check/resolve the two issues above?
Thanks!

[0] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/wide-dhcpv6.html
[1] https://bugs.debian.org/842835
[2] 
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/wide-dhcpv6_20080615-18.rbuild.log
[3] 
https://tests.reproducible-builds.org/debian/rbuild/testing/armhf/wide-dhcpv6_20080615-18.rbuild.log

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

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

Re: [PATCH] Build even further in the future to catch more non-determinstic behaviour.

2016-11-15 Thread Reiner Herrmann
On Tue, Nov 15, 2016 at 11:26:05AM +, Chris Lamb wrote:
> + sudo date --set="+3980 days +6 hours + 23 minutes"

I think this will lead to issues with apt, as the Debian signing
keys expire before that.

gpg2 --keyring /usr/share/keyrings/debian-archive-keyring.gpg --list-keys | 
grep expire
pub   rsa4096 2010-08-07 [SC] [expires: 2017-08-05]
pub   rsa4096 2010-08-27 [SC] [expires: 2018-03-05]
pub   rsa4096 2012-05-08 [SC] [expires: 2019-05-07]
pub   rsa4096 2012-04-27 [SC] [expires: 2020-04-25]
pub   rsa4096 2013-08-17 [SC] [expires: 2021-08-15]
pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]



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

[PATCH] Build even further in the future to catch more non-determinstic behaviour.

2016-11-15 Thread Chris Lamb
Hi,

Attached is the following:

  commit 60bb20a43218c6ac4b95fd7971026ac0ba5ce682
  Author: Chris Lamb 
  Date:   Tue Nov 15 11:25:28 2016 +
  
  Build even further in the future to catch more non-determinstic behaviour.
  
   * Ensure that more bytes of a year changes (eg. 2016->2017 vs. 
2026->2027)
  
   * Catch FTBFS within the lifetime of the stable release.
  
   * -days 3650 is quite common when generating certicates, so we catch 
FTBFS
 this way.
  
  Signed-off-by: Chris Lamb 
  
   update_jdn.sh | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)


You can also merge from the "build-further-in-future" branch of
https://github.com/lamby/jenkins.debian.net if that is more convenient.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
From 60bb20a43218c6ac4b95fd7971026ac0ba5ce682 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Tue, 15 Nov 2016 11:25:28 +
Subject: [PATCH] Build even further in the future to catch more
 non-determinstic behaviour.

 * Ensure that more bytes of a year changes (eg. 2016->2017 vs. 2026->2027)

 * Catch FTBFS within the lifetime of the stable release.

 * -days 3650 is quite common when generating certicates, so we catch FTBFS
   this way.

Signed-off-by: Chris Lamb 
---
 update_jdn.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/update_jdn.sh b/update_jdn.sh
index 6356c90..c4b5468 100755
--- a/update_jdn.sh
+++ b/update_jdn.sh
@@ -720,7 +720,7 @@ explain "$(date) - finished deployment."
 case $HOSTNAME in
 	# set time back to the future
 	profitbricks-build4-amd64|profitbricks-build5-amd64|profitbricks-build6-i386|profitbricks-build15-amd64|profitbricks-build16-i386)
-		sudo date --set="+398 days +6 hours + 23 minutes"
+		sudo date --set="+3980 days +6 hours + 23 minutes"
 		;;
 	jenkins)
 		# notify irc
-- 
2.10.2

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

Re: accessibility of the reproducible builds page

2016-11-15 Thread Sebastian Humenda
Hi

Chris Lamb schrieb am 14.11.2016, 20:08 +:
>HW42 wrote:
>
>> diffs are indented to reflect the nested structure of the files
>
>Indeed, this is something inherent, at least from an abstract point of
>view, in the output format.
>
>Despite that, we could have a separate text output that "flattens" the
>nested structure from an indentation point of view into a series of
>regular-looking diffs but uses additional headings to capture — albeit
>suboptimally — the current nesting. This format could also avoid Unicode
>if that's helpful.
Avoiding _these_ Unicode characters would be helpful, yes. Headings would be
very good, because then I could navigate by section, basically. I'm only seeing
_exactly_ one line at once (like on a calculator). If you would i.e. insert
#'s to indicate a new file, e.g.

### data.tar.gz

(as a third indentation level), it could be beneficial. In this case, I could
jump with a regex from diff to diff. I don't mind the indentation, it's fine,
but if that's a good compromise for a copy-paste-format, then it's helpful, too
:).

Thanks
Sebastian
-- 
Web: http://www.crustulus.de (English|Deutsch)  | Blog: 
http://www.crustulus.de/blog
FreeDict: Free multilingual dictionaries - http://www.freedict.org
Freies Latein-Deutsch-Wörterbuch: http://www.crustulus.de/freedict.de.html

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

Re: accessibility of the reproducible builds page

2016-11-15 Thread Sebastian Humenda
Hi

HW42 schrieb am 13.11.2016, 20:52 +:
>Sebastian Humenda:
>> I'd like to report and discuss with you an issue that I'm having with the
>> reproducible builds page, linked from the QA page of a package of mine.
>> My package, freedict, is affected by "unstable" builds. I suppose that's 
>> because
>> the build time stamp is inserted into some of the distributed files.
>> Therefore I have tried  to take a look at the diff output, but found this 
>> view
>> to be very inaccessible on the web site. I am using a screen reader (BRLTTY 
>> or
>> gnome-orca) to read either the console or the GUI, respectively.
>[...]
>> However, the text file contains tables made of Unicode symbols and hence I
>> cannot navigate them properly. The screen reader is reading every character 
>> on
>> the line, from left to right, ignoring the columns in the plain text format.
>> This usually works fine for plain texts or code, but in these 
>> plain-text-tables,
>> I am unable to read the information properly. It basically gets read to me
>> without structure.
>[...]
>> 3.  The diff (or build) output contains  these characters mentioned above. It
>> would be great, if somebody could explain the sense to me. As far as I
>> understand the output, it is some slightly polished diff output. If so,
>> would it be possible to provide a plain diff output as well?
>
>The text (and the html) output is generated by 'diffoscope'.
>
>citing https://diffoscope.org/:
[...]
>In the text output it uses "unified" diff output to compare the text
>representation of different parts of the file. Those diffs are indented
>to reflect the nested structure of the files in question. To make the
>structure visually more easily recognizable additional to the
>indentation there a lines drawn with those unicode chars.
>
>As a temporary work-around you can try to remove the unicode stuff and
>replace them with simple spaces with a command like:
>
>  sed -e ':a;s/^\(\s*\)[╵│├─┄]/\1 /;t a' -i 
> freedict_2016.10.22-1.diffoscope.txt
I didn't know that these characters were indentation. It looks much better with
spaces. Thanks!

>How do you deal with other text content where the indentation matters
>like for example python source code?
Indentation is not an issue. I use a braille display and hence see indentation
just fine. However, for the output of diffoscope, I get "random" characters on
my display (imagine that all the lines would start with question marks). That
simply is not helpful.

Cheers
Sebastian
-- 
Web: http://www.crustulus.de (English|Deutsch)  | Blog: 
http://www.crustulus.de/blog
FreeDict: Free multilingual dictionaries - http://www.freedict.org
Freies Latein-Deutsch-Wörterbuch: http://www.crustulus.de/freedict.de.html

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

Re: accessibility of the reproducible builds page

2016-11-15 Thread Sebastian Humenda
Hi

Valerie R Young schrieb am 13.11.2016, 13:17 -0500:
>On 11/13/2016 03:30 AM, Sebastian Humenda wrote:
>> I'd like to report and discuss with you an issue that I'm having with the
>> reproducible builds page, linked from the QA page of a package of mine.
>> My package, freedict, is affected by "unstable" builds. I suppose that's 
>> because
>> the build time stamp is inserted into some of the distributed files.
>> Therefore I have tried  to take a look at the diff output, but found this 
>> view
>> to be very inaccessible on the web site. I am using a screen reader (BRLTTY 
>> or
>> gnome-orca) to read either the console or the GUI, respectively.
>>
>> I started at
>> "https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/freedict.html";.
>> This site is built with iframes and hence I cannot view it with w3m. 
>>
>> I changed to an X session and tried the same with Firefox. Although the site 
>> was
>> still somewhat difficult to interpret (with a screen reader), I was able to 
>> find a link called "txt" and
>> it possibly contains the build diff.
>You are right, the "txt" link is the diffoscope output in text format,
>instead of HTML format. I'll make the hover text more descriptive.
>
>I'm curious about the iframe, however -- can you explain the problem a
>little more? How does it make it hard for the screen reader? Can you not
>view what is inside the iframe? Is there anything I could do to make it
>easier for the screen reader, other than get rid of iframes entirely?
The screen reader (or the underlying rendering engine) maintains a cursor
position. Everything change at this position is reported to the user (everything
else would be distractive). When I click on a link, I usually expect a new page
to load. For frames, the screen reader does not the change, because a
not-focussed part of the page updates.

>> Therefore I'd like to request the following:
>>
>> 1.  There's an image with a useless description. It is located below the 
>> heading
>> "Suite and Architecture". The line there looks like this (for me):
>>
>> unreproducible 2016.10.22-1 in testing diffoscope logo
>>
>> I find "diffoscope logo" to be not very helpful, especially because it's 
>> a
>> link pointing to a resource.
>When you said there is an image with a useless description, do you mean
>the image labeled "unreproducible" at the beginning of the line or do
>you mean the imagine "diffoscope logo" at the end of the line? The
>purpose of the "diffoscope logo" link is to be able to navigate between
>the html diffoscope output for the same package but on a different suite
>and architecture. By navigate between, I mean it will open the html
>formatted diffoscope results in the iframe.
I meant the latter. What about "switch " as a label then?

>> 2.  When clicking the link labelled "diff", it seems as if some kind of sub 
>> menu
>> would pop up (correct me, if I'm wrong). That is hard to figure out, 
>> because
>> it is not announced. I expected this link to open a new page, therefore I
>> re-read the page and it took me a while to realize that the change was
>> minimalistic. I suppose this is some kind of fancy Java script and I 
>> don't
>> know the fix for this (I'm not a web developer at all), but maybe 
>> somebody
>> on this list might know. I suppose it could be solved with an ARIA live
>> region.
>I'm not sure what you mean by the link labeled "diff"? You are right
>that clicking the "version" link ("2016.10.22-1" on the line you
>referred to above) or clicking the "diffocscope logo" link will expand a
>sub menu (containing more details and links to information about the
>results of the tests for the architecture and suite). We don't use any
>javascript on the site, however, instead we have static html pages to
>show the results of each suite/architecture pair, so these links do take
>you to a "new page". The only differences between these pages are the
>expanded submenu for the specific suite arch and the iframe will show
>the diffoscope output or build information for the that
>suite/architecture test.
I see, this was a misunderstanding on my side. I haven't looked at the page
source code. For navigation purposes, It is much clearer, if clicking a link
brings you to a new page. Ideally, there should be a heading indicating the
beginning of the requested content. As I might have said, it's fairly easy and
quick with a screen reader to jump from line to line.

The thing now is: I'd love to give you more precise feedback, however,
accessibility for Mate just broke. So I have to wait until I can use X again.

Thanks
Sebastian
-- 
Web: http://www.crustulus.de (English|Deutsch)  | Blog: 
http://www.crustulus.de/blog
FreeDict: Free multilingual dictionaries - http://www.freedict.org
Freies Latein-Deutsch-Wörterbuch: http://www.crustulus.de/freedict.de.html

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.de

Bug#844402: spykeviewer: FTBFS: ImportError: No module named spyderlib.widgets.variableexplorer.collectionseditor

2016-11-15 Thread Chris Lamb
Source: spykeviewer
Version: 0.4.4-1
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,

spykeviewer fails to build from source in unstable/amd64:

  […]

  update-alternatives: using /usr/bin/stream-im6.q16 to provide 
/usr/bin/stream-im6 (stream-im6) in auto mode
  update-alternatives: using /usr/bin/display-im6.q16 to provide 
/usr/bin/display (display) in auto mode
  update-alternatives: using /usr/bin/display-im6.q16 to provide 
/usr/bin/display-im6 (display-im6) in auto mode
  update-alternatives: using /usr/bin/montage-im6.q16 to provide 
/usr/bin/montage (montage) in auto mode
  update-alternatives: using /usr/bin/montage-im6.q16 to provide 
/usr/bin/montage-im6 (montage-im6) in auto mode
  update-alternatives: using /usr/bin/mogrify-im6.q16 to provide 
/usr/bin/mogrify (mogrify) in auto mode
  update-alternatives: using /usr/bin/mogrify-im6.q16 to provide 
/usr/bin/mogrify-im6 (mogrify-im6) in auto mode
  Setting up libpangocairo-1.0-0:amd64 (1.40.3-3) ...
  Setting up libqt5printsupport5:amd64 (5.7.1~20161021+dfsg-5) ...
  Setting up libqt5help5:amd64 (5.7.1~20161021-2) ...
  Setting up libqt5opengl5:amd64 (5.7.1~20161021+dfsg-5) ...
  Setting up libqt5svg5:amd64 (5.7.1~20161021-2) ...
  Setting up imagemagick (8:6.9.6.2+dfsg-2) ...
  Setting up libqt5designer5:amd64 (5.7.1~20161021-2) ...
  Setting up python-qt4 (4.11.4+dfsg-2) ...
  Setting up librsvg2-2:amd64 (2.40.16-1) ...
  Setting up libqt5webkit5:amd64 (5.7.1~20161021+dfsg-2) ...
  Setting up python-pyqt5 (5.7+dfsg-2+b1) ...
  Setting up python-qwt (0.5.5-1) ...
  Setting up python-pyqt5.qtwebkit (5.7+dfsg-2+b1) ...
  Setting up librsvg2-common:amd64 (2.40.16-1) ...
  Setting up python-pyqt5.qtsvg (5.7+dfsg-2+b1) ...
  Setting up gnome-icon-theme (3.12.0-2) ...
  update-alternatives: using 
/usr/share/icons/gnome/scalable/places/debian-swirl.svg to provide 
/usr/share/icons/gnome/scalable/places/start-here.svg (start-here.svg) in auto 
mode
  Setting up python-qtpy (1.1.2-1) ...
  Setting up python-qtawesome (0.3.3-3) ...
  Setting up libgtk2.0-0:amd64 (2.24.31-1) ...
  Setting up python-matplotlib (1.5.3-1) ...
  Processing triggers for sgml-base (1.29) ...
  Setting up docutils-common (0.12+dfsg-2) ...
  Processing triggers for sgml-base (1.29) ...
  Setting up python-docutils (0.12+dfsg-2) ...
  update-alternatives: using /usr/share/docutils/scripts/python2/rst-buildhtml 
to provide /usr/bin/rst-buildhtml (rst-buildhtml) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2html to 
provide /usr/bin/rst2html (rst2html) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2latex to 
provide /usr/bin/rst2latex (rst2latex) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2man to 
provide /usr/bin/rst2man (rst2man) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2odt to 
provide /usr/bin/rst2odt (rst2odt) in auto mode
  update-alternatives: using 
/usr/share/docutils/scripts/python2/rst2odt_prepstyles to provide 
/usr/bin/rst2odt_prepstyles (rst2odt_prepstyles) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2pseudoxml 
to provide /usr/bin/rst2pseudoxml (rst2pseudoxml) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2s5 to 
provide /usr/bin/rst2s5 (rst2s5) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2xetex to 
provide /usr/bin/rst2xetex (rst2xetex) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2xml to 
provide /usr/bin/rst2xml (rst2xml) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rstpep2html to 
provide /usr/bin/rstpep2html (rstpep2html) in auto mode
  Setting up python-sphinx (1.4.8-1) ...
  Setting up python-spykeutils (0.4.3-1) ...
  Setting up python-spyder (3.0.1+dfsg1-1) ...
  Setting up python-spyderlib (3.0.1+dfsg1-1) ...
  Setting up python-guidata (1.7.6-1) ...
  Setting up python-guiqwt (3.0.3-1) ...
  Setting up spykeviewer-build-deps (0.4.4-1) ...
  Processing triggers for libc-bin (2.24-5) ...
  Processing triggers for systemd (232-3) ...
  Processing triggers for ca-certificates (20161102) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.36.0-1) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=8

Bug#844401: redland: FTBFS: gcc: error: .specs: No such file or directory

2016-11-15 Thread Chris Lamb
Source: redland
Version: 1.0.17-1
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,

redland fails to build from source in unstable/amd64:

  […]

  checking whether we are using the GNU C compiler... yes
  checking whether gcc accepts -g... yes
  checking for gcc option to accept ISO C89... none needed
  checking whether gcc understands -c and -o together... yes
  checking dependency style of gcc... none
  checking for a sed that does not truncate output... /bin/sed
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for fgrep... /bin/grep -F
  checking for ld used by gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
  checking the name lister (/usr/bin/nm -B) interface... BSD nm
  checking whether ln -s works... yes
  checking the maximum length of command line arguments... 1572864
  checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
  checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
  checking for /usr/bin/ld option to reload object files... -r
  checking for objdump... objdump
  checking how to recognize dependent libraries... pass_all
  checking for dlltool... no
  checking how to associate runtime and link libraries... printf %s\n
  checking for ar... ar
  checking for archiver @FILE support... @
  checking for strip... strip
  checking for ranlib... ranlib
  checking command to parse /usr/bin/nm -B output from gcc object... ok
  checking for sysroot... no
  checking for a working dd... /bin/dd
  checking how to truncate binary pipes... /bin/dd bs=4096 count=1
  checking for mt... no
  checking if : is a manifest tool... no
  checking how to run the C preprocessor... gcc -E
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... yes
  checking for inttypes.h... yes
  checking for stdint.h... yes
  checking for unistd.h... yes
  checking for dlfcn.h... yes
  checking for objdir... .libs
  checking if gcc supports -fno-rtti -fno-exceptions... no
  checking for gcc option to produce PIC... -fPIC -DPIC
  checking if gcc PIC flag -fPIC -DPIC works... yes
  checking if gcc static flag -static works... yes
  checking if gcc supports -c -o file.o... yes
  checking if gcc supports -c -o file.o... (cached) yes
  checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
  checking whether -lc should be explicitly linked in... no
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  checking for shl_load... no
  checking for shl_load in -ldld... no
  checking for dlopen... no
  checking for dlopen in -ldl... yes
  checking whether a program can dlopen itself... yes
  checking whether a statically linked program can dlopen itself... no
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
  checking whether to build shared libraries... yes
  checking whether to build static libraries... yes
  checking what extension is used for runtime loadable modules... .so
  checking what variable specifies run-time module search path... 
LD_LIBRARY_PATH
  checking for the default library search path... /lib /usr/lib 
/usr/lib/x86_64-linux-gnu/libfakeroot /usr/local/lib /lib/x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu 
  checking for library containing dlopen... -ldl
  checking for dlerror... yes
  checking for shl_load... (cached) no
  checking for shl_load in -ldld... (cached) no
  checking for dld_link in -ldld... no
  checking for _ prefix in compiled symbols... no
  checking whether deplibs are loaded by dlopen... yes
  checking for argz.h... yes
  checking for error_t... yes
  checking for argz_add... yes
  checking for argz_append... yes
  checking for argz_count... yes
  checking for argz_create_sep... yes
  checking for argz_insert... yes
  checking for argz_next... yes
  checking for argz_stringify... yes
  checking if argz actually works... yes
  checking whether libtool supports -dlopen/-dlpreopen... yes
  checking for unistd.h... (cached) yes
  checking for dl.h... no
  checking for sys/dl.h... no
  checking for dld.h... no
  checking for mach-o/dyld.h... no
  checking for dirent.h... yes
  checking for closedir... yes
  checking for opendir... yes
  checking for readdir... yes
  checking for strlcat... no
  checking for strlcpy... no
  checking that generated files are newer than configure... done
  configure: creating ./config.status
   /bin/bash ./config.st