Re: [Reproducible-builds] .buildinfo should contain source hashes (as well as binary hashes)

2015-09-21 Thread Ximin Luo 
On 20/09/15 20:43, Jérémy Bobbio wrote:
> Ximin Luo:
>> With our current .buildinfo setup, the above process is more
>> complicated, because we *only* store hashes of the binary build
>> environment.
> 
> [..]
> 
> The idea to put a hash of the binary package in the
> Build-Environment is a late addition to the original idea. 
> 

Sure, I realised after I posted that the binary hashes hadn't been implemented 
yet. That's a side issue though.

> In any cases, we currently don't have code to store any hash of the
> Build-Environment. If we wanted to store hashes of binary packages, then
> we would need to have them in /var/lib/dpkg/status and it's not done
> yet, even if Guillem said this would be a good thing to have.
> 

`apt-cache show [pkg]` will list hashes of binaries. Is there some reason we 
can't just do this?

>> Currently, to run a DDC test, we would have to read the buildinfo
>> file, find the hashes of the binary build-deps, lookup the source
>> packages that corresponds to these hashes, find a different binary
>> build-deps for these hashes, and run our DDC-checker. This takes many
>> round trips, and contacting external infrastructure that isn't
>> necessary.
> 
> You would not need to lookup the source packages using hashes. Using
> package and version gives you enough info to retrieve a specific source
> package from the archive.
> 
>> If .buildinfo files contained source hashes, the DDC-checker could
>> work more directly, without requiring a remote repository of source
>> hash <-> binary hash mappings.
> 
> I'm interested in `.buildinfo` in the context of the Debian project. The
> Debian archive is designed to be immutable. A specific version of a
> package will always correspond to the same source and binary files.
> So I don't see why one would do complex “source hash - binary hash
> mapping” when you can just rely on what is in the archive (and what has
> been archived by snapshot.debian.org).
> 

It's a good principle to design something to rely on the least amount of 
external infrastructure as possible. Just because we already depend on some 
infrastructure, doesn't mean we need to add more dependencies to it.

Suppose someone did a source-only mirror in the future, because binaries are 
too costly to store. Then, the .buildinfo files (with source hashes) can still 
be used against this mirror.

The "intuitive meaning" that we would like a .buildinfo file to have, is to 
describe immutably the input and the output. For testing and verification 
purposes, the input is the *source code* of the build-deps and of the target.

Getting reproducible builds to work is IMO fixing a massive bug that has 
existed for decades. Normally, when you run a fixed program against fixed 
input, what do you expect? Fixed output. Binary-hash-only .buildinfo files 
would only help to prove that this bug doesn't exist. *But that's not an 
incredible achievement.* Great, f(x) == g(y) when f == g and x == y, whoopee? 
We should aim higher, to be able to generate fixed-binary proofs for when only 
the source code (and not necessarily the binaries) matches.

> If by building thing that ought to match a specific package version you
> get different result, then you will have to investigate in any cases.
> 
> 
> Implementation-wise, getting the hash of the .dsc in the .buildinfo is
> going to be very tricky. dpkg does not know about what's available in
> the archive. It just knows about packages which are or were installed.
> 

`apt-cache showsrc [pkg]` has the right information in there, but it's a bit 
messy. I need to test this without a deb-src line, though.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



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

Re: [Reproducible-builds] .buildinfo should contain source hashes (as well as binary hashes)

2015-09-21 Thread Jérémy Bobbio 
Ximin Luo:
> > Implementation-wise, getting the hash of the .dsc in the .buildinfo is
> > going to be very tricky. dpkg does not know about what's available in
> > the archive. It just knows about packages which are or were installed.
> > 
> 
> `apt-cache showsrc [pkg]` has the right information in there, but it's a bit 
> messy. I need to test this without a deb-src line, though.

Building Debian packages doesn't involve APT in any ways. There is
currently no coupling in the direction dpkg → APT.

