Re: misleading timestamps in binnmus

[Aurelien Jarno]

On 2016-11-10 11:33, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson  (2016-11-09):
> > > What version of sbuild do buildds run ?  Ie, supposing that this is
> > > fixed in sbuild in stretch, will this be fixed on the buildds ?  Or do
> > > we need to update jessie, or what ?
> > 
> > sbuild on buildds uses a specific version of sbuild, for reasons I'm not
> > going to summarize. The base version is close to what's in jessie (see the
> > first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).
> ...
> > Repository seems to live under:
> >   https://apt.buildd.debian.org/
> 
> Thanks.  When Johannes has decided exactly what the sbuild patch looks
> like in sid, I will take a look at the repo there and backport the
> change.  In what form should I supply mhy update ?  As an source+all

When it's done, just ping us with the commit number, we will backport it
in our branch and we will deploy it on the build daemons.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

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

Bug#843933: sbuild: include generated .buildinfo contents in the build log

[Niko Tyni]

Package: sbuild
Version: 0.72.0-2
Severity: wishlist
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Now that dpkg-buildpackage generates .buildinfo files by default, it
would be nice if sbuild included them in the build log like it does for
the .changes file and the binary package contents.

Many thanks for your work,
-- 
Niko Tyni   nt...@debian.org

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

FWD: Clarification regarding FTP resource constraints for buildinfo files

[Holger Levsen]

Hi,

actually forwarding this to the bug.

And adding a small note that since August we now have
buildinfo.debian.net, so maybe for a start it would be sufficient if dak
would submit these .buildinfo files via curl/https to buildinfo.d.n!?!

- Forwarded message from Ximin Luo  -

Date: Wed, 24 Aug 2016 13:16:00 +
From: Ximin Luo 
To: ftpmas...@debian.org
Cc: Reproducible Builds discussion list 

Subject: [Reproducible-builds] Clarification regarding FTP resource constraints 
for buildinfo files
Reply-To: Reproducible Builds discussion list 


Hi, I'm emailing to follow-up regarding #763822. I know we have not yet come up
with a concrete proposal on that, and that is largely because we were waiting
for comments regarding the resource constraints of ftp-master and mirrors.

There is broad understanding across the R-B team that you'd prefer a design
that does not involve "lots of small files", but there's a lot of breadth in
this statement, and none of us know the precise details involved. Originally
Lunar proposed a design with 1 large file, but there are issues with this as
well, such as the performance of updates.

Here are our current main requirements as stated by dkg in message #10, and I
confirm they're still accurate as of today:

1. We want an archive user to be able to find and fetch all .buildinfo files 
that produced a given binary package
2. We want the eventual possibility of multiple .buildinfo files per 

3. We understsand that mirror operators don't like small files because rsync 
gets fussy with them.
4. We want both buildds and debian developers to be able to upload .buildinfo 
files.

(4) by itself is easy; people have already written code to allow dak to accept
such files and discard them.

So we need to figure out how to reconcile (1,2,3). For this, it would be good
if you could tell me in more detail what the restriction (3) consists of.

We would never be uploading 10,000k buildinfo files at once, but Mattia tells
me that 1k might happen during medium binNMU transitions, growing up to 4k for
large transitions (but this would be over several days, i.e. split across
multiple runs of dinstall). Each buildinfo file is about 5.4k (median), with
7.7k as the 75% percentile, though the largest is 148k. [1]

There is also the distinction between uploading vs mirroring. Just because we
might upload 1k files over a short time, does not mean that we have to transfer
these to mirrors as 1k files. We could tar some of them up and compress them.

So could you clarify some details regarding upload resource limits, as well as
mirroring resource limits?

For example, is one extra file per source-package OK or "too much"? Or one
extra file per binary upload? How about one extra file-update, of the same
file, per binary upload? (I assume that rsync means we are free to update any
files that we store in pool/, if we need to?)

More clarifications to the above, regarding what we *don't* need:

N1. It's not essential to store 1 uploaded-buildinfo-file per 
file-in-the-archive, as long as we can still do (1).
N2. We don't care particularly about being able to get *a specific 
buildinfo-file*, as long as we can still do (1).
N3. It's OK to over-satisfy (1) with extra irrelevant data, then the user can 
just filter this out locally.

We have more ideas, but I think it's best to keep this email short for now.
Also I don't know what is feasible until I hear more details about the
constraints, and it would be pointless to skip further ahead to potentially
unfeasible things.

X

[1] (use wget, too big for browser) 
https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/?C=S;O=A

-- 
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

- End forwarded message -


-- 
cheers,
Holger


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

Re: Trial git-based task list

[Ximin Luo]

Holger Levsen:
> Hi,
> 
> I'm sorry if this sounds dismissive, but this thread (and evaluation)
> has shown me, that being decentralised is not a feature I desire in a
> tracker, on the contrary, it seems that decentralised has downsides
> making me wish for a centralized tracker which I can use with a
> webbrowser.
> 
> (or someone needs to setup a webview for this tasks.git thing. fine with
> me too.)
> 
> As I understand, this tasks.git needs me to review code to use it,
> which… (here!) basically means "no". We have a zillion trackers in
> Debian, why not use a packaged one, preferedly on a server.
> 
> Just my 2 cents & knowing we'll discuss this topic again next week in
> our IRC meeting.
> 
> & still, thanks for investigating & very much so!
> 

