reproducible.debian.net status changes for strip-nondeterminism

[Reproducible builds folks]

2016-09-12 07:35 
https://tests.reproducible-builds.org/debian/unstable/amd64/strip-nondeterminism
 changed from FTBFS -> reproducible

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

Bug#837619: jdeb: FTBFS: Failed tests: org.vafer.jdeb.signing.PGPSignerTestCase#testClearSign

[Chris Lamb]

Source: jdeb
Version: 1.5-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,

jdeb fails to build from source in unstable/amd64:

  [..]

  Adding debian:WoSign.pem
  Adding debian:WoSign_China.pem
  Adding debian:XRamp_Global_CA_Root.pem
  Adding debian:certSIGN_ROOT_CA.pem
  Adding debian:ePKI_Root_Certification_Authority.pem
  Adding debian:thawte_Primary_Root_CA.pem
  Adding debian:thawte_Primary_Root_CA_-_G2.pem
  Adding debian:thawte_Primary_Root_CA_-_G3.pem
  done.
  done.
  Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.35.4-4) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=89a63a68b5f3
  TERM=xterm
  PAGER=more
  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  PWD=/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb/jdeb-1.5
  OLDPWD=/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  GPG_KEY=1E953E27D4311E58
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building jdeb 1.5-2 on amd64   
  **
  
**
  
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package jdeb
  dpkg-buildpackage: info: source version 1.5-2
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Emmanuel Bourg 
   dpkg-source --before-build jdeb-1.5
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  dh clean --buildsystem=maven
 dh_testdir -O--buildsystem=maven
 dh_auto_clean -O--buildsystem=maven
"for dir in \$(find . -name target -type d); do if [ -f \$(echo \$dir | 
sed -e s/target\$/pom.xml/) ]; then rm -Rf \$dir; fi done"
mh_unpatchpoms -plibjdeb-java
 dh_clean -O--buildsystem=maven
   debian/rules build
  dh build --buildsystem=maven
 dh_testdir -O--buildsystem=maven
 dh_update_autotools_config -O--buildsystem=maven
 dh_auto_configure -O--buildsystem=maven
  find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar': No 
such file or directory
  find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar': 
No such file or directory
  find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': 
No such file or directory
mh_patchpoms -plibjdeb-java --debian-build --keep-pom-version 
--maven-repo=/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb/jdeb-1.5/debian/maven-repo
 dh_auto_build -O--buildsystem=maven
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb/jdeb-1.5
 -Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb/jdeb-1.5/debian/maven.properties
 org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml 
-Ddebian.dir=/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb/jdeb-1.5/debian
 