(That's why we need to get hash of the binary packages in
/var/lib/dpkg/status before they can be written in dpkg-genbuildinfo.)

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


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: [Reproducible-builds] Bug#799410: segment: please make the build reproducible

2015-09-21 Thread Santiago Vila 
On Fri, Sep 18, 2015 at 11:40:44PM +0100, Chris Lamb wrote:
> Source: segment
> Version: 1.3.5~svn57+dfsg-1.1
> Severity: wishlist
> Tags: patch
> User: reproducible-builds@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
> 
> Hi,
> 
> Whilst working on the "reproducible builds" effort [0], we noticed that
> segment could not be built reproducibly.
> 
> The attached patch removes timestamps from the build system. Once
> applied, segment can be built reproducibly using our reproducible
> toolchain.
> 
>  [0] https://wiki.debian.org/ReproducibleBuilds

I think it would be even better if we stopped using build dates altogether,
i.e. considering them to be irrelevant.

The following patch does that:

From: Santiago Vila 
Subject: Do not use the build date at all

--- a/build.xml
+++ b/build.xml
@@ -6,10 +6,6 @@


 
-   
-   
-   
-



@@ -18,7 +14,6 @@
 


-   

 

@@ -56,7 +51,6 @@



-   



--- a/doc/readme.html
+++ b/doc/readme.html
@@ -3,7 +3,7 @@
 
 Segment
 
-Version @project.fullversion@, Date @build.date@
+Version @project.fullversion@
 
 
 Table of Contents
--- a/src/net/sourceforge/segment/Version.java
+++ b/src/net/sourceforge/segment/Version.java
@@ -48,11 +48,4 @@
return version;
}

-   /**
-* @return segment build date
-*/
-   public String getDate() {
-   return date;
-   }
-   
 }
--- a/src/net/sourceforge/segment/ui/console/Segment.java
+++ b/src/net/sourceforge/segment/ui/console/Segment.java
@@ -140,9 +140,6 @@
if (Version.getInstance().getVersion() != null) {
signature += " " + Version.getInstance().getVersion();
}
-   if (Version.getInstance().getDate() != null) {
-   signature += ", " + Version.getInstance().getDate();
-   }
signature += ".";
System.out.println(signature);
helpFormatter.printHelp("segment", options);
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] .buildinfo should contain source hashes (as well as binary hashes)

2015-09-21 Thread Ximin Luo 
On 20/09/15 19:22, Johannes Schauer wrote:
> Hi,
> 
> Quoting Ximin Luo (2015-09-20 18:49:16)
>> Currently, to run a DDC test, we would have to read the buildinfo file, find
>> the hashes of the binary build-deps, lookup the source packages that
>> corresponds to these hashes, find a different binary build-deps for these
>> hashes, and run our DDC-checker. This takes many round trips, and contacting
>> external infrastructure that isn't necessary.
>>
>> If .buildinfo files contained source hashes, the DDC-checker could work more
>> directly, without requiring a remote repository of source hash <-> binary
>> hash mappings.
> 
> which packages would benefit from this?
> 

Every package that is (or might be, in the future) a build-dep of another 
package would benefit, because it would make it easier to check (though this is 
being discussed in the other branch) that *source* build-deps result in a 
fixed-binary, regardless of how they are compiled (e.g. if they're compiled by 
something compromised).

gcc and clang are only examples for the DDC case, but the point generally 
applies to (a) { checking that binary0(source1)==binary1 } vs (b) { checking 
that source0(source1)==binary1 }. For DDC, we do (b) and select source0 = 
source1, but it's harder to select this if we only have information about (a).

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



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

Re: [Reproducible-builds] Bug#799410: segment: please make the build reproducible

2015-09-21 Thread Chris Lamb 
> I think it would be even better if we stopped using build dates
> altogether,
> i.e. considering them to be irrelevant.

Of course, but that involves diverging from upstream.


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

[Reproducible-builds] Bug#799690: file: regression in MIME encoding lookups

2015-09-21 Thread Jérémy Bobbio 
Package: file
Version: 1:5.25-1
Severity: important

Hi!