I wouldn't generalise this to all decentralised trackers. The current setup is 
a massive hack for sure. But yes let's talk about it some more next meeting.

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

Bug#843925: dpkg-dev: dpkg-buildpackage should sign buildinfo files

[Ximin Luo]

Package: dpkg-dev
Version: 1.18.13
Severity: important

Dear Maintainer,

We would like dpkg-buildpackage to clearsign the buildinfo files that are
created. This allows them to be uploaded to services similar to keyservers,
for auditing and attestation purposes, that may be run independently of the
FTP archive.

Furthermore, we would like user-side tools to download and perform other
security-related logic on the signed buildinfo files - e.g. being able to see
how many, and exactly who else, managed to *actually reproduce* the binaries
that one has installed.

Neither these services nor user-tools need to perform archive-related duties
or operations, and therefore would prefer to work directly with signed
buildinfo files, rather than with signed .changes files plus an unsigned
.buildinfo file (which is what the current situation would force).

For more discussion on the rationale and intent see here:

https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Signatures
https://wiki.debian.org/ReproducibleBuilds/BuildinfoInfrastructure

An analogy that might be helpful is X509 certificates. These are signed
attestations by a CA (the signer) that "(I believe) key K belongs to entity E".
Compare this with a signed buildinfo file, which is a signed attestation that
"I built binary X from [etc]".

I'm happy to write this patch myself. That will take a little bit more time - I
wanted to file this bug report early to check that you're not opposed to this
idea - and before too many other tools start assuming that buildinfo files are
unsigned. I think this should not be the case by default, just as you rarely
see an unsigned .dsc being distributed.

There would also be a -ub option added, along the same lines as -us and -uc.
Then debsign from devscripts will also need to be updated, and I'll be happy to
write the patch for this too.

X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (200, 'experimental'), 
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg-dev depends on:
ii  binutils  2.27-9+b1
ii  bzip2 1.0.6-8
ii  libdpkg-perl  1.18.13
ii  make  4.1-9
ii  patch 2.7.5-1
pn  perl:any  
ii  tar   1.29b-1
ii  xz-utils  5.2.2-1.2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.2
ii  clang-3.5 [c-compiler]   1:3.5.2-5
ii  fakeroot 1.21-2
ii  gcc [c-compiler] 4:6.1.1-1
ii  gcc-6 [c-compiler]   6.2.0-10
ii  gnupg2.1.15-4
ii  gnupg2   2.1.15-4
ii  gpgv 2.1.15-4
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2016.09.04

-- no debconf information

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

Re: broken DDPO by not-so-broken reproducible-tracker.json

[Holger Levsen]

Hi,

On Thu, Nov 03, 2016 at 05:47:17PM +, Mattia Rizzolo wrote:
> This thread doesn't seem to make progress, anyway:

(it was still on my to-reply list…)
 
> On Tue, Oct 18, 2016 at 09:54:39PM +, Mattia Rizzolo wrote:
> > 4. figure out why the hell DDPO doesn't deal with that edit in the json,
> >see the code⁵ in Debian's QA Team SVN repo, and leave the json to
> >display testing data as it is now
> This happened now, thanks to myon.  Not sure what this means with
> regards to this dicussion, but I figured I'd let you all know.

to me it means we'll leave -tracker.json as it is now, until we have
released stretch (when I'll probably be fine switching -tracker.json to carry
results for unstable again).

This means there is a delay between an upload and showing that it worked
on DDPO, yes. But if you did an upload and want to know, you can always
check manually on t.r-b.o/debian/unstable/$your_pkg yourself.


-- 
cheers,
Holger


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

Re: Trial git-based task list

[Holger Levsen]

Hi,

I'm sorry if this sounds dismissive, but this thread (and evaluation)
has shown me, that being decentralised is not a feature I desire in a
tracker, on the contrary, it seems that decentralised has downsides
making me wish for a centralized tracker which I can use with a
webbrowser.

(or someone needs to setup a webview for this tasks.git thing. fine with
me too.)

As I understand, this tasks.git needs me to review code to use it,
which… (here!) basically means "no". We have a zillion trackers in
Debian, why not use a packaged one, preferedly on a server.

Just my 2 cents & knowing we'll discuss this topic again next week in
our IRC meeting.

& still, thanks for investigating & very much so!


-- 
cheers,
Holger


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

Re: Finding merged /usr bugs through reproducible builds?

[Holger Levsen]

Hi Adrian,

On Sun, Nov 06, 2016 at 09:38:24PM +0200, Adrian Bunk wrote:
> could you change the reproducible builds to find bugs like #843433, 

probably, yes. I've added it to our TODO yesterday…

> ideally with a rebuild of everything that is currently building 
> reproducibly?

if, I'd implemented for all builds on amd64+i386, to always do one build
with /usr-merged, and one without. And then it will take 2-3 weeks until
we have rebuild the whole archive for unstable/amd64. 

see https://tests.reproducible-builds.org/debian/index_performance.html
to get an idea for how long it will take… just note that we've double
the build capacity for amd64 this week (and will soon do the same for
i386).


disclaimer: our main interest in this setup is to find reproducibility
issues. we are not really (that) interested to make this setup expose other
bugs as well, simple because we already "see too much" with it and seeing
even more distracts from what we really want to be looking at.


-- 
cheers,
Holger


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

Re: [PATCH] Rework META_PKGSET; no functional change.

[Daniel Shahaf]

