[Reproducible-builds] diffoscope is marked for autoremoval from testing

[Debian testing autoremoval watch]

diffoscope 59 is marked for autoremoval from testing on 2016-09-20

It (build-)depends on packages with these RC bugs:
826300: fpc: fp-compiler not installable on powerpc since glibc 2.23


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

[Reproducible-builds] reprotest is marked for autoremoval from testing

[Debian testing autoremoval watch]

reprotest 0.2 is marked for autoremoval from testing on 2016-09-20

It (build-)depends on packages with these RC bugs:
826300: fpc: fp-compiler not installable on powerpc since glibc 2.23


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

[Reproducible-builds] Bug#835055: ghc test regression as provided .hi files are to tightly bound to the actual environment

[Chris Lamb]

tags 835055 + pending
thanks

> This is particularly a problem for future packaging of a version outside
> of debian (foreign distro) as this tests will always fail leading to an
> un-packagable state.

Thanks for reporting. We can at least detect this and skip the the tests
with a message (pushed).

I would agree it will — eventually — skip on "all" systems but, for now:

 a) It won't /fail/ outside of the Debian unstable right now.

 b) It's better than no tests for this module (!)

 c) Keeping track on the code coverage will mean we will be prompted to
find another solution in the future.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

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

[Reproducible-builds] Bug#835055: ghc test regression as provided .hi files are to tightly bound to the actual environment

[Levente Polyak]

Package: diffoscope

The GHC tests are too tightly bound to a very specific ghc version (in
this case ghc 7.1.0.3) and the test will fail if the HI-version
mismatche (hi magic in this case is 33214052).
In such case the diffoscope internal will select a fallback
FilesystemComperator instead of the HiFile one.

Introduced in commit 867ecde1

This is particularly a problem for future packaging of a version outside
of debian (foreign distro) as this tests will always fail leading to an
un-packagable state.

Additionally I don't think that this is very practical in its nature
because of the way haskell compiled .hi files work. They contain hashes
of the used modules (like in this case System.Posix.Time and
System.Posix.Process).
If those values change, the test will fail again (where maybe even the
matching ghc 7.1.0.3 is indeed installed).
Maybe it should be considered to do this diffoscope unit tests in a
different way (or drop it).

==
FAILURES
===
_
test_identification
_

haskell1 = <
/home/anthraxx/Projects/external/diffoscope/tests/data/test1.hi>

@skip_unless_tools_exist('ghc')
def test_identification(haskell1):
>   assert isinstance(haskell1, HiFile)
E   assert isinstance(<
/home/anthraxx/Projects/external/diffoscope/tests/data/test1.hi>, HiFile)

tests/comparators/test_haskell.py:31: AssertionError
__
test_diff
__

differences = []

@skip_unless_tools_exist('ghc')
def test_diff(differences):
with open(data('haskell_expected_diff')) as f:
expected_diff = f.read()
>   assert differences[0].unified_diff == expected_diff
E   IndexError: list index out of range

tests/comparators/test_haskell.py:44: IndexError


cheers,
Levente

___
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#763822: Moving towards buildinfo on the archive network

[Ximin Luo]

Ximin Luo:
> Signatures provide a way to for us to aggregate public trust on binaries that
> don't build themselves. So it's important to have multiple and *very direct*
> meanings of what-is-being-signed, to avoid a transitive-trust situation.
> 

I sent this in a rush; better version:

Signatures provide a way to for us to aggregate public trust on binaries that
people don't build themselves. So it's important to have multiple and *very
direct* meanings of what-is-being-signed, strongly associated to the signer,
to avoid a transitive-trust situation.

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

Re: [Reproducible-builds] Bug#763822: Moving towards buildinfo on the archive network

[Ximin Luo]

Jonathan McDowell:
> On Sun, Aug 21, 2016 at 04:01:00PM +, Ximin Luo wrote:
>> You have this backwards.
>>
>> "Being able to verify individually who build each of the packages I'm
>> running"
>>
>> is *exactly* what is required to *not* have to 
>>
>> "attribute trust of *all* of the people who packaged something I have
>> installed."
>>
>> and that is one major (probably the main) goal of R-B.
>>
>> Now that I point this out - do you agree,
> 
> No. What lets me not care about who actually built the packages and have
> to attribute trust to them is that I have the build information, which
> allows me to verify I get exactly the same output from the provided
> source. [..]
> 

