Bug#945530: python-uritemplate: upstream have changed hands

[Jérémy Bobbio]

Source: python-uritemplate

Hi!

python-uritemplate currently packages what was at 
https://github.com/uri-templates/uritemplate-py/
This project has been archived and superseded by 
https://github.com/python-hyper/uritemplate

How about updating python-uritemplate to package the latter?

It is also available from PyPI as `uritemplate` which seems like the correct 
fit given Debian package name.

Sadly, the API is not exactly the same between the two versions.

Thanks for your time,
Lunar

Bug#927376: haveged: please ship haveged-udeb to help solve entropy starvation in debian-installer

[Jérémy Bobbio]

On 18/04/2019 18:41, Cyril Brulebois wrote:
> Hi haveged maintainers,
> 
> As time passes, we encounter more and more entropy starvation issues in
> d-i; this includes UUID generation for fontconfig (#898468, worked
> around by computing the cache at build time), HTTPS connections, SSH
> keypair generations, but also wireless adapter initializations…
> 
> My starting point was:
>   https://bugs.debian.org/923675
> 
> and I've investigated using a new haveged-udeb package. Even if it isn't
> fully integrated into d-i yet, first tests look very good.
> 
> I've pushed a “buster” branch to the repository with the udeb addition
> (and also the Vcs-* update cherry-picked from the master branch because
> not having uptodate headers is very annoying), and I've subscribed to
> this package to keep an eye on it. Direct links to commits:
>   
> https://salsa.debian.org/debian/haveged/commit/448ed064ed2c54951e9878c9111e1d5bb0538fa8
>   
> https://salsa.debian.org/debian/haveged/commit/c208e76fb05117df918f416cb74ae70e08ad006c
>   
> https://salsa.debian.org/debian/haveged/commit/40e3d2a960c2ef4b65bd081d22e43921aa20c521
> 
> Any objections to my uploading an updated haveged package to unstable,
> from this buster branch?

Go ahead. I trust you to do the right thing!

-- 
Lunar

Bug#906461: florence: diff for NMU version 0.6.3-1.1

[Jérémy Bobbio]

Hi!

On 14/09/2018 15:51, Adrian Bunk wrote:
> I've prepared an NMU for florence (versioned as 0.6.3-1.1) and uploaded 
> it to DELAYED/14. Please feel free to tell me if I should cancel it.

Thanks!

Feel free to upload it right away or even take over the package.
I sadly still haven't found enough time and energy to adjust packages to
my current (non-)involvement in Debian.

--
Lunar



signature.asc
Description: OpenPGP digital signature

Bug#906294: haveged: New upstream version

[Jérémy Bobbio]

On 16/08/2018 19:22, Steffen Moeller wrote:
> Package: haveged
> Version: 1.9.1-6
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Version 1.9.6 is available. Please kindly inform me if you would appreciate 
> to be helped out.

The package is in collab-maint, please go ahead!

I'm now set on retiring from Debian but I'm still haven't found a large
enough time window to do so. If you want to be listed as the maintainer,
feel free to do so.

Thanks!
-- 
Lunar



signature.asc
Description: OpenPGP digital signature

Bug#888237: Fwd: Re: diffoscope and file renames

[Jérémy Bobbio]

Chris Lamb:
> > I had no idea I should have installed it, and indeed I was missing it.
> 
> … which is itself a bug! However, the solution is not very obvious - why
> can't really detect whether we need would benefit from fuzzy matching without
> doing said fuzzy matching!
> 
> Will have a think :)

In that case, it might have worked to run difflib.SequenceMatcher on
archive paths to compare their distance. I'm not sure if it's a good
idea at all. :)

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


signature.asc
Description: PGP signature

Bug#882103: python-pkg-resources: crashing with "ImportError: No module named load_entry_point"

[Jérémy Bobbio]

intrigeri:
> Lunar, unless you disagree I'll do a team upload that disables this
> profile by default. We can re-enable it if/once someone feels like
> keeping it up-to-date and working. What do you think?

Please go ahead! I sadly won't have time to take a look before a while.
:)

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


signature.asc
Description: PGP signature

Bug#868684: stretch-pu: package haveged/1.9.1-5+deb9u1

[Jérémy Bobbio]

Adam D. Barratt:
> On Mon, 2017-07-17 at 18:43 +0200, Jérémy Bobbio wrote:
> > Package: release.debian.org
> > User: release.debian@packages.debian.org
> > Usetags: pu
> 
> If you're going to write the metadata by hand, please at least spell it
> correctly. ;-) Fixed.

Oops! Thanks for noticing and cleaning it up. :)