Chris Lamb wrote on Thu, Nov 10, 2016 at 16:09:51 +:
> Daniel Shahaf wrote:
> 
> > Revised to avoid the Python '_ variable' idiom as per feedback on IRC.
> 
> Did you see:
> 

Yes I did, but I didn't know (when I submitted the patch) that Holger
had been convinced by that.

> I highly recommend using _ for both of these reasons.

You're preaching to the choir. :-)

Cheers,

Daniel

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

Re: [PATCH] Rework META_PKGSET; no functional change.

[Holger Levsen]

Hi Daniel,

On Thu, Nov 10, 2016 at 03:58:14PM +, Daniel Shahaf wrote:
> Revised to avoid the Python '_ variable' idiom as per feedback on IRC.
> Also available as:
> git fetch ssh://git.debian.org/~danielsh-guest/src/jenkins.debian.net 
> 5ec252e861de

thanks! took your patch now, just reworked it to use "_" as dummy
variable again and prefixed the commit msg with "reproducible Debian:"…

this convinced me:

< lamby> Especially useful as things like pylint will say "unused 
'dummy_variable'", but won't for _

:)


-- 
cheers,
Holger


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

Re: [PATCH] reproducible Debian: filter Environment section from buildinfo files

[Holger Levsen]

On Mon, Nov 07, 2016 at 06:11:36PM -0500, Daniel Kahn Gillmor wrote:
> What if we only included the .buildinfo differences (clearly demarcated)
> if there was other stuff which should be fixed?  And if nothing needs to
> be fixed, then don't show the buildinfo differences.  That strikes me as
> potentially useful output for someone trying to diagnose a problem.

I agree, this would be best. (Added showing both .buildinfo files to my
todo, will leave diffoscope to others…)


-- 
cheers,
Holger


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

Re: [PATCH] Rework META_PKGSET; no functional change.

[Chris Lamb]

Daniel Shahaf wrote:

> Revised to avoid the Python '_ variable' idiom as per feedback on IRC.

Did you see:

 < lamby > _ is really common (and useful) for deliberately pointing
   out that you aren't going to use the variable.

 < lamby > Especially useful as things like pylint will say "unused
   dummy_variable'", but won't for _

I highly recommend using _ for both of these reasons.


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

[PATCH] Rework META_PKGSET; no functional change.

[Daniel Shahaf]

---
Revised to avoid the Python '_ variable' idiom as per feedback on IRC.

Also available as:
git fetch ssh://git.debian.org/~danielsh-guest/src/jenkins.debian.net 
5ec252e861de

Cheers,

Daniel

 bin/reproducible_common.py| 6 ++
 bin/reproducible_html_pkg_sets.py | 7 ++-
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/bin/reproducible_common.py b/bin/reproducible_common.py
index b23cb0e..f901d34 100755
--- a/bin/reproducible_common.py
+++ b/bin/reproducible_common.py
@@ -89,12 +89,10 @@ JENKINS_URL = 'https://jenkins.debian.net'
 # global package set definitions
 # META_PKGSET[pkgset_id] = (pkgset_name, pkgset_group)
 # csv file columns: (pkgset_group, pkgset_name)
-META_PKGSET = {}
-pkgset_id = 0
+META_PKGSET = []
 with open(os.path.join(BIN_PATH, './reproducible_pkgsets.csv'), newline='') as 
f:
 for line in csv.reader(f):
-pkgset_id += 1
-META_PKGSET[pkgset_id] = (line[1], line[0])
+META_PKGSET.append((line[1], line[0]))
 
 # init the database data and connection
 DB_ENGINE = create_engine("sqlite:///" + REPRODUCIBLE_DB, 
connect_args={'timeout': 60})
diff --git a/bin/reproducible_html_pkg_sets.py 
b/bin/reproducible_html_pkg_sets.py
index 0cf155c..71c0564 100755
--- a/bin/reproducible_html_pkg_sets.py
+++ b/bin/reproducible_html_pkg_sets.py
@@ -117,9 +117,7 @@ def update_stats(suite, arch, stats, pkgset_name):
 def create_pkgset_navigation(suite, arch, view=None):
 # Group the package sets by section
 sections = OrderedDict()
-for index in range(1, len(META_PKGSET)+1):
-pkgset_name = META_PKGSET[index][0]
-pkgset_section = META_PKGSET[index][1]
+for pkgset_name, pkgset_section in META_PKGSET:
 pkgset = {
 'class': "active" if pkgset_name == view else "",
 'pkgset_name': pkgset_name,
@@ -302,8 +300,7 @@ for arch in ARCHS:
 if suite == 'experimental':
 continue
 create_index_page(suite, arch)
-for index in META_PKGSET:
-pkgset_name = META_PKGSET[index][0]
+for pkgset_name, pkgset_version in META_PKGSET:
 stats = gather_meta_stats(suite, arch, pkgset_name)
 if (stats):
 update_stats(suite, arch, stats, pkgset_name)

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

Re: From srebuild sbuild-wrapper to debrebuild

[HW42]

Johannes Schauer:
> Hi,
> 
> On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer  wrote:
>> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer  wrote:
>>> But then on IRC, HW42 suggested to approach this problem differently.
>>> Instead of integrating the functionality of figuring out the right
>>> repositories to reproduce the contents of a buildinfo file into sbuild,
>>> write a tool that can drive any package builder (like pbuilder).
> 
> there seems to be a conceptual problem with such an approach.
> 
> For binNMUs, the full changelog entry has to be passed to sbuild or pbuilder.
> How does one best pass such a multi-line value via command line options?

What's your problem with passing multi-line value via command line
options?

> Would the best way to pass the changelog entry via the .buildinfo
> file?

Not sure about that. If you dislike passing the value via a command line
option, just use a plain file?

> And if pbuilder and sbuild then already are parsing the .buildinfo
> file, would it not be better for the debrebuild machinery to be
> implemented by either in the first place?

My point for an independent debrebuild was that

a) Every builder needs nearly the same functionaly for this.
b) It's security relevant since it parses semi-trusted (the .buildinfo)
   and untrusted (http response from snapshot.d.o) data.