OK, I explained things badly. For you to actually strictly verify everything,
yes you would have to build everything yourself. But then you should just run a
source-based distribution and forget about other people's binaries completely.

We do also want to provide quite strong security properties, even for people
that don't want to build every single binary for themselves. That is one very
key point of R-B. If we assume everyone will check reproducibility of their own
binaries, this renders the whole exercise of R-B pointless.

Thanks for pointing this out, so that I explain it better. I'm completely at
fault here.

Signatures provide a way to for us to aggregate public trust on binaries that
don't build themselves. So it's important to have multiple and *very direct*
meanings of what-is-being-signed, to avoid a transitive-trust situation.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

Re: [Reproducible-builds] Moving towards buildinfo on the archive network

[Ximin Luo]

Jonathan McDowell:
> On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote:
>> I have trouble imagining what could make Buildinfo.tgz hard, but make
>> Buildinfo.xz easy - could you explain this in more detail, please?
> 
> Debian's archive information is largely stored within a database; things
> like the Packages and Contents files are generated each archive run from
> this database, rather than incrementally updating a file. It is easy to
> generate a Buildinfo.xz file from information contained within the
> database (I have some proof-of-concept code locally that does the
> beginnings of this), but generating a tar file like you are describing
> is either a case of storing each .buildinfo in the database and
> generating the tar each run, or adding and deleting files to an existing
> tarball. It seems overly intensive and doesn't really seem to scale.
> 
>> Regarding the OpenPGP signatures, they are vital - but I also see no
>> need to strip them in your model. From the point-of-view of the FTP
>> archive, there is no immediate need to read or understand the contents
>> of the buildinfo file. [*] It's just a dumb data blob, it shouldn't
>> matter to Debian whether it's clearsigned or not.
> 
> What I was trying to do with my proposal was turn it from being a dumb
> data blob which wasn't easily mapping to the Debian infrastructure, to
> something where almost all the information (everything except the actual
> signature from the original builder) could be provided alongside the
> binaries themselves, enabling people to have what they required to
> confirm they could reproduce the builds themselves. *I* think this is
> incredibly useful, even if it doesn't achieve everything possible with
> reproducible-builds, and I also think that it would provide a sound
> basis for another Debian service (perhaps under debian.net to start
> with) where multiple builders (starting with the original builder) would
> be able to upload their claims, based directly off the buildinfo
> information from the archive network. Yes, that's probably an extra
> step for the original builder, but it also (to me) seems to be more
> flexible and a stronger statement as multiple independent builders can
> all confirm things in a single place.
> 
> It sounds like this isn't compatible with where reproducible-builds is
> heading though, so apologies for the noise.
> 

I don't mean to suggest a database is not useful. I thought I was talking to
ftp-masters through you, so I wanted to be very clear about the security
properties we're aiming for, and get common understanding about that first.

But I'm not sure why you say it's incompatible - could you not also store the
detached signatures within the database, and generate the original file
(including signature) from this and the other information? The signatures are
much smaller than the rest of the file.

In fact, we do indeed have longer-term plans for Debian infrastructure to look
into this data and not turn it into a data blob - for example, buildds
themselves could try to reproduce a given buildinfo uploaded by a DD, and send
alerts about packages that can't be reproduced. (I hinted at this by the "more
advanced" behaviours I mentioned in my previous email.) But I wanted to start
off with a simple yet strongly-secure model first.

What I described is not supposed to contradict the ability for users to
"confirm they could reproduce the builds themselves". As I mentioned, a
majority use-case is to allow others to download "all the buildinfo files for a
given binary package", then they check this locally.

Perhaps the confusion is in the suggestion of a single Buildinfo.tgz. Let me
disclaim this for now - I wasn't present for the discussions around why all of
this information needs to be in one file, it actually does *not* make sense to
me. An obvious alternative is to cat all the buildinfo files for a given source
package, into one $source-$version.buildinfos.gz file and store this in pool/.
This would also make it easy to lookup buildinfo files for a given binary
later. Could someone tell me why this approach isn't suitable?

Now going back to "users confirming rebuilds":

The reason why I started off with this high-security dumb-data-blob approach is
to make the security arguments and reasoning very simple and obvious, so it's
harder to accidentally weaken or subvert it in the future. Debian isn't even
involved in the security logic - it's purely the end-user verifier program.

