Re: [Reproducible-builds] [Reproducible-commits] [misc] 01/01: Move timezone setting from rebuild.sh to pbuilderrc.build

[Esa Peuha]

On Sat, Feb 20, 2016 at 11:06 AM, Jérémy Bobbio <lu...@debian.org> wrote:
> Hi!
>
>> commit 420424b096c254aa5610b479fb1746e1a7bd13cb
>> Author: Esa Peuha <esa.pe...@gmail.com>
>> Date:   Sat Feb 20 09:50:46 2016 +0200
>>
>> Move timezone setting from rebuild.sh to pbuilderrc.build
>> ---
>>  prebuilder/pbuilderrc.build | 1 +
>>  prebuilder/rebuild.sh   | 1 -
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> Why is this needed?

Clarity and consistency. When I was trying to understand how
rebuild.sh worked, I found it confusing that the timezone for the
first build was specified directly on the command line, while the
timezone for the second build was in pbuilderrc.rebuild with the
locale settings. Since the first build is using pbuilderrc.build
now because of CCACHEDIR, I think it is the right place to set TZ
as well.

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

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

[Esa Peuha]

On Wed, Feb 17, 2016 at 12:57 PM, Holger Levsen  wrote:
> And then I was thinking to add another project, "develop reprotest tool", what
> other ideas do you have?

Initially I parsed that as "develop a tool to help in the case
where a protest has failed and you need to protest again" :-)
I think it would be best to spell it as "repro-test" to avoid
any further confusion.

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

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

