Re: [Reproducible-builds] repro-test (was: Re: Projects and mentors wanted for our participation in upcoming outreach programmes)

2016-02-18 Thread Holger Levsen 
Hi,

On Donnerstag, 18. Februar 2016, Johannes Schauer wrote:
>  - I also totally was reading this as re-protest initially and wondered why
> I would want to protest again, so I concur with Esa's observation and
> conclusion
> 
>  - on a second thought, maybe this was intentional :D

bingo! :-)
 
>  - it seems that the software is meant to be distribution agnostic. Would
> it still fit as a Debian SoC project? I'm not saying this wouldn't be
> useful for Debian but I think for Debian specifically a tool which lets
> developers directly test whether a given .dsc is reproducible would be
> more useful for Debian.

I guess thats totally fine. Also, diffoscope was debbindiff once too, and then 
grew. Likewise the focus of the GSOC project could be "just" creating that 
tool "within the Debian universe" (eg by implementing .deb based stuff, but 
designing with rpms and tars and foo in mind)…

>  - the README linked to above seems to implement its own backends (the
> --runner argument)  I'd like to draw your attention to the adt-virt-*
> programs which abstract several backends behind a common interface. That
> way, sbuild in experimental recently gained support for lxc, qemu and ssh
> backends without carrying its own code for each. Maybe using that would
> avoid code duplication in this tool as well?

oh wow. That made me curious and it seems piuparts supports adt-virt as well. 
Sadly that patch was merged without documentation… 

Thanks a lot for this pointer.
 

cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#815082: arachne-pnr: please make the build reproducible

2016-02-18 Thread Dhole 
Source: arachne-pnr 
Version: 0~20150927gitefdb026-1 
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi,

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

The attached patch sets the embedded date in the man pages generated by txt2man
to UTC with LC_ALL=C to normalize the locale. Once applied, arachne-pnr can be
built reproducibly in our current experimental framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds

Regards,