Another benefit of signatures, is that it gives you more information, in the
cases where you might not want to build it yourself (e.g. very large programs).
If you strip this information, then only Debian is "attesting" to a particular
hash (which it didn't even build). If you keep this information, then you can
aggregate multiple peoples' attempts to build a given binary.

Eventually we could have buildinfo-only uploads, just like we have binary-only
or source-only uploads. Then for important binaries 

Re: [Reproducible-builds] Bug#763822: Moving towards buildinfo on the archive network

[Jonathan McDowell]

On Sun, Aug 21, 2016 at 04:01:00PM +, Ximin Luo wrote:
> Jonathan McDowell:
> > On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote:
> >> Note that the builder is a *distinct entity* from the distribution.
> >> It's important to keep the *original* signature by B on C. It breaks
> >> our security logic, to strip the signature and re-sign C using (e.g.)
> >> the Debian archive release keys - because the entity in charge of this
> >> release key is not the one that actually performed the build. Doing
> >> this, would allow malicious builders to re-attribute their misdeeds to
> >> look like it's the fault of Debian.
> > 
> > Debian already does this in the context of the fact that Package files
> > etc are signed by the archive key. It's possible to go and grab the .dsc
> > file to see who did the file build, but day-to-day no one is using these
> > to verify the binaries they receive. I care more that Debian stands
> > behind the packages I download than being able to verify individually
> > who build each of the packages I'm running - there's no meaningful way I
> > can attribute trust to *all* of the people who packaged something I have
> > installed.
> > 
>
> You have this backwards.
> 
> "Being able to verify individually who build each of the packages I'm
> running"
> 
> is *exactly* what is required to *not* have to 
> 
> "attribute trust of *all* of the people who packaged something I have
> installed."
> 
> and that is one major (probably the main) goal of R-B.
> 
> Now that I point this out - do you agree,

No. What lets me not care about who actually built the packages and have
to attribute trust to them is that I have the build information, which
allows me to verify I get exactly the same output from the provided
source. The signatures over these do not allow me to trust the binaries
I receive in any additional fashion. If I trust the statement "I built
package  using source  and build information " from an
individual, without doing any verification that this is true, it doesn't
give me much over "I built package  using source ". I have to do
the build myself to ensure what I have been told is true.

Where, to me, signatures become more interesting is when it is possible
for multiple different people to attest they build a set of source using
the same information and got exactly the same output - but only if I
actually trust all the entities who are doing that signing.

> and does it change your mind on anything you previously said?

Fundamentally I still think build information without the signature of
the builder is information that it would be useful to have accompanying
the Debian archive. It seems you do not believe this is worth anything
as it loses the signature which provides a chain back to the origin. I
do not, at present, have a good solution for the extra information and
conditions you want within the context of the Debian archive.

J.

-- 
] http://www.earth.li/~noodles/ [] 101 things you can't have too much  [
]  PGP/GPG Key @ the.earth.li   []of : 49 - Bandwidth. [
] via keyserver, web or email.  [] [
] RSA: 4096/0x94FA372B2DA8B985  [] [

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

[Reproducible-builds] Bug#835053: kxmlgui: please make the build reproducible

[Chris Lamb]

Source: kxmlgui
Version: 5.25.0-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: uname
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that kxmlgui could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2016-08-21 18:19:22.645111083 
+0100
@@ -0,0 +1,13 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-21
+
+--- kxmlgui-5.25.0.orig/src/config-xmlgui.h.cmake
 kxmlgui-5.25.0/src/config-xmlgui.h.cmake
+@@ -1,5 +1,5 @@
+ #define XMLGUI_DISTRIBUTION_TEXT "${XMLGUI_DISTRIBUTION_TEXT}"
+-#define XMLGUI_COMPILING_OS "${CMAKE_SYSTEM}"
++#define XMLGUI_COMPILING_OS "Generic"
+ #define XMLGUI_COMPILER_VERSION "${XMLGUI_COMPILER_VERSION}"
+ 
+ #define CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}"
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2016-08-21 18:19:19.885060733 +0100
@@ -0,0 +1 @@
+reproducible-build.patch
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#835051: sheepdog: please make the build reproducible

[Chris Lamb]

Source: sheepdog
Version: 0.8.3-4.1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that sheepdog could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.diff1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.diff2016-08-21 18:17:02.874561258 
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-21
+
+--- sheepdog-0.8.3.orig/man/Makefile.am
 sheepdog-0.8.3/man/Makefile.am
+@@ -11,7 +11,7 @@ EXTRA_DIST   = sheep.8.in dog.8.in sheepf
+ %.8: %.8.in Makefile $(top_srcdir)/script/gen_man.pl $(top_builddir)/%/$*
+   rm -f $@-t $@
+   @sed \
+-  -e "s#@DATE@#`date '+%Y-%m-%d'`#g" \
++  -e "s#@DATE@#$$(date --utc --date 
"@$${SOURCE_DATE_EPOCH:-$$(date +%s)}" "+%Y-%m%d")#g" \
+   -e "s#@OPTIONS@#$(shell $(top_srcdir)/script/gen_man.pl 
$(top_builddir)/$*/$*)#g" \
+   $< > $@-t
+   mv $@-t $@
--- a/debian/patches/series 2016-08-21 18:09:34.798385593 +0100
--- b/debian/patches/series 2016-08-21 18:16:46.254258039 +0100
@@ -1,3 +1,4 @@
 define_EFD_SEMAPHORE_ifnone.diff
 subdir-objects.diff
 sorted_bash_completion.diff