The latest upload of file broke diffoscope test suite.

With file/1:5.24-2:

$ file --mime-encoding tests/data/binary1
tests/data/binary1: binary

With file/1:5.25-1:

$ file --mime-encoding tests/data/binary1
tests/data/binary1: application/octet-streambinary

The test file is only 16 bytes long and can be downloaded at:
https://anonscm.debian.org/cgit/reproducible/diffoscope.git/plain/tests/data/binary1

Thanks,
-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


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

[Reproducible-builds] package uploaded to our repo

2015-09-21 Thread Jérémy Bobbio 
dpkg_1.18.3.0~reproducible1.dsc has just been uploaded to 
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain

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

Re: [Reproducible-builds] Bug#799410: segment: please make the build reproducible

2015-09-21 Thread Santiago Vila 
On Mon, Sep 21, 2015 at 06:21:16PM +0100, Chris Lamb wrote:
> > I think it would be even better if we stopped using build dates
> > altogether,
> > i.e. considering them to be irrelevant.
> 
> Of course, but that involves diverging from upstream.

Well, it depends.

My theory is that stop using the build date is what a sensible
upstream would do, so we would not be diverging, just "anticipating",
since we would move in the same direction.

We don't know what the author meant by "build date", but if he really meant
"build date" and we replace it by something else (source date), which
is not exactly the same, we are modifying the program in a way that it
does no longer tell the truth. I'm a little bit uncomfortable with that.

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

Re: [Reproducible-builds] Bug#799410: segment: please make the build reproducible

2015-09-21 Thread Chris Lamb 
> > Of course, but that involves diverging from upstream.
> 
> Well, it depends.
> 
> My theory is that stop using the build date is what a sensible
> upstream would do, so we would not be diverging, just "anticipating",
> since we would move in the same direction.

I share your discomfort re. the dates, but many upstreams are dead
and/or don't care.

Do we really want to unnecessarily burden the maintainer with
maintaining this patch forever? By all means send the patch upstream,
but bear in mind the alternative in *this* case is adjusting
debian/rules, a file completely and entirely within our control.


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

[Reproducible-builds] Processing of diffoscope_35_amd64.changes

2015-09-21 Thread Debian FTP Masters 
diffoscope_35_amd64.changes uploaded successfully to localhost
along with the files:
  diffoscope_35.dsc
  diffoscope_35.tar.xz
  debbindiff_35_all.deb
  diffoscope_35_all.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

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

[Reproducible-builds] diffoscope_35_amd64.changes ACCEPTED into unstable

2015-09-21 Thread Debian FTP Masters 


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 21 Sep 2015 21:23:56 +
Source: diffoscope
Binary: diffoscope debbindiff
Architecture: source all
Version: 35
Distribution: unstable
Urgency: low
Maintainer: Reproducible builds folks 

Changed-By: Jérémy Bobbio 
Description:
 debbindiff - transitional package
 diffoscope - in-depth comparison of files, archives, and directories
Changes:
 diffoscope (35) unstable; urgency=low
 .
   [ Jérémy Bobbio ]
   * Switch to Python 3. This means code has been changed slightly
 here and there. Issues related to text encoding should now be
 far less frequent. According to some preliminary benchmark,
 diffoscope should run faster as well.
   * The system tar is now used instead of the Python module to display Tar
 archive metadata. The output should be slightly more accurate.
   * Log exceptions raised while computing diffs as errors
   * Avoid concatenating many strings in hexdump_fallback. This matters when
 looking at big binary files with xxd unavailable.
   * Let's ignore command errors when the file content is identical.
   * Fix isoinfo arguments to read Joliet data on ISO9660 images.
   * Ignore errors when reading Joliet and Rockridge data in ISO9660 images.
   * Use threads instead of processes for multiprocessing when running diff.
 There is no measurable performance impact and it helps to simplify the
 code.
   * Use the right argument order when creating CalledProcessError.
   * Propagate failure of external commands feeding diff.
   * Improve debugging log for command lines and exit codes.
   * Remove she-bang from files not meant to be executed directly.
   * Add more tests for main() behavior.
   * Improve RPM header conversion.
   * Fix a refactoring error in compare_commented_files().
 .
   [ Mattia Rizzolo ]
   * Drop X-Python-Version field, not needed anymore for python3.