So I still think that having this separate of the builder is useful. If
sbuild, pbuilder, etc. coordinate this, some kind of library might also be
an option.



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

Re: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Hi,

On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer  wrote:
> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer  wrote:
> > But then on IRC, HW42 suggested to approach this problem differently.
> > Instead of integrating the functionality of figuring out the right
> > repositories to reproduce the contents of a buildinfo file into sbuild,
> > write a tool that can drive any package builder (like pbuilder).

there seems to be a conceptual problem with such an approach.

For binNMUs, the full changelog entry has to be passed to sbuild or pbuilder.
How does one best pass such a multi-line value via command line options? Would
the best way to pass the changelog entry via the .buildinfo file? And if
pbuilder and sbuild then already are parsing the .buildinfo file, would it not
be better for the debrebuild machinery to be implemented by either in the first
place?

Thanks!

cheers, josch


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

Bug#843888: haskell-cabal-install: FTBFS: Couldn't match type `Distribution.Package.PackageIdentifier' with `Cabal-1.24.0.0:Distribution.Package.PackageIdentifier'

[Chris Lamb]

Source: haskell-cabal-install
Version: 1.24.0.1-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,

haskell-cabal-install fails to build from source in unstable/amd64:

  […]

  touch configure-ghc-stamp
  . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
  build_recipe
  Running debian/hlibrary.setup build --builddir=dist-ghc
  Building cabal-install-1.24.0.1...
  Preprocessing executable 'cabal' for cabal-install-1.24.0.1...
  [  1 of 106] Compiling Distribution.Client.Glob ( 
Distribution/Client/Glob.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Glob.o )
  [  2 of 106] Compiling Distribution.Client.Utils.Json ( 
Distribution/Client/Utils/Json.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Utils/Json.o )
  [  3 of 106] Compiling Distribution.Client.Utils.LabeledGraph ( 
Distribution/Client/Utils/LabeledGraph.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Utils/LabeledGraph.o )
  [  4 of 106] Compiling Distribution.Client.Dependency.Modular.Version ( 
Distribution/Client/Dependency/Modular/Version.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Dependency/Modular/Version.o 
)
  [  5 of 106] Compiling Distribution.Client.Dependency.Modular.PSQ ( 
Distribution/Client/Dependency/Modular/PSQ.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Dependency/Modular/PSQ.o )
  [  6 of 106] Compiling Distribution.Client.Dependency.Modular.Package ( 
Distribution/Client/Dependency/Modular/Package.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Dependency/Modular/Package.o 
)
  [  7 of 106] Compiling Distribution.Client.PackageUtils ( 
Distribution/Client/PackageUtils.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/PackageUtils.o )
  [  8 of 106] Compiling Distribution.Client.Haddock ( 
Distribution/Client/Haddock.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Haddock.o )
  [  9 of 106] Compiling Distribution.Client.Compat.FilePerms ( 
Distribution/Client/Compat/FilePerms.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Compat/FilePerms.o )
  [ 10 of 106] Compiling Distribution.Client.ParseUtils ( 
Distribution/Client/ParseUtils.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/ParseUtils.o )
  [ 11 of 106] Compiling Distribution.Client.Compat.Semaphore ( 
Distribution/Client/Compat/Semaphore.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Compat/Semaphore.o )
  [ 12 of 106] Compiling Distribution.Client.Compat.ExecutablePath ( 
Distribution/Client/Compat/ExecutablePath.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Compat/ExecutablePath.o )
  [ 13 of 106] Compiling Distribution.Client.JobControl ( 
Distribution/Client/JobControl.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/JobControl.o )
  [ 14 of 106] Compiling Distribution.Client.Compat.Process ( 
Distribution/Client/Compat/Process.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Compat/Process.o )
  [ 15 of 106] Compiling Distribution.Client.Init.Licenses ( 
Distribution/Client/Init/Licenses.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Init/Licenses.o )
  [ 16 of 106] Compiling Distribution.Client.PkgConfigDb ( 
Distribution/Client/PkgConfigDb.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/PkgConfigDb.o )
  [ 17 of 106] Compiling Distribution.Client.GZipUtils ( 
Distribution/Client/GZipUtils.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/GZipUtils.o )
  [ 18 of 106] Compiling Distribution.Client.World ( 
Distribution/Client/World.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/World.o )
  [ 19 of 106] Compiling Distribution.Client.ComponentDeps ( 
Distribution/Client/ComponentDeps.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/ComponentDeps.o )
  [ 20 of 106] Compiling Distribution.Client.PackageIndex ( 
Distribution/Client/PackageIndex.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/PackageIndex.o )
  [ 21 of 106] Compiling Distribution.Client.Init.Types ( 
Distribution/Client/Init/Types.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Init/Types.o )
  [ 22 of 106] Compiling Distribution.Client.BuildReports.Types ( 
Distribution/Client/BuildReports/Types.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/BuildReports/Types.o )
  [ 23 of 106] Compiling Distribution.Client.Compat.Time ( 
Distribution/Client/Compat/Time.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Compat/Time.o )
  [ 24 of 106] Compiling Paths_cabal_install ( 
dist-ghc/build/autogen/Paths_cabal_install.hs, 
dist-ghc/build/cabal/cabal-tmp/Paths_cabal_install.o )
  [ 25 of 106] Compiling Distribution.Client.Utils ( 
Distribution/Client/Utils.hs, 
dist-ghc/build/cabal/cabal-tmp/Distribution/Client/Utils.o )
  [ 26 of 106] Compiling Distribution.Client.FileMonitor ( 
Distribution/Client/FileMonitor.hs, 

Bug#843797: koji: FTBFS: help2man: can't get `--help' info from ./cli/koji

[Chris Lamb]

Chris Lamb wrote:

> koji fails to build from source in unstable/amd64:

I can no longer reproduce this in today's sid so closing.


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

Bug#843797: marked as done (koji: FTBFS: help2man: can't get `--help' info from ./cli/koji)

[Debian Bug Tracking System]

Your message dated Thu, 10 Nov 2016 13:12:37 +
with message-id 
<1478783557.3755462.783487289.13561...@webmail.messagingengine.com>
and subject line Re: koji: FTBFS: help2man: can't get `--help' info from 
./cli/koji
has caused the Debian Bug report #843797,
regarding koji: FTBFS: help2man: can't get `--help' info from ./cli/koji
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
843797: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843797
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: koji
Version: 1.10.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

koji fails to build from source in unstable/amd64:

  […]

  dh_auto_build
make -j1
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20161109174748.li6xI7ndXh.db.koji/koji-1.10.0'
  read the makefile
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20161109174748.li6xI7ndXh.db.koji/koji-1.10.0'
  PYTHONPATH=. help2man --no-info --version-string=1.10.0 -n "Koji build 
client" ./cli/koji > debian/koji.1
  help2man: can't get `--help' info from ./cli/koji
  Try `--no-discard-stderr' if option outputs to stderr
  debian/rules:11: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20161109174748.li6xI7ndXh.db.koji/koji-1.10.0'
  debian/rules:8: recipe for target 'build' failed
  make: *** [build] Error 2

  […]

The full build log is attached.


Regards,

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


koji.1.10.0-1.unstable.amd64.log.txt.gz
Description: Binary data
--- End Message ---
--- Begin Message ---
Chris Lamb wrote:

> koji fails to build from source in unstable/amd64:

I can no longer reproduce this in today's sid so closing.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` End Message ---
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: misleading timestamps in binnmus

[Niko Tyni]

On Thu, Nov 10, 2016 at 10:34:33AM +, Holger Levsen wrote:
> On Thu, Nov 10, 2016 at 08:24:38AM -0200, Johannes Schauer wrote:
> > > I certainly hope it's part of the .buildinfo file as well, else, for
> > > reproducing binNMUs we would also need to store the .changes files in an
> > > easily accessable manner… (which we plan to do for .buildinfo files, but
> > > not for .changes files atm…)
> > 
> > for binary-only uploads, dpkg-genbuildinfo will add the Binary-Only-Changes
> > field to the .buildinfo file which contains the text of the last changelog
> > entry together with the maintainer name and date.
> 
> can someone please point at a real life/archive example of such a file?
> (a binNMU .changes file with Binary-Only-Changes field…)

That's in the .buildinfo file (not .changes), and I don't think they are
stored in the archive yet? But just try building a binNMU with sbuild
and look at the resulting .buildinfo. Something like

  sbuild --make-binNMU="test rebuild" -m"Niko Tyni " 
--binNMU=2 libxml-parser-perl_2.44-2

results in a .buildinfo file with

  Format: 0.1
  Source: libxml-parser-perl (2.44-2)
  Binary: libxml-parser-perl
  Architecture: amd64
  Version: 2.44-2+b2
  Binary-Only-Changes:
   libxml-parser-perl (2.44-2+b2) unstable; urgency=low, binary-only=yes
   .
 * Binary-only non-maintainer upload for amd64; no source changes.
 * test rebuild
   .
-- Niko Tyni   Tue, 05 Jul 2016 21:55:41 +0200
  Checksums-Md5:
 [...]

> I'm still confused, thinking that this Binary-Only-Changes field needs
> to be assembled into a file, called changelog.$arch, which is then put
> into the debian directory of the unpacked source package. (And which is
> then not included in the resulting binary packages…)

When asked to make a binNMU, sbuild will append an entry to
debian/changelog in the source, containing "binary-only=yes". During
package build, dh_installchangelogs (so debhelper not dpkg!) will
then extract that debian/changelog entry and install that in the
binary package as /usr/share/doc//changelog.Debian.,
separately from the rest of the changelog which goes to
/usr/share/doc//changelog.Debian. (This is done to not break
M-A:same coinstallability.)