> > I'd like to update the haveged package in stretch. The current version
> > has a bug which is proving to be affecting more computers than it
> > originally seemed. The issue (#858134) is a race that can lead to failed
> > or greatly delayed boots.
> 
> +haveged (1.9.1-5+deb9u1) stable; urgency=medium
> 
> Please use "stretch" as the changelog distribution. With that change,
> feel free to upload.

Uploaded. Thanks for your prompt review!

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


signature.asc
Description: PGP signature

Bug#868684: stretch-pu: package haveged/1.9.1-5+deb9u1

[Jérémy Bobbio]

Package: release.debian.org
User: release.debian@packages.debian.org
Usetags: pu
Tags: stretch
Severity: normal

Hi!

I'd like to update the haveged package in stretch. The current version
has a bug which is proving to be affecting more computers than it
originally seemed. The issue (#858134) is a race that can lead to failed
or greatly delayed boots.

Attached is the diff between the package currently in stretch and the
proposed update.

Thanks!

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru haveged-1.9.1/debian/changelog haveged-1.9.1/debian/changelog
--- haveged-1.9.1/debian/changelog	2016-11-30 15:49:36.0 +0100
+++ haveged-1.9.1/debian/changelog	2017-07-17 18:31:46.0 +0200
@@ -1,3 +1,11 @@
+haveged (1.9.1-5+deb9u1) stable; urgency=medium
+
+  * Start haveged.service after systemd-tmpfiles-setup.service has been run.
+Many thanks to Jan Echternach for reporting the problem and suggesting
+a fix. (Closes: #858134)
+
+ -- Jérémy Bobbio <lu...@debian.org>  Mon, 17 Jul 2017 18:31:46 +0200
+
 haveged (1.9.1-5) unstable; urgency=medium
 
   * Fix URL in Homepage control field.
diff -Nru haveged-1.9.1/debian/gbp.conf haveged-1.9.1/debian/gbp.conf
--- haveged-1.9.1/debian/gbp.conf	2015-09-04 17:39:38.0 +0200
+++ haveged-1.9.1/debian/gbp.conf	2017-07-17 18:31:46.0 +0200
@@ -1,2 +1,2 @@
 [DEFAULT]
-debian-branch = master
+debian-branch = stretch
diff -Nru haveged-1.9.1/debian/haveged.service haveged-1.9.1/debian/haveged.service
--- haveged-1.9.1/debian/haveged.service	2016-11-30 12:22:40.0 +0100
+++ haveged-1.9.1/debian/haveged.service	2017-07-17 18:31:46.0 +0200
@@ -3,7 +3,7 @@
 Documentation=man:haveged(8) http://www.issihosts.com/haveged/
 DefaultDependencies=no
 ConditionVirtualization=!container
-After=apparmor.service systemd-random-seed.service
+After=apparmor.service systemd-random-seed.service systemd-tmpfiles-setup.service
 Before=sysinit.target shutdown.target
 
 [Service]


signature.asc
Description: Digital signature

Bug#848365: jessie-pu: package coquelicot/0.9.2-4+deb8u1

[Jérémy Bobbio]

Adam D. Barratt:
> Control: tags -1 + moreinfo
> 
> On Fri, 2016-12-16 at 18:31 +0100, Jérémy Bobbio wrote:
> > I would like to important issues affecting coquelicot in jessie:
> > 
> > #809351: properly run coquelicot under the 'coquelicot' user and not
> > as root. It was always intended that way, that's why the cron is running
> > under the coquelicot user already. The issue has been fixed a while ago
> > for stretch (in 0.9.4-1, uploaded September 2015). This backports the
> > changes from the unstable branch which switched to using
> > init-d-script(5).
> > 
> > #808018: silence deprecation warnings coming from cron. While the
> > warnings actually come from ruby-fast-gettext, they make the garbage
> > collection cron send an email on every run.
> 
> + sysvinit-utils (>= 2.88dsf-50),
> 
> What's that for? sysvinit-utils is Essential:yes.
> 
> Hmmm, so the answer appears to be "because that's when init-d-script(5)
> was added". That doesn't really seem like a minimal change for fixing
> the user that the daemon is running as.

You are right. I agree it's not a minimal change but the initscript
using init-d-script has been in Stretch for more than a year. I thought
it would be safer to use a version that has received more testing than
to patch the older one. I could still do that if you'd prefer.

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


signature.asc
Description: Digital signature

Bug#848049: diffoscope: Add detection of order-only differences in plain text formats

[Jérémy Bobbio]

Hi!

Маша Глухова:
> The reason why I did not use some algorihm like that is that it requires to
> read files for the second time. Right now, all the actual work with the
> content of the files (except for the quick check for has_same_content) is
> delegated to diff, and on big files, it occupies most of the time. Assuming
> that for big files, reading them from drive would be the bottleneck, I
> tried to avoid reading them again, instead working with the result of the
> diff.
> Still, I would be happily mistaken. I will implement your version and
> compare the performance.

You would not have to read the file twice as long as you do the hash
in the difference module, when each line is actually fed to diff.
A similar trick is already used to cope with files that are too long,
see diffoscope.difference.make_feeder_from_raw_reader()

I don't know if my suggestions is a good one. It might not be a good
idea at all. Feel free to discuss it with your mentor before spending
too much time on it.

> Thank you again :)

PS: Please call me Lunar. :)

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


signature.asc
Description: Digital signature

Bug#849142: [PATCH] Update dex_expected_diffs and test requirement to ensure test compatibility with enjarify >= 1.0.3. (Closes: #849142)

[Jérémy Bobbio]

Chris Lamb:
> Daniel Shahaf wrote:
> 
> > > +if subprocess.call(
> > > +('python3', '-c', 'import enjarify.typeinference'),
> > 
> > Use sys.executable instead of hardcoding 'python3', to handle the case
> > that there's more than one python3 binary on the system?
> 
> I deliberately used python3 to match the behaviour of what the
> /usr/bin/enjarify script does.

Guess it's worth adding a comment about it for future readers. :)

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


signature.asc
Description: Digital signature

Bug#848049: diffoscope: Add detection of order-only differences in plain text formats

[Jérémy Bobbio]

Маша Глухова:
> I believe the attached patch would provide the requested functionality.

Nice work! :)

> From: Maria Glukhova 
> Date: Sat, 24 Dec 2016 12:29:57 +0200
> Subject: [PATCH] Add detection of order-only difference in plain text format.
> 
> Detect if the text files' contents differ only in line ordering, and give an 
> appropriate comment.
> […]
> +def order_only_difference(unified_diff):
> +diff_lines = unified_diff.splitlines()
> +added_lines = [line[1:] for line in diff_lines if line.startswith('+')]
> +removed_lines = [line[1:] for line in diff_lines if line.startswith('-')]
> +# Faster check: does number of lines match?
> +if len(added_lines) != len(removed_lines):
> +return False
> +# Counter stores line and number of its occurrences.
> +return sorted(added_lines) == sorted(removed_lines)

I guess it's a fine approach to the problem, but I wonder if it would
not be better to use a slightly less accurate strategy that would be
nicer to memory and CPU.

What I have in mind is to incrementally compute a hash value that would
give the same result even if the lines are in different order.

Drawing from discussions on StackOverflow [1], I think doing a sum of
Python's hash() would work. My test was:

def unordered_hash(lines):
h = 0
for line in lines:
h += hash(line)
return h

h1 = unordered_hash(open('tests/data/text_order1').readlines())
h2 = unordered_hash(open('tests/data/text_order2').readlines())
print(h1, h2, h1 == h2)

That way, it could probably be implemented directly in the difference
module and work for other file types than just text files.

 [1]: 
https://stackoverflow.com/questions/30734848/order-independant-hash-algorithm

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


signature.asc
Description: Digital signature

Bug#848365: jessie-pu: package coquelicot/0.9.2-4+deb8u1

[Jérémy Bobbio]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi!

I would like to important issues affecting coquelicot in jessie:

#809351: properly run coquelicot under the 'coquelicot' user and not
as root. It was always intended that way, that's why the cron is running
under the coquelicot user already. The issue has been fixed a while ago
for stretch (in 0.9.4-1, uploaded September 2015). This backports the
changes from the unstable branch which switched to using
init-d-script(5).

#808018: silence deprecation warnings coming from cron. While the
warnings actually come from ruby-fast-gettext, they make the garbage
collection cron send an email on every run.

debdiff is attached.

Better late than never the old issues, and thanks for your review!

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru coquelicot-0.9.2/debian/changelog coquelicot-0.9.2/debian/changelog
--- coquelicot-0.9.2/debian/changelog	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/changelog	2016-12-16 18:08:03.0 +0100
@@ -1,3 +1,14 @@
+coquelicot (0.9.2-4+deb8u1) stable; urgency=medium
+
+  * Backport init.d fixes from stretch to properly run the daemon as
+coquelicot:coquelicot. Thanks Edouard GAULUE for noticing this
+needed to be fixed in jessie. (Closes: #809351)
+  * Suppress deprecation warnings when running the daemon and garbage
+collection in cron. Thanks Matteo Calorio for the report.
+(Closes: #808018)
+
+ -- Jérémy Bobbio <lu...@debian.org>  Fri, 16 Dec 2016 18:08:03 +0100
+
 coquelicot (0.9.2-4) unstable; urgency=medium
 
   * Fix Build-Depends for activesupport. (Closes: #759921)
diff -Nru coquelicot-0.9.2/debian/control coquelicot-0.9.2/debian/control
--- coquelicot-0.9.2/debian/control	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/control	2016-12-16 17:46:12.0 +0100
@@ -54,6 +54,7 @@
  ruby-sinatra-contrib,
  ruby-upr,
  ruby | ruby-interpreter,
+ sysvinit-utils (>= 2.88dsf-50),
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: apache2 | nginx | pound
diff -Nru coquelicot-0.9.2/debian/coquelicot.cron.d coquelicot-0.9.2/debian/coquelicot.cron.d
--- coquelicot-0.9.2/debian/coquelicot.cron.d	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/coquelicot.cron.d	2016-12-16 18:07:45.0 +0100
@@ -1,4 +1,4 @@
 # crontab fragment for coquelicot
 
 # Run the garbage collection procedure every 15 minutes
-11,26,41,56 * * * * coquelicot [ -x /usr/bin/coquelicot ] && [ -f /etc/coquelicot/settings.yml ] && /usr/bin/coquelicot gc
+11,26,41,56 * * * * coquelicot [ -x /usr/bin/coquelicot ] && [ -f /etc/coquelicot/settings.yml ] && RUBYOPT="-W0" /usr/bin/coquelicot gc
diff -Nru coquelicot-0.9.2/debian/coquelicot.init.d coquelicot-0.9.2/debian/coquelicot.init.d
--- coquelicot-0.9.2/debian/coquelicot.init.d	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/coquelicot.init.d	2016-12-16 18:07:45.0 +0100
@@ -1,4 +1,8 @@
 #!/bin/sh
+# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
+if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
+set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
+fi
 ### BEGIN INIT INFO
 # Provides:  coquelicot
 # Required-Start:$remote_fs
@@ -10,91 +14,38 @@
 #with a focus on protecting users' privacy.
 ### END INIT INFO
 
-# Do NOT "set -e"
+# Author: Jérémy Bobbio <lu...@debian.org>
 
-PATH=/sbin:/usr/sbin:/bin:/usr/bin
 DESC='Coquelicot "one-click" file sharing web application'
-NAME=coquelicot
 DAEMON=/usr/bin/coquelicot
 DAEMON_ARGS="start"
-PIDFILE=/var/run/$NAME.pid
-SCRIPTNAME=/etc/init.d/$NAME
+PIDFILE=/var/run/coquelicot/coquelicot.pid
 
-. /lib/lsb/init-functions
+# can be overriden in /etc/default/coquelicot
+USER=coquelicot
+GROUP=coquelicot
 
-do_start()
-{
-	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
-		|| return 1
-	LC_ALL=C.UTF-8 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
-		$DAEMON_ARGS \
-		|| return 2
+
+do_start_prepare() {
+	START_ARGS="--chuid $USER:$GROUP"
+	/usr/bin/install -m 02750 -o "$USER" -g "$USER" -d "$(dirname "$PIDFILE")"
+
+	# suppress deprecation warnings
+	export RUBYOPT="-W0"
 }
 
-do_stop()
-{
-	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
+# We can't use init-d-script(5) do_stop_cmd() because it matches on the
+# executable path and Coquelicot is written in Ruby. So this is almost
+# the same function but without `--exec` when calling 

Bug#838229: libmygpo-qt-dev: missing cmake targets file, which makes whole cmake stuff useless

[Jérémy Bobbio]

Hi Pino!

Pino Toscano:
> > libmygpo-qt-dev ships configuration files for cmake, so that doing
> > 
> >   find_package(Mygpo-qt)
> >   ..
> >   include_directories(${LIBMYGPO_QT_INCLUDE_DIRS})
> >   ..
> >   target_link_libraries(myapp ${LIBMYGPO_QT_LIBRARIES})
> > 
> > works -- or at least, it should wihout fail when linking.
> > The problem is that the Mygpo-qtTargets-${BUILD_TYPE}.cmake config file
> > for cmake, correctly installed by the upstream build system, is not
> > shipped in libmygpo-qt-dev, and thus the "mygpo-qt" imported library
> > target cannot be loaded.
> > 
> > Attached there is a simple patch for libmygpo-qt-dev.install, to
> > install the missing file, no matter what is the build type set in cmake.
> > I'd like to enable the gpodder.net integration in amarok (#655362),
> > but this bug causes build issues.
> […]
> Still an issue with 1.0.9-1 -- please fix this.

Thanks for the reminder! Please accept my apologies for having
overlooked your patches for weeks. I'll try to fix this as soon as
possible.

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


signature.asc
Description: Digital signature

Bug#838260: diffoscope: Reduce noise from offsets deltas in readelf(1) diffs

[Jérémy Bobbio]

Daniel Shahaf:
> Jérémy Bobbio wrote on Tue, Sep 20, 2016 at 13:18:49 +:
>> But why stop with images? In the precise case of the readelf output,
>> having line-oriented diff means we are carrying around a useless and
>> confusing information: the line numbers are not helpful in anyway to
>> locate and undrstand the differences.
>>
>> But what if we could replace the line numbers by the instruction
>> addresses? Then the noise mentioned by Daniel disappears. Meanwhile, the
>> actual output will become even more relevant.
> 
> In the example in the OP, the (source code) line numbers and instruction
> addresses are the same between both builds.  It is the .rodata addresses
> embeddded into the instructions that differ.

Thanks for pointing this out, I had actually misunderstood the problem
at hand. :)

-- 
Lunar.''`.
lunar at debian.org : :Ⓐ :  # apt-get install anarchism
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#838260: diffoscope: Reduce noise from offsets deltas in readelf(1) diffs

[Jérémy Bobbio]

Chris Lamb:
>> Could these offset differences in readelf(1) output be ignored, at least
>> optionally?
> 
> Love the idea! However, my gut cautions against ignoring them. even with an
> option. 
> 
> Perhaps there is a perfect solution whereby we would normalise these two
> offsets to — making it up here! — relative values, but simply need to 
> nclude that we have done that once in the diff. That way, we have a) still
> captured the underlying issue, b) reduced the noise, and c) avoided a
> cumbersome option flag.

One idea that crossed my mind at some point that might be able to solve
this as well: be able to record other kinds of differences than just
line-oriented ones. Initially, I thought of this as a way to add image
comparison as I felt sad not knowing any free software that could easily
provide similar features to what GitHub offers [1].

But why stop with images? In the precise case of the readelf output,
having line-oriented diff means we are carrying around a useless and
confusing information: the line numbers are not helpful in anyway to
locate and undrstand the differences.

But what if we could replace the line numbers by the instruction
addresses? Then the noise mentioned by Daniel disappears. Meanwhile, the
actual output will become even more relevant.

Such an approach would require some structural changes to the code, but
could have benefits on many fronts.

 [1]: https://help.github.com/articles/rendering-and-diffing-images/

Hope that's any useful,
-- 
Lunar.''`.
lunar at debian.org : :Ⓐ :  # apt-get install anarchism
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#829113: [Reproducible-builds] Bug#829113: reprotest: Should unset $DISPLAY to avoid GUI popups from some build tools

[Jérémy Bobbio]

Hi Axel!

Axel Beckert:
> Running
> 
> $ reprotest 'dpkg-buildpackage -b' 
> ../debian-paketmanagement-buch_0\~2016.06.29_all.deb
> 
> from a git checkout of commit 5f069a920df4e6f20a8eb9309c20c39ad60e6132
> under X to see if my $SOURCE_DATE_EPOCH implementation in that commit is
> working correctly.
> 
>* What was the outcome of this action?
> 
> Two GUI popups from ebook-convert (from the package calibre) moaning
> about non-existent $HOME and hence unreadable $HOME/.config/…
> 
>* What outcome did you expect instead?
> 
> No interactivity, especially no GUI interactivity at all.
> 
> Unsetting $DISPLAY should this issue.
> 
> (I'm not sure if setting and not setting $DISPLAY is or should be one of
> the not explicitly listed variations. But since I got that popup twice,
> I assume not.)

I don't think this is a bug in reprotest. As far as I can see by looking
in dpkg source tree, `dpkg-buildpackage` doesn't do anything to the
DISPLAY variable etiher. So I would assume building the package might
fail just as well without reprotest. If building the package requires to
unset DISPLAY, I think this should be done in `debian/rules`…

One take though, maybe reprotest should ensure that $HOME is set to an
existing (temporary) directory; other building tools might get unhappy.

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


signature.asc
Description: Digital signature

Bug#824179: haveged should start after AppArmor

[Jérémy Bobbio]

Control: tags -1 pending

Nicolas Braud-Santoni:
> Since the collab-maint process is a tad slower than expected,
>   I'm sending you the patch here instead.

Thanks, applied. :)

(Although without the changes to debian/changelog: I prefer writing the
new entry at once by looking at the commits since the latest upload.)

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


signature.asc
Description: Digital signature

Bug#821455: subliminal: Please ship Nautilus extension

[Jérémy Bobbio]

Package: subliminal
Version: 1.1.1-1
Severity: wishlist

Hi!

Subliminal documentation mentions a Nautilus extension:
https://github.com/Diaoul/subliminal#nautilus-integration

It would be really nice if it could be added to the subliminal
package—or an extra one.

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


signature.asc
Description: Digital signature

Bug#783239: closed by Khalid Aziz <kha...@debian.org> (Bug#783239: fixed in kexec-tools 1:2.0.10-2)

[Jérémy Bobbio]

Control: reopen -1

Hi!

The patch did not account for locale variation so kexec-tools is still
unreproducible. An updated patch is attached.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff --git a/debian/patches/allow-external-build-date.patch b/debian/patches/allow-external-build-date.patch
index 9d196f5..3baf983 100644
--- a/debian/patches/allow-external-build-date.patch
+++ b/debian/patches/allow-external-build-date.patch
@@ -11,7 +11,7 @@ Author: Jérémy Bobbio <lu...@debian.org>
  
 -AC_DEFINE_UNQUOTED(PACKAGE_DATE, "`date '+%d %B %Y'`",
 +if test "x$BUILD_DATE" = x; then
-+	BUILD_DATE=`date '+%d %B %Y'`
++	BUILD_DATE=`LC_ALL=C date '+%d %B %Y'`
 +fi
 +AC_DEFINE_UNQUOTED(PACKAGE_DATE, "$BUILD_DATE",
  		[Define to the release date of this package])
diff --git a/debian/rules b/debian/rules
index 1f31435..acf2c0a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@
 #export DH_VERBOSE=1
 
 
-BUILD_DATE = $(shell dpkg-parsechangelog -S Date | date -u +'%d %B %Y' -f -)
+BUILD_DATE = $(shell dpkg-parsechangelog -S Date | LC_ALL=C date -u +'%d %B %Y' -f -)
 export BUILD_DATE
 
 ifneq (,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS


signature.asc
Description: Digital signature

Bug#815248: liblcms2: Writes uninitialized strings when writing named colors

[Jérémy Bobbio]

Thomas Weber:
> > When writing named colors, liblcms2 currently writes uninitialized memory
> > when the prefix, suffix, or root color name strings are not
> > 32-characters long (including the NULL terminator). This prevents colord
> > from building reproducibly.
> > 
> > The attached patch will zero the memory before copying the profile
> > strings to ensure a consistent output.
> 
> I am a bit unsure about the fact that you reduced the size of root[33]
> to root[32]. Even if this works out okay in the current code base, such
> a change should be made globally (i.e., _cms_NAMEDCOLORLIST_struct
> should be changed).
> 
> What is your opinion on that?

The spec says the field to be 32 bytes long. Every other instance
of the code uses a 32 bytes long array. And IIRC, only 32 bytes could
ever be copied from the array, so assumed it was a typo while looking at
the code. It should probably be a separate patch…

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


signature.asc
Description: Digital signature

Bug#812459: python3-stem: fails to upgrade from 'testing' - trying to overwrite /usr/bin/tor-prompt

[Jérémy Bobbio]

Hi Donncha,

Donncha O'Cearbhaill:
> This package is marked for autoremoval on the 8th March and the bug has
> not received a response from the package maintainer.
> 
> I've attached an NMU patch which I think will resolve this issue.

Thanks for the patch! 

> diff -Nru python-stem-1.4.1b/debian/changelog 
> python-stem-1.4.1b/debian/changelog
> --- python-stem-1.4.1b/debian/changelog   2016-01-18 14:58:04.0 
> +0100
> +++ python-stem-1.4.1b/debian/changelog   2016-03-06 00:16:13.0 
> +0100
> @@ -1,3 +1,12 @@
> +python-stem (1.4.1b-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * debian/rules: Use update-alternatives to select between
> +/usr/bin/tor-prompt for the Python 2 and Python 3 packages
> +(Closes: #812459).

I don't think alternatives are the solution to this. tor-prompt as provided
by python-stem or by python3-stem should be strictly equilavent in terms
of features. I can't imagine why would someone prefer to use the
Python 2 version when someone else would prefer the Python 3 one.

I think either tor-prompt should be moved to its own package, or only
kept in python3-stem (because Python 2 will have to go away one day). We
can make python-stem Depends on python3-stem to make sure that
tor-prompty will continue to be there on upgrade.

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


signature.asc
Description: Digital signature

Bug#815844: [Reproducible-builds] Bug#815844: diffoscope won't build without python-magic from PyPi

[Jérémy Bobbio]

Leo Famulari:
> However, diffoscope's README [2] says that:
> 
> ``Magic-file-extension`` can be used instead of
> ``python-magic``. It is built from `file
> `_.
> Available on Debian and Fedora as ``python3-magic``.
> 
> I removed the requirement of python-magic from setup.py and built
> against the Python bindings distributed with `file`, as packaged in Guix
> [3]. Diffoscope seems to work just fine this way.

Indeed. That's how it works in Debian.

> Will you consider making python-magic an optional dependency of
> diffoscope, so that downstream packagers don't have to package
> python-magic from PyPi or work around this issue by patching setup.py?

I have no idea how you can specify alternate dependencies in setup.py or
if that's possible. If you find a solution I guess someone could apply a
patch.

If that's not possible, I believe that carrying a one-liner in Guix is
not unreasonable.

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


signature.asc
Description: Digital signature

Bug#815171: [Reproducible-builds] Bug#815171: Bug#815171: Bug#815171: Bug#815171: diffoscope: build time tests fail on armhf

[Jérémy Bobbio]

Holger Levsen:
> But given the above (100% build failure on armhf and 33% 
> failure on am64) I now think this is indeed a serious 
> issue, thus it should be treated as such. 

I've removed myself from Uploaders. As you are listed there, feel free
to fix the bug as you see fit.

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


signature.asc
Description: Digital signature

Bug#778862: closed by Robert Luberda <rob...@debian.org> (Bug#778862: fixed in ispell 3.4.00-1)

[Jérémy Bobbio]

Control: reopen -1

Hi!

Debian Bug Tracking System:
> This is an automatic notification regarding your Bug report
> which was filed against the src:ispell package:
> 
> #778862: ispell: please make building .hash files reproducible

Sorry but the issue still exists. For example, iitalian still has the
following difference:

│   ├── data.tar.xz
│   │   ├── data.tar
│   │   │   ├── ./usr/lib/ispell/italian.hash
│   │   │   │ @@ -80871,15 +80871,15 @@
│   │   │   │  0013be60: 6cc8 0500   c000   0004  
l...
│   │   │   │  0013be70: ec90    73c8 0500    
s...
│   │   │   │  0013be80:    0004      

│   │   │   │  0013be90: 7ec8 0500   0100   0004  
~...
│   │   │   │  0013bea0:          

│   │   │   │  0013beb0:          

│   │   │   │  0013bec0:          

│   │   │   │ -0013bed0:     30c6 d900    
0...
│   │   │   │ +0013bed0:     30e6 3c02    
0.<.
│   │   │   │  0013bee0: 0600 0100  0200 0100     


https://tests.reproducible-builds.org/dbdtxt/unstable/amd64/iitalian_2.3-3.diffoscope.txt

I've verified that the uninitialized bytes above are written when writing
`sflaglist`: 
https://sources.debian.net/src/ispell/3.4.00-4/buildhash.c/?hl=402:403#L402

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


signature.asc
Description: Digital signature

Bug#815171: [Reproducible-builds] Bug#815171: Bug#815171: diffoscope: build time tests fail on armhf

[Jérémy Bobbio]

Holger Levsen:
> I dont see why this should be a normal bug, ftbfs are 
> serious by default. 

Because it's just a test that is brittle. It doesn't affect normal use
of the installed package and does only prevent a successful build one
times out of ten.

To please the cruel god of FTBFS I can also disable running the test
suite entirely at build time. I believe this would be the wrong thing to
do, but if you insist, I'll just do that.

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


signature.asc
Description: Digital signature

Bug#797778: Please package pyroute2 >= 0.3.10

[Jérémy Bobbio]

Hi Florian,

I also would like to see an updated version of pyroute2 in Debian as I'd
like to use it to fiddle with ipsets.

Florian Pelgrim:
> I will update the package soon.
> Guess this will be done next week.

Do you need any help to do the update?

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


signature.asc
Description: Digital signature

Bug#815252: colord: please make the build reproducible (timestamps)

[Jérémy Bobbio]

Christopher James Halse Rogers:
> Thanks for the patches! I'll add the necessary autofoo checks and propose
> them upstream.

Great! :)

Do you have any contacts with lcms2 upstream? Because I guess they would
need to accept the required patch as well before it makes sense to write
such a test. It's a pretty straight forward patch, so I really hope it
will be an easy one to get in.

> Would it make more sense for cd-it8 to also respect SOURCE_DATE_EPOCH? Is
> there a reason other than ‘it was simpler to just disable timestamps’
> (before I try duplicating the cd-create-profile logic into that patch).

cd-it8 is the first thing that I've patched to try to get colord
reproducible, so I went for the easiest path. I discovered later that
the creation date/time was mandatory for ICC profiles, so I implement
full SOURCE_DATE_EPOCH logic there. You feel it's more coherent to do
the same in cd-it8, please port it there! :)

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


signature.asc
Description: Digital signature

Bug#806493: closed by Yaroslav Halchenko <deb...@onerussian.com> (Bug#806493: fixed in cython 0.23.4+git4-g7eed8d8-1)

[Jérémy Bobbio]

Debian Bug Tracking System:
> This is an automatic notification regarding your Bug report
> which was filed against the src:cython package:
> 
> #806493: cython: please make the output reproducible
> 
> It has been closed by Yaroslav Halchenko .

Sadly, this doesn't seem to fix all issues:
https://tests.reproducible-builds.org/dbd/unstable/amd64/astroscrappy_1.0.3-6.diffoscope.html

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


signature.asc
Description: Digital signature

Bug#815171: diffoscope: build time tests fail on armhf

[Jérémy Bobbio]

Control: retitle -1 diffoscope: tests for directory are brittle
Control: severity -1 normal

Holger Levsen:
> diffoscope fails to build from source in unstable/armhf but has 
> successfully built in the past: […]
> […]
> tests/comparators/test_directory.py:53: AssertionError
> […]
> tests/comparators/test_directory.py:59: IndexError

Feel free to just retry. The test suite for the directory comparator is
brittle and tend to break once in a while for timing reasons.

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


signature.asc
Description: Digital signature

Bug#813023: flash-kernel: quoting error with bootargs in generic U-Boot boot script

[Jérémy Bobbio]

Ian Campbell:
> So I'm afraid I'm still not clear exactly what issue you are seeing.
> 
> Please can you post:
> 
>  * the contents of your /boot/cmdline.txt
>  * the contents of the flash kernel db entry you have added for the
>RPi2
>  * the resulting generated boot.scr.
>  * a full serial console log booting with that boot.scr

Sorry Ian, but I don't remember the exact details. That box is now in
production and I'd rather not take the risk to break it before next
month.

Feel free to just ditch that bug report. It's moot for the RPi2 until we
have a compatible kernel in Debian anyway.

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


signature.asc
Description: Digital signature

Bug#813023: flash-kernel: quoting error with bootargs in generic U-Boot boot script

[Jérémy Bobbio]

Ian Campbell:
> On Sat, 2016-02-20 at 14:41 +0100, Jérémy Bobbio wrote:
> > Ian Campbell:
> > > On Sat, 2016-02-20 at 13:29 +0100, Jérémy Bobbio wrote:
> > > > Ian Campbell:
> > > > > Lunar -- which platform did you see an issue on and what do the
> > > > > above
> > > > > test commands give in that case?
> > > > 
> > > > The version in Debian: https://packages.debian.org/sid/u-boot-rpi
> > > 
> > > and how does it behave in the tests compared to the other two
> > > platforms
> > > I mentioned?
> > 
> > Like the most recent version.
> 
> Did you ever see an actual problem related to the lack of quoting this
> bug is about or did you just spot what looked like an error by
> inspection?

I stumbled on it because I had put in /etc/default/flash-kernel:

LINUX_KERNEL_CMDLINE="$(cat /boot/cmdline.txt)"

(which expands to multiple words) while trying to get U-Boot working on
the RPi2 as close as possible to Debian generic behavior.

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


signature.asc
Description: Digital signature

Bug#813023: flash-kernel: quoting error with bootargs in generic U-Boot boot script

[Jérémy Bobbio]

Ian Campbell:
> On Sat, 2016-02-20 at 13:29 +0100, Jérémy Bobbio wrote:
> > Ian Campbell:
> > > Lunar -- which platform did you see an issue on and what do the
> > > above
> > > test commands give in that case?
> > 
> > The version in Debian: https://packages.debian.org/sid/u-boot-rpi
> 
> and how does it behave in the tests compared to the other two platforms
> I mentioned?

Like the most recent version.

I assume the behavior has changed with
http://git.denx.de/?p=u-boot.git;a=commit;h=ea882baf9c17cd142c99e3ff640d3ab01daa5cec
but that's a wild guess.

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


signature.asc
Description: Digital signature

Bug#815252: colord: please make the build reproducible (timestamps)

[Jérémy Bobbio]

Source: colord
Version: 1.2.12-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
Control: block -1 by 814883

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that colord could not be built reproducibly.

The attached patches remove extra timestamps when generating CMF and
spectra and implement support for SOURCE_DATE_EPOCH. Together with a
patched lcms2, they make colord reproducible in our current experimental
framework.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From 97d54abbf3240a14b271ac7f8f79331adbf1a219 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Sat, 20 Feb 2016 12:48:47 +0100
Subject: [PATCH 1/2] Stop writing a CREATED header in CMF and spectra

For the same input `cd-it8 create-cmf` and `cd-it8 create-sp`
will create the exact same output except for the creation time.
As the header is optional and prevents CMF and spectra to be built
reproducibly, we use cd_it8_set_enable_created() to remove it
from the output.
---
 client/cd-it8.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/client/cd-it8.c b/client/cd-it8.c
index 987776a..26bc26d 100644
--- a/client/cd-it8.c
+++ b/client/cd-it8.c
@@ -303,6 +303,7 @@ cd_util_create_cmf (CdUtilPrivate *priv,
 	if (dot != NULL)
 		*dot = '\0';
 	cd_it8_set_title (cmf, title);
+	cd_it8_set_enable_created (cmf, FALSE);
 
 	/* save */
 	file = g_file_new_for_path (values[0]);
@@ -464,6 +465,7 @@ cd_util_create_sp (CdUtilPrivate *priv,
 	if (dot != NULL)
 		*dot = '\0';
 	cd_it8_set_title (cmf, title);
+	cd_it8_set_enable_created (cmf, FALSE);
 
 	/* save */
 	file = g_file_new_for_path (values[0]);
-- 
2.7.0

From fc72fa8fe89e1eae4cbda2f4eed806756e1fb88a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Sat, 20 Feb 2016 12:55:57 +0100
Subject: [PATCH 2/2] cd-create-profile: Add support for SOURCE_DATE_EPOCH

When creating profiles, the current time used to be written in
the generated header as the creation date/time. This prevents
cd-create-profile from generating the same bytes, despite
getting the same input. Also, as cd-create-profile transforms
an XML description into a binary ICC profile, the current time
does not reflect will when the profile was actually created.

So we now use the modification time of the source file as the
creation date/time. However, if the SOURCE_DATE_EPOCH environment
variable is specified, its value will be used instead to ease
reproducible builds.

For more details about SOURCE_DATE_EPOCH, see
https://reproducible-builds.org/specs/source-date-epoch/

This uses cmsSetHeaderCreationDateTime() and thus requires a
version of lcms2 with this feature.
---
 client/cd-create-profile.c | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/client/cd-create-profile.c b/client/cd-create-profile.c
index d9159a3..f0edee9 100644
--- a/client/cd-create-profile.c
+++ b/client/cd-create-profile.c
@@ -22,10 +22,14 @@
 #include "config.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
@@ -686,6 +690,55 @@ cd_util_icc_set_metadata_coverage (CdIcc *icc, GError **error)
 }
 
 /**
+ * cd_util_adjust_creation_time:
+ **/
+static gboolean
+cd_util_adjust_creation_time (CdUtilPrivate *priv, const char *source_filename,  GError **error)
+{
+	GStatBuf st;
+	struct tm *creation_time;
+	time_t build_date = 0;
+	char *source_date_epoch_string;
+	unsigned long long source_date_epoch;
+	char *endptr;
+
+	/* adjust creation time to match the XML one or SOURCE_DATE_EPOCH if specified and older */
+	source_date_epoch_string = getenv ("SOURCE_DATE_EPOCH");
+	if (source_date_epoch_string) {
+		errno = 0;
+		source_date_epoch = strtoull (source_date_epoch_string, , 10);
+		if ((source_date_epoch == ERANGE && (source_date_epoch == ULLONG_MAX || source_date_epoch == 0))
+		|| (errno != 0 && source_date_epoch == 0)) {
+		g_set_error (error, 1, 0, "Environment variable $SOURCE_DATE_EPOCH: strtoull: %s\n", g_strerror (errno));
+			return FALSE;
+		}
+		if (endptr == source_date_epoch_string) {
+			g_set_error (error, 1, 0, "Environment variable $SOURCE_DATE_EPOCH: No digits were found: %s\n", endptr);
+			return FALSE;
+		}
+		if (*endptr != '\0') {
+			g_set_error (error, 1, 0, "Environment variable $SOURCE_DATE_EPOCH: Trailing garbage: %s\n", endptr);
+			return FALSE;
+		}
+		if (source_date_epoch > ULONG_MAX) {
+			g_set_error (error, 1, 0, "Environment variable $SOURCE_DATE_EPOCH: value must be smaller than or equal to: %lu but was found to be: %llu \n", ULONG_MAX, source_date_epoch);
+			return FALSE;
+		}
+		build_date = source_date_epoch;
+	}
+
+	if (g_stat 

Bug#815248: liblcms2: Writes uninitialized strings when writing named colors

[Jérémy Bobbio]

Package: liblcms2
Version: 2.6-3
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness

Hi!

When writing named colors, liblcms2 currently writes uninitialized memory
when the prefix, suffix, or root color name strings are not
32-characters long (including the NULL terminator). This prevents colord
from building reproducibly.

The attached patch will zero the memory before copying the profile
strings to ensure a consistent output.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru lcms2-2.6/debian/patches/dont-write-uninitialized-memory-for-color-strings.patch lcms2-2.6/debian/patches/dont-write-uninitialized-memory-for-color-strings.patch
--- lcms2-2.6/debian/patches/dont-write-uninitialized-memory-for-color-strings.patch	1970-01-01 01:00:00.0 +0100
+++ lcms2-2.6/debian/patches/dont-write-uninitialized-memory-for-color-strings.patch	2016-02-20 12:43:36.0 +0100
@@ -0,0 +1,59 @@
+Description: Zero named color strings before writing them
+ For each named colors (namedColor2Type) a prefix, a suffix and the
+ color root name get written. These three strings are 32-characters long.
+ In order to avoid capturing unitialized memory—which is not good for
+ privacy and prevent getting the same bytes for the same profile—the
+ placeholder allocated on the stack are zero'ed before a copy of the
+ actual string is made.
+ .
+ For consistency, we also remove unneeded extra allocated bytes in
+ Type_ColorantTable_Write() and Type_NamedColor_Write().
+Author: Jérémy Bobbio <lu...@debian.org>
+
+diff --git a/src/cmstypes.c b/src/cmstypes.c
+index 60c09ef..0afec90 100644
+--- a/src/cmstypes.c
 b/src/cmstypes.c
+@@ -3013,9 +3013,10 @@ cmsBool  Type_ColorantTable_Write(struct _cms_typehandler_struct* self, cmsIOHAN
+ 
+ for (i=0; i < nColors; i++) {
+ 
+-char root[33];
++char root[32];
+ cmsUInt16Number PCS[3];
+ 
++memset(root, 0, 32); /* Ensure we don't write uninitialized memory. */
+ if (!cmsNamedColorInfo(NamedColorList, i, root, NULL, NULL, PCS, NULL)) return 0;
+ root[32] = 0;
+ 
+@@ -3138,11 +3139,13 @@ cmsBool Type_NamedColor_Write(struct _cms_typehandler_struct* self, cmsIOHANDLER
+ if (!_cmsWriteUInt32Number(io, 0)) return FALSE;
+ if (!_cmsWriteUInt32Number(io, nColors)) return FALSE;
+ if (!_cmsWriteUInt32Number(io, NamedColorList ->ColorantCount)) return FALSE;
++/* Ensure we don't write unitialized memory. */
++memset(prefix, 0, 32);
++memset(suffix, 0, 32);
+ 
+-strncpy(prefix, (const char*) NamedColorList->Prefix, 32);
+-strncpy(suffix, (const char*) NamedColorList->Suffix, 32);
+-
+-suffix[31] = prefix[31] = 0;
++/* Only copy 31 characters to ensure strings will be NULL-terminated */
++strncpy(prefix, (const char*) NamedColorList->Prefix, 31);
++strncpy(suffix, (const char*) NamedColorList->Suffix, 31);
+ 
+ if (!io ->Write(io, 32, prefix)) return FALSE;
+ if (!io ->Write(io, 32, suffix)) return FALSE;
+@@ -3151,9 +3154,11 @@ cmsBool Type_NamedColor_Write(struct _cms_typehandler_struct* self, cmsIOHANDLER
+ 
+cmsUInt16Number PCS[3];
+cmsUInt16Number Colorant[cmsMAXCHANNELS];
+-   char Root[33];
++   char Root[32];
+ 
++	/* Ensure we don't write unitialized memory. */
++	memset(Root, 0, 32);
+ if (!cmsNamedColorInfo(NamedColorList, i, Root, NULL, NULL, PCS, Colorant)) return 0;
+ if (!io ->Write(io, 32 , Root)) return FALSE;
+ if (!_cmsWriteUInt16Array(io, 3, PCS)) return FALSE;
+ if (!_cmsWriteUInt16Array(io, NamedColorList ->ColorantCount, Colorant)) return FALSE;
diff -Nru lcms2-2.6/debian/patches/series lcms2-2.6/debian/patches/series
--- lcms2-2.6/debian/patches/series	2014-06-16 17:15:31.0 +0200
+++ lcms2-2.6/debian/patches/series	2016-02-20 12:42:05.0 +0100
@@ -4,3 +4,4 @@
 sanity-check-profiles-CVE-2014-0459.patch
 fix-unaligned-access.patch
 endianness-verification-fix-powerpc.patch
+dont-write-uninitialized-memory-for-color-strings.patch


signature.asc
Description: Digital signature

Bug#813023: flash-kernel: quoting error with bootargs in generic U-Boot boot script

[Jérémy Bobbio]

Ian Campbell:
> Lunar -- which platform did you see an issue on and what do the above
> test commands give in that case?

The version in Debian: https://packages.debian.org/sid/u-boot-rpi

> I'm going to push a change relating to the other suggestion here (the
> ability to set a defaults before ${bootargs}, but so far don't plan to
> make any change wrt the quoting behaviour.

Works for me.

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


signature.asc
Description: Digital signature

Bug#813052: [Reproducible-builds] Bug#813052: Bug#813052: diffoscope takes more than an hour on foreign arch libc6

[Jérémy Bobbio]

Steven Chamberlain:
> > Anyway, I've just pushed another patch to filter by filenames before
> > looking at content. This should further improve the situation.
> 
> I don't think it worked?  It's still doing as before, looking at
> text, gzip files and validating the sha1sums in a .buildinfo:
> 
> | DEBUG Looking for a dbgsym package for Build Id 
> 4bfc8175c9c53156a7e20d0216bc9fff0d25ae2a (debuglink: 
> fc8175c9c53156a7e20d0216bc9fff0d25ae2a.debug)
> | DEBUG Using TextFile for a/build/.bash_logout
> | DEBUG Using TextFile for a/build/.bashrc
> | DEBUG Using TextFile for a/build/.profile
> […]

True. It missed another bit. Thanks for double-checking, I hadn't tested
the other change properly.

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


signature.asc
Description: Digital signature

Bug#813052: [Reproducible-builds] Bug#813052: Bug#813052: Bug#813052: Bug#813052: diffoscope takes more than an hour on foreign arch libc6

[Jérémy Bobbio]

Steven Chamberlain:
> With your patch, it doesn't recurse any more.

Thanks for the feedback! :)

> But it will still stat() everything in the containing directory,
> looking for .debs.  It also opens some files and reads them - even
> decompressing random .gz files along the way!

Are you sure that it is actually decompressing files and not just
identifying them?

Anyway, I've just pushed another patch to filter by filenames before
looking at content. This should further improve the situation.

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


signature.asc
Description: Digital signature

Bug#814883: lcms2: please add a way for clients to set the creation date/time in profile headers

[Jérémy Bobbio]

Package: liblcms2-dev
Version: 2.6-3
Severity: wishlist
Tag: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain

Hi!

liblcms will currently always use the current time to set the creation
time in profile headers. In the context of the “Reproducible Builds”
effort [1], this will prevent colord from building its profiles
bit-for-bit identical, despite having the exact same source.

The attached patch adds cmsSetHeaderCreationDateTime() to allow clients
to set an explicit creation date/time for a profile.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru lcms2-2.6/debian/patches/add_set_header_creation_date_time.patch lcms2-2.6/debian/patches/add_set_header_creation_date_time.patch
--- lcms2-2.6/debian/patches/add_set_header_creation_date_time.patch	1970-01-01 01:00:00.0 +0100
+++ lcms2-2.6/debian/patches/add_set_header_creation_date_time.patch	2016-02-16 09:35:33.0 +0100
@@ -0,0 +1,51 @@
+Description: add cmsSetHeaderCreationDateTime
+ Clients might want to set an explicit value for the creation date/time
+ of a profile, e.g. to match the creation date/time of a description
+ file.
+Author: Jérémy Bobbio <lu...@debian.org>
+
+--- lcms2-2.6.orig/include/lcms2.h
 lcms2-2.6/include/lcms2.h
+@@ -1446,6 +1446,7 @@ CMSAPI cmsUInt32Number   CMSEXPORT cmsGe
+ CMSAPI void  CMSEXPORT cmsSetHeaderModel(cmsHPROFILE hProfile, cmsUInt32Number model);
+ CMSAPI void  CMSEXPORT cmsSetHeaderAttributes(cmsHPROFILE hProfile, cmsUInt64Number Flags);
+ CMSAPI void  CMSEXPORT cmsSetHeaderProfileID(cmsHPROFILE hProfile, cmsUInt8Number* ProfileID);
++CMSAPI void  CMSEXPORT cmsSetHeaderCreationDateTime(cmsHPROFILE hProfile, const struct tm *DateTime);
+ CMSAPI void  CMSEXPORT cmsSetHeaderRenderingIntent(cmsHPROFILE hProfile, cmsUInt32Number RenderingIntent);
+ 
+ CMSAPI cmsColorSpaceSignature
+--- lcms2-2.6.orig/src/cmsio0.c
 lcms2-2.6/src/cmsio0.c
+@@ -908,6 +908,12 @@ cmsBool  CMSEXPORT cmsGetHeaderCreationD
+ return TRUE;
+ }
+ 
++void CMSEXPORT cmsSetHeaderCreationDateTime(cmsHPROFILE hProfile, const struct tm *DateTime)
++{
++_cmsICCPROFILE*  Icc = (_cmsICCPROFILE*) hProfile;
++memmove( ->Created, DateTime, sizeof(struct tm));
++}
++
+ cmsColorSpaceSignature CMSEXPORT cmsGetPCS(cmsHPROFILE hProfile)
+ {
+ _cmsICCPROFILE*  Icc = (_cmsICCPROFILE*) hProfile;
+--- lcms2-2.6.orig/src/lcms2.def
 lcms2-2.6/src/lcms2.def
+@@ -272,6 +272,7 @@ cmsSetHeaderFlags
+ cmsSetHeaderManufacturer =cmsSetHeaderManufacturer
+ cmsSetHeaderModel=cmsSetHeaderModel
+ cmsSetHeaderProfileID=cmsSetHeaderProfileID
++cmsSetHeaderCreationDateTime =cmsSetHeaderCreationDateTime
+ cmsSetHeaderRenderingIntent  =cmsSetHeaderRenderingIntent
+ cmsSetLogErrorHandler=cmsSetLogErrorHandler
+ cmsSetPCS=cmsSetPCS
+--- lcms2-2.6.orig/utils/delphi/lcms2dll.pas
 lcms2-2.6/utils/delphi/lcms2dll.pas
+@@ -1251,6 +1251,7 @@ PROCEDURE cmsGetHeaderProfileID(hProfile
+ 
+ // TODO:
+ // FUNCTION  cmsGetHeaderCreationDateTime(hProfile: cmsHPROFILE; struct tm *Dest): cmsBool; StdCall;
++// PROCEDURE cmsSetHeaderCreationDate(hProfile: cmsHPROFILE; const struct tm *DateTime); StdCall;
+ 
+ FUNCTION  cmsGetHeaderRenderingIntent(hProfile: cmsHPROFILE): cmsUInt32Number; StdCall;
+ PROCEDURE cmsSetHeaderFlags(hProfile: cmsHPROFILE; Flags: cmsUInt32Number); StdCall;
diff -Nru lcms2-2.6/debian/patches/series lcms2-2.6/debian/patches/series
--- lcms2-2.6/debian/patches/series	2014-06-16 17:15:31.0 +0200
+++ lcms2-2.6/debian/patches/series	2016-02-16 09:30:45.0 +0100
@@ -4,3 +4,4 @@
 sanity-check-profiles-CVE-2014-0459.patch
 fix-unaligned-access.patch
 endianness-verification-fix-powerpc.patch
+add_set_header_creation_date_time.patch
diff -Nru lcms2-2.6/debian/liblcms2-2.symbols lcms2-2.6/debian/liblcms2-2.symbols
--- lcms2-2.6/debian/liblcms2-2.symbols	2014-06-16 17:15:31.0 +0200
+++ lcms2-2.6/debian/liblcms2-2.symbols	2016-02-16 09:23:06.0 +0100
@@ -389,6 +389,7 @@
  cmsSetDeviceClass@Base 2.2+git20110628
  cmsSetEncodedICCversion@Base 2.2+git20110628
  cmsSetHeaderAttributes@Base 2.2+git20110628
+ cmsSetHeaderCreationDateTime@Base 2.6-3.0~reproducible1
  cmsSetHeaderFlags@Base 2.2+git20110628
  cmsSetHeaderManufacturer@Base 2.2+git20110628
  cmsSetHeaderModel@Base 2.2+git20110628


signature.asc
Description: Digital signature

Bug#814832: libpgm: please make the build reproducible (timestamps)

[Jérémy Bobbio]

Source: libpgm
Version: 5.1.118-1~dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that libpgm could not be built reproducibly.

The attached patch adds support for SOURCE_DATE_EPOCH to set the
build timestamp. Once applied, libpgm can be built reproducibly in
our current experimental framework.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru libpgm-5.1.118-1~dfsg/debian/changelog libpgm-5.1.118-1~dfsg/debian/changelog
--- libpgm-5.1.118-1~dfsg/debian/changelog	2015-01-17 20:03:11.0 +0100
+++ libpgm-5.1.118-1~dfsg/debian/changelog	2016-02-15 19:22:58.0 +0100
@@ -1,3 +1,9 @@
diff -Nru libpgm-5.1.118-1~dfsg/debian/patches/series libpgm-5.1.118-1~dfsg/debian/patches/series
--- libpgm-5.1.118-1~dfsg/debian/patches/series	2014-10-20 22:03:15.0 +0200
+++ libpgm-5.1.118-1~dfsg/debian/patches/series	2016-02-15 19:25:11.0 +0100
@@ -1 +1,2 @@
 hurd-ftbfs-fix.patch
+support_source_date_epoch.patch
diff -Nru libpgm-5.1.118-1~dfsg/debian/patches/support_source_date_epoch.patch libpgm-5.1.118-1~dfsg/debian/patches/support_source_date_epoch.patch
--- libpgm-5.1.118-1~dfsg/debian/patches/support_source_date_epoch.patch	1970-01-01 01:00:00.0 +0100
+++ libpgm-5.1.118-1~dfsg/debian/patches/support_source_date_epoch.patch	2016-02-15 19:38:54.0 +0100
@@ -0,0 +1,20 @@
+Description: add support for SOURCE_DATE_EPOCH
+ Allow to override the recorded build time by setting SOURCE_DATE_EPOCH
+ in the environment. More details can be found on:
+ https://reproducible-builds.org/specs/source-date-epoch/
+Author: Jérémy Bobbio <lu...@debian.org>
+
+--- libpgm-5.1.118-1~dfsg.orig/openpgm/pgm/version_generator.py
 libpgm-5.1.118-1~dfsg/openpgm/pgm/version_generator.py
+@@ -4,8 +4,9 @@ import os
+ import platform
+ import time
+ 
+-build_date = time.strftime ("%Y-%m-%d")
+-build_time = time.strftime ("%H:%M:%S")
++timestamp = time.gmtime (int (os.getenv ('SOURCE_DATE_EPOCH', time.time (
++build_date = time.strftime ("%Y-%m-%d", timestamp)
++build_time = time.strftime ("%H:%M:%S", timestamp)
+ build_rev = filter (str.isdigit, "$Revision: 1369 $")
+ 
+ print """


signature.asc
Description: Digital signature

Bug#813052: [Reproducible-builds] Bug#813052: Bug#813052: diffoscope takes more than an hour on foreign arch libc6

[Jérémy Bobbio]

Hi Helmut,

Helmut Grohne:
> On Fri, Jan 29, 2016 at 03:11:55PM +0100, Jérémy Bobbio wrote:
> > Helmut Grohne:
> > > Even though I cannot reproduce the issue at hand, I think that the code
> > > adding automatic debug symbols looks fishy to me. It appears to recurse
> > > over /tmp here and that looks very wrong to me.
> > 
> > I don't understand what you mean by that. Could you provide be (at least
> > some) of the `--debug` output?
> 
> What I mean is that diffoscope takes the directory that contains the
> first debian package and then recursively looks at all contained files.
> If that tree happens to be big, bad things can happen.

diffoscope will try to locate a package with matching debug symbols when
it's comparing ELF files inside two .deb. It will indeed look at the
files in the parent container (in your case a directory), but it's only
a quick look: looking for .deb files and looking at the control file.

Still, it was indeed looking at all files in the tree. Could you try the
attached patch and see if it helps?

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From c909c3d00d8d49065bf100deda16ae1d3d12ba66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= <lu...@debian.org>
Date: Fri, 5 Feb 2016 12:57:55 +0100
Subject: [PATCH] Use recursive containers for directory

This will prevent detecting renames until we implement fuzzy-matching accross
containers (#797759) but improves the behavior when searching for matching
debug packages. Otherwise, we would be looking at all files in the
tree instead of just the one at the same level as the binary package.

Closes: #813052
---
 diffoscope/comparators/directory.py | 16 ++--
 tests/comparators/test_directory.py |  7 ---
 2 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/diffoscope/comparators/directory.py b/diffoscope/comparators/directory.py
index 03713ec..aaf295a 100644
--- a/diffoscope/comparators/directory.py
+++ b/diffoscope/comparators/directory.py
@@ -168,15 +168,11 @@ class FilesystemDirectory(object):
 
 class DirectoryContainer(Container):
 def get_member_names(self):
-path = self.source.path
-names = []
-for root, _, files in os.walk(path):
-if root == path:
-root = ''
-else:
-root = root[len(path) + 1:]
-names.extend([os.path.join(root, f) for f in files])
-return sorted(names)
+return sorted(os.listdir(self.source.path))
 
 def get_member(self, member_name):
-return diffoscope.comparators.specialize(FilesystemFile(os.path.join(self.source.path, member_name), container=self))
+member_path = os.path.join(self.source.path, member_name)
+if not os.path.islink(member_path) and os.path.isdir(member_path):
+return FilesystemDirectory(member_path)
+else:
+return diffoscope.comparators.specialize(FilesystemFile(os.path.join(self.source.path, member_name), container=self))
diff --git a/tests/comparators/test_directory.py b/tests/comparators/test_directory.py
index d1008f7..9416538 100644
--- a/tests/comparators/test_directory.py
+++ b/tests/comparators/test_directory.py
@@ -49,10 +49,11 @@ def differences(tmpdir):
 
 def test_content(differences):
 output_text(differences[0], print_func=print)
-assert differences[0].source1 == 'dir/text'
+assert differences[0].source1 == 'dir'
+assert differences[0].details[0].source1 == 'text'
 expected_diff = open(os.path.join(os.path.dirname(__file__), '../data/text_ascii_expected_diff')).read()
-assert differences[0].unified_diff == expected_diff
+assert differences[0].details[0].unified_diff == expected_diff
 
 def test_stat(differences):
 output_text(differences[0], print_func=print)
-assert 'stat' in differences[0].details[0].source1
+assert 'stat' in differences[0].details[0].details[0].source1
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#800774: ic2-tools: python3 support etc

[Jérémy Bobbio]

Control: tag -1 + patch

peter green:
> There is a general push to move towards python3 in Debian, so please
> investiage whether it is reasonable to pull these updates into Debian.

The attached patch adds a python3-smbus package—inspired by what was in
Raspbian.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru i2c-tools-3.1.1/debian/changelog i2c-tools-3.1.1/debian/changelog
--- i2c-tools-3.1.1/debian/changelog	2014-03-02 22:32:21.0 +
+++ i2c-tools-3.1.1/debian/changelog	2016-02-05 11:45:15.0 +
@@ -1,3 +1,9 @@
+i2c-tools (3.1.1-1.0~python3) UNRELEASED; urgency=medium
+
+  * Add support for Python 3 inspired by the Raspbian package.
+
+ -- Jérémy Bobbio <lu...@debian.org>  Fri, 05 Feb 2016 11:44:43 +
+
 i2c-tools (3.1.1-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru i2c-tools-3.1.1/debian/control i2c-tools-3.1.1/debian/control
--- i2c-tools-3.1.1/debian/control	2014-03-02 22:26:08.0 +
+++ i2c-tools-3.1.1/debian/control	2016-02-05 11:46:05.0 +
@@ -1,7 +1,7 @@
 Source: i2c-tools
 Section: utils
 Priority: extra
-Build-Depends: debhelper (>= 5), python-all-dev (>= 2.6.6-3~)
+Build-Depends: debhelper (>= 5), python-all-dev (>= 2.6.6-3~), python3-all-dev
 Maintainer: Aurelien Jarno <aure...@debian.org>
 Standards-Version: 3.9.5
 Homepage: http://www.lm-sensors.org
@@ -39,3 +39,14 @@
  This Python module allows SMBus access through the I2C /dev interface on 
  Linux hosts.  The host kernel must have I2C support, I2C device interface
  support, and a bus adapter driver.
+
+Package: python3-smbus
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Provides: ${python3:Provides}
+Recommends: i2c-tools
+Description: Python 3 bindings for Linux SMBus access through i2c-dev 
+ This Python module allows SMBus access through the I2C /dev interface on 
+ Linux hosts.  The host kernel must have I2C support, I2C device interface
+ support, and a bus adapter driver.
diff -Nru i2c-tools-3.1.1/debian/patches/02-add-python3-support.diff i2c-tools-3.1.1/debian/patches/02-add-python3-support.diff
--- i2c-tools-3.1.1/debian/patches/02-add-python3-support.diff	1970-01-01 00:00:00.0 +
+++ i2c-tools-3.1.1/debian/patches/02-add-python3-support.diff	2016-02-05 11:55:12.0 +
@@ -0,0 +1,106 @@
+Description: Add Python 3 support
+Origin: upstream
+Author: Jean Delvare <kh...@linux-fr.org>
+
+diff -Nru i2c-tools-3.1.1/py-smbus/smbusmodule.c i2c-tools-3.1.1+svn/py-smbus/smbusmodule.c
+--- i2c-tools-3.1.1/py-smbus/smbusmodule.c	2014-02-20 09:56:05.873116000 +
 i2c-tools-3.1.1+svn/py-smbus/smbusmodule.c	2015-03-27 11:06:04.0 +
+@@ -92,7 +92,11 @@
+ 	PyObject *ref = SMBus_close(self);
+ 	Py_XDECREF(ref);
+ 
++#if PY_MAJOR_VERSION >= 3
++	Py_TYPE(self)->tp_free((PyObject *)self);
++#else
+ 	self->ob_type->tp_free((PyObject *)self);
++#endif
+ }
+ 
+ #define MAXPATH 16
+@@ -432,11 +436,19 @@
+ 
+ 	for (ii = 0; ii < len; ii++) {
+ 		PyObject *val = PyList_GET_ITEM(list, ii);
++#if PY_MAJOR_VERSION >= 3
++		if (!PyLong_Check(val)) {
++			PyErr_SetString(PyExc_TypeError, msg);
++			return 0; /* fail */
++		}
++		data->block[ii+1] = (__u8)PyLong_AS_LONG(val);
++#else
+ 		if (!PyInt_Check(val)) {
+ 			PyErr_SetString(PyExc_TypeError, msg);
+ 			return 0; /* fail */
+ 		}
+ 		data->block[ii+1] = (__u8)PyInt_AS_LONG(val);
++#endif
+ 	}
+ 
+ 	return 1; /* success */
+@@ -635,9 +647,14 @@
+ };
+ 
+ static PyTypeObject SMBus_type = {
++#if PY_MAJOR_VERSION >= 3
++	PyVarObject_HEAD_INIT(NULL, 0)
++	"SMBus",			/* tp_name */
++#else
+ 	PyObject_HEAD_INIT(NULL)
+ 	0,/* ob_size */
+ 	"smbus.SMBus",			/* tp_name */
++#endif
+ 	sizeof(SMBus),			/* tp_basicsize */
+ 	0,/* tp_itemsize */
+ 	(destructor)SMBus_dealloc,	/* tp_dealloc */
+@@ -676,24 +693,50 @@
+ 	SMBus_new,			/* tp_new */
+ };
+ 
++#if PY_MAJOR_VERSION >= 3
++static struct PyModuleDef SMBusModule = {
++	PyModuleDef_HEAD_INIT,
++	"SMBus",			/* m_name */
++	SMBus_module_doc,  		/* m_doc */
++	-1,/* m_size */
++	NULL,/* m_methods */
++	NULL,/* m_reload */
++	NULL,/* m_traverse */
++	NULL,/* m_clear */
++	NULL,/* m_free */
++};
++#define INIT_RETURN(m)	return m
++#define INIT_FNAME	PyInit_smbus
++#else
+ static PyMethodDef SMBus_module_methods[] = {
+ 	{NULL}
+ };
++#define INIT_RETURN(m)	return
++#define INIT_FNAME	initsmbus
++#endif
+ 
+ #ifndef PyMODINIT_FUNC	/* declarations for DLL import/export */
+ #define PyMODINIT_FUNC void
+ #endif
+ PyMODINIT_FUNC
+-initsmbus(void) 
++INIT_FNAME(void)
+ {
+ 	PyObject* m;
+ 
+ 	if (PyType_Ready(_type) < 0)
+-		return;
++		INIT_RETURN(NULL);
+ 
++#if PY_MAJOR_VERSION >= 3
++	m = PyModule_Create();
++#

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Guillem Jover:
> On Sun, 2016-01-31 at 14:43:08 +0100, Jérémy Bobbio wrote:
> > Guillem Jover:
> > > > How about naming the field “Environment-Variables”?
> > > 
> > > Hmm, or Environment, or Build-Environment, which reminds me that I've
> > > found the usage of Build-Environment (as the list of transitively
> > > required packages) slightly confusing, precisely because the first
> > > thing that comes to mind with environment is the variable space.
> > > 
> > > Perhaps we should consider renaming that one? Say Build-Packages (but
> > > that might be confusing), Build-Depends-Used, or something else? We
> > > also already have a Built-Using field too (although for source
> > > packages not binary ones, with a name I've also found slightly
> > > confusing as being too generic).
> > 
> > Ok. What about “Environment” for the variables,
> 
> I'm not sure if it'd be better to be explicit about this being a build
> thing, and not just a random environment. Are you worried about confusion
> with the previous usage of the field with the same name?

I'm indeed worry about confusion. The file is called '.buildinfo', so I
think it's fine to imply that these were environment variables defined
during the time the .buildinfo was generated.


  .
 / \ We have entered
/ ! \bike shedding territory
~


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


signature.asc
Description: Digital signature

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Holger Levsen:
> I know that *you* have grasped the concept of transitive build depends very 
> well, but I'm pretty sure that 97% of the DD population have no idea what 
> transitive build depends are, especially compared to build-depends or 
> alternative build-depends. And even 70% were too many.

Sorry Holger but we are introducing new concepts. So sure, 97% of the DD
population have no idea what we are talking about, but that's fine.

We have to educate them about .buildinfo file and what the various
fields mean. We have to aim at field names that are as unambigious as
possible to avoid laying traps on users.

For the particular case of “Installed-Transitive-Build-Depends”,
it's easy enough to explain “these are the name and version of all
packages which made building these binary packages possible”. Math
geeks can get a more formal definition.

“Built-Using” is already taken with a very precise meaning (and is there
for license-compliance reasons), but that would be the simpliest way to
sum up the short statement above. Given these are .buildinfo files, I
would be bold and suggest just “Using”.


I need to state that I care more about not drowning ourselves in bike
shedding than finding the perfect name.


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


signature.asc
Description: Digital signature

Bug#138409: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Hi!

We were discussions the restrictions on buildinfo identifiers:

fweb_1.62-12+b2_brahms-20120530T114812Z.buildinfo
^^^
  this part

The proposal was “the string should consist only of alphanumeric
characters and hyphens”. Guillem made the following comment while
reviewing the patches for dpkg:

Guillem Jover:
> Can we just simply use the package name rules instead? It also avoids
> potential problems with case and similar. (There's a
> pkg_name_is_illegal function in Dpkg::Package already.)

After reaching out to Ansgar with a patch for dak to implement the
above, he replied:

Ansgar Burchardt:
> The allowed sets for package names and the suffix of buildinfo
> filenames won't be the same even with that change.  However currently
> the suffix of buildinfo filenames matches what is allowed for .changes
> files.
> 
> I'm not sure why allowing capital letters used in the suffix of
> buildinfo files should be an issue? After all we allow capital letters
> for both version numbers (part of the filename) and in names of changes
> files.
> 
> (In the other direction not everything allowed as a package name can be
> used as the suffix of .changes and .buildinfo files either.)

Guillem, any further comments? Do you have any strong opposition to the
initial proposal?

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


signature.asc
Description: Digital signature

Bug#812899: libsm: please make the build reproducible (locale)

[Jérémy Bobbio]

Julien Cristau:
> On Wed, Jan 27, 2016 at 18:48:18 +0100, Jérémy Bobbio wrote:
> 
> > Source: libsm
> > Version: 2:1.2.2-1
> > Severity: wishlist
> > Tags: patch
> > User: reproducible-bui...@lists.alioth.debian.org
> > Usertags: locale
> > 
> > Hi!
> > 
> > While working on the “reproducible builds” effort [1], we have noticed
> > that libsm could not be built reproducibly.
> > 
> > The attached patch makes sure the text documentation is always generated
> > using a UTF-8 locale. Once applied, libsm can be built reproducibly in
> > our current experimental framework.
> > 
> That patch is not suitable for upstream, since the C.UTF-8 locale is
> non-standard.

Fair enough. Any suggestions then? Using `en_US.UTF-8` and `locales-all`
in Build-Depends? Unsetting LANG, LC_ALL and LC_CTYPE?

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


signature.asc
Description: Digital signature

Bug#812188: closed by Osamu Aoki <os...@debian.org> (Re: Bug#812188: debiandoc-sgml-doc-pt-br: FTBFS: make[1]: nsgmls: Command not found)

[Jérémy Bobbio]

Debian Bug Tracking System:
> This package is caught up in the package transition which caused:
> 
> >   make[1]: nsgmls: Command not found
> 
> With recent NMU of debiandoc-sgml changing by Niel its package
> dependencies, this should have been fixed. See Bug#805061

The last build attempted on 2016-01-31 on reproducible.debia.net failed
with the same error.

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


signature.asc
Description: Digital signature

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

RE
 .TP
+.BI \-\-buildinfo-identifier= identifier
+Specify the identifier part of the \fB.buildinfo\fP file name (since dpkg
+1.18.5).
+By default, \fBdpkg\-buildpackage\fP will create an identifier using the
+current time and the first characters of the MD5 hash.
+An arbitrary identifier can be specified as a replacement.
+The identifier has the same restriction as package names: they
+must consist only of lower case letters (a-z), digits (0-9), plus (+)
+and minus (\-) signs, and periods (.), be at least two characters long
+and must start with an alphanumeric character.
+.TP
 .BI \-p sign-command
 When \fBdpkg\-buildpackage\fP needs to execute GPG to sign a source
 control (\fB.dsc\fP) file or a \fB.changes\fP file it will run
@@ -351,6 +367,10 @@ Passed unchanged to \fBdpkg\-source\fP. See its manual page.
 Pass option \fIopt\fP to \fBdpkg\-source\fP (since dpkg 1.15.6).
 Can be used multiple times.
 .TP
+.BI \-\-buildinfo\-option= opt
+Pass option \fIopt\fP to \fBdpkg\-genbuildinfo\fP (since dpkg 1.18.5).
+Can be used multiple times.
+.TP
 .BI \-\-changes\-option= opt
 Pass option \fIopt\fP to \fBdpkg\-genchanges\fP (since dpkg 1.15.6).
 Can be used multiple times.
@@ -422,6 +442,7 @@ and initial arguments for
 .BR dpkg\-source (1),
 .BR dpkg\-architecture (1),
 .BR dpkg\-buildflags (1),
+.BR dpkg\-genbuildinfo (1),
 .BR dpkg\-genchanges (1),
 .BR fakeroot (1),
 .BR lintian (1),
diff --git a/man/dpkg-genbuildinfo.1 b/man/dpkg-genbuildinfo.1
new file mode 100644
index 000..1745f24
--- /dev/null
+++ b/man/dpkg-genbuildinfo.1
@@ -0,0 +1,98 @@
+.\" dpkg manual page - dpkg-genbuildinfo(1)
+.\"
+.\" Copyright © 1995-1996 Ian Jackson <i...@chiark.chu.cam.ac.uk>
+.\" Copyright © 2000 Wichert Akkerman <wakke...@debian.org>
+.\" Copyright © 2008-2010 Raphaël Hertzog <hert...@debian.org>
+.\" Copyright © 2006-2014 Guillem Jover <guil...@debian.org>
+.\" Copyright © 2015 Jérémy Bobbio <lu...@debian.org>
+.\"
+.\" This is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation; either version 2 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public License
+.\" along with this program.  If not, see <https://www.gnu.org/licenses/>.
+.
+.TH dpkg\-genbuildinfo 1 "2015-01-01" "Debian Project" "dpkg utilities"
+.SH NAME
+dpkg\-genbuildinfo \- generate Debian .buildinfo files
+.
+.SH SYNOPSIS
+.B dpkg\-genbuildinfo
+.RI [ option ...]
+.br
+.
+.SH DESCRIPTION
+.B dpkg\-genbuildinfo
+reads information from an unpacked and built Debian source tree and
+from the files it has generated and generates a Debian control
+file describing the build environment and the build products
+.RB ( .buildinfo " file)."
+.
+.SH OPTIONS
+.TP
+.BI \-c controlfile
+Specifies the main source control file to read information from. The
+default is
+.BR debian/control .
+.TP
+.BI \-l changelog-file
+Specifies the changelog file to read information from. The
+default is
+.BR debian/changelog .
+.TP
+.BI \-f files-list-file
+Specifies where is the list of files that have been produced by the build,
+rather than using
+.BR debian/files .
+.TP
+.BI \-F changelog-format
+Specifies the format of the changelog. See \fBdpkg\-parsechangelog\fP(1)
+for information about alternative formats.
+.TP
+.BI \-u upload-files-dir
+Look for the files to be uploaded in
+.I upload-files-dir
+rather than
+.B ..
+.RB ( dpkg\-genbuildinfo
+needs to find these files so that it can include their sizes and
+checksums in the
+.B .buildinfo
+file).
+.TP
+.BI \-\-admindir= dir
+Change the location of the \fBdpkg\fR database. The default location is
+\fI/var/lib/dpkg\fP.
+.TP
+.BI \-\-always\-include\-path
+By default, the \fBBuild\-Path\fR field will only be written if the current
+directory starts with \fB/build/\fR. Specify this option to always write
+a \fBBuild\-Path\fR field when generating the \fB.buildinfo\fR.
+.TP
+.B \-q
+.B dpkg\-genbuildinfo
+might produce informative messages on standard error.
+.B \-q
+suppresses these messages.
+.TP
+.BR \-? ", " \-\-help
+Show the usage message and exit.
+.TP
+.BR \-\-version
+Show the version and exit.
+.
+.SH FILES
+.TP
+.B debian/files
+The list of generated files.
+.B dpkg\-genbuildinfo
+reads the data here when producing a
+.B .buildinfo
+file.
diff --git a/man/po/po4a.cfg b/man/po/po4a.cfg
index 64d00ae..21d2bf8 100644
--- a/man/po/po4a.cfg
+++ b/man/po/po4a.cfg
@@ -93,6 +93,9 @@
 [type:man] dpkg-divert.1 $lang:$lang/dpkg

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Guillem Jover:
> > How about naming the field “Environment-Variables”?
> 
> Hmm, or Environment, or Build-Environment, which reminds me that I've
> found the usage of Build-Environment (as the list of transitively
> required packages) slightly confusing, precisely because the first
> thing that comes to mind with environment is the variable space.
> 
> Perhaps we should consider renaming that one? Say Build-Packages (but
> that might be confusing), Build-Depends-Used, or something else? We
> also already have a Built-Using field too (although for source
> packages not binary ones, with a name I've also found slightly
> confusing as being too generic).

Ok. What about “Environment” for the variables, and
“Installed-Build-Depends” for the list of packages?

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


signature.asc
Description: Digital signature

Bug#138409: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Guillem Jover:
> Lunar:
> > I think the proposed patch is missing a field to record some environment
> > variables that can affect the build process. Right now, I'm thinking of
> > DEB_BUILD_OPTIONS and DEB_flag_{SET,STRIP,APPEND,PREPEND} (from
> > dpkg-buildflags). Maybe others? Build profiles?
> >
> > Initially I was against recording such information, but now that we
> > understand the purpose of .buildinfo files better and not mandate that
> > they be reproducible themselves, it doesn't matter if one contains
> > `DEB_BUILD_OPTIONS=parallel=4` and the other
> > `DEB_BUILD_OPTIONS=parallel=16`. It is the responsibility of users
> > trying to recreate a given package to filter this out.
> 
> Hmm right, makes sense, but I see this also to be a bit problematic.
> There are many variables that do affect the build which we'd need to
> record. Including all of the them seems like another privacy
> concerning issue. Whitelisting, we might end up missing some but it's
> privacy-safe; blacklisting we might end-up including sensitive ones,
> but not miss any build-related ones, which is privacy-unsafe.
> 
> Some things that come to mind that do affect the build in a significant
> way: CC, LD_LIBRARY_PATH, DEB*, DPKG_*, PATH, MAKEFLAGS.
> 
> The traditional build flags (i.e. CFLAGS, LDFLAGS, etc) might also affect
> the build depending on the rules file.

I was thinking of a whitelist approach and to start with use cases we
can already think of, adding more variables to record if we identify
them as missing in the future.

How about naming the field “Environment-Variables”?

I will also add another vendor hook for the list of variables.

> Build profiles are already recorded in the binary packages, but having
> that in the .buildinfo file seems right as it makes it easier to
> reproduce the build environment.

Should it be a new field or would recording the DEB_BUILD_PROFILES
variable be enough?

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


signature.asc
Description: Digital signature

Bug#138409: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Guillem Jover:
> > One of the main change is that `.buildinfo` should now be named with an
> > arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP
> > but can be set to an arbitrary value by the `--buildinfo-identifier`
> > command line flag.
> 
> Hmmm, leaking the hostname seems slightly privacy-concerning? If the
> information therein is not relevant I'd rather use something like an
> UUID (although that would require increasing the pseudo-build-essential
> set), or just hashing the hostname-timestamp with something like md5
> or sha1 or similar.

My hunch is that having a timestamp visible in the file name might help
recognizing files quickly after a bunch of builds, especially to
identify the last one. So I'd rather keep it.

If privacy is the goal, hashing just the hostname would not be help
much, as any precomputed table would work.

How about $TIMESTAMP-$EIGHT_FIRST_CHARS_OF_BUILDINFO_MD5?

(I'm picking md5 because it's already used in dpkg-gensymbols.)

> Can we just simply use the package name rules instead? It also avoids
> potential problems with case and similar. (There's a
> pkg_name_is_illegal function in Dpkg::Package already.)

Sounds reasonable. I've updated the wiki page and prepared a patch for
dak.

> > +} else {
> > +warning(_g('no .dsc file, skipping .buildinfo generation'));
> > +}
> >  }
>
> ISTR mentioning this before, but I don't see why generating the
> buildinfo file is tied to existing a source package at all? The source
> should be included if we are including a source in the upload, that's
> it.

The whole puprose of the reproducible builds effort is to provide a
verifiable path from sources to binaries. Signed .buildinfo files are
certifications that the listed binary packages have been built using the
described source and environment.

Only listing the source in .buildinfo when a source is included in the
upload would prevent us to have multiple builders certify the same
binaries. That would cut us from providing multiple certifications and
would undermine the purpose of reproducible builds.

So I could remove the limitation, but the resulting .buildinfo file
would not be very useful for reproducible builds.

> > +$fields->{'Source'} = $spackage;
> > +if ($changelog->{'Binary-Only'}) {
> > +$fields->{'Source'} .= ' (' . $sourceversion . ')';
> > +$fields->{'Changes'} = $changelog->{'Changes'} . "\n\n"
> > + . ' -- ' . $changelog->{'Maintainer'}
> > + . '  ' . $changelog->{'Date'};
> > +}
> 
> Hmmm, it bothers me slightly that the Changes field here diverges in
> form from the one in the .changes file.

I can understand. It's been designed that way because it's actually only
there for binNMUs where the source is the same as the original and we
need a way to reconstruct the right changelog file.

Because sbuild might actually change its strings in the future, it felt
like plain copy/pasting was the safest. So recreating the changelog in
case of binNMU is about outputing the value of the Changes field in the
.buildinfo, a blank line, and the changelog from the original source.

> I think I'd prefer to have the Date as its own field, maybe always
> included. And also the Maintainer field. Any reason to not include
> them all the time or on their own?

I think they would be confusing. If we would to include the “Maintainer”
I guess we should call it “Changed-By” like in .changes. “Date”
as such would be a confusing name because I would tend to think of it
as the date of the build, and not as the date of the latest changelog
of a binNMU… So maybe “Changed-On” or “Change-Date”.

But this feels just more complicated than just the current
implementation, even if the format differs slightly. Maybe we can rename
that field instead to “Extra-Changelog-Entry” or something else so it's
clear they have different format?

> > +my $environment = Dpkg::Deps::AND->new();
> > +foreach my $pkg (sort keys %env_pkgs) {
> > +foreach my $installed_pkg (@{$facts->{pkg}->{$pkg}}) {
> > +my $version = $installed_pkg->{version};
> > +my $architecture = $installed_pkg->{architecture};
> > +my $pkg_name = $pkg;
> 
> > +if (defined $architecture &&
> > +$architecture ne 'all' && $architecture ne $build_arch) {
> > +$pkg_name = "$pkg_name:$architecture";
> > +}
> […]
> Also this will include all Multi-Arch instances for a given package
> regardless of them being used or not, I don't think that's desirable.

Can we know for sure which one have been used?


I'm already working on other changes you suggested.

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


signature.asc
Description: Digital signature

Bug#813023: flash-kernel: quoting error with bootargs in generic U-Boot boot script

[Jérémy Bobbio]

Ian Campbell:
> On Thu, 2016-01-28 at 16:36 +, Ian Campbell wrote:
> > > > While, I am at it, I wonder if it would not make more sense to
> > > > reverse the order when setting that variable so it reads:
> > > > 
> > > > setenv bootargs "@@LINUX_KERNEL_CMDLINE@@ ${bootargs}"
> > > > 
> > > > That way, it's possible to override the default command line by doing
> > > > something like:
> > > > 
> > > > setenv bootargs console=ttyAMA0,115200
> > > > boot
> > > 
> > > Yes, I guess that makes sense. Ian, do you see anything that would speak
> > > against this change?
> > 
> > It would prevent @@LINUX_KERNEL_CMDLINE@@ from overriding a bad (or just
> > inconvenient) ${bootargs} baked into a system's default firmware? In some
> > cases things are headless so you can't fix ${bootargs} yourself.
> > 
> > Perhaps we should switch things as suggested but also add
> > @@LINUX_KERNEL_CMDLINE_OVERRIDES@@ at the end to allow us to put things at
> > both the beginning and the end?
> 
> Having slept on it I think we might be safer leaving the semantics of
>  @@LINUX_KERNEL_CMDLINE@@ alone, but we could always add a different
> substitution at the beginning of the line (e.g.
> @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ perhaps).

Another option to fit my use case is to change the default script to add
an extra variable:

setenv bootargs "${bootargs} @@LINUX_KERNEL_CMDLINE@@ ${extra_bootargs}"

Then I could do:

setenv extra_bootargs "ip=dhcp"
boot

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


signature.asc
Description: Digital signature

Bug#813052: [Reproducible-builds] Bug#813052: diffoscope takes more than an hour on foreign arch libc6

[Jérémy Bobbio]

Helmut Grohne:
> Even though I cannot reproduce the issue at hand, I think that the code
> adding automatic debug symbols looks fishy to me. It appears to recurse
> over /tmp here and that looks very wrong to me.

I don't understand what you mean by that. Could you provide be (at least
some) of the `--debug` output?

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


signature.asc
Description: Digital signature

Bug#813023: flash-kernel: quoting error with bootargs in generic U-Boot boot script

[Jérémy Bobbio]

Package: flash-kernel
Version: 3.56
Tag: patch

Hi!

There's a small quoting mistake in the generic U-Boot script. It
probably hasn't been noticed so far because the default
LINUX_KERNEL_CMDLINE doesn't contain spaces. See the attached patch.

While, I am at it, I wonder if it would not make more sense to
reverse the order when setting that variable so it reads:

setenv bootargs "@@LINUX_KERNEL_CMDLINE@@ ${bootargs}"

That way, it's possible to override the default command line by doing
something like:

setenv bootargs console=ttyAMA0,115200
boot

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From 8d87ea9e4adcc48e4bffa0ff3a378fc3e417afe4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Thu, 28 Jan 2016 16:14:28 +0100
Subject: [PATCH] Properly quote LINUX_KERNEL_CMDLINE in U-Boot generic boot
 script

Otherwise we get an error as soon as LINUX_KERNEL_CMDLINE contains spaces.
---
 bootscript/all/bootscr.uboot-generic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bootscript/all/bootscr.uboot-generic b/bootscript/all/bootscr.uboot-generic
index c318be5..1c3f129 100644
--- a/bootscript/all/bootscr.uboot-generic
+++ b/bootscript/all/bootscr.uboot-generic
@@ -25,7 +25,7 @@ if test -n "${console}"; then
   setenv bootargs "${bootargs} console=${console}"
 fi
 
-setenv bootargs ${bootargs} @@LINUX_KERNEL_CMDLINE@@
+setenv bootargs "${bootargs} @@LINUX_KERNEL_CMDLINE@@"
 @@UBOOT_ENV_EXTRA@@
 
 if test -z "${fk_kvers}"; then
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#138409: [Reproducible-builds] Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Guillem Jover:
> I've some pending changes I'll be committing to master or a separate
> branch, that I'd like to be tested on the reproducible setup (ideally
> against the already generated and pre-existing reproducible binaries),
> if that's possible, I'll ask about that when those land, I just need
> to finish up fewm more unit tests.
> 
> Here's a quick review: […]

Thanks for the review! Just so I can organize my work, are your pending
changes related to the .buildinfo?

I can spend the next days improving the patch with your remarks, but I'd
rather not duplicate your work. :)

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


signature.asc
Description: Digital signature

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

Jérémy Bobbio:
> The attached patch will enable dpkg-buildpackage to create .buildinfo
> files as specified on the Debian wiki [1]. They have two main purposes:
> 
>  * recording information about the system environment used during a
>particular build—versions of the build dependencies installed, system
>architecture, etc. for easier forensics/debugging;
>  * describe how to recreate (partially or in full) the original
>environment when trying to reproduce a particular build.

I think the proposed patch is missing a field to record some environment
variables that can affect the build process. Right now, I'm thinking of
DEB_BUILD_OPTIONS and DEB_flag_{SET,STRIP,APPEND,PREPEND} (from
dpkg-buildflags). Maybe others? Build profiles?

Initially I was against recording such information, but now that we
understand the purpose of .buildinfo files better and not mandate that
they be reproducible themselves, it doesn't matter if one contains
`DEB_BUILD_OPTIONS=parallel=4` and the other
`DEB_BUILD_OPTIONS=parallel=16`. It is the responsibility of users
trying to recreate a given package to filter this out.

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


signature.asc
Description: Digital signature

Bug#812895: libxml++2.6: please make the build reproducible (environment)

[Jérémy Bobbio]

Source: libxml++2.6
Version: 2.40.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that libxml++2.6 could not be built reproducibly.

The reason is that the entire `examples` directory is shipped after
being built and so contains several libtool scripts which capture the
PATH. These files and others added during the build are actually not
useful as examples.

The attached patch replaces the wildcard in
`debian/libxml++2.6.examples` by the output of
`find examples -type f | LC_ALL=C sort` to ship only source files. Once
applied, libxml++2.6 can be built reproducibly in our current
experimental framework.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru libxml++2.6-2.40.1/debian/libxml++2.6-doc.examples libxml++2.6-2.40.1/debian/libxml++2.6-doc.examples
--- libxml++2.6-2.40.1/debian/libxml++2.6-doc.examples	2012-02-06 04:48:29.0 +0100
+++ libxml++2.6-2.40.1/debian/libxml++2.6-doc.examples	2016-01-27 17:59:41.0 +0100
@@ -1 +1,65 @@
-examples/*
+examples/Makefile.am
+examples/Makefile.in
+examples/README
+examples/dom_build/main.cc
+examples/dom_parse_entities/example.dtd
+examples/dom_parse_entities/example.xml
+examples/dom_parse_entities/main.cc
+examples/dom_parser/example.dtd
+examples/dom_parser/example.xml
+examples/dom_parser/example_invalid.xml
+examples/dom_parser/example_with_namespace.xml
+examples/dom_parser/main.cc
+examples/dom_parser_raw/example.dtd
+examples/dom_parser_raw/example.xml
+examples/dom_parser_raw/example_invalid.xml
+examples/dom_parser_raw/main.cc
+examples/dom_read_write/README
+examples/dom_read_write/example.dtd
+examples/dom_read_write/example.xml
+examples/dom_read_write/main.cc
+examples/dom_update_namespace/example1.xml
+examples/dom_update_namespace/example2.xml
+examples/dom_update_namespace/main.cc
+examples/dom_xinclude/example.xml
+examples/dom_xinclude/include1.txt
+examples/dom_xinclude/include2.xml
+examples/dom_xinclude/main.cc
+examples/dom_xpath/example.xml
+examples/dom_xpath/main.cc
+examples/dtdvalidation/example.dtd
+examples/dtdvalidation/main.cc
+examples/import_node/example1.xml
+examples/import_node/example2.xml
+examples/import_node/main.cc
+examples/sax_exception/example.xml
+examples/sax_exception/main.cc
+examples/sax_exception/myparser.cc
+examples/sax_exception/myparser.h
+examples/sax_parser/example.xml
+examples/sax_parser/main.cc
+examples/sax_parser/myparser.cc
+examples/sax_parser/myparser.h
+examples/sax_parser_build_dom/README
+examples/sax_parser_build_dom/example.xml
+examples/sax_parser_build_dom/main.cc
+examples/sax_parser_build_dom/svgdocument.cc
+examples/sax_parser_build_dom/svgdocument.h
+examples/sax_parser_build_dom/svgelement.cc
+examples/sax_parser_build_dom/svgelement.h
+examples/sax_parser_build_dom/svggroup.h
+examples/sax_parser_build_dom/svgparser.cc
+examples/sax_parser_build_dom/svgparser.h
+examples/sax_parser_build_dom/svgpath.h
+examples/sax_parser_entities/example.xml
+examples/sax_parser_entities/main.cc
+examples/sax_parser_entities/myparser.cc
+examples/sax_parser_entities/myparser.h
+examples/schemavalidation/example.rng
+examples/schemavalidation/example.xml
+examples/schemavalidation/example.xsd
+examples/schemavalidation/main.cc
+examples/testutilities.cc
+examples/testutilities.h
+examples/textreader/example.xml
+examples/textreader/main.cc
--- libxml++2.6-2.40.1/debian/rules	2012-02-06 04:48:29.0 +0100
+++ libxml++2.6-2.40.1/debian/rules	2016-01-27 18:15:57.278176904 +0100
@@ -23,4 +23,3 @@
  --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 DEB_MAKE_CHECK_TARGET := check
 DEB_DH_MAKESHLIBS_ARGS_$(SHARED_PKG) += -V"$(SHARED_PKG) (>= $(SHVER))"
-DEB_INSTALL_EXAMPLES_$(DOC_PKG) += -XMakefile -X.deps -X.libs -X.o


signature.asc
Description: Digital signature

Bug#812899: libsm: please make the build reproducible (locale)

[Jérémy Bobbio]

Source: libsm
Version: 2:1.2.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that libsm could not be built reproducibly.

The attached patch makes sure the text documentation is always generated
using a UTF-8 locale. Once applied, libsm can be built reproducibly in
our current experimental framework.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From f23f58eb98288fc3178d582dc03a77a332dc82fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Wed, 27 Jan 2016 18:32:31 +0100
Subject: [PATCH] Make sure text documentation is generated as UTF-8

Otherwise, if the package is built on a system with a locale
using another character encoding, the resulting text documentation
might not be readable on other systems.
---
 docbook.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docbook.am b/docbook.am
index bba4d54..0c1a086 100644
--- a/docbook.am
+++ b/docbook.am
@@ -43,7 +43,7 @@ if HAVE_XMLTO_TEXT
 
 shelf_DATA += $(docbook:.xml=.txt)
 %.txt: %.xml $(chapters)
-	$(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
+	LC_ALL=C.UTF-8 $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
 endif HAVE_XMLTO_TEXT
 
 if HAVE_FOP
-- 
2.7.0


signature.asc
Description: Digital signature

Bug#812895: libxml++2.6: please make the build reproducible (environment)

[Jérémy Bobbio]

Control: tag -1 - patch

Jérémy Bobbio:
> The attached patch replaces the wildcard in
> `debian/libxml++2.6.examples` by the output of
> `find examples -type f | LC_ALL=C sort` to ship only source files. Once
> applied, libxml++2.6 can be built reproducibly in our current
> experimental framework.

Mh… On second thought, the patch will result in all example files in a
single directory. Not ideal.

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


signature.asc
Description: Digital signature

Bug#751930: clementine: Can't export songs to my Sandisk Sansa Clip +

[Jérémy Bobbio]

Control: tag -1 + confirmed
Control: severity -1 wishlist

Hi Mark!

Mark Caglienzi:
> My music collection is in FLAC+CUE format (I rip my CDs using abcde and
> tag the files on a USB hard disk).
> 
> I found that Clementine could be the best audio player for my (wanted) use
> case:
> * Listen to my music collection in FLAC+CUE format
> * Occasionally transcode some music to ogg vorbis and export it to my sansa
> clip+
> 
> (Just to say... Neither amarok, nor mocp, nor exaile seem to like cue files, 
> which
> clementine support out of the box. Yay!)
> 
> Here come the bad news: everywhere on the internet I see that it's "easy" to 
> do
> in clementine:
> * Select some songs in a playlist
> * Right click
> * Choose 'Copy to device' (eventually, setting the transcoding preferences
> before)
> 
> But Clementine doesn't seem to have that menu item.
> 
> I tried in every possible way, booting the Sansa with Rockbox and with its
> original firmware, nothing changes.
> 
> The unit is seen by Clementine, but I don't have the menu item to export songs
> to it.
> 
> Maybe the fact that the songs are not single files (a.k.a. a CD with 10 songs
> it's 2 files: 1 flac and 1 cue, instead of 10 flac/ogg/whatever) is causing
> this problem to Clementine?

I just tried again with the latest version (1.3~rc1) and I can confirm
that the “Copy to device” option does not show for tracks coming from
CUE files.

You should be able to confirm this by putting the FLAC file directly on
the playlist (without using the CUE). The track context menu should have
a “Copy to device” option.

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


signature.asc
Description: Digital signature

Bug#812879: debhelper: should not add Build-Ids field to udebs

[Jérémy Bobbio]

Package: debhelper
Version: 9.20160115

Hi!

It seems that debhelper will add a Build-Ids field to udebs. The debug
files themselves are not in the package, though.

An example file is available at:
https://tests.reproducible-builds.org/artifacts/r00t-me/xorg-server_unstable_tmp-qtMva/b1/xserver-xorg-core-udeb_1.18.0-2_armhf.udeb

$ dpkg-deb -I xserver-xorg-core-udeb_1.18.0-2_armhf.udeb control | grep 
Build-Ids
Build-Ids: 1986b37315f158bba0c653972f05b5f686fe2a32 
1d845dd34944a795235d6af4ecb183adfd5fefa0 
2df762fbfe31c333c553d59279f8b60330615ccd 
4d086d75b6d330a0b673ad75ba3cd0a60653fac6 
750735c0dbbd920a089aa5ec095f50e01e4ba71f 
a7161d55fb5cfeef6e2c880e8a47f9d4dce195e1 
aafe3eaa7c2c8d8de3d3937fffa8dd9ed138382b 
e5b673542ae0f917f2f6ce4595021286db1056e0 
e996fec303a6941f1eb6ebe9f8737dea5b4d3365

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


signature.asc
Description: Digital signature

Bug#812876: glib2.0: please make the build reproducible (locale)

[Jérémy Bobbio]

Source: glib2.0
Version: 2.46.2-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that glib2.0 could not be built reproducibly.

The attached patch ensure that functions are sorted using the C locale
when giotypefuncs.c is generated.

Once applied, glib2.0 can be built reproducibly in our current
experimental framework.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru glib2.0-2.46.2/debian/patches/locale-independent-sort-for-giotypefuncs.patch glib2.0-2.46.2/debian/patches/locale-independent-sort-for-giotypefuncs.patch
--- glib2.0-2.46.2/debian/patches/locale-independent-sort-for-giotypefuncs.patch	1970-01-01 01:00:00.0 +0100
+++ glib2.0-2.46.2/debian/patches/locale-independent-sort-for-giotypefuncs.patch	2016-01-27 14:33:11.0 +0100
@@ -0,0 +1,13 @@
+Index: glib2.0-2.46.2/gio/tests/Makefile.am
+===
+--- glib2.0-2.46.2.orig/gio/tests/Makefile.am
 glib2.0-2.46.2/gio/tests/Makefile.am
+@@ -558,7 +558,7 @@ giotypefuncs.c: Makefile
+ 	  ${CPP} $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) xgen-giosrc.c | \
+ 	  $(GREP) -o '\bg_[A-Za-z0-9_]*_get_type\b' | \
+ 	  $(GREP) -v 'g_io_extension_get_type\|g_variant_get_type' | \
+-	  sort | uniq | \
++	  LC_ALL=C sort | uniq | \
+ 	  $(SED) -e 's/^/*tp++ = /' -e 's/$$/ ();/' >> xgen-gio && \
+ 	  cp xgen-gio $@ # && rm -f xgen-gio xgen-giosrc.c
+ 
diff -Nru glib2.0-2.46.2/debian/patches/series glib2.0-2.46.2/debian/patches/series
--- glib2.0-2.46.2/debian/patches/series	2015-12-23 17:08:41.0 +0100
+++ glib2.0-2.46.2/debian/patches/series	2016-01-27 14:31:36.0 +0100
@@ -14,3 +14,4 @@
 0001-Fix-trashing-on-overlayfs.patch
 bug712848-volume-monitor-deadlock-kfreebsd.patch
 disable-failing-test-for-pcre838.patch
+locale-independent-sort-for-giotypefuncs.patch


signature.asc
Description: Digital signature

Bug#805848: Please update taglib in Debian to version 1.10

[Jérémy Bobbio]

Control: unblock 810498 by 805848

Lunar:
> The latest release of Clementine requires taglib 1.10. It would be great
> if you could update the Debian package.

Actually, it seems to work fine with the current version. An update
would still be welcome though. :)

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


signature.asc
Description: Digital signature

Bug#807669: dh-strip-nondeterminism: Breaks some jar file

[Jérémy Bobbio]

Control: tag -1 + patch

Raphael Hertzog:
> On Mon, 14 Dec 2015, Raphael Hertzog wrote:
> > Your analysis is correct but dh_strip_nondeterminisn should detect the
> > signature and avoid messing up with the file in that case.
> > 
> > That's what this bug is about.
> 
> And we got another case where dh_strip_nondeterminism actually broke a
> working package... https://bugs.kali.org/view.php?id=3019
> 
> Is there anything we can do to ensure that this bug gets a timely fix?

Attached is a patch which I think could work. I'm not confident enough
in my Perl skills to commit directly though.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From e2dfd6d97a2f0af21f5d113d7eed12d90ebe2384 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Tue, 26 Jan 2016 13:59:14 +
Subject: [PATCH] Don't process signed Jar file

Otherwise, we will break the signature and that's not a good thing.

I guess it would be better if we had a way to pass a warning back. But that's
something for the future.

Closes: #807669
---
 lib/File/StripNondeterminism/handlers/jar.pm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/File/StripNondeterminism/handlers/jar.pm b/lib/File/StripNondeterminism/handlers/jar.pm
index e136395..4af06a0 100644
--- a/lib/File/StripNondeterminism/handlers/jar.pm
+++ b/lib/File/StripNondeterminism/handlers/jar.pm
@@ -87,6 +87,12 @@ sub _jar_normalize_member {
 
 sub normalize {
 	my ($jar_filename) = @_;
+	my $jar = Archive::Zip->new($jar_filename);
+	my @filenames = $jar->memberNames();
+	for my $filename (@filenames) {
+		# don't process signed jars
+		return 0 if $filename =~ /\AMETA-INF\/[^\/]+\.SF\Z/i;
+	}
 	return File::StripNondeterminism::handlers::zip::normalize($jar_filename,
 			filename_cmp => \&_jar_filename_cmp,
 			member_normalizer => \&_jar_normalize_member);
-- 
2.6.1



signature.asc
Description: Digital signature

Bug#812762: findutils: FTBFS if fr_FR or other locales are installed

[Jérémy Bobbio]

Source: findutils
Version: 4.6.0-2
Severity: important
User: reproducible-bui...@lists.alioth.debian.org
Usertag: ftbfs

Hi!

findutils will FTBFS due to test errors if fr_FR or a couple other
locales are installed. The failing tests are test-mbrtowc{1,2,3,4}.sh.
The log contains:

test-mbrtowc.c:49: assertion 'ret == (size_t)(-2)' failed
Aborted

An easy way to test this is to install the locales-all package in the
build environment.

Maybe mbrtowc() behavior when n == 0 has changed in recent libc?

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


signature.asc
Description: Digital signature

Bug#805848: Please update taglib in Debian to version 1.10

[Jérémy Bobbio]

Control: block 810498 by 805848

Hi!

The latest release of Clementine requires taglib 1.10. It would be great
if you could update the Debian package.

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


signature.asc
Description: Digital signature

Bug#812703: bc: please enable all hardening flags

[Jérémy Bobbio]

Source: bc
Version: 1.06.95-9
Severity: wishlist
Tags: patch
User: hardening-disc...@lists.alioth.debian.org
Usertag: goal-hardening

Hi!

bc and dc provides ELF executables that are not compiled as a position
independent executable (PIE). PIE is required for fully enabling Address
Space Layout Randomization (ASLR), which makes "Return-oriented" attacks
more difficult.

I have successfully rebuilt bc adding the following line in
debian/rules:

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

I did some quick tests and the package seemed to work fine. Please
consider this easy way to improve the security of Debian users.

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


signature.asc
Description: Digital signature

Bug#812524: [Reproducible-builds] Bug#812524: UnicodeDecodeError with glob2/0.9.4.4-2.4 on unstable/amd64

[Jérémy Bobbio]

Control: tag -1 + pending

Mattia Rizzolo:
>   File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
> return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 95: 
> ordinal not in range(128)

Fixed in 00b26a6.

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


signature.asc
Description: Digital signature

Bug#812534: [Reproducible-builds] Bug#812534: TypeError with python-expyriment/0.7.0+git34-g55a4e7e-3.1 on unstable/amd64

[Jérémy Bobbio]

Control: tag -1 + pending

Mattia Rizzolo:
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/debian.py", 
> line 185, in recognizes
> for d in buildinfo.get('Checksums-Sha256'):
> TypeError: 'NoneType' object is not iterable

Already fixed in af6bcf80.

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


signature.asc
Description: Digital signature

Bug#812428: libgcrypt20: please make the build reproducible (timestamps)

[Jérémy Bobbio]

Source: libgcrypt20
Version: 1.6.4-4
Severity: wishlist
Tag: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that libgcrypt20 could not be built reproducibly.

The attached patch adds support for SOURCE_DATE_EPOCH to set the value
of BUILD_TIMESTAMP defined in the configure script. Once applied,
libgcrypt20 is nearly reproducible in our current experimental
framework—their might be remaining timestamps in the PDF documentation.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff --git a/debian/control b/debian/control
index ff31343..e3a19c4 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Uploaders: Andreas Metzler <ametz...@debian.org>,
  Eric Dorland <e...@debian.org>, James Westby <jw+deb...@jameswestby.net>,
  Simon Josefsson <si...@josefsson.org>
 Build-Depends: debhelper (>= 9.20150628),
- libgpg-error-dev (>= 1.11), autotools-dev
+ libgpg-error-dev (>= 1.11), autotools-dev, dh-autoreconf
 Build-Depends-Indep: texlive-latex-base, texlive-generic-recommended,
  texinfo (>= 4.6-0)
 Standards-Version: 3.9.6
diff --git a/debian/patches/30_support_source_date_epoch.diff b/debian/patches/30_support_source_date_epoch.diff
new file mode 100644
index 000..8e43921
--- /dev/null
+++ b/debian/patches/30_support_source_date_epoch.diff
@@ -0,0 +1,18 @@
+Description: support setting BUILD_TIMESTAMP using SOURCE_DATE_EPOCH
+ Enable reproducible builds by supporting setting the value of BUILD_TIMESTAMP
+ through the SOURCE_DATE_EPOCH environment variable. More information at:
+ https://reproducible-builds.org/specs/source-date-epoch/
+Author: Jérémy Bobbio <lu...@debian.org>
+Last-Update: 2016-01-23
+
+--- libgcrypt20-1.6.4.orig/configure.ac
 libgcrypt20-1.6.4/configure.ac
+@@ -1993,7 +1993,7 @@ changequote([,])dnl
+ BUILD_FILEVERSION="${BUILD_FILEVERSION}mym4_revision_dec"
+ AC_SUBST(BUILD_FILEVERSION)
+ 
+-BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+ 2>/dev/null || date`
++BUILD_TIMESTAMP=`date -d"@$SOURCE_DATE_EPOCH" -u +%Y-%m-%dT%H:%M+ 2>/dev/null || date -u +%Y-%m-%dT%H:%M+ 2>/dev/null || date`
+ AC_SUBST(BUILD_TIMESTAMP)
+ AC_DEFINE_UNQUOTED(BUILD_TIMESTAMP, "$BUILD_TIMESTAMP",
+[The time this package was configured for a build])
diff --git a/debian/patches/series b/debian/patches/series
index d5154e9..2f0a91b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 12_lessdeps_libgcrypt-config.diff
 15_multiarchpath_in_-L.diff
 20_fedora_libgcrypt-1.6.3-aliasing.patch
+30_support_source_date_epoch.diff
diff --git a/debian/rules b/debian/rules
index 27614f9..1b137a5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,4 +48,4 @@ override_dh_gencontrol:
 	dh_gencontrol --remaining-packages
 
 %:
-	dh $@ --parallel --with autotools_dev
+	dh $@ --parallel --with autoreconf --with autotools_dev


signature.asc
Description: Digital signature

Bug#808207: diffoscope: Filter objdump --disassemble output before diffing it

[Jérémy Bobbio]

Hi Mike!

Mike Hommey:
> When comparing large ELF binaries, some minor differences can end up hurting
> the visibility of more important differences.
> 
> Specifically, objdump --disassemble displays symbols+offsets for addresses
> it derives from IP-relative addressing, like the following:
> 
>9d2be2: 48 8d 05 42 65 24 02lea0x2246542(%rip),%rax# 
> 2c1912b <_fini@@xul45a1+0x1d803>

I would be grateful if you could try again using the master branch.
Dhole made diffoscope compare ELF sections individually and I wonder how
much it helped with this problem.

If it doesn't, would you be so kind to provide example binaries?

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


signature.asc
Description: Digital signature

Bug#808197: diffoscope: readelf --debug-dump can be brutal

[Jérémy Bobbio]

Control: tag -1 + pending

Mike Hommey:
> However, if each debug section was compared individually, that give more
> chance for diffoscope to work. (--debug-dump takes values allowing to treat
> each debug section independently)

Implemented by Dhole and currently available in the master branch.

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


signature.asc
Description: Digital signature

Bug#808267: diffoscope: Redundant information in ELF comparisons

[Jérémy Bobbio]

Hi Mike,

Mike Hommey:
> When comparing ELF files, the following commands are used:
> - readelf --all
> - readelf --debug-dump
> - objdump --disassemble --full-contents
> 
> objdump --disassemble --full-contents is actually redundant in itself. For
> example, it will dump both an hexdump and a disassembly of the .text section.
> It's also redundant with the output of readelf --debug-dump because it does an
> hexdump of the .debug_* sections that readelf --debug-dump does a dwarf dump
> of.

The master branch now compare ELF files section by section. If you could
test it and see if there's still redundancies, I would be grateful.

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


signature.asc
Description: Digital signature

Bug#811373: python-stem: please restore tor-prompt as an executable

[Jérémy Bobbio]

Source: python-stem
Version: 1.3.0-1
Severity: wishlist

Hi!

With the upload of python-stem/1.3.0-1, tor-prompt has been moved away
from the standard PATH. In Jessie, typing “tor-prompt” works just fine.

I don't see a reason why it cannot be provided as part of either
python3-stem or a dedicated tor-prompt package. In any cases, a NEWS
file to warn users of the change is probably required.

Thanks!

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


signature.asc
Description: Digital signature

Bug#759886: dpkg-dev: please make mtimes of packaged files deterministic

[Jérémy Bobbio]

reassign 759886 dpkg-dev
retitle 759886 dpkg-dev: please make mtimes of packaged files deterministic
thanks

Hi!

The attached patch series is an attempt to make the mtimes of packaged
files deterministic. It is taken from the `pu/reproducible_builds`
dpkg branch maintained by the “reproducible builds” folks [1].

The first two patches introduce the idea of a canonical build timestamp
that will be used throughout dpkg-deb.

The first patch will make use of this timestamp to set the mtime in ar
headers (that's #75). All headers will thus get the same timestamp
instead of recording the current time as they are added.

The second patch will use the --mtime and --clamp-mtime option of tar to
clamp the mtime of files recorded in control.tar and data.tar to the
build timestamp: files created at a later time will see their mtime
set to the build timestamp (that's #759886). As --clamp-mtime is only
available since tar/1.28-1 and has not yet been merged upstream,
dpkg-deb will first look for its availability by looking for the option
in the output of “tar --help”. If it's not available, it will fallback
to the previous behavior.

The third patch adds the ability to set the aforementioned build
timestamp using the SOURCE_DATE_EPOCH environment variable [2].

The forth patch changes dpkg-buildpackage to set SOURCE_DATE_EPOCH to
the time of the latest debian/changelog entry if it hasn't been already
set, effectively making the timestamps recorded by dpkg-deb in the most
common build process deterministic.

 [1]: 
https://anonscm.debian.org/cgit/reproducible/dpkg.git/log/?h=pu/reproducible_builds
 [2]: https://reproducible-builds.org/specs/source-date-epoch/

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From e56a69e2fac8531c9a45008470ca8aa8dd9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Tue, 27 Aug 2013 22:38:31 +0200
Subject: [PATCH 1/4] dpkg-deb: Use a single timestamp for ar headers when
 building a .deb

In order to make build reproducible in the future, we now use a single
timestamp in all ar headers when creating a .deb.

Previously, each ar header would have the current time of its creation.
This level of precision is not really needed and the time of the beginning of
the build is good enough.

Address: #75
---
 dpkg-deb/build.c   | 10 +++---
 dpkg-split/split.c |  4 ++--
 lib/dpkg/ar.c  | 13 +++--
 lib/dpkg/ar.h  |  4 ++--
 4 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 8d9f066..117e424 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -529,6 +530,7 @@ do_build(const char *const *argv)
   int arfd;
   int p1[2], gzfd;
   pid_t c1, c2;
+  time_t build_timestamp;
 
   /* Decode our arguments. */
   dir = *argv++;
@@ -559,6 +561,8 @@ do_build(const char *const *argv)
   }
   m_output(stdout, _(""));
 
+  build_timestamp = time(NULL);
+
   /* Now that we have verified everything its time to actually
* build something. Let's start by making the ar-wrapper. */
   arfd = creat(debar, 0644);
@@ -636,8 +640,8 @@ do_build(const char *const *argv)
 compressor_get_extension(control_compress_params.type));
 
 dpkg_ar_put_magic(debar, arfd);
-dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, strlen(deb_magic));
-dpkg_ar_member_put_file(debar, arfd, adminmember, gzfd, -1);
+dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, build_timestamp, strlen(deb_magic));
+dpkg_ar_member_put_file(debar, arfd, adminmember, gzfd, build_timestamp, -1);
   } else {
 internerr("unknown deb format version %d.%d", deb_format.major, deb_format.minor);
   }
@@ -679,7 +683,7 @@ do_build(const char *const *argv)
 if (lseek(gzfd, 0, SEEK_SET))
   ohshite(_("failed to rewind temporary file (%s)"), _("data member"));
 
-dpkg_ar_member_put_file(debar, arfd, datamember, gzfd, -1);
+dpkg_ar_member_put_file(debar, arfd, datamember, gzfd, build_timestamp, -1);
 
 close(gzfd);
   }
diff --git a/dpkg-split/split.c b/dpkg-split/split.c
index 8137654..d132e3e 100644
--- a/dpkg-split/split.c
+++ b/dpkg-split/split.c
@@ -210,13 +210,13 @@ mksplit(const char *file_src, const char *prefix, off_t maxpartsize,
 		  (intmax_t)st.st_size, (intmax_t)partsize,
 		  curpart, nparts, pkg->available.arch->name);
 		dpkg_ar_member_put_mem(file_dst.buf, fd_dst, PARTMAGIC,
-		   partmagic.buf, partmagic.used);
+		   partmagic.buf, time(NULL), partmagic.used);
 		varbuf_reset();
 
 		/* Write the data part. */
 		varbuf_printf(, "data.%d", curpart);
 		dpkg_ar_member_put_file(file_dst.buf, fd_dst, partname.buf,
-		fd_src, 

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Jérémy Bobbio]

\-g\fP are specified).
 .IP \fB6.\fP 3
+Unless a source-only build has been requested, it runs the \fBbuildinfo\fP hook
+and calls \fBdpkg\-genbuildinfo\fP to generate a \fB.buildinfo\fP file.
+Several \fBdpkg\-buildpackage\fP options are forwarded to
+\fBdpkg\-genbuildinfo\fP.
+.IP \fB7.\fP 3
 It runs the \fBchanges\fP hook and calls \fBdpkg\-genchanges\fP to
 generate a \fB.changes\fP file.
 Many \fBdpkg\-buildpackage\fP options are forwarded to
 \fBdpkg\-genchanges\fP.
-.IP \fB7.\fP 3
+.IP \fB8.\fP 3
 It runs the \fBpostclean\fP hook and if \fB\-tc\fP is specified, it will
 call \fBfakeroot debian/rules clean\fP again.
-.IP \fB8.\fP 3
-It calls \fBdpkg\-source \-\-after\-build\fP.
 .IP \fB9.\fP 3
+It calls \fBdpkg\-source \-\-after\-build\fP.
+.IP \fB10.\fP 3
 It runs the \fBcheck\fP hook and calls a package checker for the
 \fB.changes\fP file (if a command is specified in \fBDEB_CHECK_COMMAND\fP or
 with \fB\-\-check\-command\fP).
-.IP \fB10.\fP 3
+.IP \fB11.\fP 3
 It runs the \fBsign\fP hook and calls \fBgpg2\fP or \fBgpg\fP to sign
 the \fB.dsc\fP file (if any, unless \fB\-us\fP is specified or on UNRELEASED
 builds), and the \fB.changes\fP file (unless \fB\-uc\fP is specified or on
 UNRELEASED builds).
-.IP \fB11.\fP 3
+.IP \fB12.\fP 3
 It runs the \fBdone\fP hook.
 .
 .SH OPTIONS
@@ -317,6 +322,12 @@ The source package version (without the epoch).
 The upstream version.
 .RE
 .TP
+.BI \-\-buildinfo-identifier= identifier
+By default, \fBdpkg\-buildpackage\fP put the system hostname and the
+current time in the name of the \fB.buildinfo\fP file. An arbitrary
+identifier can be specified as a replacement (since dpkg 1.18.5). It must
+contain only alphanumeric characters and hyphens.
+.TP
 .BI \-p sign-command
 When \fBdpkg\-buildpackage\fP needs to execute GPG to sign a source
 control (\fB.dsc\fP) file or a \fB.changes\fP file it will run
@@ -351,6 +362,10 @@ Passed unchanged to \fBdpkg\-source\fP. See its manual page.
 Pass option \fIopt\fP to \fBdpkg\-source\fP (since dpkg 1.15.6).
 Can be used multiple times.
 .TP
+.BI \-\-buildinfo\-option= opt
+Pass option \fIopt\fP to \fBdpkg\-genbuildinfo\fP (since dpkg 1.18.5).
+Can be used multiple times.
+.TP
 .BI \-\-changes\-option= opt
 Pass option \fIopt\fP to \fBdpkg\-genchanges\fP (since dpkg 1.15.6).
 Can be used multiple times.
@@ -422,6 +437,7 @@ and initial arguments for
 .BR dpkg\-source (1),
 .BR dpkg\-architecture (1),
 .BR dpkg\-buildflags (1),
+.BR dpkg\-genbuildinfo (1),
 .BR dpkg\-genchanges (1),
 .BR fakeroot (1),
 .BR lintian (1),
diff --git a/man/dpkg-genbuildinfo.1 b/man/dpkg-genbuildinfo.1
new file mode 100644
index 000..77f2a76
--- /dev/null
+++ b/man/dpkg-genbuildinfo.1
@@ -0,0 +1,98 @@
+.\" dpkg manual page - dpkg-genbuildinfo(1)
+.\"
+.\" Copyright © 1995-1996 Ian Jackson <i...@chiark.chu.cam.ac.uk>
+.\" Copyright © 2000 Wichert Akkerman <wakke...@debian.org>
+.\" Copyright © 2008-2010 Raphaël Hertzog <hert...@debian.org>
+.\" Copyright © 2006-2014 Guillem Jover <guil...@debian.org>
+.\" Copyright © 2015 Jérémy Bobbio <lu...@debian.org>
+.\"
+.\" This is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation; either version 2 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public License
+.\" along with this program.  If not, see <https://www.gnu.org/licenses/>.
+.
+.TH dpkg\-genbuildinfo 1 "2015-01-01" "Debian Project" "dpkg utilities"
+.SH NAME
+dpkg\-genbuildinfo \- generate Debian .buildinfo files
+.
+.SH SYNOPSIS
+.B dpkg\-genbuildinfo
+.RI [ option ...]
+.br
+.
+.SH DESCRIPTION
+.B dpkg\-genbuildinfo
+reads information from an unpacked and built Debian source tree and
+from the files it has generated and generates a Debian control
+file describing the build environment and the build products
+.RB ( .buildinfo " file)."
+.
+.SH OPTIONS
+.TP
+.BI \-c controlfile
+Specifies the main source control file to read information from. The
+default is
+.BR debian/control .
+.TP
+.BI \-l changelog-file
+Specifies the changelog file to read information from. The
+default is
+.BR debian/changelog .
+.TP
+.BI \-f files-list-file
+Specifies where is the list of files that have been produced by the build,
+rather than using
+.BR debian/files .
+.TP
+.BI \-F changelog-format
+Specifies the format of the changelog. See \fBdpkg\-parsechangelog\fP(1)
+for information about alternative formats.
+.TP
+.BI \-u upload-files-dir
+Look for the files to be u

Bug#808120: [Reproducible-builds] Bug#808120: diffoscope: Should use less memory

[Jérémy Bobbio]

Control: tag -1 + pending

Mike Hommey:
>* What was the outcome of this action?
> 
> A 533KB HTML file that, considering its size, doesn't contain much 
> differences.
> Yet, while processing this, the diffoscope process (not its children readelf,
> objdump or diff processes) sucked more than 4GB of memory. That tells me
> something unexpectedly suboptimal is happening.

Absolutely! The code was building a full list of lines to compare in
memory instead of feeding them to diff as they were produced. The fix
was trivial once the issue was understood. Thanks for the nudge.

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


signature.asc
Description: Digital signature

Bug#808541: [Reproducible-builds] Bug#808541: diffoscope TypeError with openocd/0.9.0-1 in testing/amd64

[Jérémy Bobbio]

Control: tag -1 + pending

Mattia Rizzolo:
> TypeError: unorderable types: bytes() < str()

I've pushed a fix. Thanks for the report.

(This only appeared when the default encoding was not Unicode-aware.)

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


signature.asc
Description: Digital signature

Bug#808003: [Reproducible-builds] Bug#808003: diffoscope: Comparing directories shouldn't care about file order

[Jérémy Bobbio]

Control: tag -1 + pending

Mike Hommey:
>* What led up to the situation?
> 
> Comparing two directories
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Ran `diffoscope --html output.html a b` where a and b are directories 
> containing
> more or less the same thing.
> 
>* What was the outcome of this action?
> 
> The output contained differences in the output for find due to
> filesystem-dependent behavior wrt file ordering in readdir(3).
> 
>* What outcome did you expect instead?
> 
> The sorted list should be compared instead.

I've just commited a fix. Thanks for the report.

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

Bug#808199: [Reproducible-builds] Bug#808199: diffoscope: Weird line numbering in diff output

[Jérémy Bobbio]

Control: tag -1 + pending

Mike Hommey:
> Attached here is two files that can be compared directly, exposing the
> same problem. That's essentially the output of tar --full-time -tvf on
> both tarballs from the original bug report.
> 
> The following patch fixes the numbering issue:
> […]

Commited, thanks. The bug was around since the very first version of
the current HTML presenter code!

> However, there's another issue, that the diff is actually incomplete:
> the right hand side stops 3 lines too early.

I've fixed this as well.  The 'lines skipped' message was not written
when we were skipping lines at the end of the diff.

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


signature.asc
Description: Digital signature

Bug#808121: [Reproducible-builds] Bug#808121: Bug#808121: diffoscope: HTML output is bloated

[Jérémy Bobbio]

Esa Peuha:
> While we are at it, let's convert HTML character entity references
> (which each use 6-8 characters and as many bytes in the HTML file)
> to actual characters (which UTF-8 encodes as 2-3 bytes). Since all
> diffoscope output files are peppered with abundant amounts of these
> things, this could reduce the file sizes by a few percent at least.
> I used Python string literals instead of the actual characters in
> the Python file, because 1) the non-breaking and zero-width spaces
> would be very hard to distinguish from ordinary space and missing
> string content, respectively, and 2) it is impossible to be sure
> that every piece of software that is ever going to be used to view
> or edit the file would handle non-ASCII characters correctly.

Thanks for the patch. It's been commited and push.

I would be grateful if you could submit ready-to-merge Git changes next
time (see git-format-patch(1)).

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


signature.asc
Description: Digital signature

Bug#808121: [Reproducible-builds] Bug#808121: Bug#808121: diffoscope: HTML output is bloated

[Jérémy Bobbio]

Mike Hommey:
> Here's another easy win, attached.

Nice. Commited. :)

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


signature.asc
Description: Digital signature

Bug#808103: [Reproducible-builds] Bug#808103: diffoscope: Truncated symbols in ELF diffs

[Jérémy Bobbio]

Control: tag -1 + pending

Mike Hommey:
> When there are differences in symbols-related sections of ELF files,
> symbols can be truncated if they are long enough. That happens often
> with C++ mangled symbols.
> 
> The following patch fixes the issue: […]

Applied, thanks!

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


signature.asc
Description: Digital signature

Bug#808104: [Reproducible-builds] Bug#808104: diffoscope 43 KeyError's with several packages

[Jérémy Bobbio]

Control: tag -1 + pending

Mattia Rizzolo:
> Seen on rb.d.n, with several packages, e.g.
> dhcpdump/1.8-2 on testing/amd64
> console-data/2:1.12-5 on testing/amd64
> 
> 
> Wed Dec 16 01:52:13 UTC 2015 - diffoscope 43 will be used to compare the two 
> builds:
> Traceback (most recent call last):
> […]
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/libarchive.py", 
> line 150, in get_member
> raise KeyError('%s not found in archive', member_name)
> KeyError: ('%s not found in archive', './md5sums')

Thanks for the report. Fix pushed.

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


signature.asc
Description: Digital signature

Bug#808121: [Reproducible-builds] Bug#808121: diffoscope: HTML output is bloated

[Jérémy Bobbio]

Close: tag -1 + pending

Mike Hommey:
> Looking at the HTML in the HTML output, one can see that it is needlessly 
> large.
> 
> Specifically, there appears to be a lot of e.g. 
> following each other, without even a separation between them. This conflates
> the amount of memory necessary for browsers to render those pages.

I've commited a fix for this specific issue. The HTML presenter borrowed
a lot of code from diff2html which was probably not much optimized in
the first place. I guess the output could be vastly improved, but I'd
rather focus on other part of the code for now. Patches highly welcome
in the meantime.

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


signature.asc
Description: Digital signature

Bug#808002: [Reproducible-builds] Bug#808002: diffoscope: Add support for Mozilla-optimized ZIPs

[Jérémy Bobbio]

Control: tag -1 + pending

Mike Hommey:
> On Tue, Dec 15, 2015 at 04:31:46PM +0100, Jérémy Bobbio wrote:
> > Mike Hommey:
> > > It would be useful for diffoscope to output differences in omni.ja files 
> > > as
> > > for other Zip files, instead of ending up with a diff of an hexdump.
> > > 
> > > The attached patch implements a minimal support for this. It however 
> > > doesn't
> > > look at the difference in the `preload` value.
> > 
> > Great! I think it's fine to just skip the preload value. It will show up
> > in the fallback binary comparison if that's the only remaining difference.
> > 
> > I was going to merge this, but actually I have to ask: would you be kind
> > enough to amend the test suite as well?
> 
> Attached.

Awesome! Applied. :)

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


signature.asc
Description: Digital signature

Bug#808002: [Reproducible-builds] Bug#808002: diffoscope: Add support for Mozilla-optimized ZIPs

[Jérémy Bobbio]

Mike Hommey:
> It would be useful for diffoscope to output differences in omni.ja files as
> for other Zip files, instead of ending up with a diff of an hexdump.
> 
> The attached patch implements a minimal support for this. It however doesn't
> look at the difference in the `preload` value.

Great! I think it's fine to just skip the preload value. It will show up
in the fallback binary comparison if that's the only remaining difference.

I was going to merge this, but actually I have to ask: would you be kind
enough to amend the test suite as well?

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


signature.asc
Description: Digital signature

Bug#807084: libjs-jcrop: please make the build reproducible

[Jérémy Bobbio]

Chris Lamb:
> --- a/debian/rules2015-12-05 09:42:10.758251726 +0200
> --- b/debian/rules2015-12-05 09:51:58.484426475 +0200
> @@ -1,6 +1,7 @@
>  #!/usr/bin/make -f
>  
>  export JCROP_BUILD = debian/$(shell dpkg-parsechangelog --show-field Version)
> +export JCROP_COPYRIGHT = $(shell date --date="$$(dpkg-parsechangelog 
> --show-field Date)" +%Y)

For the sake of consistency, it might be better to use `date -u` here.
(Tiny corner case, I know.)

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


signature.asc
Description: Digital signature

Bug#806891: [Reproducible-commits] [diffoscope] 01/01: Multi-file HTML output

[Jérémy Bobbio]

Joachim Breitner:
> Multi-file HTML output

Really great idea. :) Thanks for the initial patch!

> +parser.add_argument('--jquery', metavar='url', dest='jquery_url',
> +help='link to the jquery url, with --html-dir. By 
> default, a symlink to /usr/share/javascript/jquery/jquery.js is created')

To make the Suggests a reality, I think it would be better to only
display “By default, a symlink…” if the file is already present on the
filesystem. Otherwise, if `--html-dir` is specified, the software should
exit with an error, asking users to specify `--jquery`.

Related question: is the browser going to visit the subpage if I have
JavaScript disabled? In that case, one other option is to only add the
JavaScript code when we have access to jQuery. I know some people don't
want JavaScript in their browser, so specifying something like
`--no-jquery` or `--jquery=none` could also be a way to turn it off.

> +# no output desired? print text
> +if not parsed_args.text_output and not parsed_args.html_output and 
> not parsed_args.html_output_directory:
> +parsed_args.text_output = "-"

Maybe it would be nicer to write:

if not any(parsed_args.text_output, parsed_args.html_output, 
parsed_args.html_output_directory):

> +def output_unified_diff(print_func, directory, anchor, unified_diff):
> +if directory and len(unified_diff) > 
> Config.general.separate_file_diff_size:
> +# open a new file for this table
> +filename="%s.html" % hashlib.md5(anchor.encode('utf-8')).hexdigest()

I'm not entirely sure the anchor as it's working right now will be
unique… 

> +logger.debug('separate html output for diff of %s (size %d)', 
> anchor, len(unified_diff))
> +with file_printer(directory, filename) as new_print_func:
> +output_unified_diff_table(new_print_func, unified_diff)

So I think it would be great to crash here instead of overwrite if the file
aleardy exists. What do you think?

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


signature.asc
Description: Digital signature

Bug#806321: coreutils: please make the build reproducible (timestamps)

[Jérémy Bobbio]

Source: coreutils
Version: 8.23-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that coreutils could not be built reproducibly. The build process uses
help2man to create some of manpages.

help2man author added support for the SOURCE_DATE_EPOCH environment
variable [2] in version 1.47.1 which makes it possible to use a
pre-defined value instead of the time of the build.

As coreutils source currently contains an old version of help2man, the
attached patch will copy the version in the help2man Debian package
before running ./configure on top of setting SOURCE_DATE_EPOCH to the
date of the latest debian/changelog entry.

Once applied, coreutils can be built reproducibly in our current
experimental framework.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -u coreutils-8.23/debian/changelog coreutils-8.23/debian/changelog
--- coreutils-8.23/debian/changelog
+++ coreutils-8.23/debian/changelog
@@ -1,3 +1,14 @@
+coreutils (8.23-4.0~reproducible1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Make the build reproducible:
+- Replace in-tree help2man by the one in the help2man package. Add
+  the required Build-Depends. The in-tree help2man doesn't support
+  SOURCE_DATE_EPOCH.
+- Set SOURCE_DATE_EPOCH to the date of the latest debian/changelog entry.
+
+ -- Jérémy Bobbio <lu...@debian.org>  Thu, 26 Nov 2015 12:43:39 +0100
+
 coreutils (8.23-4) unstable; urgency=low
 
   * [33] remove chroot optimization that avoids the actual chroot when 
diff -u coreutils-8.23/debian/control coreutils-8.23/debian/control
--- coreutils-8.23/debian/control
+++ coreutils-8.23/debian/control
@@ -3,7 +3,7 @@
 Section: utils
 Priority: required
 Standards-Version: 3.9.6.0
-Build-Depends: gettext (>= 0.10.37), debhelper (>= 5.0.0), autotools-dev, dh-buildinfo, texinfo (>= 4.2), groff, dpatch, libattr1-dev [linux-any], libacl1-dev [linux-any], libselinux1-dev (>= 1.32) [linux-any], gperf, bison
+Build-Depends: gettext (>= 0.10.37), debhelper (>= 5.0.0), autotools-dev, dh-buildinfo, texinfo (>= 4.2), groff, dpatch, libattr1-dev [linux-any], libacl1-dev [linux-any], libselinux1-dev (>= 1.32) [linux-any], gperf, bison, help2man
 XS-Testsuite: autopkgtest
 
 Package: coreutils
diff -u coreutils-8.23/debian/rules coreutils-8.23/debian/rules
--- coreutils-8.23/debian/rules
+++ coreutils-8.23/debian/rules
@@ -20,6 +20,9 @@
   endif
 endif
 
+# ensure reproducible output
+export SOURCE_DATE_EPOCH = $(shell date -d "$$(dpkg-parsechangelog -SDate)" +%s)
+
 # implement no optimization build option
 CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
 LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
@@ -46,6 +46,9 @@
 	dh_testdir
 	dh_autotools-dev_updateconfig
 
+	# replace in-tree help2man by the one in Debian
+	cp /usr/bin/help2man man/help2man
+
 	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" \
 		LDFLAGS='$(LDFLAGS)' ./configure \
 		--build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \


signature.asc
Description: Digital signature

Bug#806328: xz-utils: please ship xz.pot

[Jérémy Bobbio]

Source: xz-utils
Version: 5.1.1alpha+20120614-2.1
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org, sanv...@debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that xz-utils could not be built reproducibly. One of the problem is
that the Gettext files always contain a different value for
POT-Creation-Date.

That's because the template for translations, xz.pot, is currently not
shipped as part of the source. So xgettext will be run everytime,
resulting in a new POT-Creation-Date and this slight loss of
information. This is not considered a good practice, as Santiago Vila
has explained in another bug report [2].

Upstream do ship xz.pot in its release tarballs. They also reference the
file to potential translators in README. So it would probably be better
to ship the file in Debian source.

Thanks!

 [1]: https://wiki.debian.org/ReproducibleBuilds
 [2]: https://bugs.debian.org/792687#15

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


signature.asc
Description: Digital signature

Bug#806331: xz-utils: make the selected POSIX shell stable accross build environments

[Jérémy Bobbio]

Source: xz-utils
Version: 5.1.1alpha+20120614-2.1
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org, sanv...@debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that xz-utils could not be built reproducibly.

When dash is the default shell, the configure script
m4/posix-shell.m4 will select /bin/bash as the “conforming POSIX
shell”. When bash is the default shell, /bin/sh will be selected.

The binary package currently in sid on amd64 uses /bin/bash. As bash
is currently Essential:yes (#103284), this is probably not a problem.
But I wonder if they would not be troubles if the package was built on
an environment were bash is the default shell, but later installed on a
system where /bin/dash is /bin/sh.

So for reproducibility and safety reason, it would be best if the
selected path to the shell would not depend on the build environment.

Thanks!

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

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


signature.asc
Description: Digital signature

Bug#806149: diffoscope TypeError processing openjfx/8u60-b27-4

[Jérémy Bobbio]

Control: merge 805774 806149
Control: tag 805774 pending

Mattia Rizzolo:
> Seen on rb.d.n with openjfx/8u60-b27-4 on testing (trying it on unstable
> resulted with a FTBFS of the package...)

Same problem as #805774. Fixed in Git.

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


signature.asc
Description: Digital signature

Bug#765494: dpkg-dev: dpkg-buildpackage should allow hooks to be specified via environment variable or configuration file

[Jérémy Bobbio]

Guillem Jover:
> On Wed, 2014-10-15 at 17:48:01 +0200, Axel Beckert wrote:
> > Package: dpkg-dev
> > Version: 1.17.18
> > Severity: wishlist
> 
> > according to dpkg-buildpackage's man page there seems no other way to
> > specify hooks as via the --hook-* commandline parameter.
> > 
> > If I'm right with that observation, please implement a way to specify
> > hooks environment variable or configuration file
> 
> Yes, I'm planning on adding config file supportthis during the 1.18.x
> cycle. Merging with the existing request.

This would be great.

There is currently no way to implement sanity checks on the source
tarball. As people can have different environment variables on their
system that affect which file gets ignored, it would help preventing bad
uploads.

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


signature.asc
Description: Digital signature

Bug#780280: dak: generate rejection mail for mails with expired signature

[Jérémy Bobbio]

Ansgar Burchardt:
> It would be nice if dak would generate rejection mails for uploads that
> have a valid signature, but where the signature is expired or from an
> expired key.

It would not only be nice, it would help not being trapped in very silly
situation: files uploaded with a valid signature but with an expired
key are not removed from the queue. That means teammates are unable to
sponsor the upload while waiting for the keyring to be updated.
It's not possible to remove them using dcut either as the key will still
be expired…

I would be grateful if you could properly REJECT uploads for such cases.

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


signature.asc
Description: Digital signature

Bug#802466: man refers to missing control-spec.txt

[Jérémy Bobbio]

Jean-Michel Vourgère:
> I'd like to switch virtual circuits in some cases.
> 
> I can do that interactively using vidalia "New identity" option. So I looked
> in the manual how it's done. But tor manual says "using the Tor Control
> Protocol (described in control-spec.txt)."

It's unrelated to this specific bug, but if you want to do stuff with
the Tor control protocol, I highly recommend you look at Stem, available
in the python-stem package, and its `tor-prompt` utility:
https://stem.torproject.org/tutorials/down_the_rabbit_hole.html

Running:

$ tor-prompt
SIGNAL NEWNYM

Will do the same as the “New identity” feature of Vidalia.

Another more flexible option is to pass different SOCKS
username/password to get different circuits. This is how the “New
circuit for this site” and per domain circuit isolation is done in Tor
Browser.
(This is the `IsolateSOCKSAuth` option, enabled by default.)

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


signature.asc
Description: Digital signature

Bug#801855: ongl: test strings depend on default character encoding of the build system

[Jérémy Bobbio]

Source: ognl
Version: 2.7.3-6
Severity: minor
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale

Hi!

It seems that depending on the build system default character encoding,
the non-ASCII characters in org/ognl/test/QuotingTest.java might get
mistranslated.

This also prevents ongl from building reproducibly when one locale is
ISO-8859-15 and the other is UTF-8. See:
https://reproducible.debian.net/dbd/unstable/amd64/ognl_2.7.3-6.debbindiff.html
(also supplied as attachment)

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


ognl_2.7.3-6.debbindiff.html.xz
Description: Binary data


signature.asc
Description: Digital signature

Bug#801333: retitle

[Jérémy Bobbio]

retitle 801333 diffoscope: UnicodeDecodeError with 
haskell-authenticate-oauth/1.5.1.1-4
clone 801333 -1
retitle -1 diffoscope: UnicodeDecodeError in test_text_option_with_file
severity -1 minor
thanks

Holger Levsen:
> someone just reported the same problem on irc: […]

It was not the same problem. With a quick look at the stack trace,
you can see that the error is raised in a different location of the
code. Just like when you see “Segmentation fault”, it's a bad idea to
assume that it's due to the same bug.

> ==
>  FAILURES 
> ==
> _
>  test_text_option_with_file 
> _
> 
> tmpdir = local('/tmp/pytest-bnewbold/pytest-4/test_text_option_with_file0'), 
> capsys = <_pytest.capture.CaptureFixture object at 0x7f643f784c18>
> 
> def test_text_option_with_file(tmpdir, capsys):
> report_path = str(tmpdir.join('report.txt'))
> args = ['--text', report_path, TEST_TAR1_PATH, TEST_TAR2_PATH]
> with pytest.raises(SystemExit) as excinfo:
> main(args)
> assert excinfo.value.code == 1
> out, err = capsys.readouterr()
> assert err == ''
> assert out == ''
> with open(report_path, 'r') as f:
> >   assert f.read().startswith('--- ')
> 
> tests/test_main.py:105: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> 
> self = 
> input = b'--- /home/bnewbold/diffoscope/tests/data/test1.tar\n+++ 
> /home/bnewbold/diffoscope/tests/data/test2.tar\n\xe2\x94\x9c...n the Ends of 
> Goods and Evils, or alternatively [About]\n\xe2\x94\x82 +The 
> Purposes of Good and Evil).\n\xe2\x95\xb5\n'
> final = True
> 
> def decode(self, input, final=False):
> >   return codecs.ascii_decode(input, self.errors)[0]
> E   UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 
> 102: ordinal not in range(128)
> 
> /usr/lib/python3.4/encodings/ascii.py:26: UnicodeDecodeError
> 
>  1 failed, 11 passed in 0.61 seconds 
> =
> 
> 
> [10:40] < bnewbold> this is with the diffoscope 36 package installed, running 
> the tests in a git checkout
> [10:42] < bnewbold> this is in a just-created 'sid' lxc container created on 
> a debian jessie laptop (created with lxc-create)

The test suite assumes to be run under a UTF-8 locale. That needs to be
either enforced or fixed.

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


signature.asc
Description: Digital signature

Bug#759886: debhelper: please make mtimes of packaged files deterministic

[Jérémy Bobbio]

Lunar:
> The attached patch will add a new helper `dh_fixmtimes`, largely
> inspired by `dh_fixperms`, that will change the modification time of any
> file that has been created later than the time of the latest
> debian/changelog entry to the time of the latest debian/changelog entry.

A quick update on where we stand, more than a year after the original
patch. (*time flies*)

The experimental toolchain used to test package reproducibility [1]
currently adjust mtimes in `dh_builddeb`. There was several concerns
with this approach.

Meanwhile, a patch has been written adding an option to get a similar
behavior when using GNU Tar to create an archive (#790415). The patch is
in Debian since tar/1.28-1 (although more discussions with upstream
seem to be required).

Using this new `--clamp-mtime` option, it becomes very simple to adjust
mtimes directly in `dpkg-deb`. This would be even better than changing
debhelper.

In any cases, in the future, dpkg maintainers wish to replace usage of
GNU Tar by creating the archive using internal code. This would also
make it easy to solve the problem there.

I wonder if that means it's time to reassign to dpkg-dev.

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

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


signature.asc
Description: Digital signature

Bug#719845: [PATCH] Deterministic file order for control and data archives

[Jérémy Bobbio]

Jérémy Bobbio:
> Jérémy Bobbio:
> > Jérémy Bobbio:
> > > Here are four patches based on the current master (1e059955) that will
> > > write files in deterministic order in the control and data archives.
> > > File names are sorted by forking `sort` before being piped to `tar`.
> > 
> > Attached are the patch based on current master (36eda4c1bc).
> 
> Attached are the patch based on master (1b8c20ad2).

Attached is a much simpler replacement for the earlier 3 patches:
> Subject: [PATCH 2/4] Extract the creation of the control tarball to a
> Subject: [PATCH 3/4] Rename create_control_tar() variables to more meaningful
> Subject: [PATCH 4/4] Also write control.tar.gz in deterministic order

Instead of feeding the list of control files using `find+sort`, we now
use the new `--sort=name` option that has been added in GNU Tar 1.28.
This makes making the order of control.tar deterministic a simple
one-line change.

tar/1.28-1 is already in testing. I think it's fine to ask a more recent
tar to be used when building packages with a more recent version of
dpkg-dev.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From 1c5a4b8c8b35dbec822399cce4e40b41611251df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= <lu...@debian.org>
Date: Thu, 8 Oct 2015 14:24:57 +
Subject: [PATCH] Write control.tar in a deterministic order

This requires the new `--sort=name` option available since
GNU Tar 1.28. Adding the required Depends for dpkg-dev.

Closes: #719845
---
 debian/control   | 3 ++-
 dpkg-deb/build.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 68c8f6a..c0e8e51 100644
--- a/debian/control
+++ b/debian/control
@@ -51,7 +51,8 @@ Priority: optional
 Architecture: all
 Multi-Arch: foreign
 Depends: libdpkg-perl (= ${source:Version}), bzip2, xz-utils,
- patch (>= 2.7), make, binutils, base-files (>= 5.0.0), ${misc:Depends}
+ patch (>= 2.7), make, binutils, base-files (>= 5.0.0), tar (>= 1.28)
+ ${misc:Depends}
 Recommends: gcc | c-compiler, build-essential, fakeroot,
  gnupg | gnupg2, gpgv | gpgv2, libalgorithm-merge-perl
 Suggests: debian-keyring
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 3e028fd..e3235db 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -522,7 +522,7 @@ do_build(const char *const *argv)
   ohshite(_("failed to chdir to '%.255s'"), dir);
 if (chdir(BUILDCONTROLDIR))
   ohshite(_("failed to chdir to '%.255s'"), ".../DEBIAN");
-execlp(TAR, "tar", "-cf", "-", "--format=gnu", ".", NULL);
+execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--sort=name", ".", NULL);
 ohshite(_("unable to execute %s (%s)"), "tar -cf", TAR);
   }
   close(p1[1]);
-- 
2.6.1



signature.asc
Description: Digital signature