Checksums-Sha1:
 cfcc47236b7b5d6f6bd870b83dda81a7de01f7cc 1968 diffoscope_35.dsc
 8872c643e45969cfe89216d75f74e9e110e8e565 202096 diffoscope_35.tar.xz
 0c98caf1800220f256699efcc4c9af2cf51bcc59 9690 debbindiff_35_all.deb
 defa18017014700b186aefc272c418ab1b9ed19a 41620 diffoscope_35_all.deb
Checksums-Sha256:
 eae82a9bca3fafb54be431a02eea36704fb1d0444b8891a7f9d7b6ba19879350 1968 
diffoscope_35.dsc
 dcc4a74c24cbd183aa3a40fc9085cec68f78cf3eef7a537b44b0cea60b0ec0d6 202096 
diffoscope_35.tar.xz
 056b0bc2db475aa9a17d583487f4582a561f31df5856958ab1e9626202a63b94 9690 
debbindiff_35_all.deb
 07cc8fda19095be22149062eb29b8d79fa255f6117dfdd9f4091187317849ced 41620 
diffoscope_35_all.deb
Files:
 dacab523673eaa50275902b88ad7e942 1968 devel optional diffoscope_35.dsc
 5ee54d63293e47ff420db8fffe2d4b4b 202096 devel optional diffoscope_35.tar.xz
 1a56cf6a8e05967583cd5bd39e652986 9690 oldlibs extra debbindiff_35_all.deb
 c66003ecba35f06548a67e8b5178b792 41620 devel optional diffoscope_35_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJWAHeyAAoJEEAsIlA9Nuk20ZsQAIe5TEIVR+QSPr4TE4MlrTVa
mJ88+ViLyFd48kcO42m0IqIbBi0UXit/JeXAnu448coThVxwKoIxZ93S1dALWI8f
6jne8cH0P3Ehs4Jwnel/BQOtAx/jmjx1IpHFcY9xsMEz6khK74/K2XibCfTVZuAW
GiRq86gPY2oXinWuRvNfyfMeJq0q4golqbMrYmp2YHYEw41lzKWB0HtJOnUwKawQ
QaNyLeTHFwcBkY2RtoF2wUTbgARpZ8MgLna9H1jox1cQEfDNjXoTD1tYjRlxfbyw
NpITK9Lbq2yvvg0ddippf066k8/Mo3ly0LMl1CmpMzHsJqtIuIgEYoy7xoS/HXB+
Nm0deljSxThq1cqJeRwvfoFOnUoYK82Zpg0ToajlZuR7NPmbwHrZqWx9qy5GOZR0
mCYzb3OEFOcmXW+9COG+bzc/lnuafv1YR8AeIrOvfaaW1R9agygpa1nPeH1RzRqV
qzPriPSSSj2Do8kyhzg4q/J2twTrsZ9LejoTdnlG+VDv5MRS4ZYSfb7+7AE2gTX8
lrAHyRLtOUtX+NzdmrJRgHQcSA6iP07hBUvlZTjXC2mn0SED0N3GbR1NluqyTYsn
5othlYxtN4/XQJqmRvG7+VEnnosdzd0e7SaTgqQUvBzuxEci0OICmKko/HW4BgoX
HvbO7OvNeKeO3uPtTPBk
=rKoL
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

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

[Reproducible-builds] Processing of diffoscope_35_amd64.changes

2015-09-21 Thread Debian FTP Masters 
diffoscope_35_amd64.changes uploaded successfully to ftp-master.debian.org
along with the files:
  diffoscope_35.dsc
  diffoscope_35.tar.xz
  debbindiff_35_all.deb
  diffoscope_35_all.deb

Greetings,