As Johannes wrote, dpkg-genbuildinfo will also read debian/changelog in
the source and write out a corresponding Binary-Only-Changes field in the
resulting .buildinfo if the changelog entry contains "binary-only=yes".

To reproduce a binNMU from a .buildinfo file, one would need to parse
the Binary-Only-Changes field and extract the parts that needs to be
passed to sbuild. This currently seems rather fragile as noted by Ian
in #843773: the binNMU version needs to be parsed from the +bX notation,
and the message needs to be separated from the "Binary-only [...]" text
that's hardcoded in sbuild and might even change in the future. And then
there's the timestamp issue where I'll defer to others :)

But all that seems fixable on the sbuild side, and I think Johannes is
actively working on this stuff (thanks!)

Hope this clarifies a bit,
-- 
Niko Tyni   nt...@debian.org

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

Re: misleading timestamps in binnmus

[Ian Jackson]

Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> Ian Jackson  (2016-11-09):
> > What version of sbuild do buildds run ?  Ie, supposing that this is
> > fixed in sbuild in stretch, will this be fixed on the buildds ?  Or do
> > we need to update jessie, or what ?
> 
> sbuild on buildds uses a specific version of sbuild, for reasons I'm not
> going to summarize. The base version is close to what's in jessie (see the
> first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).
...
> Repository seems to live under:
>   https://apt.buildd.debian.org/