+reproducible-build.diff
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] diffoscope 59 MIGRATED to testing

[Debian testing watch]

FYI: The status of the diffoscope source package
in Debian's testing distribution has changed.

  Previous version: 56
  Current version:  59

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

Re: [Reproducible-builds] Moving towards buildinfo on the archive network

[Ximin Luo]

Jonathan McDowell:
> On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote:
>> Note that the builder is a *distinct entity* from the distribution.
>> It's important to keep the *original* signature by B on C. It breaks
>> our security logic, to strip the signature and re-sign C using (e.g.)
>> the Debian archive release keys - because the entity in charge of this
>> release key is not the one that actually performed the build. Doing
>> this, would allow malicious builders to re-attribute their misdeeds to
>> look like it's the fault of Debian.
> 
> Debian already does this in the context of the fact that Package files
> etc are signed by the archive key. It's possible to go and grab the .dsc
> file to see who did the file build, but day-to-day no one is using these
> to verify the binaries they receive. I care more that Debian stands
> behind the packages I download than being able to verify individually
> who build each of the packages I'm running - there's no meaningful way I
> can attribute trust to *all* of the people who packaged something I have
> installed.
> 

You have this backwards.

"Being able to verify individually who build each of the packages I'm running"

is *exactly* what is required to *not* have to 

"attribute trust of *all* of the people who packaged something I have 
installed."

and that is one major (probably the main) goal of R-B.

Now that I point this out - do you agree, and does it change your mind on 
anything you previously said?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

Re: [Reproducible-builds] Moving towards buildinfo on the archive network

[Jonathan McDowell]

On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote:
> Jonathan McDowell:
> > Having been impressed by the current status of reproducible builds
> > and the fact it looks like we're close to having the important
> > pieces in Debian proper, I have started to have a look at how I
> > could help out with this bug. I've done some poking around in the
> > dak code, and think I have a vague idea of how to achieve what I
> > think is wanted.
> > 
> > First, it is helpful to describe what I think is wanted. What I
> > think we need is the archive network to have, alongside the binary
> > packages it contains, details of exactly how to build those
> > binaries. This is, I believe, the information contained in the
> > .buildinfo files.
> > 
> In our newest discussions, this purpose is secondary. The primary
> purpose of buildinfo files is to record what *one particular builder
> actually did in order to produce some output*. Or, equivalently:
>
>   | A buildinfo file, abstractly, is a *claim* C by some builder entity B that
>   | "I executed process P with env/input I to produce output results R".
>
> This latter form is slightly easier to reason about, in terms of
> security properties. We securely bind the claim C (the contents of the
> buildinfo file) to the entity B using a cryptographic signature.

I think the problem here is it's not clear (on either side) who "we" or
"our" means. Different people want different things from reproducible
builds, or have different opinions about relative priorities.

As a *minimum* I think distributions should be providing the information
of how a particular binary was produced. I suppose what it sort of maps
to is "I executed process P with env/input I to produce output results
R" (though, of course, distros already provide R; that's the binaries
shipped). You've used all the letters I might want to refer to it by, so
let's call it Z.

