[Reproducible-builds] TT Swift Payment Copy !!
Dear Sir, Sorry for the late reply. Please find the transfer swift copy attached. Please Confirm receipt and let us know if the order is now ready. Regards, Ashan Bachi Dear Sir, Sorry for the late reply. Please find the transfer swift copy attached. Please Confirm receipt and let us know if the order is now ready. Regards, Ashan Bachi South Africas premier free email service - www.webmail.co.za ___ 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 Builds — proof of concept successful for 83% of all sources in main
Daniel Kahn Gillmor writes (Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main): However, for packages that don't use a framework we can fix, or which use a tool that has no plans to adopt these kinds of modes upstream, I think that if tool upstreams reject (or stall) our requests for reproducible-compatible modes of operation, we should apply such patches ourselves. But I hope this will be very rare. Certainly we should be willing to backport patches from upstreams' development versions to testing (when testing isn't frozen). Your concerns about bit-rot are legitimate, though; if a piece of the toolchain is where a proper fix belongs, and all the dependent packages are working around it now, perhaps we could (a) make sure that the proper fix bug report is filed in the bts against the piece of the toolchain, and that it is marked as affects: with all the packages that are currently working around it. I would generally very much prefer to fix things at the root. That is less effort overall. It may mean that this specific goal is achieved less quickly, but if we spend less effort achieving this goal we can spend that effort on other goals that are also important. We ought to be able in any case to get very far within a single Debian release cycle. Basically, i think the BTS has the semantics to support keeping track of these dependent issues so that we end up with clean long-term fixes, while we can use our packager's discretion to implement the shorter-term workarounds, annoying though they may be. what do you think? Also, less involvement with annoying workarounds means less annoyance and therefore more fun and therefore more work and faster progress. This does depend of course on the interactions between different maintainers on these subjects also being fun and constructive. If they aren't then a workaround may be better. (IMO such maintainers ought to be replaced. We have too many who are hard to work with. But the only sensible way to get rid of them, or even just to get a needed patch accepted, is to ask the Technical Committee; and the TC has shown itself to be extremely reluctant to intervene.) Ian. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#778571: sbuild: predictible build location for reproducible builds
Package: sbuild
Version: 0.65.0-1
Severity: wishlist
Tags: patch
Thanks for maintaining sbuild!
In order to use sbuild for reproducible builds, the build dir needs to
be consistent across rebuilds, but sbuild currenty generates a
randomly named build dir.
The following proof-of-concept patch does this by setting the build
dir to /build/PACKAGE-VERSION rather than /build/PACKAGE-XX:
From 15b77405a67faaea7bc3974a4e7a3862620d0b42 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian vagr...@debian.org
Date: Fri, 13 Feb 2015 23:18:23 -0800
Subject: [PATCH 1/2] Make predictible build dir location based on the package
version.
---
lib/Sbuild/Build.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 155e4fc..5149a8a 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -396,8 +396,8 @@ sub run_chroot_session {
# TODO: Don't hack the build location in; add a means to customise
# the chroot directly. i.e. allow changing of /build location.
$self-set('Chroot Build Dir',
- tempdir($self-get('Package') . '-XX',
- DIR = $session-get('Location') . /build));
+ $session-get('Location') . /build/ .
$self-get('Package') . - . $self-get('Version'));
+ mkdir $self-get('Chroot Build Dir');
$self-set('Build Dir', $session-strip_chroot_path($self-get('Chroot
Build Dir')));
--
2.1.4
This patch is really only a small step forward, making the build dir
consistent only when building with sbuild. Ideally, the build dir
should be set to /usr/src/debian/PACKAGE-VERSION (or some other widely
agreed upon dir) so that builds would be reproducible if built with
other tools such as pbuilder using the same build dir.
Making the build dir configurable might also help...
live well,
vagrant
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing'), (120, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sbuild depends on:
ii adduser 3.113+nmu3
ii apt-utils 1.0.9.6
ii libsbuild-perl 0.65.0-1
ii perl5.20.1-5
ii perl-modules5.20.1-5
Versions of packages sbuild recommends:
ii debootstrap 1.0.66
ii fakeroot 1.20.2-1
Versions of packages sbuild suggests:
pn deborphan none
ii wget 1.16-1
-- no debconf information
signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#778563: differing header files
Source: witty Version: 3.3.3+dfsg-4.1 User: reproducible-builds@lists.alioth.debian.org Hi! While working on Debian's “reproducible builds” effort [1], we have noticed that witty doesn't build reproducibly [2]. There is a difference in the header file /usr/include/Wt/WConfig.h. Depending on the build, some macros are defined or not: On one build it had the following content: #define WT_STATIC #define WTDBO_STATIC #define WTDBOPOSTGRES_STATIC #define WTDBOSQLITE3_STATIC #define WTDBOFIREBIRD_STATIC #define WTDBOMYSQL_STATIC #define WTHTTP_STATIC #define WT_EXT_STATIC #define WT_EXT_STATIC While on another build it contained the following lines: /* #undef WT_STATIC */ /* #undef WTDBO_STATIC */ /* #undef WTDBOPOSTGRES_STATIC */ /* #undef WTDBOSQLITE3_STATIC */ /* #undef WTDBOFIREBIRD_STATIC */ /* #undef WTDBOMYSQL_STATIC */ /* #undef WTHTTP_STATIC */ /* #undef WT_EXT_STATIC */ /* #undef WT_EXT_STATIC */ The build environments differed in user/group, hostname, time, locale, but the toolchain was the same. The generated header should always be identical with the same toolchain. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds [2]: https://reproducible.debian.net/witty signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#778570: sbuild: ignore .buildinfo files in .changes
Package: sbuild
Version: 0.65.0-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Thanks for maintaining sbuild!
When using dpkg from the reproducible builds toolchain, it generates a
.buildinfo file in the .changes file:
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#dpkg
When .buildinfo files are present in the .changes, sbuild treats it as
an attempted build, rather than a successful build; it appears to be
treating the .buildinfo file as a .deb and tries to unpack it:
ltsp_5.5.4-4~20150213~1_amd64.buildinfo
───
dpkg-deb: error:
`/«CHROOT»/«BUILDDIR»/ltsp_5.5.4-4~20150213~1_amd64.buildinfo' is not a debian
format archive
dpkg-deb: error:
`/«CHROOT»/«BUILDDIR»/ltsp_5.5.4-4~20150213~1_amd64.buildinfo' is not a debian
format archive
The following patch should fix/workaround this:
From 8468411099b8ec28641df015742784b63b98b573 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian vagr...@debian.org
Date: Fri, 13 Feb 2015 23:51:11 -0800
Subject: [PATCH 2/2] Ignore .buildinfo files produced by reproducible builds.
---
lib/Sbuild/Build.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 5149a8a..f15e94a 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1768,6 +1768,8 @@ sub build {
foreach (@debcfiles) {
my $deb = $build_dir/$_;
next if $deb !~ /(\Q$host_arch\E|all)\.[\w\d.-]*$/;
+ # ignore .buildinfo files produced by reproducible builds.
+ next if $deb =~ /\.*buildinfo$/;
$self-log_subsubsection($_);
if (!open( PIPE, dpkg --info $deb 21 | )) {
--
2.1.4
live well,
vagrant
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing'), (120, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sbuild depends on:
ii adduser 3.113+nmu3
ii apt-utils 1.0.9.6
ii libsbuild-perl 0.65.0-1
ii perl5.20.1-5
ii perl-modules5.20.1-5
Versions of packages sbuild recommends:
ii debootstrap 1.0.66
ii fakeroot 1.20.2-1
Versions of packages sbuild suggests:
pn deborphan none
ii wget 1.16-1
-- no debconf information
signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Patches for sbuild reproducible builds
On 2015-02-16, Holger Levsen wrote:
On Samstag, 14. Februar 2015, Vagrant Cascadian wrote:
One patch sets the build dir to a static location based on the package
version, rather than a tempdir with a random string.
The other patch ignores .buildinfo files in the .changes when displaying
package contents. Without it, the build status gets set to attempted
and is treated as a failed build:
cool! I think it would be good if you could file a wishlist bug against
sbuild
(please add support for reproducible building of packages with sbuild) and
attach the patches there, so they do get lost.
Ok, I'll submit bugs about it so that they do *not* get lost. :)
the current setup on jenkins.d.n just uses pbuilder twice. Maybe we should
use
sbuild once and pbuilder once? Could you help us with patches for that too? I
at least have no clue about sbuild whatsoever ;-) We'd need to use our custom
repo anyway, so using an sbuild rebuild plus your two patches is rather
trivial...
The patch that configures the build dir would have to be rewritten for
that to work; sbuild seems to hard-code /build/ in a number of places ,
rather than the proposed /usr/src/debian/PACKAGE-VERSION; I'm not sure
what directory pbuilder is configured to use.
Also, pbuilder and sbuild would need to ensure the same exact package
set from build dependencies; there are various different dependency
resolvers which might result in differences that could cause
unreproducibility...
Could also add a third (and/or fourth) build with sbuild, to catch
issues where a package is rebuildable with pbuilder or sbuilder, but
doesn't produce consistant results when built once with pbuilder and
once with sbuild...
git clone ssh://git.debian.org/git/qa/jenkins.debian.net.git and then check
bin/reproducible_build.sh line 193 and 207 to see how pbuilder is used.
Using sbuild once instead should be trivial, no? ;-)
With the above two issues (and perhaps other undiscovered issues) fixed,
it should be as simple as replacing:
pbuild --build ... --distribution sid ${SRCPACKAGE}_*.dsc
with:
sbuild --chroot sid ${SRCPACKAGE}_*.dsc
With appropriately configured sbuild/schroot chroots.
live well,
vagrant
p.s. not (yet) subscribed to list, so if you need me to respond, please
CC me.
signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Patches for sbuild reproducible builds
Hi, Quoting Vagrant Cascadian (2015-02-16 21:01:18) Also, pbuilder and sbuild would need to ensure the same exact package set from build dependencies; there are various different dependency resolvers which might result in differences that could cause unreproducibility... this has been taken care of by the srebuild wrapper which will take a buildinfo file and reproduces exactly that environment. You can find it in the reproducible sbuild git. cheers, josch signature.asc Description: signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Preliminary review of dpkg-genbuildinfo
Daniel Kahn Gillmor: On Fri 2015-02-13 03:36:20 -0500, Hans-Christoph Steiner wrote: I think it would be much simpler to just have the single package signature that is embedded in the package file itself, like Android APKs and Java JARs. Since the package is built reproducibly, anyone who builds it can just copy the canonical signature into their copy of the package they just built, and it'll match the sha512sum of the signed apt metadata. It seems like you're saying everyone will be able to agree on which signing authority is canonical for any given package. I'm not convinced that's the case. The big question there is determining the where the canonical signature happens. It seems like it should be the official Debian build process, since it is the only process guaranteed to be the same Even though i'm personally likely to treat Debian as the canonical source i care about, i don't want it to be that way. I would like Debian to be able to be a downstream as well as an upstream (see the work feeding back into debian from ubuntu, for example); if a .deb package can contain an internal signature, and i'm looking at a given .deb in isolation on my debian system, i want to see it signed *by debian*, not by whoever happened to produce it first. Otherwise, it's not clear to me that the embedded signature is useful to me as an end user at all. Another question is whether dpkg checks whether the signers match when upgrading, like the Android model (a package can only be upgraded by another package signed by the same key). This would be nice, but seems optional and hard to do in Debian. Maybe this is the question we need to answer to move the discussion forward to make sure we're taking the desire for embedded signatures into account when thinking about reproducible .debs: how exactly do we expect an embedded signature to be used/evaluated? by who, and in what context? I think the .buildinfo file is useful, but for a separate process. It should be the canonical file for running a reproducible build. I'm not sure what this means. I'd be very happy if *all* of my debian packages were reproducible builds, and i could have a way of verifying it. I'd consider that more valuable than knowing that all my .debs were signed by any individual authority. So if we're really talking about a tradeoff between signed buildinfo files and signed packages, i'd certainly prefer signed buildinfo files. But my proposal was an attempt to let people have both, without forcing the entire ecosystem to agree on who is a canonical authority for package X, without whom a reproducible package is impossible --dkg I think this topic is far too vast with far too many dependencies to really have a useful discussion on without a full time, dedicated team. Since that seems highly unlikely in the near future, we need to break it down into chunks of work that we can achieve with the time and resources we actually have. So we need to focus on drilling down to what is the simplest useful form of package signing that will cause the least amount of problems when we decide to change how package signing works. This means we get a prototype out as soon as possible, and we can learn a lot from that. I think that's pretty easy to do, something like this: * make dpkg optionally check package sigs, and refuse to install on bad sig * use apt signing model: signatures verified from the apt key ring * signing can start happening in the build tools, by the uploader * start work towards getting the Debian built/apt infrastructure signing .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindexsearch=0x9F0FE587374BBE81 ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [Debian Wiki] Update of ReproducibleBuilds/TimestampsInClassFilesCompiledByGroovy by ReinerHerrmann
Debian Wiki:
New page:
Java classes (.class) that were compiled by the groovy compiler (groovyc)
contain timestamps.
See also: [[http://thread.gmane.org/gmane.comp.lang.groovy.user/39306/|Thread
on groovy-user mailing list]]
= Detection =
The diff of .class files contains the string
{{{__timeStamp__XXX_neverHappenX}}}.
= Workaround =
None yet.
= Solution =
None yet.
I think this has been fixed upstream:
http://jira.codehaus.org/browse/GROOVY-6308
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] TT Swift Payment Copy !!
___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] TT Swift Payment Copy !!
___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