Thanks.  When Johannes has decided exactly what the sbuild patch looks
like in sid, I will take a look at the repo there and backport the
change.  In what form should I supply mhy update ?  As an source+all
upload of sbuild, as if I were being sponsored ?  As a
git-format-patch against a git import of what I find there (or a
dgitish git branch) ?

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

Re: sbuild should use build date as binnmu changelog date

[Ian Jackson]

Johannes Schauer writes ("Re: sbuild should use build date as binnmu changelog 
date"):
> While "Pkg Start Time" might be a good default, I guess for to be able to
> reproduce a binNMU it would be necessary to also allow the user to pass a
> custom timestamp.

Not only a custom timestamp (although I can see situations where that
might be useful), but a whole custom binnmu changelog entry.

Is there already a command line option to provide the binnmu changelog
entry ?  I think srebuild and/or derebuild wants to use the binnmu
changelog entry from the .buildinfo file and pass it to sbuild.

Imagine, for example, that a new version of sbuild changes some minor
detail of the text in its binnmu changelog entries.  That new version
of sbuild would generate different .debs - unless it used the one from
the .buildinfo.  (And it is no answer to say "use the old sbuild",
because sbuild runs outside the build chroot and there might be very
good reasons for wanting a new one.)

> I propose to add the command line option --binNMU-date and use that
> or, if the command line option is not given, the value from the
> environment variable SOURCE_DATE_EPOCH.

I think this is a good option to have, just for flexibility's sake,
but I don't think debrebuild.pl should use it.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

Bug#843871: salt-formula-ceilometer: FTBFS: AttributeError: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: undefined symbol: OPENSSL_no_config

[Chris Lamb]

Source: salt-formula-ceilometer
Version: 2016.4.1-3
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

salt-formula-ceilometer fails to build from source in unstable/amd64:

  […]

 dh_auto_test
make -j1 test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20161110103411.rqNHd4HyoD.db.salt-formula-ceilometer/salt-formula-ceilometer-2016.4.1'
  [ ! -d tests ] || (cd tests; ./run_tests.sh)
  /usr/bin/salt-call
  Traceback (most recent call last):
File "/usr/bin/salt-call", line 11, in 
  salt_call()
File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 346, in 
salt_call
  import salt.cli.call
File "/usr/lib/python2.7/dist-packages/salt/cli/call.py", line 6, in 

  from salt.utils import parsers
File "/usr/lib/python2.7/dist-packages/salt/utils/parsers.py", line 28, in 

  import salt.config as config
File "/usr/lib/python2.7/dist-packages/salt/config/__init__.py", line 41, 
in 
  import salt.utils.sdb
File "/usr/lib/python2.7/dist-packages/salt/utils/sdb.py", line 9, in 

  import salt.loader
File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 30, in 
  import salt.utils.event
File "/usr/lib/python2.7/dist-packages/salt/utils/event.py", line 72, in 

  import salt.payload
File "/usr/lib/python2.7/dist-packages/salt/payload.py", line 17, in 

  import salt.crypt
File "/usr/lib/python2.7/dist-packages/salt/crypt.py", line 42, in 
  import salt.utils.rsax931
File "/usr/lib/python2.7/dist-packages/salt/utils/rsax931.py", line 69, in 

  libcrypto = _init_libcrypto()
File "/usr/lib/python2.7/dist-packages/salt/utils/rsax931.py", line 63, in 
_init_libcrypto
  libcrypto.OPENSSL_no_config()
File "/usr/lib/python2.7/ctypes/__init__.py", line 375, in __getattr__
  func = self.__getitem__(name)
File "/usr/lib/python2.7/ctypes/__init__.py", line 380, in __getitem__
  func = self._FuncPtr((name_or_ordinal, self))
  AttributeError: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: undefined symbol: 
OPENSSL_no_config
  [ERROR] Execution of ceilometer.agent_cluster failed
  [ERROR] Execution failed
  Makefile:22: recipe for target 'test' failed
  make[1]: *** [test] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20161110103411.rqNHd4HyoD.db.salt-formula-ceilometer/salt-formula-ceilometer-2016.4.1'
  dh_auto_test: make -j1 test returned exit code 2
  debian/rules:6: recipe for target 'build' failed
  make: *** [build] Error 2

  […]

The full build log is attached.


Regards,

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


salt-formula-ceilometer.2016.4.1-3.unstable.amd64.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#843870: trash-cli: FTBFS: make[1]: *** [override_dh_auto_test] Segmentation fault (core dumped)

[Chris Lamb]

Source: trash-cli
Version: 0.12.9.14-2
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,

trash-cli fails to build from source in unstable/amd64:

  […]

 debian/rules override_dh_auto_test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20161110103840.4NlvA7GPuf.db.trash-cli/trash-cli-0.12.9.14'
  nosetests
  .SS...debian/rules:12: recipe for target 
'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Segmentation fault (core dumped)
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20161110103840.4NlvA7GPuf.db.trash-cli/trash-cli-0.12.9.14'
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 2

  […]

The full build log is attached.


Regards,

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


trash-cli.0.12.9.14-2.unstable.amd64.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#843866: photofloat: FTBFS: Can't find bundle for base name org.mozilla.javascript.resources.Messages, locale en_US

[Chris Lamb]

Source: photofloat
Version: 0~20120917+dfsg-3
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

photofloat fails to build from source in unstable/amd64:

  […]

  Adding debian:AddTrust_Low-Value_Services_Root.pem
  Adding debian:Starfield_Class_2_CA.pem
  Adding debian:Secure_Global_CA.pem
  Adding debian:QuoVadis_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G2.pem
  Adding debian:Comodo_Secure_Services_root.pem
  Adding debian:Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem
  Adding debian:Equifax_Secure_eBusiness_CA_1.pem
  Adding debian:ApplicationCA_-_Japanese_Government.pem
  Adding debian:DST_ACES_CA_X6.pem
  Adding debian:Entrust_Root_Certification_Authority_-_EC1.pem
  Adding debian:COMODO_ECC_Certification_Authority.pem
  Adding debian:certSIGN_ROOT_CA.pem
  Adding debian:Swisscom_Root_CA_2.pem
  Adding debian:QuoVadis_Root_CA_2.pem
  Adding debian:UTN_USERFirst_Hardware_Root_CA.pem
  Adding debian:SecureSign_RootCA11.pem
  Adding debian:COMODO_Certification_Authority.pem
  Adding debian:XRamp_Global_CA_Root.pem
  Adding debian:thawte_Primary_Root_CA.pem
  Adding debian:IGC_A.pem
  Adding debian:GlobalSign_Root_CA.pem
  Adding debian:DigiCert_Global_Root_G2.pem
  Adding debian:CFCA_EV_ROOT.pem
  Adding debian:TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem
  Adding debian:EC-ACC.pem
  Adding debian:COMODO_RSA_Certification_Authority.pem
  Adding debian:GeoTrust_Global_CA_2.pem
  Adding debian:UTN_USERFirst_Email_Root_CA.pem
  Adding debian:OpenTrust_Root_CA_G2.pem
  Adding debian:Baltimore_CyberTrust_Root.pem
  Adding debian:AddTrust_Qualified_Certificates_Root.pem
  Adding debian:Entrust.net_Premium_2048_Secure_Server_CA.pem
  Adding debian:IdenTrust_Commercial_Root_CA_1.pem
  Adding debian:AddTrust_Public_Services_Root.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_2.pem
  Adding debian:Microsec_e-Szigno_Root_CA.pem
  Adding debian:DST_Root_CA_X3.pem
  Adding debian:CNNIC_ROOT.pem
  Adding debian:SwissSign_Silver_CA_-_G2.pem
  Adding debian:Root_CA_Generalitat_Valenciana.pem
  Adding debian:Actalis_Authentication_Root_CA.pem
  Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem
  Adding debian:OpenTrust_Root_CA_G3.pem
  Adding debian:WoSign.pem
  Adding debian:OISTE_WISeKey_Global_Root_GB_CA.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority.pem
  Adding debian:WoSign_China.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_EV_2009.pem
  Adding debian:Certigna.pem
  Adding debian:Hongkong_Post_Root_CA_1.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_2009.pem
  Adding debian:PSCProcert.pem
  Adding debian:Certification_Authority_of_WoSign_G2.pem
  Adding debian:DigiCert_Assured_ID_Root_G3.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_3.pem
  Adding debian:Deutsche_Telekom_Root_CA_2.pem
  Adding debian:Certplus_Root_CA_G2.pem
  Adding debian:Certinomis_-_Autorité_Racine.pem
  Adding debian:GeoTrust_Global_CA.pem
  Adding debian:Certum_Root_CA.pem
  Adding debian:Camerfirma_Global_Chambersign_Root.pem
  Adding debian:OISTE_WISeKey_Global_Root_GA_CA.pem
  Adding debian:DigiCert_Global_Root_G3.pem
  Adding debian:IdenTrust_Public_Sector_Root_CA_1.pem
  Adding debian:thawte_Primary_Root_CA_-_G3.pem
  Adding debian:ePKI_Root_Certification_Authority.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority.pem
  Adding debian:GeoTrust_Universal_CA.pem
  Adding debian:Cybertrust_Global_Root.pem
  Adding debian:AffirmTrust_Commercial.pem
  Adding debian:GlobalSign_Root_CA_-_R2.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R5.pem
  Adding debian:EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem
  Adding debian:Trustis_FPS_Root_CA.pem
  Adding debian:StartCom_Certification_Authority_2.pem
  Adding debian:ACCVRAIZ1.pem
  Adding debian:Certum_Trusted_Network_CA.pem
  Adding debian:Atos_TrustedRoot_2011.pem
  Adding debian:thawte_Primary_Root_CA_-_G2.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G3.pem
  Adding debian:TC_TrustCenter_Class_3_CA_II.pem
  Adding debian:Equifax_Secure_CA.pem
  Adding debian:ComSign_CA.pem
  Adding debian:QuoVadis_Root_CA_3_G3.pem
  Adding 
debian:China_Internet_Network_Information_Center_EV_Certificates_Root.pem
  Adding debian:SwissSign_Gold_CA_-_G2.pem
  Adding debian:NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem
  Adding debian:Juur-SK.pem
  Adding debian:Go_Daddy_Class_2_CA.pem
  Adding debian:DigiCert_Assured_ID_Root_CA.pem
  Adding debian:SecureTrust_CA.pem
  Adding debian:Chambers_of_Commerce_Root_-_2008.pem
  Adding debian:GeoTrust_Primary_Certification_Authority.pem
  Adding debian:Izenpe.com.pem
  Adding debian:GlobalSign_Root_CA_-_R3.pem
  Adding debian:CA_WoSign_ECC_Root.pem
  Adding debian:Camerfirma_Chambers_of_Commerce_Root.pem
  Adding debian:Entrust_Root_Certification_Authority.pem
  Adding 

Re: misleading timestamps in binnmus

[Holger Levsen]

On Thu, Nov 10, 2016 at 08:24:38AM -0200, Johannes Schauer wrote:
> > I certainly hope it's part of the .buildinfo file as well, else, for
> > reproducing binNMUs we would also need to store the .changes files in an
> > easily accessable manner… (which we plan to do for .buildinfo files, but
> > not for .changes files atm…)
> 
> for binary-only uploads, dpkg-genbuildinfo will add the Binary-Only-Changes
> field to the .buildinfo file which contains the text of the last changelog
> entry together with the maintainer name and date.

can someone please point at a real life/archive example of such a file?
(a binNMU .changes file with Binary-Only-Changes field…)

I'm still confused, thinking that this Binary-Only-Changes field needs
to be assembled into a file, called changelog.$arch, which is then put
into the debian directory of the unpacked source package. (And which is
then not included in the resulting binary packages…)

Maybe I'm just confused because this is news to me and I've never seen
nor heart about it.


-- 
cheers,
Holger


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

Re: misleading timestamps in binnmus

[Johannes Schauer]

Hi,

Quoiting Holger Levsen (2016-11-10 07:48:33)
> On Thu, Nov 10, 2016 at 10:38:45AM +0100, Emilio Pozuelo Monfort wrote:
> > > I see. And this changelog.$arch is neither part of the source package,
> > > the .changes file nor the .buildinfo file, it's just included in the
> > > binary packages? Or is it also part of the .changes file?
> > It's in .changes as well. No idea if (any of it) is in .buildinfo
>  
> I certainly hope it's part of the .buildinfo file as well, else, for
> reproducing binNMUs we would also need to store the .changes files in an
> easily accessable manner… (which we plan to do for .buildinfo files, but
> not for .changes files atm…)

for binary-only uploads, dpkg-genbuildinfo will add the Binary-Only-Changes
field to the .buildinfo file which contains the text of the last changelog
entry together with the maintainer name and date.

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: misleading timestamps in binnmus

[Holger Levsen]

On Thu, Nov 10, 2016 at 10:38:45AM +0100, Emilio Pozuelo Monfort wrote:
> > I see. And this changelog.$arch is neither part of the source package,
> > the .changes file nor the .buildinfo file, it's just included in the
> > binary packages? Or is it also part of the .changes file?
> It's in .changes as well. No idea if (any of it) is in .buildinfo
 
I certainly hope it's part of the .buildinfo file as well, else, for
reproducing binNMUs we would also need to store the .changes files in an
easily accessable manner… (which we plan to do for .buildinfo files, but
not for .changes files atm…)


-- 
cheers,
Holger


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

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 10:33, Holger Levsen wrote:
> On Thu, Nov 10, 2016 at 10:01:55AM +0100, Emilio Pozuelo Monfort wrote:
>> These days, a changelog entry is added to a changelog.$arch. This is to avoid
>> problems when co-installing ma:same packages, as the changelog entries 
>> will/may
>> differ between different architectures.
> 
> I see. And this changelog.$arch is neither part of the source package,
> the .changes file nor the .buildinfo file, it's just included in the
> binary packages? Or is it also part of the .changes file?

It's in .changes as well. No idea if (any of it) is in .buildinfo

Cheers,
Emilio

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

Re: misleading timestamps in binnmus

[Holger Levsen]

On Thu, Nov 10, 2016 at 10:01:55AM +0100, Emilio Pozuelo Monfort wrote:
> These days, a changelog entry is added to a changelog.$arch. This is to avoid
> problems when co-installing ma:same packages, as the changelog entries 
> will/may
> differ between different architectures.

I see. And this changelog.$arch is neither part of the source package,
the .changes file nor the .buildinfo file, it's just included in the
binary packages? Or is it also part of the .changes file?


-- 
cheers,
Holger


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

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 00:53, Wouter Verhelst wrote:
> On Tue, Nov 08, 2016 at 10:41:09PM +, Ian Jackson wrote:
>> Is this a recommended recipe ?  AIUI a buildd doing a binnmu will not
>> modify the debian/changelog file.
> 
> Are you sure? When last I checked, this was not true (it may have
> changed since, however).

These days, a changelog entry is added to a changelog.$arch. This is to avoid
problems when co-installing ma:same packages, as the changelog entries will/may
differ between different architectures.

Cheers,
Emilio

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