date:20160617

Re: [Reproducible-builds] Reprotest week 59 blog comments

2016-06-17 Thread Ximin Luo

Ceridwen:
> On Fri, 2016-06-17 at 19:13 +0200, Ximin Luo wrote:
>>> For other packages, it's unclear to me whether I should specify
>>> them as depends or recommends: they aren't dependencies in a strict
>>> sense, but marking them as dependencies will make it easier to
>>> install a fully-functional reprotest.
>>
>> You should specify these as Recommends, the definition matches what
>> you just described [1]. Also see how diffoscope does things.
>>
>> [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-
>> binarydeps starting from "The meaning of the five dependency fields
>> is as follows:"
> 
> autopkgtest has these as Suggests rather than Recommends, and I
> followed its example.  On Lunar's suggestion, for the first alpha
> release I'm removing them altogether since the functionality that
> requires them isn't working yet.  When I get the functionality, I will
> put them back as Recommends if everyone agrees about that.
> 

OK. I'd still say Recommends is better than Suggests, for when you finally get 
this working. The reason is, because a common use case would be to try to vary 
as much as you can. By contrast for autopkgtest, you typically pick one of the 
Suggests and you don't really get that much additional functionality by using 
all of them.

Some system configurations default to installing all of a package's Recommends 
by default (treating them as hard dependencies), including my own system. Much 
much fewer systems would treat Suggests like that, and it's a less reasonable 
thing to do in general.

>> I'd say it's better to fail fast. Warnings can easily be missed. If
>> the user really doesn't want to test a variation, they can disable it
>> using the mechanisms you already mentioned. 
> 
> I will make it so that if a variation *is* available for a particular 
> environment/container but can't be executed because something is missing, 
> reprotest will error out.  Since not all environments/containers can test all 
> variations, I don't think it will be useful to force users to go through and 
> disable all the variations that can't be tested on the environment/container 
> they want to run it on.  For instance, I'm not going to have reprotest 
> complain that when building on an existing system, the variations that 
> require superuser privileges aren't available.
> 

Automatically enabling or disabling features based on "what's available" is 
less predictable, and I think it's better to be predictable than to require 
slightly less effort.

How about you have it fail fast by default, but if the user gives a 
--ignore-missing flag then you can switch to your autodetection behaviour? Then 
it's very obvious that the user is asking for something that's less predictable.

>>> Locales are a particular problem because I don't know of a way in
>>> Debian to specify that a given locale must be installed.
>>
>> All locales are installed by default (unless you install the
>> "localepurge" package, which is an unsupported hack that you don't
>> need to worry about), so you just need to reconfigure the locales
>> package to "generate" the fr locale. I'm not sure how this works
>> exactly, but you can look into it. You can do it manually via `sudo
>> dpkg-reconfigure locales` but you might be able to script this within
>> reprotest.
> 
> The bigger problem here is that since I'm designing reprotest not to be
> useful just for Debian-based systems, as far as I know there's no
> general way to control which locales are available.  What about BSD and
> MacOS?
> 
> The prebuilder script hard-codes certain locales, which vary by
> architecture on tests.reproducible-builds.org.  From asking in IRC, as
> far as I know different locales were chosen for different architectures
> simply to test more different locales on t.rb.o.  Some accompanying
> questions about locales:
> 
> * Should reprotest also hard-code certain locales?
> 
> * If more than one locale is hard-coded, how does it pick which locales
> to test with?
> 
> * Given the behavior above, where it errors out if something it needs
> to test a variation isn't available, should it error out if a hard
> -coded locale is missing, or should it fall back on some other locale? 
>  If it falls back, how should it pick which locale to fall back too?
> 
> * Should it be able to test more than two different locales?  Should
> this be the default?  This makes things more complicated and
> potentially a lot slower.
> 
> * How do I communicate to the users all of this locale handling in a
> transparent and simple way?
> 
> I'm a little averse to hard-coding specific locales, but I don't have
> great solutions for any of these problems.
> 

I'd suggest:

- Pick a random locale out of what's installed, and choose a random one out of 
this to test with. Or let the user specify it on the command line, as in 
--vary-locale=$$$, or the configuration file.

- If m locales are installed, and m>> While at the moment, reprotest only builds on the

[Reproducible-builds] Bug#827572: xprobe: please make the build reproducible

2016-06-17 Thread Reiner Herrmann

Source: xprobe
Version: 0.3-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that xprobe could not be built reproducibly.
The order of object files packed into static library archives is
unsorted.

The attached patch fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch
new file mode 100644
index 000..fa353a0
--- /dev/null
+++ b/debian/patches/reproducible_build.patch
@@ -0,0 +1,49 @@
+Author: Reiner Herrmann 
+Description: Sort order of object files in static libraries
+
+--- a/libs-external/USI++/src/Makefile.in
 b/libs-external/USI++/src/Makefile.in
+@@ -15,7 +15,7 @@
+ 	clear
+ 
+ usi++:icmp.o datalink.o ip.o misc.o udp.o tcp.o TX_IP.o Layer2.o arp.o
+-	ar cr libusi++.a *.o
++	ar cr libusi++.a `LC_ALL=C ls *.o`
+ #	ld *.o -Bshareable -o libusi++.so
+ 	$(RANLIB) libusi++.a
+ 	rm -f *.o
+--- a/src/xpmodules/alive_probe/Makefile.in
 b/src/xpmodules/alive_probe/Makefile.in
+@@ -42,7 +42,7 @@
+ all: alive_probe.a
+ 
+ alive_probe.a: icmp_ping.o tcp_ping.o udp_ping.o ttl_module portscan_module
+-	ar cr alive_probe.a *.o ttl_calc/*.o portscanner/*.o
++	ar cr alive_probe.a `LC_ALL=C ls *.o ttl_calc/*.o portscanner/*.o`
+ 	$(RANLIB) alive_probe.a
+ 
+ icmp_ping.o: icmp_ping.cc
+--- a/src/xpmodules/os_probe/Makefile.in
 b/src/xpmodules/os_probe/Makefile.in
+@@ -43,8 +43,8 @@
+ 
+ os_probe.a: icmp_port_unreach_mod icmp_echo_id_mod icmp_timestamp_mod \
+ icmp_inforeq_mod icmp_addrmask_mod tcp_handshake_mod tcp_rst_mod smb_mod snmp_mod
+-	ar cr os_probe.a icmp_port_unreach/*.o icmp_echo_id/*.o icmp_timestamp/*.o \
+-icmp_inforeq/*.o icmp_addrmask/*.o tcp_handshake/*.o tcp_rst/*.o smb/*.o snmp/*.o
++	ar cr os_probe.a `LC_ALL=C ls icmp_port_unreach/*.o icmp_echo_id/*.o icmp_timestamp/*.o \
++icmp_inforeq/*.o icmp_addrmask/*.o tcp_handshake/*.o tcp_rst/*.o smb/*.o snmp/*.o`
+ 	$(RANLIB) os_probe.a
+ 
+ 	
+--- a/src/xplib/Makefile.in
 b/src/xplib/Makefile.in
+@@ -44,7 +44,7 @@
+ all: libxplib.a
+ 
+ libxplib.a: $(OBJS)
+-	ar cr libxplib.a *.o
++	ar cr libxplib.a `LC_ALL=C ls *.o`
+ 	$(RANLIB) libxplib.a
+ 
+  .c.o: $(INCLUDES)
diff --git a/debian/patches/series b/debian/patches/series
index 7a23e24..aa1238f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 fix-build-usi.patch
 fix-for-gcc4.3.patch
 fix-man-page.patch
+reproducible_build.patch


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] Reprotest week 59 blog comments

2016-06-17 Thread Ceridwen

On Fri, 2016-06-17 at 19:13 +0200, Ximin Luo wrote:
> > For other packages, it's unclear to me whether I should specify
> > them as depends or recommends: they aren't dependencies in a strict
> > sense, but marking them as dependencies will make it easier to
> > install a fully-functional reprotest.
> 
> You should specify these as Recommends, the definition matches what
> you just described [1]. Also see how diffoscope does things.
> 
> [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-
> binarydeps starting from "The meaning of the five dependency fields
> is as follows:"

autopkgtest has these as Suggests rather than Recommends, and I
followed its example.  On Lunar's suggestion, for the first alpha
release I'm removing them altogether since the functionality that
requires them isn't working yet.  When I get the functionality, I will
put them back as Recommends if everyone agrees about that.

> I'd say it's better to fail fast. Warnings can easily be missed. If
> the user really doesn't want to test a variation, they can disable it
> using the mechanisms you already mentioned. 

I will make it so that if a variation *is* available for a particular 
environment/container but can't be executed because something is missing, 
reprotest will error out.  Since not all environments/containers can test all 
variations, I don't think it will be useful to force users to go through and 
disable all the variations that can't be tested on the environment/container 
they want to run it on.  For instance, I'm not going to have reprotest complain 
that when building on an existing system, the variations that require superuser 
privileges aren't available.

> > Locales are a particular problem because I don't know of a way in
> > Debian to specify that a given locale must be installed.
> 
> All locales are installed by default (unless you install the
> "localepurge" package, which is an unsupported hack that you don't
> need to worry about), so you just need to reconfigure the locales
> package to "generate" the fr locale. I'm not sure how this works
> exactly, but you can look into it. You can do it manually via `sudo
> dpkg-reconfigure locales` but you might be able to script this within
> reprotest.

The bigger problem here is that since I'm designing reprotest not to be
useful just for Debian-based systems, as far as I know there's no
general way to control which locales are available.  What about BSD and
MacOS?

The prebuilder script hard-codes certain locales, which vary by
architecture on tests.reproducible-builds.org.  From asking in IRC, as
far as I know different locales were chosen for different architectures
simply to test more different locales on t.rb.o.  Some accompanying
questions about locales:

* Should reprotest also hard-code certain locales?

* If more than one locale is hard-coded, how does it pick which locales
to test with?

* Given the behavior above, where it errors out if something it needs
to test a variation isn't available, should it error out if a hard
-coded locale is missing, or should it fall back on some other locale? 
 If it falls back, how should it pick which locale to fall back too?

* Should it be able to test more than two different locales?  Should
this be the default?  This makes things more complicated and
potentially a lot slower.

* How do I communicate to the users all of this locale handling in a
transparent and simple way?

I'm a little averse to hard-coding specific locales, but I don't have
great solutions for any of these problems.

> > While at the moment, reprotest only builds on the existing system,
> > when I start extending it to other build environments, this will
> > require double-dispatch, because the code that needs to be executed
> > will depend on both the variation to be tested and the environment
> > being built on.

"Double-dispatch" in this case just means that there are two parameters
that determine what code needs to be run, in this case the variation
and the environment.

Ceridwen

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

[Reproducible-builds] Bug#827567: gprbuild: FTBFS: libgnatprj.so: undefined reference to `update_path'

2016-06-17 Thread Chris Lamb

Source: gprbuild
Version: 2015-5
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,

gprbuild fails to build from source in unstable/amd64:

  [..]

libxmlada-dom6-dev libxmlada-input-sources4.5.2015
libxmlada-input-sources6-dev libxmlada-sax4.5.2015 libxmlada-sax6-dev
libxmlada-schema4.5.2015 libxmlada-schema6-dev libxmlada-unicode4.5.2015
libxmlada-unicode6-dev
  Suggested packages:
gcc-6-locales gcc-6-multilib gcc-6-doc libgcc1-dbg libgomp1-dbg libitm1-dbg
libatomic1-dbg libasan3-dbg liblsan0-dbg libtsan0-dbg libubsan0-dbg
libcilkrts5-dbg libmpx2-dbg libquadmath0-dbg gnat-6-doc
ada-reference-manual-2012 gnat-6-sjlj
  Recommended packages:
ada-reference-manual-2012 gnat-gps libxmlada-doc
  The following NEW packages will be installed:
cpp-6 gcc-6 gnat gnat-6 libasan3 libgcc-6-dev libgnat-6 libgnatprj6
libgnatprj6-dev libgnatvsn6 libgnatvsn6-dev libmpx2 libxmlada-dom4.5.2015
libxmlada-dom6-dev libxmlada-input-sources4.5.2015
libxmlada-input-sources6-dev libxmlada-sax4.5.2015 libxmlada-sax6-dev
libxmlada-schema4.5.2015 libxmlada-schema6-dev libxmlada-unicode4.5.2015
libxmlada-unicode6-dev
  0 upgraded, 22 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 84.8 MB of archives.
  After this operation, 440 MB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 cpp-6 amd64 6.1.1-6 
[30.8 MB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 libasan3 amd64 
6.1.1-6 [303 kB]
  Get:3 http://httpredir.debian.org/debian sid/main amd64 libmpx2 amd64 6.1.1-6 
[11.0 kB]
  Get:4 http://httpredir.debian.org/debian sid/main amd64 libgcc-6-dev amd64 
6.1.1-6 [2296 kB]
  Get:5 http://httpredir.debian.org/debian sid/main amd64 gcc-6 amd64 6.1.1-6 
[30.2 MB]
  Get:6 http://httpredir.debian.org/debian sid/main amd64 libgnat-6 amd64 
6.1.1-6 [966 kB]
  Get:7 http://httpredir.debian.org/debian sid/main amd64 libgnatvsn6 amd64 
6.1.1-6 [296 kB]
  Get:8 http://httpredir.debian.org/debian sid/main amd64 libgnatprj6 amd64 
6.1.1-6 [710 kB]
  Get:9 http://httpredir.debian.org/debian sid/main amd64 gnat-6 amd64 6.1.1-6 
[12.4 MB]
  Get:10 http://httpredir.debian.org/debian sid/main amd64 libgnatvsn6-dev 
amd64 6.1.1-6 [1510 kB]
  Get:11 http://httpredir.debian.org/debian sid/main amd64 libgnatprj6-dev 
amd64 6.1.1-6 [3524 kB]
  Get:12 http://httpredir.debian.org/debian sid/main amd64 gnat all 6.1 [2926 B]
  Get:13 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-unicode4.5.2015 amd64 4.5.2015-7 [179 kB]
  Get:14 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-unicode6-dev amd64 4.5.2015-7 [267 kB]
  Get:15 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-input-sources4.5.2015 amd64 4.5.2015-7 [21.1 kB]
  Get:16 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-input-sources6-dev amd64 4.5.2015-7 [37.8 kB]
  Get:17 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-sax4.5.2015 amd64 4.5.2015-7 [123 kB]
  Get:18 http://httpredir.debian.org/debian sid/main amd64 libxmlada-sax6-dev 
amd64 4.5.2015-7 [267 kB]
  Get:19 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-dom4.5.2015 amd64 4.5.2015-7 [53.5 kB]
  Get:20 http://httpredir.debian.org/debian sid/main amd64 libxmlada-dom6-dev 
amd64 4.5.2015-7 [103 kB]
  Get:21 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-schema4.5.2015 amd64 4.5.2015-7 [265 kB]
  Get:22 http://httpredir.debian.org/debian sid/main amd64 
libxmlada-schema6-dev amd64 4.5.2015-7 [420 kB]
  Fetched 84.8 MB in 0s (105 MB/s)
  Selecting previously unselected package cpp-6.
  (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 .../cpp-6_6.1.1-6_amd64.deb ...
  Unpacking cpp-6 (6.1.1-6) ...
  Selecting previously unselected package libasan3:amd64.
  Preparing to unpack .../libasan3_6.1.1-6_amd64.deb ...
  Unpacking libasan3:amd64 (6.1.1-6) ...
  Selecting previously unselected package libmpx2:amd64.
  Preparing to unpack .../libmpx2_6.1.1-6_amd64.deb ...
  Unpacking libmpx2:amd64 (6.1.1-6) ...
  Selecting previously unselected package libgcc-6-dev:amd64.
  Preparing to unpack .../libgcc-6-dev_6.1.1-6_amd64.deb ...
  Unpacking libgcc-6-dev:amd64 (6.1.1-6) ...

[Reproducible-builds] Reprotest week 59 blog comments

2016-06-17 Thread Ximin Luo

> For other packages, it's unclear to me whether I should specify them as 
> depends or recommends: they aren't dependencies in a strict sense, but 
> marking them as dependencies will make it easier to install a 
> fully-functional reprotest.

You should specify these as Recommends, the definition matches what you just 
described [1]. Also see how diffoscope does things.

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps 
starting from "The meaning of the five dependency fields is as follows:"

> When reprotest runs with variations enabled that it can't test because it 
> doesn't have the correct packages installed, I intend to have it print a 
> warning but continue to run.

I'd say it's better to fail fast. Warnings can easily be missed. If the user 
really doesn't want to test a variation, they can disable it using the 
mechanisms you already mentioned. 

> Locales are a particular problem because I don't know of a way in Debian to 
> specify that a given locale must be installed.

All locales are installed by default (unless you install the "localepurge" 
package, which is an unsupported hack that you don't need to worry about), so 
you just need to reconfigure the locales package to "generate" the fr locale. 
I'm not sure how this works exactly, but you can look into it. You can do it 
manually via `sudo dpkg-reconfigure locales` but you might be able to script 
this within reprotest.

> While at the moment, reprotest only builds on the existing system, when I 
> start extending it to other build environments, this will require 
> double-dispatch, because the code that needs to be executed will depend on 
> both the variation to be tested and the environment being built on.

I don't understand this - could you elaborate a bit more, on what you mean by 
"double dispatch" and why we need this?

X

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

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

[Reproducible-builds] Bug#827546: git-buildpackage: please make the build reproducible

2016-06-17 Thread Sascha Steinbiss

Package: git-buildpackage
Version: 0.7.5
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps randomness

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that git-buildpackage could not be built reproducibly.

This is fixed by the attached patch. Firstly, it sets deterministic timestamps
(the last Debian release date) in the manpages. This is currently done
explicitly in the docs/Makefile as the more generic docbook2man patch [2]
has not been accepted yet.
Secondly, the patch excludes some test configuration module variables from the
Epydoc documentation as they contain the names of build-specific temporary
directories.
Once applied, git-buildpackage can be built reproducibly in our current
experimental framework.

Best regards
Sascha

[1] https://wiki.debian.org/ReproducibleBuilds
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800797
diff --git a/docs/Makefile b/docs/Makefile
index 581e0a1..106245f 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -27,6 +27,7 @@ VERSION_ENT=version.ent
 GBP_VERSION=../gbp/version.py
 DEB_VERSION=$(shell sed -ne 's/^gbp_version="\([.a-z0-9~-]\+\)"/\1/p' $(GBP_VERSION))
 CHANGELOG=../debian/changelog
+MAN_DATE=$(shell dpkg-parsechangelog -l ../debian/changelog -SDate | TZ=UTC LC_ALL=C date -f- +'%d %B %Y')
 
 # Stuff to build docs outside Debian
 HAVE_SGML2X ?= 1
@@ -49,12 +50,14 @@ BUILD_MAN_XREF_PAGES=$(patsubst %,buildxref/%,$(SGML_MANPAGES))
 
 buildxref/%.1 buildxref/%.5: man.%.sgml manpages/%.sgml
 	docbook2man -o buildxref $<
+	sed -i -r "s/\"[^\"]+\"/\"$(MAN_DATE)\"/3" $@
 
 manpage.refs: $(BUILD_MAN_XREF_PAGES)
 	cp buildxref/$@ $@
 
 %.1 %.5: manpage.refs
 	docbook2man -o . man.$*.sgml
+	sed -i -r "s/\"[^\"]+\"/\"$(MAN_DATE)\"/3" $@
 
 git-pbuilder.1: ../bin/git-pbuilder
 	pod2man $< $@
diff --git a/setup.cfg b/setup.cfg
index d443f2a..2bbb17a 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -10,7 +10,7 @@ name = git-buildpackage
 sourcecode = no
 url = https://honk.sigxcpu.org/piki/projects/git-buildpackage/
 target = build/apidocs/
-fail-on = docstring_warning
+#fail-on = docstring_warning
 modules = gbp, tests/test_*.py
 
 [pep8]
diff --git a/tests/test_GitRepository.py b/tests/test_GitRepository.py
index fed8b02..c8ecb49 100644
--- a/tests/test_GitRepository.py
+++ b/tests/test_GitRepository.py
@@ -1,6 +1,6 @@
 # vim: set fileencoding=utf-8 :
 
-"""
+'''
 Test L{gbp.git.GitRepository}
 
 This testcase creates several repositores:
@@ -9,7 +9,9 @@ This testcase creates several repositores:
 - A bare repository at L{bare_dir} called I{bare}
 - A clone of I{repo} below L{clone_dir} called I{clone}
 - A mirror of I{repo} below L{mirror_clone_dir} called I{mirror}
-"""
+
+@undocumented: repo_dir bare_dir clone_dir mirror_clone_dir
+'''
 
 from . import context
 
diff --git a/tests/test_PristineTar.py b/tests/test_PristineTar.py
index 150dbcf..c2407c3 100644
--- a/tests/test_PristineTar.py
+++ b/tests/test_PristineTar.py
@@ -1,6 +1,6 @@
 # vim: set fileencoding=utf-8 :
 
-"""
+'''
 Test pristine-tar related methods in
 
 - L{gbp.deb.DebianPristineTar}
@@ -13,7 +13,8 @@ This testcase creates this reposity:
 
 - A repository at L{repo_dir} called I{repo}
 
-"""
+@undocumented: repo_dir test_data
+'''
 
 from . import context
 
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#827516: qmidinet: FTBFS:

2016-06-17 Thread Chris Lamb

Source: qmidinet
Version: 0.3.0-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,

qmidinet fails to build from source in unstable/amd64:

  [..]

  configure:3053: gcc  -c -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5
  configure:3053: $? = 0
  configure:3066: result: none needed
  configure:3091: checking how to run the C preprocessor
  configure:3122: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c
  configure:3122: $? = 0
  configure:3136: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c
  conftest.c:11:28: fatal error: ac_nonexistent.h: No such file or directory
  compilation terminated.
  configure:3136: $? = 1
  configure: failed program was:
  | /* confdefs.h */
  | #define PACKAGE_NAME "QmidiNet"
  | #define PACKAGE_TARNAME "qmidinet"
  | #define PACKAGE_VERSION "0.3.0"
  | #define PACKAGE_STRING "QmidiNet 0.3.0"
  | #define PACKAGE_BUGREPORT "rn...@rncbc.org"
  | #define PACKAGE_URL ""
  | #define CONFIG_PREFIX "/usr"
  | #define CONFIG_DEBUG 1
  | /* end confdefs.h.  */
  | #include 
  configure:3161: result: gcc -E
  configure:3181: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c
  configure:3181: $? = 0
  configure:3195: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c
  conftest.c:11:28: fatal error: ac_nonexistent.h: No such file or directory
  compilation terminated.
  configure:3195: $? = 1
  configure: failed program was:
  | /* confdefs.h */
  | #define PACKAGE_NAME "QmidiNet"
  | #define PACKAGE_TARNAME "qmidinet"
  | #define PACKAGE_VERSION "0.3.0"
  | #define PACKAGE_STRING "QmidiNet 0.3.0"
  | #define PACKAGE_BUGREPORT "rn...@rncbc.org"
  | #define PACKAGE_URL ""
  | #define CONFIG_PREFIX "/usr"
  | #define CONFIG_DEBUG 1
  | /* end confdefs.h.  */
  | #include 
  configure:3281: checking for g++
  configure:3297: found /usr/bin/g++
  configure:3308: result: g++
  configure:3335: checking for C++ compiler version
  configure:3344: g++ --version >&5
  g++ (Debian 5.4.0-4) 5.4.0 20160609
  Copyright (C) 2015 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  
  configure:3355: $? = 0
  configure:3344: g++ -v >&5
  Using built-in specs.
  COLLECT_GCC=g++
  COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
  Target: x86_64-linux-gnu
  Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.0-4' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
  Thread model: posix
  gcc version 5.4.0 20160609 (Debian 5.4.0-4) 
  configure:3355: $? = 0
  configure:3344: g++ -V >&5
  g++: error: unrecognized command line option '-V'
  g++: fatal error: no input files
  compilation terminated.
  configure:3355: $? = 1
  configure:3344: g++ -qversion >&5
  g++: error: unrecognized command line option '-qversion'
  g++: fatal error: no input files
  compilation terminated.
  configure:3355: $? = 1
  configure:3359: checking whether we are using the GNU C++ compiler
  configure:3378: g++ -c -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp >&5
  configure:3378: $? = 0
  configure:3387: result: yes
  configure:3396: checking whether g++ accepts -g
  configure:3416: g++ -c -g -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp >&5
  configure:3416: $? = 0
  configure:3457: result: yes
  configure:3485: checking how to run the C++ preprocessor
  configure:3512: g++ -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp
  configure:3512: $? = 0
  configure:3526: g++ -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp
  conftest.cpp:11:28: fatal error: ac_nonexistent.h: No such file or directory
  compilation terminated.
  configure:3526: $? = 1

Re: [Reproducible-builds] FontForge needs a new patch to learn about S_D_E

2016-06-17 Thread Mattia Rizzolo

FYI:

On Tue, May 10, 2016 at 11:43:53AM +, Mattia Rizzolo wrote:
> Our FontForge package is unused since quite some time.
> While rebasing it wouldn't be hard, it actually needs some more work.

I've now moved the package away from our apt repository into the "attic"
at https://reproducible.alioth.debian.org/old-packages/
I haven't touched the git repository.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


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] Reprotest week 59 blog comments

[Reproducible-builds] Bug#827572: xprobe: please make the build reproducible

Re: [Reproducible-builds] Reprotest week 59 blog comments

[Reproducible-builds] Bug#827567: gprbuild: FTBFS: libgnatprj.so: undefined reference to `update_path'

[Reproducible-builds] Reprotest week 59 blog comments

[Reproducible-builds] Bug#827546: git-buildpackage: please make the build reproducible

[Reproducible-builds] Bug#827516: qmidinet: FTBFS:

Re: [Reproducible-builds] FontForge needs a new patch to learn about S_D_E

8 matches

Site Navigation

Mail list logo

Footer information