-Dmaven.repo.local=/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb/jdeb-1.5/debian/maven-repo
 package -DskipTests -Dnotimestamp=true -Dlocale=en_US
  [INFO] Scanning for projects...
  [INFO]
 
  [INFO] 

  [INFO] Building jdeb 1.5
  [INFO] 

  [INFO] 
  [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ jdeb ---
  [INFO] Using 'UTF-8' encoding to copy filtered resources.
  [INFO] Copying 2 resources
  [INFO] 
  [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ jdeb ---
  [INFO] Changes detected - recompiling the module!
  [INFO] Compiling 49 source files to 
/home/lamby/temp/cdt.20160912225159.DpKdGEDtQm.db.jdeb/jdeb-1.5/target/classes
  [INFO] 

Bug#837618: docbook-slides: FTBFS: dh_installxmlcatalogs: Unexpected debhelper version format

[Chris Lamb]

Source: docbook-slides
Version: 3.4.0-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,

docbook-slides fails to build from source in unstable/amd64:

  [..]

  
  
**
  ** Starting build 
  **
  
**
  
   Package:  docbook-slides
   Version:  3.4.0-5
   Build architecture:   amd64
   Date: Mon, 12 Sep 2016 22:51:50 +0100
   Hostname: 8f539c25af1f
   Uname:Linux 8f539c25af1f 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 
(2016-08-28) x86_64 GNU/Linux
   /etc/timezone:Europe/London
  
  
**
  ** Installing build dependencies  
  **
  
**
  
  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'docbook-slides-build-deps' in 
'../docbook-slides-build-deps_3.4.0-5_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package docbook-slides-build-deps.
  (Reading database ... 23321 files and directories currently installed.)
  Preparing to unpack docbook-slides-build-deps_3.4.0-5_all.deb ...
  Unpacking docbook-slides-build-deps (3.4.0-5) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
sgml-base xml-core
  Suggested packages:
sgml-base-doc
  The following NEW packages will be installed:
sgml-base xml-core
  0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 38.9 kB of archives.
  After this operation, 263 kB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 sgml-base all 1.28 
[14.7 kB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 xml-core all 
0.13+nmu2 [24.2 kB]
  Fetched 38.9 kB in 0s (0 B/s)
  Selecting previously unselected package sgml-base.
  (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 ... 23325 files and directories currently installed.)
  Preparing to unpack .../0-sgml-base_1.28_all.deb ...
  Unpacking sgml-base (1.28) ...
  Selecting previously unselected package xml-core.
  Preparing to unpack .../1-xml-core_0.13+nmu2_all.deb ...
  Unpacking xml-core (0.13+nmu2) ...
  Setting up sgml-base (1.28) ...
  Processing triggers for man-db (2.7.5-1) ...
  Setting up xml-core (0.13+nmu2) ...
  Processing triggers for sgml-base (1.28) ...
  Setting up docbook-slides-build-deps (3.4.0-5) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=8f539c25af1f
  TERM=xterm
  PAGER=more
  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  
PWD=/home/lamby/temp/cdt.20160912225148.W8rB87PWuO.db.docbook-slides/docbook-slides-3.4.0
  OLDPWD=/home/lamby/temp/cdt.20160912225148.W8rB87PWuO.db.docbook-slides
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  GPG_KEY=1E953E27D4311E58
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building docbook-slides 3.4.0-5 on 

Re: Draft of blog post for week 72 in blog.git

[Holger Levsen]

On Mon, Sep 12, 2016 at 04:39:17PM +0100, Chris Lamb wrote:
> > you published on Monday, I dont think there is any need to apologize for
> > it. I believe publishing on Monday or Tuesday is totally fine
> Regular is rationally and irrationally good for both reader and writer :) 

if "regular" is the most important criteria, I would vote for aiming for
releasing on Tuesdays then :-D

rationale: weekends should be off. one day for review.


-- 
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: [Reproducible-builds] Minimising work needed for this build-path issue

[HW42]

Ximin Luo:
> Daniel Kahn Gillmor:
>> On Fri 2016-09-09 01:33:00 +0200, HW42 wrote:
>>> According to codesearch.d.n it seems only SOURCE_DIR_ROOT isn't taken
>>> yet. (Google finds at least one case).
>>
>> thanks for looking, that's what i should have done in the first place.
>>
>>> also bikeshedding: I dislike SOURCE_DIR_ROOT because the name is some
>>> how redundant. What's the difference between SOURCE_DIR and
>>> SOURCE_DIR_ROOT? But I don't care much about the naming.
>>
>> if i've got some source with code in three directories, they're all
>> SOURCE_DIRs, but only the top level is SOURCE_DIR_ROOT.
>>
> 
> I can see the benefit in choosing the name carefully; here are my suggestions:
> 
> SOURCE_ROOTDIR
> SOURCE_TOPDIR

With _DIR they are both already used.

> SOURCE_PREFIX oh, already used by firefox :(
> 
> I preferred the ${x}dir style instead of dir_${x} or ${x}_dir because
> of some existing conventions like
> 
> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html

Well, OTOH, freedesktop.org uses _DIR:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html



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: Build path variation and __FILE__

[Sascha Steinbiss]

Hi all,

> HW42:
>> Sascha Steinbiss:
>>> a) Introducing something like -ffile-prefix-map similarly to
>>> -fdebug-prefix-map to address this issue. There is already an
>>> unreviewed patch for gcc submitted by an unrelated party [3] and I
>>> could try and raise awareness for this bug with the GCC devs. However,
>>> this option would be incompatible with old compilers and hence
>>> probably not easily enabled in the default dpkg-buildflags. IMHO it
>>> would be a good thing to have though.
>>
>> If I understood Guillem correctly he is fine with dpkg-buildflags in
>> unstable to export compiler flags which are only supported by the
>> compilers in unstable. So a new flag would be ok.
>
> This is my preferred approach as well. On top of [3] we should add a
> patch for GCC to use SOURCE_ROOT_DIR[*] for -ffile-prefix-map if it is
> not set on the command line.

Agreed. I have posted a follow-up messge on the bug tracker, but no
response yet. Will also ping the gcc-patches mailing list. The original
author submitted a patch [1] which seemed to have been overlooked and/or
abandoned. If I can get that discussion going again then we can suggest
this addition.

Cheers
Sascha

>>>
>>> [1] http://public.kitware.com/pipermail/cmake/2013-January/053114.html
>>> [2] https://paste.debian.net/806611
>>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
>>> [4] http://ohnopub.net/~ohnobinki/bin_replace_string/
>>
>


-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

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

Re: Draft of blog post for week 72 in blog.git

[Chris Lamb]

> you published on Monday, I dont think there is any need to apologize for
> it. I believe publishing on Monday or Tuesday is totally fine

Regular is rationally and irrationally good for both reader and writer :) 


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

Re: Draft of blog post for week 72 in blog.git

[Holger Levsen]

On Mon, Sep 12, 2016 at 08:52:09AM +0100, Chris Lamb wrote:
> Well, I would never publish without any review - just would prefer to
> have given more! :)