The claim, C, is a signature over Z by B. It's useful extra information,
but it's not required for me to ensure that the source I have build the
binaries I have.

> Note that the builder is a *distinct entity* from the distribution.
> It's important to keep the *original* signature by B on C. It breaks
> our security logic, to strip the signature and re-sign C using (e.g.)
> the Debian archive release keys - because the entity in charge of this
> release key is not the one that actually performed the build. Doing
> this, would allow malicious builders to re-attribute their misdeeds to
> look like it's the fault of Debian.

Debian already does this in the context of the fact that Package files
etc are signed by the archive key. It's possible to go and grab the .dsc
file to see who did the file build, but day-to-day no one is using these
to verify the binaries they receive. I care more that Debian stands
behind the packages I download than being able to verify individually
who build each of the packages I'm running - there's no meaningful way I
can attribute trust to *all* of the people who packaged something I have
installed.

> Now back to the "secondary" purpose:
> 
> Using these information "B claims C", other reproduction programs
> (that we're also developing) can attempt to actually reproduce the
> binaries described. It would do this, by (1) reading the buildinfo
> file (2) recreating _some_ of the environment stored in C, and (3)
> executing the process, and see if it gives R.

You don't need the signature to validate the reproducibility.

> The "_some_" in clause (2) is currently up-for-debate, but the
> important thing is that this can be changed in the future *without
> affecting already-produced buildinfo files*. It may even well be the
> case that in the future we'd want to support different values for
> "_some_" for a given reproduction tool.
> 
> The main point is that, this is not a concern of the producer nor
> distributor of the buildinfo files. I.e.: you guys (the FTP team) only
> have to care about making these signed-claims available to be
> downloaded by users, and it is up to the users to run a tool that
> "interprets" these claims for purposes such as actually attempting
> reproduction of a binary.

To clarify: I am not a member of the FTP team and do not claim to
represent them. I am a DD who was present at the DebConf talk about
reproducible builds, was impressed by how far it's come, and asked how I
could help get what was missing and still required into Debian.

> In this way, we achieve full end-to-end security properties
> (verifiability of build) between the producers (builders) and
> consumers (users). Distributors only need to care about availiability,
> they take no part in the security (except for the case where they are
> also a builder, as noted already).

I think I take a less strict view on this, which may be where some of
the disconnect comes from. I care that Debian stands behind it's builds.
I'd like the builder claims to be available (and my original mail did
talk about the fact I didn't think I 

Re: [Reproducible-builds] Bug#834993: oss4: please make the build reproducible

[Reiner Herrmann]

On Sun, Aug 21, 2016 at 01:37:47PM +0200, Reiner Herrmann wrote:
> The attached patch fixes several issues:

Sorry, forgot to attach the patch.
diff --git a/debian/control b/debian/control
index be2fd60..ebadea0 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Uploaders: Sebastien NOEL ,
Benda Xu 
 Build-Depends: cdbs,
debhelper (>= 9),
+   tar (>= 1.28),
dkms [linux-any],
gawk,
libgtk2.0-dev,
diff --git a/debian/create-ma-tree.sh b/debian/create-ma-tree.sh
index 34ae919..1232e00 100644
--- a/debian/create-ma-tree.sh
+++ b/debian/create-ma-tree.sh
@@ -45,7 +45,7 @@ for i in ac97 audio midi midi_stubs mixer osscore remux sndstat uart401 vmix_cor
 	[ -d "$i" ] || continue
 	NAME="`basename $i`"
 	pushd "$i"
-	for j in `ls *.c`; do
+	for j in `LC_ALL=C ls *.c`; do
 		SOURCES="$SOURCES $j"
 		SRCCOUNT=$((SRCCOUNT + 1))
 	done
@@ -90,7 +90,7 @@ for i in kernel/drv/*; do
 	pushd $i
 	SOURCES=""
 	SRCCOUNT=0
-	for j in `ls *.c`; do
+	for j in `LC_ALL=C ls *.c`; do
 		if [ "$j" = "$NAME.c" ]; then
 			mv $j ${NAME}driver.c
 			SOURCES="$SOURCES ${NAME}driver.c"
diff --git a/debian/patches/102_use_system_txt2man.patch b/debian/patches/102_use_system_txt2man.patch
index e790a34..06d2bda 100644
--- a/debian/patches/102_use_system_txt2man.patch
+++ b/debian/patches/102_use_system_txt2man.patch
@@ -1,6 +1,11 @@
 oss-v4.2-build2006-src-gpl/setup/Linux/build.sh.orig	2012-02-18 18:53:51.707280520 +0100
-+++ oss-v4.2-build2006-src-gpl/setup/Linux/build.sh	2012-02-18 18:54:01.955280417 +0100
-@@ -8,7 +8,7 @@
+--- a/setup/Linux/build.sh
 b/setup/Linux/build.sh
+@@ -4,11 +4,11 @@
+ 
+ if gawk '' >/dev/null
+ then
+-   TXT2MAN=$SRCDIR/setup/txt2man
++   TXT2MAN=/usr/bin/txt2man
  else
 echo "No gawk found. Using lesser replacement" >&2
 cc -o txt2man origdir/setup/txt2man.c
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..b0f6ad9
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,11 @@
+--- a/setup/setupdir.sh
 b/setup/setupdir.sh
+@@ -200,7 +200,7 @@
+ 
+ touch .depend
+ 
+-if date -u +%Y%m%d%H%M > build.id.new 2>/dev/null
++if date -u +%Y%m%d%H%M -d "@${SOURCE_DATE_EPOCH:-$(date +%s)}" > build.id.new 2>/dev/null
+ then
+ 	rm -f build.id
+ 	mv build.id.new build.id
diff --git a/debian/patches/series b/debian/patches/series
index e219784..3d89d4d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -19,3 +19,4 @@
 #generic_srccconf.patch (seems completely broken to me)
 501_linux_version.patch
 502_linux_io.patch
+reproducible-build.patch
diff --git a/debian/rules b/debian/rules
index cde4f26..f2981f4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,7 +30,7 @@ stamp-build-oss4:
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 	# TODO: rewrite upstream's 'build.sh' from scratch
 	cat `find $(CURDIR)/build-tree/oss-build/kernel/drv -name .devices`| grep -v '^#' \
-	| sort | grep -v '^osscore' | grep -v '^oss_audiocs' | grep -v '^oss_sadasupport' \
+	| LC_ALL=C sort | grep -v '^osscore' | grep -v '^oss_audiocs' | grep -v '^oss_sadasupport' \
 	> $(CURDIR)/build-tree/oss-build/prototype/usr/lib/oss/etc/devices.list
 
 	for n in `cat $(CURDIR)/build-tree/oss-build/prototype/usr/lib/oss/etc/devices.list | cut -f 1 | uniq` ; do \
@@ -57,7 +57,7 @@ build/oss4-source:: stamp-source-oss4
 	cp debian/copyright build-tree/modules/oss4/debian/
 	cp debian/changelog build-tree/modules/oss4/debian/
 	chmod 755 build-tree/modules/oss4/debian/rules
-	cd build-tree/ &&  tar cjf oss4.tar.bz2 modules/
+	cd build-tree/ &&  tar --mtime="@$(SOURCE_DATE_EPOCH)" --sort=name --mode=go=rX,u+rw,a-s -cjf oss4.tar.bz2 modules/
 
 build/oss4-dkms:: stamp-source-oss4
 	sed -e 's#_VERSION_#$(UPSTREAM_VERSION)#' < debian/oss4-dkms.install.in > debian/oss4-dkms.install


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#834993: oss4: please make the build reproducible

[Reiner Herrmann]

Source: oss4
Version: 4.2-build2010-5
Severity: wishlist
Tags: patch upstream
User: reproducible-builds@lists.alioth.debian.org
Usertags: locale timestamps fileordering umask
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi!

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

The attached patch fixes several issues:
- Use system txt2man in upstream build script (build.sh), which supports
  SOURCE_DATE_EPOCH.
- Use SOURCE_DATE_EPOCH for the generated build-id.
- Sort files in modules tarball, fix permissions and timestamps.
- Fix ordering issues in some other places.

Regards,
 Reiner

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


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#834988: twitter-bootstrap3: please make the build reproducible

[Chris Lamb]

Source: twitter-bootstrap3
Version: 3.3.6+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that twitter-bootstrap3 could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2016-08-21 11:54:36.103131504 
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-21
+
+--- twitter-bootstrap3-3.3.6+dfsg.orig/docs/assets/js/src/customizer.js
 twitter-bootstrap3-3.3.6+dfsg/docs/assets/js/src/customizer.js
+@@ -14,7 +14,7 @@ window.onload = function () { // wait fo
+ 
+   var cw = '/*!\n' +
+' * Bootstrap v3.3.5 (http://getbootstrap.com)\n' +
+-   ' * Copyright 2011-' + new Date().getFullYear() + ' Twitter, 
Inc.\n' +
++   ' * Copyright 2011-' + (new Date(process.env.SOURCE_DATE_EPOCH ? 
(process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime())).getFullYear() + 
' Twitter, Inc.\n' +
+' * Licensed under MIT 
(https://github.com/twbs/bootstrap/blob/master/LICENSE)\n' +
+' */\n\n'
+ 
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2016-08-21 11:54:46.991242483 +0100
@@ -0,0 +1 @@
+reproducible-build.patch
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#834983: eyed3: please make the build reproducible

[Chris Lamb]

Source: eyed3
Version: 0.6.18-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that eyed3 could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2016-08-21 11:14:28.190933490 
+0100
@@ -0,0 +1,19 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-21
+
+--- eyed3-0.6.18.orig/configure
 eyed3-0.6.18/configure
+@@ -1674,7 +1674,11 @@ fi
+ 
+ BUILD_DATE=`date`
+ 
+-MANPAGE_DATE=`date +'%b. %d, %Y'`
++if test -n "$SOURCE_DATE_EPOCH"; then
++MANPAGE_DATE=`LC_ALL=C date --utc --date="@$SOURCE_DATE_EPOCH" +'%b. %d, 
%Y'`
++else
++MANPAGE_DATE=`date +'%b. %d, %Y'`
++fi
+ 
+ 
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${MAKE-make} sets 
\$(MAKE)" >&5
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2016-08-21 11:14:27.050922086 +0100
@@ -0,0 +1 @@
+reproducible-build.patch
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#834976: auto-apt-proxy: FTBFS: SC2039: In POSIX sh, 'local' is undefined

[Chris Lamb]

Source: auto-apt-proxy
Version: 1
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

auto-apt-proxy fails to build from source in unstable/amd64:

  [..]

  
  
**
  ** Starting build 
  **
  
**
  
   Package:  auto-apt-proxy
   Version:  1
   Build architecture:   amd64
   Date: Sun, 21 Aug 2016 10:40:03 +0100
   Hostname: 4084b642edd1
   Uname:Linux 4084b642edd1 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 
(2016-07-18) x86_64 GNU/Linux
   /etc/timezone:Europe/London
  
  
**
  ** Installing build dependencies  
  **
  
**
  
  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'auto-apt-proxy-build-deps' in 
'../auto-apt-proxy-build-deps_1_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package auto-apt-proxy-build-deps.
  (Reading database ... 23244 files and directories currently installed.)
  Preparing to unpack auto-apt-proxy-build-deps_1_all.deb ...
  Unpacking auto-apt-proxy-build-deps (1) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
shellcheck
  The following NEW packages will be installed:
shellcheck
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 1667 kB of archives.
  After this operation, 13.9 MB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 shellcheck amd64 
0.4.4-2 [1667 kB]
  Fetched 1667 kB in 0s (84.9 MB/s)
  Selecting previously unselected package shellcheck.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 23248 files and directories currently installed.)
  Preparing to unpack .../shellcheck_0.4.4-2_amd64.deb ...
  Unpacking shellcheck (0.4.4-2) ...
  Setting up shellcheck (0.4.4-2) ...
  Processing triggers for man-db (2.7.5-1) ...
  Setting up auto-apt-proxy-build-deps (1) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=4084b642edd1
  TERM=xterm
  PAGER=more
  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  
PWD=/home/lamby/temp/cdt.20160821104002.Ei1p5KYGw2.db.auto-apt-proxy/auto-apt-proxy-1
  OLDPWD=/home/lamby/temp/cdt.20160821104002.Ei1p5KYGw2.db.auto-apt-proxy
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  GPG_KEY=1E953E27D4311E58
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building auto-apt-proxy 1 on amd64 
  **
  
**
  
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package auto-apt-proxy
  dpkg-buildpackage: info: source version 1
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Antonio