Your Debian queue daemon (running on host coccia.debian.org)

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

[Reproducible-builds] Bug#799656: node-websocket: FTBFS: error: 'NanScope' was not declared in this scope

2015-09-21 Thread Chris Lamb 
Source: node-websocket
Version: 1.0.19-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,

node-websocket fails to build from source in unstable/amd64:

  [..]

  make[3]: Entering directory '/tmp/buildd/node-websocket-1.0.19/build'
CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
  ../src/bufferutil.cc: In static member function 'static void
  BufferUtil::Initialize(v8::Handle)':
  ../src/bufferutil.cc:27:14: error: 'NanScope' was not declared in this
  scope
   NanScope();
^
  ../src/bufferutil.cc:28:33: error: 'NanNew' was not declared in this
  scope
   Local t = NanNew(New);
   ^
  ../src/bufferutil.cc:28:56: error: expected primary-expression before
  '>' token
   Local t = NanNew(New);
  ^
  ../src/bufferutil.cc:30:52: error: no matching function for call to
  'NODE_SET_METHOD(v8::Local&, const char [7],
  Nan::NAN_METHOD_RETURN_TYPE (&)(Nan::NAN_METHOD_ARGS_TYPE))'
   NODE_SET_METHOD(t, "unmask", BufferUtil::Unmask);
  ^
  [..]

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


https://reproducible.debian.net/logs/unstable/amd64/node-websocket_1.0.19-1.build1.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Sun Sep 20 08:13:40 GMT+12 2015
I: pbuilder-time-stamp: 1442780020
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 9.0.0), nodejs-dev, node-uglify, node-gyp, node-nan
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20256 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on nodejs-dev; however:
  Package nodejs-dev is not installed.
 pbuilder-satisfydepends-dummy depends on node-uglify; however:
  Package node-uglify is not installed.
 pbuilder-satisfydepends-dummy depends on node-gyp; however:
  Package node-gyp is not installed.
 pbuilder-satisfydepends-dummy depends on node-nan; however:
  Package node-nan is not installed.

Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
pbuilder-satisfydepends-dummy is already installed at the requested version 
(0.invalid.0)
pbuilder-satisfydepends-dummy is already installed at the requested version 
(0.invalid.0)
The following NEW packages will be installed:
  ca-certificates{a} gyp{a} libexpat1{a} libjs-inherits{a} 
  libjs-node-uuid{a} libpython-stdlib{a} libpython2.7-minimal{a} 
  libpython2.7-stdlib{a} libssl-dev{a} libssl1.0.0{a} libuv1{a} 
  libuv1-dev{a} mime-support{a} node-abbrev{a} node-ansi{a} node-async{a} 
  node-block-stream{a} node-combined-stream{a} node-cookie-jar{a} 
  node-delayed-stream{a} node-forever-agent{a} node-form-data{a} 
  node-fstream{a} node-glob{a} node-graceful-fs{a} node-gyp{a} 
  node-inherits{a} node-json-stringify-safe{a} node-lru-cache{a} 
  node-mime{a} node-minimatch{a} node-minimist{a} node-mkdirp{a} 
  node-nan{a} node-node-uuid{a} node-nopt{a} node-npmlog{a} node-once{a} 
  node-optimist{a} node-osenv{a} node-qs{a} node-request{a} node-rimraf{a} 
  node-semver{a} node-sigmund{a} node-tar{a} node-tunnel-agent{a} 
  node-uglify{a} node-which{a} node-wordwrap{a} nodejs{a} nodejs-dev{a} 
  openssl{a} python{a} python-minimal{a} python-pkg-resources{a} 
  python2.7{a} python2.7-minimal{a} zlib1g-dev{a} 
0

[Reproducible-builds] Bug#799657: python-admesh: FTBFS: admesh.c:1391:47: error: type of formal parameter 1 is incomplete

2015-09-21 Thread Chris Lamb 
Source: python-admesh
Version: 0.98.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,