me too, indeed.

> I regrettably ended up delaying further and have just published. Apologies
> this wasn't live until now.

you published on Monday, I dont think there is any need to apologize for
it. I believe publishing on Monday or Tuesday is totally fine, Sunday
rocks, but then there is maybe less time for reviews… :-)


-- 
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: Build path variation and __FILE__

[Ximin Luo]

HW42:
> Sascha Steinbiss:
>> a) Introducing something like -ffile-prefix-map similarly to
>> -fdebug-prefix-map to address this issue. There is already an
>> unreviewed patch for gcc submitted by an unrelated party [3] and I
>> could try and raise awareness for this bug with the GCC devs. However,
>> this option would be incompatible with old compilers and hence
>> probably not easily enabled in the default dpkg-buildflags. IMHO it
>> would be a good thing to have though.
> 
> If I understood Guillem correctly he is fine with dpkg-buildflags in
> unstable to export compiler flags which are only supported by the
> compilers in unstable. So a new flag would be ok.
> 

This is my preferred approach as well. On top of [3] we should add a patch for 
GCC to use SOURCE_ROOT_DIR[*] for -ffile-prefix-map if it is not set on the 
command line.

This would be consistent with our other approaches, and this consistency would 
help to strengthen the legitimacy of this approach more broadly too.

X

[*] name TBD, see the other thread "Minimising work needed for this build-path 
issue".

>>
>> [1] http://public.kitware.com/pipermail/cmake/2013-January/053114.html
>> [2] https://paste.debian.net/806611
>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
>> [4] http://ohnopub.net/~ohnobinki/bin_replace_string/
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://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

python-popcon source package counts

[Ximin Luo]

Hi Bastian,

I'm wondering if you could get around to this pull request soon?

https://github.com/venthur/python-popcon/pull/2

We would like it to make this page more accurate:

https://tests.reproducible-builds.org/index_issues.html

At the moment we are assuming that source and binary packages are the same 
(since that is all python-popcon offers) which gives wildly inaccurate results, 
e.g. it thinks linux "has popcon score 5".

I'm also happy to take over maintenance of this package, if you don't have the 
time for that.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://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

Re: Draft of blog post for week 72 in blog.git

[Ximin Luo]

Chris Lamb:
>> (I've added two bits about t.r-b.o.)
> 
> ACK, thank you.
> 
>> looks nice & thanks for giving some time to review!
> 
> Well, I would never publish without any review - just would prefer to
> have given more! :)
> 
> I regrettably ended up delaying further and have just published. Apologies
> this wasn't live until now.
> 

Sorry I didn't reply earlier. What happened to the usual "Packages reviewed and 
fixed, and bugs filed" section (which took most of the work, running scripts 
etc) - was there none this week or did we just decide to drop that section?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://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