[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.
--- presenters/html.py.orig 2015-12-16 19:42:25.0 +0200
+++ presenters/html.py  2015-12-17 15:10:53.654467937 +0200
@@ -290,9 +290,9 @@
 n = TABSIZE-(i%TABSIZE)
 if n == 0:
 n = TABSIZE
-t.write(''+''*(n-1))
+t.write('\xbb'+'\xa0'*(n-1))
 elif c == " " and ponct == 1:
-t.write('')
+t.write('\xb7')
 elif c == "\n" and ponct == 1:
 t.write('\')
 elif ord(c) < 32:
@@ -304,11 +304,11 @@
 i += 1
 
 if WORDBREAK.count(c) == 1:
-t.write('')
+t.write('\u200b')
 i = 0
 if i > LINESIZE:
 i = 0
-t.write("")
+t.write('\u200b')
 
 return t.getvalue()
 
@@ -353,7 +353,7 @@
 print_func(u'')
 else:
 s1 = ""
-print_func(u'')
+print_func(u'\xa0')
 
 if s2 is not None:
 print_func(u'%d ' % line2)
@@ -362,7 +362,7 @@
 print_func(u'')
 else:
 s2 = ""
-print_func(u'')
+print_func(u'\xa0')
 finally:
 print_func(u"\n", force=True)
 
@@ -522,7 +522,7 @@
 print_func(u"%s"
% escape(difference.source2))
 anchor = '/'.join(sources[1:])
-print_func(u" " % 
(anchor, anchor))
+print_func(u" \xb6" % 
(anchor, anchor))
 print_func(u"")
 if difference.comments:
 print_func(u"%s"
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] How to react on "the second build failed, even though the first build was successful" ?

[Esa Peuha]

On Sat, Dec 12, 2015 at 6:14 PM, Chris Lamb  wrote:
> I've lost my scrollback apologies but IIRC it wasn't anything beyond 
> acknowledgement of the issue which I felt was enough to share with Thomas to 
> prevent him thinking it was "his" issue to debug.

OK, no problem. I was just wondering if anyone had any idea what
might be causing the issue or how to debug it. From what I've seen
on my pbuilder setup, the issue seems reproducible; as long as
the package to build and its build dependencies don't change,
the build will always fail the same way. That makes me think that
it probably shouldn't be too difficult to debug, at least for
someone who knows how to debug pbuilder, but I'm afraid I don't.

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

Re: [Reproducible-builds] How to react on "the second build failed, even though the first build was successful" ?

[Esa Peuha]

On Fri, Dec 11, 2015 at 11:09 PM, Chris Lamb  wrote:

> There is some issue (discussed on IRC earlier) with the second build

Is this IRC discussion archived somewhere? If not, could you
summarize it on the mailing list?

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

Re: [Reproducible-builds] Bug#803482: ncurses: please make the build reproducible, take two

[Esa Peuha]

On Fri, Oct 30, 2015 at 10:44 PM, Sven Joachim  wrote:
> Certainly aclocal.m4 is _not_ a generated file in ncurses,

Not in the Debian package, but upstream must be generating it from
configure.in by running aclocal.

> Possible
> solutions are to run dh_strip_nondeterminism on the -dbg packages, or to
> just remove the static debug libraries (I don't think they actually
> work anyway, see #556378 for reasons).

I don't know if the static debug libraries work or not (wouldn't the
latter mean that #556378 isn't really fixed?), but I think
dh_strip_nondeterminism is probably the best option here.

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

[Reproducible-builds] Bug#803482: ncurses: please make the build reproducible, take two

[Esa Peuha]

Source: ncurses
Version: 6.0+20151024-1
Severity: wishlist
User: reproducible-builds@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi!

While ncurses 6.0+20151017-1 fixed the earlier reproducibility bug
#801864, it also introduced a reproducibility regression; now all the
lib*_g.a files in the lib*-dbg packages are affected by the umask,
uid/gid and build time of the build environment. The reason for this
regression is upstream patch 20151010, specifically the update of
CF_AR_FLAGS in aclocal.m4 (which is propagated to configure) that
causes the static libraries to be generated with "ar -curvU". I don't
really know where this should be fixed (patching aclocal.m4 doesn't
seem right since it's a generated file) so I can't suggest a patch.

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

Re: [Reproducible-builds] Weird localedef failures

[Esa Peuha]

On Sat, Oct 17, 2015 at 5:09 PM, Santiago Vila  wrote:
> The locales package is not build-essential so packages using it during
> the build need a build-depends on it.

Yes, I'm aware of that.

> For the same reason (not being build-essential), it is ok that it's
> not pre-installed in pbuilder chroot, and in fact, usually it's not.

Huh? How is the second build supposed to be able to set the locale to
fr_CH without the locales package?

> For example, it's not here:
>
> https://reproducible.debian.net/buildinfo/unstable/amd64/base-files_9.4_amd64.buildinfo

A .buildinfo file doesn't (and isn't meant to) list all installed
packages, only those that are actually needed for the build.

> If you can verify that installing the locales package fixes the error,
> then it would be clearly a "missing build-depends: locales" bug.

No, that is not the problem. If you look at

https://reproducible.debian.net/rbuild/unstable/amd64/apertium-en-ca_0.9.3~r61232-1.rbuild.log

you can see that locales is in the Build-Depends list, but pbuilder
doesn't try to install it, so either there is something wrong with
the installed packages database (which would be a bug in our pbuilder
setup) or locales is installed but some of its files are somehow
inaccessible (which would also be a bug in our pbuilder setup).

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

[Reproducible-builds] Weird localedef failures

[Esa Peuha]

Many apertium language pair packages fail with

localedef -f UTF-8 -i en_US ./debian/tmp/locale/en_US.UTF-8/
character map file `UTF-8' not found: No such file or directory
cannot read character map directory `/usr/share/i18n/charmaps': No
such file or directory

What is causing this? The directory /usr/share/i18n/charmaps is part
of package locales which should be pre-installed in pbuilder chroot.

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

[Reproducible-builds] Bug#801212: unicode-data: please make the build reproducible

[Esa Peuha]

Source: unicode-data
Version: 8.0-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi!

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

The attached patch sets TZ=UTC before calling unzip, ensuring that
the modification time of the extracted files will not vary depending
on the timezone of the build enviromnent. Once this patch is applied,
unicode-data can be built reproducibly.

 [1]: https://wiki.debian.org/ReproducibleBuilds
--- debian/rules.orig   2015-06-20 15:14:56.0 +0300
+++ debian/rules2015-10-07 16:38:16.972507828 +0300
@@ -17,8 +17,8 @@
dh_testdir
mkdir -p $(SOURCE_DIR)
mkdir -p $(STAMP_DIR)
-   (cd $(SOURCE_DIR) && unzip ../UCD.zip )
-   (cd $(SOURCE_DIR) && unzip ../Unihan.zip )
+   (cd $(SOURCE_DIR) && TZ=UTC unzip ../UCD.zip )
+   (cd $(SOURCE_DIR) && TZ=UTC unzip ../Unihan.zip )
( find $(SOURCE_DIR) -name '*txt' | while read f; do \
tr -d \\r < $$f > tmpf  ; \
mv tmpf $$f ;   \
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: Remove packages that were built reproducibly.

[Esa Peuha]

On Fri, Jun 12, 2015 at 3:59 PM, Holger Levsen hol...@layer-acht.org wrote:
 On Freitag, 12. Juni 2015, Esa Peuha wrote:

 -akuma:
 -  version: 1.9-1
 -  comments: |
 -it builds fine on jenkins.d.n, but when building locally it embeds the
 username into the manifest file -unclear, why this is hidden on
 jenkins.d.n
 -  issues:
 -- user_in_java_jar_manifest

 did you confirm this ain't the case anymore or did you blindly remove this
 package?

Sorry, I must have missed that comment. Feel free to put it back if you
think it should be preserved, but maybe we should just explicitly state
that any claim about building packages reproducibly is strictly about
building them on jenkins, and building them anywhere else may not be
reproducible; that is really all that the automated checking can do,
whether we say so or not. If we do say so, then I don't see much point
in having comments about building a package somewhere else.

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