python-admesh fails to build from source in unstable/amd64:

  [..]

  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
  -Wstrict-prototypes -fno-strict-aliasing -g -O2
  -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
  -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python2.7 -c admesh.c -o
  build/temp.linux-x86_64-2.7/admesh.o
  admesh.c:625:69: warning: 'enum stl_type' declared inside parameter
  list
   static CYTHON_INLINE PyObject* __Pyx_PyInt_From_enum__stl_type(enum
   stl_type value);
   ^
  admesh.c:625:69: warning: its scope is only this definition or
  declaration, which is probably not what you want
  admesh.c: In function '__pyx_pf_6admesh_3Stl_2__str__':
  admesh.c:1391:47: error: type of formal parameter 1 is incomplete
 __pyx_t_2 =
 __Pyx_PyInt_From_enum__stl_type(__pyx_v_self->_c_stl_file.stats.type);
 if (unlikely(!__pyx_t_2)) {__pyx_filename = __pyx_f[0];
 __pyx_lineno = 29; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
 ^
  admesh.c: At top level:
  admesh.c:13073:69: warning: 'enum stl_type' declared inside parameter
  list
   static CYTHON_INLINE PyObject* __Pyx_PyInt_From_enum__stl_type(enum
   stl_type value) {
   ^
  admesh.c:13073:78: error: parameter 1 ('value') has incomplete type
   static CYTHON_INLINE PyObject* __Pyx_PyInt_From_enum__stl_type(enum
   stl_type value) {

^
  admesh.c: In function '__Pyx_PyInt_From_enum__stl_type':
  admesh.c:13074:16: error: variable 'neg_one' has initializer but
  incomplete type
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
  ^
  admesh.c:13074:41: error: conversion to incomplete type
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
   ^
  admesh.c:13074:25: error: storage size of 'neg_one' isn't known
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
   ^
  admesh.c:13074:41: error: variable 'const_zero' has initializer but
  incomplete type
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
   ^
  admesh.c:13074:74: error: conversion to incomplete type
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
^
  admesh.c:13074:55: error: storage size of 'const_zero' isn't known
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
 ^
  admesh.c:13077:20: error: invalid application of 'sizeof' to
  incomplete type 'enum stl_type'
   if (sizeof(enum stl_type) < sizeof(long)) {
  ^
  admesh.c:13079:27: error: invalid application of 'sizeof' to
  incomplete type 'enum stl_type'
   } else if (sizeof(enum stl_type) <= sizeof(unsigned long)) {
 ^
  admesh.c:13081:27: error: invalid application of 'sizeof' to
  incomplete type 'enum stl_type'
   } else if (sizeof(enum stl_type) <= sizeof(unsigned
   PY_LONG_LONG)) {
 ^
  admesh.c:13085:20: error: invalid application of 'sizeof' to
  incomplete type 'enum stl_type'
   if (sizeof(enum stl_type) <= sizeof(long)) {
  ^
  admesh.c:13087:27: error: invalid application of 'sizeof' to
  incomplete type 'enum stl_type'
   } else if (sizeof(enum stl_type) <= sizeof(PY_LONG_LONG)) {
 ^
  admesh.c:13094:52: error: invalid application of 'sizeof' to
  incomplete type 'enum stl_type'
   return _PyLong_FromByteArray(bytes, sizeof(enum stl_type),
  ^
  admesh.c:13074:55: warning: unused variable 'const_zero'
  [-Wunused-variable]
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
 ^
  admesh.c:13074:25: warning: unused variable 'neg_one'
  [-Wunused-variable]
   const enum stl_type neg_one = (enum stl_type) -1, const_zero =
   (enum stl_type) 0;
   ^
  admesh.c: In function '__pyx_convert__to_py_stl_stats':
  admesh.c:13177:52: error: type of formal parameter 1 is incomplete
 member =

[Reproducible-builds] Bug#799658: krecipes: FTBFS: Missing Build-Depends on libsoprano-dev

2015-09-21 Thread Chris Lamb 
Source: krecipes
Version: 2.0~beta2-3
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,

krecipes fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


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