Re: [Reproducible-builds] Minimising work needed for this build-path issue

[Ximin Luo]

Daniel Kahn Gillmor:
> On Fri 2016-09-09 01:33:00 +0200, HW42 wrote:
>> According to codesearch.d.n it seems only SOURCE_DIR_ROOT isn't taken
>> yet. (Google finds at least one case).
> 
> thanks for looking, that's what i should have done in the first place.
> 
>> also bikeshedding: I dislike SOURCE_DIR_ROOT because the name is some
>> how redundant. What's the difference between SOURCE_DIR and
>> SOURCE_DIR_ROOT? But I don't care much about the naming.
> 
> if i've got some source with code in three directories, they're all
> SOURCE_DIRs, but only the top level is SOURCE_DIR_ROOT.
> 

I can see the benefit in choosing the name carefully; here are my suggestions:

SOURCE_ROOTDIR
SOURCE_TOPDIR
SOURCE_PREFIX oh, already used by firefox :(

I preferred the ${x}dir style instead of dir_${x} or ${x}_dir because of some 
existing conventions like

https://www.gnu.org/prep/standards/html_node/Directory-Variables.html

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://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

Re: Do the file timestamps in ISOs matter ?

[Thomas Schmitt]

Hi,

by the narrow margin of one vote, the proposal "set_to_mtime" wins.
Committed as http://libburnia-project.org/changeset/5757

man 1 xorrisofs of the next release will state:

  SOURCE_DATE_EPOCH  belongs to the specs of reproducible-builds.org.  It
  is supposed to be either undefined or to contain a decimal number which
  tells the seconds since january 1st 1970. If it contains a number, then
  it is used as time value to set the default of --modification-date= and
  --gpt_disk_guid.The   default   of   --set_all_file_dates  is  then
  "set_to_mtime".
  Startup  files  and  program  options  can  override  the   effect   of
  SOURCE_DATE_EPOCH.

This refers to the description of two new options:

  --gpt_disk_guid value
  Control  whether  an emerging GPT shall get a randomly generated
  disk GUID or whether the GUID is supplied by  the  user.   Value
  "random"  is  default.  Value "modification-date" produces a low
  quality GUID from the value set by option --modification-date=.
  [...]

  --set_all_file_dates timestring
  [...]
  If the timestring is "set_to_mtime", then the atime and ctime of
  each file and directory get set to  the  value  found  in  their
  mtime.
  [...]


I am now beginning final regression tests for the release of xorriso-1.4.6.


Have a nice day :)

Thomas


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

Processing of strip-nondeterminism_0.028-1_amd64.changes

[Debian FTP Masters]

strip-nondeterminism_0.028-1_amd64.changes uploaded successfully to localhost
along with the files:
  strip-nondeterminism_0.028-1.dsc
  strip-nondeterminism_0.028.orig.tar.gz
  strip-nondeterminism_0.028-1.debian.tar.xz

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

Re: Draft of blog post for week 72 in blog.git

[Chris Lamb]

> (I've added two bits about t.r-b.o.)

ACK, thank you.

> looks nice & thanks for giving some time to review!

Well, I would never publish without any review - just would prefer to
have given more! :)

I regrettably ended up delaying further and have just published. Apologies
this wasn't live until now.


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#837524: psychtoolbox-3: FTBFS: cp: cannot stat 'moglcore.mex': No such file or directory

[Chris Lamb]

Source: psychtoolbox-3
Version: 3.0.12.20160414.dfsg1-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,

psychtoolbox-3 fails to build from source in unstable/amd64:

  [..]

  gl_auto.c: In function 'glut_soliddodecahedron':
  gl_auto.c:5297:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutSolidDodecahedron' will never be NULL [-Waddress]
if (NULL == glutSolidDodecahedron) 
mogl_glunsupported("glutSolidDodecahedron");
 ^~
  gl_auto.c: In function 'glut_wireteapot':
  gl_auto.c:5304:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutWireTeapot' will never be NULL [-Waddress]
if (NULL == glutWireTeapot) mogl_glunsupported("glutWireTeapot");
 ^~
  gl_auto.c: In function 'glut_solidteapot':
  gl_auto.c:5311:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutSolidTeapot' will never be NULL [-Waddress]