-- 
Dhole
diff -Nru arachne-pnr-0~20150927gitefdb026/debian/changelog 
arachne-pnr-0~20150927gitefdb026/debian/changelog
--- arachne-pnr-0~20150927gitefdb026/debian/changelog   2016-02-06 
11:33:55.0 +0100
+++ arachne-pnr-0~20150927gitefdb026/debian/changelog   2016-02-18 
01:38:23.0 +0100
@@ -1,3 +1,10 @@
+arachne-pnr (0~20150927gitefdb026-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Set changelog date to UTC with LC_ALL=C to make man pages reproducible. 
+
+ -- Eduard Sanou   Thu, 18 Feb 2016 01:38:01 +0100
+
 arachne-pnr (0~20150927gitefdb026-1) unstable; urgency=low
 
   * Initial release (Closes: #801230)
diff -Nru arachne-pnr-0~20150927gitefdb026/debian/rules 
arachne-pnr-0~20150927gitefdb026/debian/rules
--- arachne-pnr-0~20150927gitefdb026/debian/rules   2016-02-06 
11:33:55.0 +0100
+++ arachne-pnr-0~20150927gitefdb026/debian/rules   2016-02-18 
15:14:07.0 +0100
@@ -5,7 +5,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-CHANGELOG_DATE ?= $(shell date -d "`dpkg-parsechangelog --show-field Date`" 
+"%d %B %Y")
+CHANGELOG_DATE ?= $(shell LC_ALL=C date -u -d "`dpkg-parsechangelog 
--show-field Date`" +"%d %B %Y")
 
 %:
dh $@ 


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

[Reproducible-builds] repro-test (was: Re: Projects and mentors wanted for our participation in upcoming outreach programmes)

2016-02-18 Thread Johannes Schauer 
Hi,

Quoting Holger Levsen (2016-02-17 11:57:03)
> And then I was thinking to add another project, "develop reprotest tool", 
> what 
> other ideas do you have?

I have some more random thoughts about this:

 - unfortunately I failed to take part in that discussion in Athens but I
   assume you are talking about:
   https://reproducible-builds.org/events/athens2015/reprotest/ ?

 - I also totally was reading this as re-protest initially and wondered why I
   would want to protest again, so I concur with Esa's observation and
   conclusion

 - on a second thought, maybe this was intentional :D

 - it seems that the software is meant to be distribution agnostic. Would it
   still fit as a Debian SoC project? I'm not saying this wouldn't be useful
   for Debian but I think for Debian specifically a tool which lets developers
   directly test whether a given .dsc is reproducible would be more useful for
   Debian.

 - on the other hand, the linked README mentioned buildinfo files which are
   currently Debian specific

 - Can the now distribution-agnostic reproducible builds project not apply for
   their own slots with Google or outreachy? Since reproducibility benefits
   Debian as well, we would then overall have more slots :)

 - the README linked to above seems to implement its own backends (the --runner
   argument)  I'd like to draw your attention to the adt-virt-* programs which
   abstract several backends behind a common interface. That way, sbuild in
   experimental recently gained support for lxc, qemu and ssh backends without
   carrying its own code for each. Maybe using that would avoid code
   duplication in this tool as well?

 - tool seems to check if a package can be built reproducibly (by building
   twice in differing environments) as well as whether an existing Debian
   package can be reproduced (according to the information in its buildinfo).
   As for the latter, prospective students might want to have a look at code
   from #774415.

Thanks!

cheers, josch


signature.asc
Description: 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] licencing reproducible/presentations.git

2016-02-18 Thread Vagrant Cascadian 
On 2016-02-04, Holger Levsen wrote:
> I'd like to add proper licencing to the presentations in 
> git.debian.org/git/reproducible/presentations.git and you in the to: headers 
> of the mail are a git commiter to this repository, so I would like you to 
> (re-)licence your contributions under the following licence:
...
> but in any case the question is: are you fine to licence your work under 
> Creative Commons Attribution-Share Alike 3.0 License or (at the choice of the 
> user of the works) under GNU Free Documentation License, Version 1.3 or 
> later, 
> with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts?

I think my only contribution was those awful pictures of the armhf build
infrastructure, but I'm perfectly fine with those being licensed under
anything DFSG-free, and the above proposal sounds fine to me.

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

Re: [Reproducible-builds] Projects and mentors wanted for our participation in upcoming outreach programmes

2016-02-18 Thread Jérémy Bobbio 
Holger Levsen:
> On Sonntag, 14. Februar 2016, Nicolas Dandrimont wrote:
> > Some of you have been waiting for it, and it's finally time: we are looking
> > for mentors and project ideas for Debian's next participation in outreach
> > programmes, from May to August 2016.
> […]
> Also, I've mostly copied last years template so far, so I think we should 
> update it a bit.

I just did that, tried to capture the different things that people can
do and ideas that were submitted to the list. Its still listed as a
single project because I find it easier that way, but it could as well
be split into 5.

> And then I was thinking to add another project, "develop reprotest
> tool", what other ideas do you have?

My main concern about making reprotest a GSoC project is “who is going
to take care of the code after the summer?”  I've seen way too many
GSoC projects deliver something quite usable which is not followed up
properly and then quickly rot. So the project gets an applicant excited,
I really would want to lay down a proper plan for “after GSoC” as part
of the application process.

All other projects currently on the list are either because they already
have primary maintainers that will be able to review, merge and
follow-up on contributions.

-- 
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] Bug#815063: ruby-gruff: FTBFS: Testsuite hangs

2016-02-18 Thread Chris Lamb 
Source: ruby-gruff
Version: 0.4.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,

ruby-gruff fails to build from source in unstable/amd64 as the testsuite hangs:

  [..]

  
===
  E
  
===
  Error: test_wide(TestGruffArea): Magick::ImageMagickError: unable to read 
font `(null)' @ error/annotate.c/RenderFreetype/1127: `(null)'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb::in
 `get_type_metrics'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb::in
 `calculate_caps_height'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:522:in
 `setup_graph_measurements'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:484:in
 `setup_drawing'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:449:in
 `draw'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/area.rb:11:in
 `draw'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:423:in
 `write'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/test/gruff_test_case.rb:30:in
 `write'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/test/test_area.rb:119:in
 `test_wide'
   116:   def test_wide
   117: g = setup_basic_graph('800x400')
   118: g.title = "Area Wide"
=> 119: g.write("test/output/area_wide.png")
   120:   end
   121: 
   122: protected
  
===
  E
  
===
  Error: test_background_gradient_bottom_top(TestGruffBar): 
Magick::ImageMagickError: unable to read font `(null)' @ 
error/annotate.c/RenderFreetype/1127: `(null)'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb::in
 `get_type_metrics'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb::in
 `calculate_caps_height'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:522:in
 `setup_graph_measurements'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:484:in
 `setup_drawing'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:449:in
 `draw'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/bar.rb:20:in
 `draw'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/lib/gruff/base.rb:423:in
 `write'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/test/gruff_test_case.rb:30:in
 `write'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/test/gruff_test_case.rb:114:in
 `write_test_file'
  
/home/lamby/temp/cdt.20160218111610.VMPm034k2Z/ruby-gruff-0.4.0/test/test_bar.rb:325:in
 `test_background_gradient_bottom_top'
   322:   g.data(name, values)
   323: end
   324: g.minimum_value = 0
=> 325: write_test_file(g, 'bar_background_gradient_bottom_top.png')
   326:   end
   327: 
   328:   def test_background_gradient_left_right

  [..]

The full build log is attached.


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#815062: openttd-openmsx: FTBFS: override_dh_auto_test [..] Differences in md5sums

2016-02-18 Thread Chris Lamb 
Source: openttd-openmsx
Version: 0.3.1-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,

openttd-openmsx fails to build from source in unstable/amd64:

  [..]

   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: source package openttd-openmsx
  dpkg-buildpackage: source version 0.3.1-3
  dpkg-buildpackage: source distribution unstable
  dpkg-buildpackage: source changed by Matthijs Kooijman 
   dpkg-source --before-build openttd-openmsx-0.3.1
  dpkg-buildpackage: host architecture amd64
   fakeroot debian/rules clean
  dh  clean
 dh_testdir
 debian/rules override_dh_auto_clean
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  # Don't use dh_auto_clean. It thinks any target is valid because
  # it generates output (dependency analysis) before erroring out.
  make distclean
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  Version change detected. Re-build forced.
  
  [Generating] Makefile.dep
  [Cleaning]
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
 dh_clean
   debian/rules build
  dh  build
 dh_testdir
 dh_update_autotools_config
 dh_auto_configure
 debian/rules override_dh_auto_build
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  make  
"INSTALL_DIR=debian/openttd-openmsx/usr/share/games/openttd/baseset/openmsx" 
"UNIX2DOS=" "_V="
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  Version change detected. Re-build forced.
  [ -e *.REV ] && rm *.REV || echo ""
  
  touch openmsx-0.3.1.REV
  [Generating] Makefile.dep
  for i in `: st -A | grep -v  "^I" | grep -v "^?" | grep -v "^R" | grep -v 
"^\!" | cut -d\  -f2 | grep -E '(list|grf)$'`; do echo "$i: "`for j in list 
mid; do cat $i |  grep -v '^//' | grep -o "[a-zA-Z0-9/_.-]\+\.$j" | sort | 
uniq; done` | grep -v -E ": $" ; done | sort | uniq | awk '{ print $0"\n\t$(_V) 
touch $@" }' > Makefile.dep
  for i in `ls Makefile* scripts/* | grep -v Makefile.dep`; do echo 
"Makefile.dep: $i"; done >> Makefile.dep
  [ -e openmsx-0.3.1.REV ] && [ "`cat openmsx-0.3.1.REV`" = "0.3.1" ] || echo 
"0.3.1" > openmsx-0.3.1.REV
  make  -f Makefile openmsx.obm
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  [Generating] openmsx.obm
  cat docs/descriptions.ptxt | grep -E '^description' | sed 's/$/ [OpenMSX 
0.3.1]/' >> openmsx.obm
  cat src/themes.list | scripts/playlist.py >> openmsx.obm
  cat src/themes.list | scripts/sanitize_list.py | scripts/md5list.py >> 
openmsx.obm
  cat src/themes.list | scripts/sanitize_list.py | scripts/namelist.py >> 
openmsx.obm
  [Done] Basesound successfully generated.
  
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
 debian/rules override_dh_auto_test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  # Check md5sums of files. This isn't really useful (mostly meant
  # for use with opengfx), but we'll have to override dh_auto_test
  # anyway (since make test generates debug output), so we might
  # as well call make check.
  make check  
"INSTALL_DIR=debian/openttd-openmsx/usr/share/games/openttd/baseset/openmsx" 
"UNIX2DOS=" "_V="
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20160218105550.q49Y2v5K53/openttd-openmsx-0.3.1'
  if [ -f openmsx-0.3.1.md5 ]; then echo "[CHECKING md5sums]"; else echo 
"Required file 'openmsx-0.3.1.md5' which to test against not found!"; false; fi
  [CHECKING md5sums]
  md5sum  src/tttheme2.mid src/big_man_boogie_redfarn.mid 
src/ttsong_iv_imuh3.mid src/modern_motion.mid src/busy_schedule.mid 
src/the_fast_route.mid src/ttsong_iii_imuh3.mid src/train_filled_with_cash.mid 
src/flying_scotsman.mid src/chuggachugga.mid src/the_hobo_redfarn.mid 
src/ultimate_run.mid src/midnight_snow_run.mid src/run_for_your_life.mid 
src/coconut_run2.mid src/harp_harmony.mid src/mighty_giant_run.mid 
src/wood_whistles.mid src/linns_basket.mid src/relax_song.mid 
src/chemistry_lab.mid src/5432gone_redfarn.mid src/boogi_marabi_redfarn.mid 
src/moo_redfarn.mid src/say_what_redfarn.mid src/be_sharp_bw_redfarn.mid 
src/careless_perc_redfarn.mid src/mosey_along_redfarn.mid 
src/slow_neasy_redfarn.mid src/city_blues_redfarn.mid 
src/no_work_song_redfarn.mid openmsx.obm | sed "s/  / /;s/