if (NULL == glutSolidTeapot) mogl_glunsupported("glutSolidTeapot");
 ^~
  gl_auto.c: In function 'glut_wireoctahedron':
  gl_auto.c:5318:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutWireOctahedron' will never be NULL [-Waddress]
if (NULL == glutWireOctahedron) mogl_glunsupported("glutWireOctahedron");
 ^~
  gl_auto.c: In function 'glut_solidoctahedron':
  gl_auto.c:5325:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutSolidOctahedron' will never be NULL [-Waddress]
if (NULL == glutSolidOctahedron) mogl_glunsupported("glutSolidOctahedron");
 ^~
  gl_auto.c: In function 'glut_wiretetrahedron':
  gl_auto.c:5332:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutWireTetrahedron' will never be NULL [-Waddress]
if (NULL == glutWireTetrahedron) mogl_glunsupported("glutWireTetrahedron");
 ^~
  gl_auto.c: In function 'glut_solidtetrahedron':
  gl_auto.c:5339:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutSolidTetrahedron' will never be NULL [-Waddress]
if (NULL == glutSolidTetrahedron) 
mogl_glunsupported("glutSolidTetrahedron");
 ^~
  gl_auto.c: In function 'glut_wireicosahedron':
  gl_auto.c:5346:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutWireIcosahedron' will never be NULL [-Waddress]
if (NULL == glutWireIcosahedron) mogl_glunsupported("glutWireIcosahedron");
 ^~
  gl_auto.c: In function 'glut_solidicosahedron':
  gl_auto.c:5353:11: warning: the comparison will always evaluate as 'false' 
for the address of 'glutSolidIcosahedron' will never be NULL [-Waddress]
if (NULL == glutSolidIcosahedron) 
mogl_glunsupported("glutSolidIcosahedron");
 ^~
  gl_auto.c: In function 'gl_clearnamedframebufferfv':
  gl_auto.c:9159:3: warning: passing argument 4 of 
'__glewClearNamedFramebufferfv' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
 (const GLfloat*)mxGetData(prhs[3]));
 ^
  gl_auto.c:9159:3: note: expected 'GLfloat * {aka float *}' but argument is of 
type 'const GLfloat * {aka const float *}'
  In file included from mogltypes.h:45:0,
   from gl_auto.c:9:
  gl_auto.c: In function 'gl_clearnamedframebufferfi':
  gl_auto.c:9166:2: error: too few arguments to function 
'__glewClearNamedFramebufferfi'
glClearNamedFramebufferfi((GLuint)mxGetScalar(prhs[0]),
^
  gl_auto.c: In function 'gl_multidrawarraysindirectcountarb':
  gl_auto.c:10360:3: warning: passing argument 2 of 
'__glewMultiDrawArraysIndirectCountARB' makes pointer from integer without a 
cast [-Wint-conversion]
 (GLintptr)mxGetScalar(prhs[1]),
 ^
  gl_auto.c:10360:3: note: expected 'const void *' but argument is of type 
'long int'
  gl_auto.c: In function 'gl_multidrawelementsindirectcountarb':
  gl_auto.c:10372:3: warning: passing argument 3 of 
'__glewMultiDrawElementsIndirectCountARB' makes pointer from integer without a 
cast [-Wint-conversion]
 (GLintptr)mxGetScalar(prhs[2]),
 ^
  gl_auto.c:10372:3: note: expected 'const void *' but argument is of type 
'long int'
  gl_auto.c: In function 'gl_matrixindexubvarb':
  gl_auto.c:10398:3: warning: passing argument 2 of '__glewMatrixIndexubvARB' 
discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 (const GLubyte*)mxGetData(prhs[1]));
 ^
  gl_auto.c:10398:3: note: expected 'GLubyte * {aka unsigned char *}' but 
argument is of type 'const GLubyte * {aka const unsigned char *}'
  gl_auto.c: In function 'gl_matrixindexusvarb':
  gl_auto.c:10406:3: warning: passing argument 2 of '__glewMatrixIndexusvARB' 
discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 (const GLushort*)mxGetData(prhs[1]));
 ^