Bug#894217: reprotest: robust mode to make it usuable in CI pipelines

[Holger Levsen]

control: retitle -1 "reprotest: robust mode to make it usuable in CI pipelines"
control: severity -1 wishlist
# trying to summarize this feature request
# thanks

hi,

maybe there could be a robust mode using "safe" locales and another
mode, thoroughly testing stuff...


-- 
cheers,
Holger


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

Bug#894217: Info received (reprotest: robust mode to make it usuable in CI pipelines)

[Holger Levsen]

control: retitle -1 "reprotest: robust mode to make it more usuable in CI 
pipelines"
# thanks

-- 
cheers,
Holger


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

Re: distributing .buildinfo files (Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master)

[Holger Levsen]

On Thu, Apr 05, 2018 at 10:43:04AM +0200, Philipp Kern wrote:
> So what would be needed to make at least a simple export of the data
> happen? I think the requirements I'd have are these:

that's a good question! :)

maybe we can sit together with some ftp-team and reproducible builds
folks in Hamburg and finalize the design and implement it? 

> * Data is sufficiently fresh and optimally accessible before the mirror
> pulse happens so that you can always fetch the corresponding buildinfo
> for a newly pushed package.
> * Some way of actually deducing the path to the buildinfo file, either
> through some sort of redirector or by naming the files in a consistent
> fashion.
> 
> Right now the second point does not work with the date-based farm that
> is used to archive the buildinfo files. It would work if we were to just
> apply the same splitting as in the regular pool. For the former just
> pushing the content through static.d.o should work and dak could push
> the content before pushing the mirrors?
> 
> Intuitively I would not care about cryptographic authentication of the
> data. After all it can be verified by rebuilding if the package is
> reproducible.

agreed with all of these points, thanks!


-- 
cheers,
Holger


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

Re: [rb-general] Please review the draft for week 156's blog post

[Holger Levsen]

On Sun, Apr 22, 2018 at 08:32:18AM +0100, Chris Lamb wrote:
> Please review the draft for week 156's blog post:
>   https://reproducible.alioth.debian.org/blog/drafts/156/

I get a 404 here.

the old url should still be working :)


-- 
cheers,
Holger


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

Bug#802241: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

- Forwarded message from Drew Parsons  -

Date: Tue, 24 Apr 2018 16:43:48 +0800
From: Drew Parsons 
To: 802...@bugs.debian.org
Subject: Bug#802241: please store the hash of the installed .deb and allow to 
query it
Reply-To: dpars...@debian.org, 802...@bugs.debian.org
List-Id: 

I got caught out by this apt bug when handling sasview. I had installed
a local build of sasview with my patch for 4.2.0~git20180309-3. Stuart
Prescott added another patch and uploaded.

I assumed apt had picked up on the update and installed the final,
official version.  But it hadn't, even though the contents and
changelog had changed.  I was left wondering why the "new" version was
misbehaving (still showing the bug that Stuart had patched).

Drew


- End forwarded message -


-- 
cheers,
Holger


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

Bug#897442: reprotest timeouts while installing the build-dependencies

[Holger Levsen]

Hi Paride,

thanks for your bug report! (I'll let others comment on it's content...)

On Wed, May 02, 2018 at 06:59:53PM +0200, Paride Legovini wrote:
> This is how it fails:
> https://paste.debian.net/1022959/

this is nice on IRC but not so good in the BTS where we rather want to
archive things forever and independently of external sources.

so, this is the content of https://paste.debian.net/1022959/

Selecting previously unselected package imagemagick.
Preparing to unpack .../031-imagemagick_8%3a6.9.9.34+dfsg-3+b1_i386.deb ...
Unpacking imagemagick (8:6.9.9.34+dfsg-3+b1) ...
E: Caught signal ‘Terminated’: terminating immediately
Selecting previously unselected package libasound2-data.
Preparing to unpack .../032-libasound2-data_1.1.6-1_all.deb ...
Unpacking libasound2-data (1.1.6-1) ...
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py", line 461, 
in execute
(out, err) = proc.communicate()
  File "/usr/lib/python3.6/subprocess.py", line 835, in communicate
self.wait()
  File "/usr/lib/python3.6/subprocess.py", line 1457, in wait
(pid, sts) = self._try_wait(0)
  File "/usr/lib/python3.6/subprocess.py", line 1404, in _try_wait
(pid, sts) = os.waitpid(self.pid, wait_flags)
  File "/usr/lib/python3/dist-packages/reprotest/lib/VirtSubproc.py", line 64, 
in alarm_handler   
raise Timeout()
reprotest.lib.VirtSubproc.Timeout

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 831, in run 
  
return 0 if check_func(*check_args) else 1
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 394, in 
check_auto  
  
dist_x0 = proc.send(("control", var_x0))
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 329, in 
corun_builds
  
bctx.run_build(testbed, build, os.environ, artifact_pattern, 
testbed_build_pre, no_clean_on_error)   
 
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 200, in 
run_build   
  
(self.testbed_src, artifact_pattern, testbed_build_pre or "true")])
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 61, in 
check_exec2 
   
xenv=xenv, kind=kind)
  File "/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py", line 480, 
in execute
self.bomb(msg)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 70, in bomb 
  
raise _type(m)
reprotest.lib.adtlog.TestbedFailure: timed out on command "sh -ec cd 
"/tmp/reprotest.uIgGNX/build-control/" && rm -rf ./*.deb && apt-get -y 
--no-install-recommends build-dep ./"flif_0.3-1.dsc"" (kind: short)



-- 
cheers,
Holger


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

Re: Please review the draft for week 158's blog post

[Holger Levsen]

On Sun, May 06, 2018 at 04:37:22PM +0100, Chris Lamb wrote:
> Please review the draft for week 158's blog post:
>   https://reproducible-builds.org/blog/posts/158/

looks good to me, though suprisingly short.

(and I would like to get back the word "draft" into the url, but enotime
atm unfortunatly.)

and now I wonder whether we should mention again that we lack funding
atm, which hugely contributes to my lack of "time"…


-- 
cheers,
Holger


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

Re: Please review the draft for week 158's blog post

[Holger Levsen]

On Mon, May 07, 2018 at 07:55:39PM +0100, Chris Lamb wrote:
> > looks good to me, though suprisingly short.
> Well, alas, there's not much I can do about that at report-writing
> time…

sure. 

> > and now I wonder whether we should mention again that we lack funding
> > atm, which hugely contributes to my lack of "time"
> Whilst I appreciate the intention behind this, without a specific
> request, recommendation or task, etc. I fear it would be interpreted
> incorrectly.

we could have a paragraph "you might be wondering about why less things
have recently happened in the reproducible builds efforts and this is
because lack of funding. Please contact us if you can help us getting
our work funded again." 


-- 
cheers,
Holger


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

Re: Please review the draft for week 158's blog post

[Holger Levsen]

On Tue, May 08, 2018 at 05:01:59PM +0100, Chris Lamb wrote:
> That's how I originally interepreted your query. I feel the trade-off
> between it being accidentally intepreted a "sulk" and it attracting
> meaningful results (not mere community support) means we should err
> on the side of omitting it.

well...

this also means we wont get the support we might be getting.


-- 
cheers,
Holger


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

Re: packages which have not been rebuild since December 2016

[Holger Levsen]

Hi,

On Thu, May 31, 2018 at 05:33:10PM +0200, Guillem Jover wrote:
> > We have the "upload_history" relation but that will only give us an
> > upper limit (roughly 50% of the archive).
> 
> I think this should be relatively easy to compute:
 
yes, that's the easy part, once you have the data :)

>   if ! -e pkg.buildinfo
> → rebuild
>   elif dpkg-dev not in pkg.buildinfo
> → rebuild
>   elfi dpkg-dev < 1.18.17 in pkg.buildinfo
> → rebuild

yup. (and/or s#rebuild#display 'this package needs rebuid'#)

> And, hey, just today I stumbled upon this
>  :), which might perhaps
> be a nice starting point.

oh, indeed, seems David is already colling .buildinfo's somewhere.
David, is that on a public site somewhere?


-- 
cheers,
Holger


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

Re: packages which have not been rebuild since December 2016

[Holger Levsen]

Hi Chris,

On Fri, Jun 01, 2018 at 10:40:18AM +0100, Chris Lamb wrote:
> > I think this should be relatively easy to compute:
> Indeed — 9182/33705 packages need a rebuild in sid.
> (Full output of following script attached.)

hehe, very nice. 

Just the numbers strike me as odd: we currently have 28043 source
packages in sid/main (according to our stats on tests.r-b.o), so…

sid  debian-work:/var/lib/apt/lists$ grep -c ^Package: 
deb.debian.org_debian_dists_sid_main_source_Sources
33168
sid  debian-work:/var/lib/apt/lists$ grep ^Package: 
deb.debian.org_debian_dists_sid_main_source_Sources|sort -u|wc -l
  28049  

ah, ok, that explains, you counted some packages twice.

an then I was curious how big contrib and non-free were:

sid  debian-work:/var/lib/apt/lists$ grep ^Package: 
deb.debian.org_debian_dists_sid_contrib_source_Sources | sort -u |wc -l
156
sid  debian-work:/var/lib/apt/lists$ grep ^Package: 
deb.debian.org_debian_dists_sid_non-free_source_Sources | sort -u |wc -l
325

So in other words a bit less than 33% of the archive still needs a rebuild.


-- 
cheers,
Holger


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

re: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

Hi Guillem,

ping on this bug, you haven't replied to it yet and it's a blocker for
"#774415 sbuild: please add the srebuild sbuild wrapper to reproduce builds"
which is a rather important one to give users the means to easily
reproduce Debian packages, which is a core feature of reproducible
builds and which we would love to see for Buster…! 

:)


-- 
cheers,
Holger


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

Re: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

Guillem, josch:

thanks for your feedback, much appreciated.

On Fri, Jun 08, 2018 at 08:38:49AM +0200, Johannes Schauer wrote:
> > I say it's an artificial blocker, because it is based on the problem
> > faced while implementing the srebuild script to use the current
> > snapshot.d.o API. And I think that's your actual blocker. Fixing that
> > API would also mean you can use it right away independently of what's
> > already installed on the system and might be useful for other users
> > too. I think the fix would imply adding an API entry point based on
> > the name-version-arch tuple.
> 
> yes, that would also solve the problem.
 
as I'm not an sbuild user (yet) myself, I was hesistant to try this
myself, so I'm confused now: does it work as it is now? (or does it need
changes to snapshot.d.o?)

> I unblocked the bug, because it's not a hard blocker but just an 
> inconvenience.

thanks

> The bigger blocker of #774415 is, that the script needs somebody who feels
> responsible for it and who is willing to maintain it. I only wrote it but I
> have no intention of being its maintainer.

I'd be happy to maintain it, once I'm a user of it :) (which might
happen quite soon via tests.r-b.o…)


-- 
cheers,
Holger


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

Re: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Holger Levsen]

Hi josch,

adding #774415 to to: and reply-to:…

On Fri, Jun 08, 2018 at 07:54:20PM +0200, Johannes Schauer wrote:
> > as I'm not an sbuild user (yet) myself, I was hesistant to try this
> > myself, so I'm confused now: does it work as it is now? (or does it need
> > changes to snapshot.d.o?)
> 
> yes, it does work as it is now.
> 
> Just supply the script with a buildinfo file to see it in action.
> 
> It does not require superuser privileges.
> 
> The script will query snapshot.debian.org to retrieve the right snapshot
> timestamp that contains all the package versions specified in the buildinfo
> file.
> 
> At the end of execution the script will print how to either reproduce the
> buildinfo manually via dpkg-buildpackage or how to run sbuild such that it 
> does
> it for you.
> 
> People who know how to use pbuilder could easily add a section that outputs 
> how
> to run pbuilder to do the same.
> 
> Naturally, instead of just printing how to use sbuild or pbuilder, the script
> could also be made actually run either.
> 
> The main two limitations of the script are:
> 
>  1. it will fail if there is not a single snapshot that contains all the right
> package versions
> 
>  2. it will instruct sbuild/pbuilder to use the last stable release as the 
> base
> which might not allow upgrading to the right package versions
> 
> Both issues can be fixed by manually downloading exactly the required binary
> package set and creating a completely new chroot with exactly the required
> packages. But I didn't get around to doing that yet.

thank you very much for this nice summary!

As it sounds, I now believe this script would better live in
src:devscripts and as such I would like to reassign #774415 to
devscripts - or do you see any issue with that?


-- 
cheers,
Holger


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

#774415: devscripts: please add the srebuild wrapper for reproducible builds

[Holger Levsen]

control: reassign -1 devscripts
control: retitle -1 devscripts: please add the srebuild wrapper for 
reproducible builds
thanks

On Sat, Jun 09, 2018 at 10:33:16PM +0200, Johannes Schauer wrote:
> Quoting Holger Levsen (2018-06-09 22:12:33)
> > As it sounds, I now believe this script would better live in src:devscripts
> > and as such I would like to reassign #774415 to devscripts - or do you see
> > any issue with that?
> I see no issues with that from my side.

ok :) 

thanks!


-- 
cheers,
Holger


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

Re: koji_1.16.0-2_source.changes ACCEPTED into unstable

[Holger Levsen]

On Wed, Jul 18, 2018 at 11:41:25PM -0400, Sergio Durigan Junior wrote:
> Secondly, I would like to propose renaming the current "koji-common"
> package to "python{,3}-koji" (IOW, we'd also build it for Python 3),
> which would make it be have the same name as in Fedora.  WDYT?

I think you should file a bug for this.


-- 
cheers,
Holger


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

Re: RFC: dpkg patch to using -ffile-prefix-map

[Holger Levsen]

On Tue, Jul 31, 2018 at 04:54:09AM +0200, Guillem Jover wrote:
> > > --- a/scripts/Dpkg/Vendor/Debian.pm
> > > +++ b/scripts/Dpkg/Vendor/Debian.pm
[...]

thanks for your work on this, Guillem! (and Vagrant of course too!)

Not sure we attributed Guillem corrently on this in
https://reproducible-builds.org/blog/posts/171 (and can't check
currently as offline on the way back from DebConf18 and haven't updated
that git repo before I left...)

> > So by default, it would be disabled initially, and then we could
> > explicitly enable this for the reproducible builds test framework? After
> > it proves to be working and useful and not disruptive, I presume we
> > would enable it by default?
> Yeah. That was at Mattia's request too. I'm not sure I'd mind much
> setting it by default from the get go. 

cool too!

> But it might be wiser to let
> the repro buildds crunch on this for a bit in case unrelated things
> break. :)

sure! We've been running this code since last Saturday... so in a while
we should know for sure :)


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


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

dpkg/gcc-8 regressions

[Holger Levsen]

hi,

from irc:

[14:52] <  h01ger> | vgrntc: moin :)

https://tests.reproducible-builds.org/debian/unstable/amd64/stats_pkg_state.png
looks like we are regressing. havent looked closer though. also visible
on other archs, eg arm64 (amd armhf and i386 to a lesser degree)
[15:03] < vgrntc> | h01ger: to be expected
[15:03] <  h01ger> | that much? uff
[15:05] < vgrntc> | h01ger: i figured maybe 2/3rd of the path issues
[15:08] < vgrntc> | h01ger: which wete maybe 10-15% total
[15:14] <  h01ger> | vgrntc: when you say "maybe 2/3rd of the path
issues" you mean "maybe 2/3rd of the path issues we had fixed with our
patched gcc-7" and not "maybe 2/3rd of the path issues visible in sid
but not in buster" right? though the diff is not that big anyway
[15:15] <  h01ger> | the diff between sid and buster is less than
10% (in total, not in percent), so i dont get why sid becomes so
unreproducible anyway

(times are CEST yesterday)


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


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

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi Guillem,

people are still affected by this bug...

On Fri, Mar 02, 2018 at 01:25:51AM +0100, Guillem Jover wrote:
> Perhaps the simplest and more correct might be to name it using
> something like source+amd64 as the arch name, which seems like a
> dubious arch, but at least is accurate and might be trivial to
> implement, taking care of not ending up with such fake arch in
> unexpected places…

could we have this simple migation for now, please? 


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


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

Re: Empty build-id to make package reproducible

[Holger Levsen]

Hi,

(replying to the list with Otto's permission..)

On Sun, Aug 05, 2018 at 02:51:16AM +0800, Otto Kekäläinen wrote:
> This is what we talked about today:
> https://salsa.debian.org/mariadb-team/galera-3/commit/1460cfa128fb457b5b5c60fcc5cac6faf5a216d5

I'm wondering, is this really a good approach? (to set build-id=none) 

I'm somewhat sceptical but then also a bit clueless here... ;)


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


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

Bug#905885: diffoscope: skipping tests on ci.debian.net is perhaps wrong?

[Holger Levsen]

Control: retitle -1 'allow to override @skip_unless_tools_exist during tests 
and fail the test if the tool is missing'


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

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

Bug#909694: reprotest: please export DEB_BUILD_OPTIONS=reproducible=+all

[Holger Levsen]

Package: reprotest
Version: 0.7.8
Severity: important

Dear Maintainer,

< KGB-1> | Mattia Rizzolo master 4860753 jenkins.debian.net  
bin/reproducible_build.sh * https://deb.li/v57l
< KGB-1> reproducible debian: enable all the reproducible-related build flags 
 from dpkg, by export DEB_BUILD_OPTIONS=reproducible=+all
 https://deb.li/3oWVI
[22:44] <  h01ger> | mapreri: re: 4860753: shouldt this also be done for 
reprotest?
[22:45]  | h01ger: possibly indeed yes :)


cheers,
Holger

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Holger Levsen]

Package: diffoscope
Severity: important

Hi,

I just gave a small presentation about diffoscope at the mirage.io
hackretreat (which was well received) which resulted in people
wanting to file bugs against diffoscope, which turned out to be "complicated":

- the project on salsa has issues disabled (but would require a login on
  salsa anyway), still filing bugs in a webbrowser is something many
  people want to do today, so I think maybe we should enable issues?
- the link "Bugs and feature requests" on https://diffoscope.org just
  points to https://bugs.debian.org/src:diffoscope - this is helpful for
  Debian developers but hardly for anyone else.
- there is still https://github.com/ReproducibleBuilds but thats empty, 
  so noone could file issues there.

I've got no good idea how to fix this best, but I wanted to at least
document this so we can come up with something better. It's unfortunate
to say 'please file bugs' and then...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Holger Levsen]

On Mon, Oct 08, 2018 at 10:22:56AM +0200, Mattia Rizzolo wrote:
> On Mon, Oct 08, 2018 at 12:15:36AM +0200, Marek Marczykowski-Górecki wrote:
> > Filling bugs in web browser is indeed something many people expect.
> (grumpy person here that don't understand those people…!)

I think you're just officially an old person now. Soon you will be part
of the Debian grandparents team! ;)

> > What about providing appropriate "mailto" link to open new issue on BTS,
> > including all the magic headers, bug template etc?
> > Like the "reply" one existing already on BTS (I'm using it right now, I
> > even get quoted message I reply to!).
> I just added such a link in https://diffoscope.org/ - what do you all
> think? :)

awesome, thanks a lot, much much better!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Holger Levsen]

Dear Chris,

On Sun, Oct 07, 2018 at 10:33:49PM +0100, Chris Lamb wrote:
> (Adjusting severity only because important severity bugs are treated
> somewhat different in some interfaces, but agree this is more
> severe than "just another" wishlist entry.)

I agree, was thinking the same when filing the bug...

> > - the project on salsa has issues disabled (but would require a login on
> >   salsa anyway), still filing bugs in a webbrowser is something many
> >   people want to do today, so I think maybe we should enable issues?
> 
> No strong objection to the principle except that we would then have
> some duplication between the two trackers.

while I do agree that duplication is a problem, I think having bugs not
filed because "it's complicated" is worse.

> I'm thinking specifically of those times when I'd like to pick up on a
> previous issue, but then would need to "mentally merge" two lists of
> bugs, filtering any potential duplicates, etc.

we could make the habbit to always file a debian bug and set it
forwarded to the github issue if we'd agree to use github issues... 

but...

> > - there is still https://github.com/ReproducibleBuilds but thats empty, 
> >   so noone could file issues there.
> Well, this one is easily "fixed":
>   https://i.imgur.com/vXbuKYU.png

sigh. for two reasons:

first, I find the style of explaining an issue by the means of a
screenshot to be, dunno, passive aggressive, or maybe just annoying? its
definitly not accessable not stored in the bts, and requires everyone
reading the bts mail to go to a graphical webbrowser (& be online) to
see what you have done... so for those who have not followed that link,
Chris deleted https://github.com/ReproducibleBuilds

second, I was basically suggesting to discuss using the github tracker
and instead of allowing the discussion you killed it within minutes
after my report. surely we could recreate the github project again, but
that would mean everybody again needs to apply to become a member etc.

I actually would have been in favor of allowing people to report issues
on github, just because it has 40mio users, which includes most people
working on reproducible builds, while a.) salsa has a few thousand and
hardly anyone not involved in Debian and b.) filing bugs via mail (while
I like it a lot) is something many people dislike.

But I guess this discussion is academic now. :(


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Holger Levsen]

On Mon, Oct 08, 2018 at 03:21:41PM +0100, Chris Lamb wrote:
> Oh sure, we are all in agreement here but users of diffoscope in Debian
> are likely to file their generic issues in the Debian bug tracker,
> resulting in duplication.

I dont think this is a problem, or rather a problem with diffoscope, but
rather with all the other 26000 source packages too. And the solution is
simple and the same as everywhere: forward those bugs to the upstream
tracker.

(just that we dont have an upstream tracker atm...)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Holger Levsen]

Dear Chris,

On Mon, Oct 08, 2018 at 03:36:55PM +0100, Chris Lamb wrote:
> I'm sorry this appears to have upset you so much I'm afraid I'm
> somewhat struggling to see the full extent why.

and
 
> Naturally, if I thought this would have been a problem I would not have
> pushed the button.

sure, I never doubted that! :)

As I tried to explain was the combination of the immediate action
itself, coming from a discussion which was just started, combined with
explaining/announcing this action with a screenshot (which itself I'm
sure was ment 'funny' or geeky or some harmless/nice thing).

> Not only was the entire GitHub organisation empty (and was at least
> since the salsa migration), it was highly misleading and, naturally, we
> can recreate it within 60 seconds.

It has been that way for months, so I dont understand the perceived
hurry. Also that organisation still had members (which surely can be
added easily), so I think my main complaint is what I wrote above: the
combination of... (see above :)


anyhow, i dont hold any grudge or anything and would prefer to move on
with the question at hand:

> (I also would have thought that any solution to /potential/ duplication
> of issues between the Debian BTS and salsa would not be to introduce a
> _third_ entity anyway, 

2nd, we dont have issues on salsa enabled.

> and alas GitHub Issues cannot really be used
> without also duplicating the code there too, making the workflow for
> code even worse too. Indeed, this is what I was definitely finding
> before when we had a mirror.)

so let's get the mirror back and track upstream issues on github?

I was going to write "Or let's accept that diffoscope is a 'Debian
Reproducible Builds Project' and use the BTS or salsa for upstream bug
tracking too" but then I realized that we have the same problem with eg
the website, though there it's probably less a problem as we strive less
for drive-by contributors there.

But I think we want to move something distro agnostic, and salsa.d.o
is very much Debian centric, so I think we should look for something
else. I'd be fine to using github.com or gitlab.com or foobar.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Holger Levsen]

Hi Chris,

On Mon, Oct 08, 2018 at 08:15:59PM +0100, Chris Lamb wrote:
> > But I think we want to move something distro agnostic, and salsa.d.o
> > is very much Debian centric, so I think we should look for something
> > else. I'd be fine to using github.com or gitlab.com or foobar.
> Let's try and enumerate some of the potential options here so we aren't
> lost or confusing each other in paragraphs (or otherwise letting this go
> on for too long):

thanks, this seems useful! :)

before answering, some questions about these scenarios:

>  a) Some hybrid where we have the code remain on salsa yet mirror it on
> Github. Somewhat like the situation ~12 months ago.

where would we track the upstream issues in a.)?

>  b) Another frankenstein hybrid where we have the code remain on salsa
> & mirror on Github, but move issue tracking to salsa.
> 
>  c) Make salsa the canonical location, enable issues on it and use it
> for MRs. "Forward" issues upstream to salsa from the BTS.
> 
>  d) Make GitHub the canonical location and use it for PRs and issues.
> Remove diffoscope entirely from salsa & "forward" issues to GitHub
> from the BTS.
> 
>  e) Make GitLab the canonical location for both code and use it for MRs
> and issues. Remove diffoscope entirely from salsa and forward
> "issues" here from the BTS.

you mean a gitlab.com instance in e.)?

> I'm not *really* that fussed philosophically but as someone who has
> done a lot of the diffoscope coding over the past years I just want to
> remove as much day-to-day infrastructure overhead with respect to
> collating, collapsing, merging issues and suchforth.

nods, same here. plus I want it easy for new non-Debian contributors.
(Wish I'm sure you want too.)

> It is very easy to overloop what a big mental barrier and annoyance it
> is to have to do this extra work.

understood but what extra work exactly? of course we should automate
mirroring...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Holger Levsen]

On Wed, Oct 10, 2018 at 04:34:39PM +0200, Marek Marczykowski-Górecki wrote:
> > I'd like to hear what potential bug reporters would like to see, rather
> > than us trying to guess what they might think; therefore, I believe this
> > bug should (well, could) be deferred to in-person discussion in Paris.
> +1

I've added this to my list of things to do/discuss in Paris.

Thank you all for this discussion so far!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910542: better support for OCaml object files via ocamlobjinfo

[Holger Levsen]

On Tue, Oct 16, 2018 at 05:00:35PM -0400, Chris Lamb wrote:
> Thanks for the report. I've implemented this in Git, now pending upload:
>   
> https://salsa.debian.org/reproducible-builds/diffoscope/commit/bc92ac311960b43abd1067df83ddee1729dc38bd

awesome, thank you!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi,

On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> We were again biten by this issue for some security-updates (most
> recent one nginx). Do any involved parties know, was there any
> progress in adressing this problem? 

in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
wrote:

   Perhaps the simplest and more correct might be to name it using
   something like source+amd64 as the arch name, which seems like a
   dubious arch, but at least is accurate and might be trivial to
   implement, taking care of not ending up with such fake arch in
   unexpected places…

and I cannot find anything wrong with this simple solution and have
already asked Guillem in August to implement this ;)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: salsa is fine

[Holger Levsen]

On Fri, Dec 14, 2018 at 05:11:30PM +0100, Marek Marczykowski-Górecki wrote:
> This is all fine, but issues on salsa diffoscope project are still
> disabled.

any objections to me enabling them? :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: [rb-general] salsa is fine

[Holger Levsen]

On Fri, Dec 14, 2018 at 07:05:49PM +0100, Chris Lamb wrote:
> > any objections to me enabling them? :)
> Yes and no. :)

:)

> As in; I have nothing against moving to salsa (!) if we go that route,
> we should just first firmly decide whether the BTS or salsa is the
> canonical source of truth.

I dont think there is a canonical source of truth ;)

Rather (if we go this route), salsa will be the upstream bug tracker and
the BTS will be for Debian issues. And like with all other packages in
Debian, sometimes users will report upstream issues in the BTS and we as
maintainers should (or could/can) forward them to the upstream tracker,
which will be on salsa.

(And of course we should then encourage everyone to file upstream issues
on salsa.)

> (eg. one must surely be a strict subset of the other, rather than
> having two distinct/overlapping sets of issues, where things get
> lost in the cracks etc.)

sure.

> As I hinted at last time as someone who is taking on the majority of
> the heavy-lifting of diffoscope development these days, I humbly feel
> like I should at least have some input on the processes and procedures
> that I use day-to-day. :)

I hope the above addresses your concerns. Does it?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#910541: [rb-general] salsa is fine

[Holger Levsen]

On Fri, Dec 14, 2018 at 07:19:46PM +0100, Chris Lamb wrote:
> My reading of this is that (ignoring Debian-specific issues as they
> are an "easy" case IMHO) salsa becomes the single source of truth; ie.
> we both encourage and at least aim to forward/refile all "upstream"
> bugs to Salsa.

absolutly.

> I'm totally cool with that, I only insist on it not being undefined or
> ambiguous.

great!

I just wanted to enable issues on diffoscope.git on salsa, but couldnt
find the setting... so: could someone else please do that? :)

Once this has been done, we also need to update CONTRIBUTING.rst to
reflect this new reality. (I'm happy to do so, but don't want to do it
before the feature is enabled...)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#920732: strip-nondeterminism should normalize file ownerships in epubs too

[Holger Levsen]

Package: strip-nondeterminism
Version: 1.1.0-1
Severity: wishlist

Hi,

debian-edu-doc 2.10.11 when tested on tests.r-b.o shows this:

│ │ │ ├── ./usr/share/doc/debian-edu-doc-da/debian-edu-buster-manual.epub
│ │ │ │ ├── bsdtar -tvf {}
│ │ │ │ │ @@ -1,54 +1,54 @@
│ │ │ │ │  drwxr-xr-x  0 0  0   0 Jan 20 13:47 epub/
│ │ │ │ │  drwxr-xr-x  0 0  0   0 Jan 20 13:47 epub/META-INF/
│ │ │ │ │ --rw-r--r--  0      255 Jan  1  1970 
epub/META-INF/container.xml
│ │ │ │ │ +-rw-r--r--  0      255 Jan  1  1970 
epub/META-INF/container.xml

etc

despite this code (probably too much) in 
src:debian-edu-doc/documentation/common/Makefile.common

build-epub:
# build the English EPUB version
echo "Creating epub for en"
$(DBTOEPUB) $(name).xml
unzip -q $(name).epub -d epub
sed -i 's#_idm[0-9]\{14\}#_idm1234567#' epub/OEBPS/content.opf
sed -i 's#_idm[0-9]\{14\}#_idm1234567#' epub/OEBPS/toc.ncx
find epub -exec touch -d @0 {} \;
rm $(name).epub
zip -q -r -o $(name).epub epub/
rm -rf epub/
strip-nondeterminism -t zip $(name).epub
# build all other EPUB versions
-for LINGUA in $(LANGUAGES) ; do \
echo "Creating epub for $$LINGUA"; \
po4a --translate-only $(name).$$LINGUA.xml po4a.cfg ; \
mkdir images-tmp ; \
cp images/*.* images-tmp/ ; \
if [ -e images/$$LINGUA ] ; then \
cp -v images/$$LINGUA/*.* images-tmp/ ; \
fi ; \
sed -i "s#./images#./images-tmp#g" $(name).$$LINGUA.xml ; \
$(DBTOEPUB) $(name).$$LINGUA.xml ; \
sed -i "s#./images-tmp#./images/#g" $(name).$$LINGUA.xml ; \
rm -rf images-tmp/ ; \
done

IOW: we call strip-nondeterminism already and it would be nice if it would
normalize file ownerships.

And this 'find epub -exec touch -d @0 {} \;' also looks like something
strip-nd should do. Please close and retitle this bug report
accordingly.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Buildd-setup faffing around with __FILE__ breaks my unit tests.

[Holger Levsen]

Hi Sune,

thanks for reaching out to us!

On Sat, Feb 09, 2019 at 07:54:16PM +0100, Sune Vuorela wrote:
> (Please keep me CC'ed. Not subscribed)

done.

> The latest incarnations of the reproducible build  autobuilder setup passes 
> some options to gcc to not let __FILE__ actualy be the full file path, but 
> some 
> relative path.
> 
> This breaks at least some of my unit tests.

this is unfortunate to say the least.

we are tracking these problems at
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
and so far we are only aware of two cases. How many (and which) other affected
sources packages do you know about?


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Buildd-setup faffing around with __FILE__ breaks my unit tests.

[Holger Levsen]

On Sun, Feb 10, 2019 at 03:58:15PM +0100, Sune Vuorela wrote:
> On Sunday, February 10, 2019 3:34:27 PM CET Holger Levsen wrote:
> > On Sat, Feb 09, 2019 at 07:54:16PM +0100, Sune Vuorela wrote:
> > > (Please keep me CC'ed. Not subscribed)
> > done.
> thanks.

and again :)

> According to debian codesearch, there are 70 packages in the archive using 
> QFINDTESTDATA. A few of them uses them only in "manual tests", while most of 
> them uses it for automatic tests. I'd expect all of those should be affected. 
> 
> I sampled a couple of them, and at least
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/
> knotifications.html
> 
> The other ones I sampled didn't run the test suite on the buildds (which also 
> kind of surprised me, but that's an issue for another mail list)

for now I've just added knotifications to ftbfs_due_to_f-file-prefix-map. 

Not sure what else to do about this right now. 


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Buildd-setup faffing around with __FILE__ breaks my unit tests.

[Holger Levsen]

On Sun, Feb 10, 2019 at 04:41:10PM +0100, Sune Vuorela wrote:
> (Please keep me CC'ed. Not subscribed)

ack.

> If you have magic regexes to auto tag issues, lines matching
> /WARNING: .* testdata .* could not be located!/ 
> would probably find those where it applies to current test cases, at least of 
> the QFINDTESTDATA variety. 

we dont have magic regexes, but if you want to query codesearch.d.n and
give me a list of affected packages...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#926065: unblock: diffoscope/113

[Holger Levsen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package diffoscope, it has been in sid for 26 days without
any regressions reported (compared to 112 in buster currently) and
has been used to compare all unreproducible packages in unstable (with
path variations) and buster (without those) on amd64, and half of them
on arm64 and armhf. (see "oldest builds" on
https://tests.reproducible-builds.org/debian/index_performance.html)

During this time no new breakages have been occured as both the BTS as
well as
https://tests.reproducible-builds.org/debian/index_breakages.html shows.

Sadly the debdiff is rather big, due to coding style refactorings:

 128 files changed, 2766 insertions(+), 1667 deletions(-)

I'll reply to this with the debdiff as its 53kb xz-compressed (and
thus too big for the list.)

unblock diffoscope/113

Also, please don't hesitate to say 'no'. I understand and appreciate
the release teams work and policies! :) I just also think this version
is worth having in buster:

 diffoscope (113) unstable; urgency=medium
 .
   * Replace over 8 MB of Android boot ROM test suite fixtures with 14 KB
 equivalents. (Closes: #894334, reproducible-builds/diffoscope#13)
   * Compare .asc PGP signatures as text, not as a hexdump. (Closes: #908991,
 reproducible-builds/diffoscope#7)
   * Improve the displayed comment when falling back to a binary diff to include
 the file type. (Closes: reproducible-builds/diffoscope#49)
   * Explicitly mention when the guestfs module is missing at runtime and we are
 falling back to a binary diff. (Closes: reproducible-builds/diffoscope#45)
   * Provide explicit help when the libarchive system package is missing or
 "incomplete". (Closes: reproducible-builds/diffoscope#50)
   * Improve the --help outout:
 * Indent and wrap the list of supported file formats.
 * Include links to the diffoscope homepage and bug tracker.
 * Refer to the Debian package names when indicating how to obtain the tlsh
   and argcomplete modules.
   * Drop "DOS/MBR" source string test.
   * Correct a "recurse" typo.
   * Adopt the "black"  source code formatter:
 - Add an initial configuration in a PEP 518 pyproject.toml file and update
   MANIFEST.in to include pyproject.toml in future release tarballs.
 - Run the formatter against the source.
 - Test that the source code satisfies the formatter.

-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Some people say that the climate crisis  is something that we all have created,
but  that is not true,  because if everyone is guilty  then no one is to blame.
And someone is to blame.  Some people, some companies,  some decision-makers in
particular, have known exactly what priceless values they have been sacrificing
to continue making unimaginable amounts of money.


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

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi,

On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote:
> > On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > > On Thu, 2018-11-08 at 20:28:57 +, Holger Levsen wrote:
> > > > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > > > wrote:
> > > > > 
> > > > >Perhaps the simplest and more correct might be to name it using
> > > > >something like source+amd64 as the arch name, which seems like a
> > > > >dubious arch, but at least is accurate and might be trivial to
> > > > >implement, taking care of not ending up with such fake arch in
> > > > >unexpected places…
> > > > > 
> > > > > and I cannot find anything wrong with this simple solution and have
> > > > > already asked Guillem in August to implement this ;)
> > > > 
> > > > So, as I mentioned at the time this would require modifing the internal
> > > > filtering of the debian/files entries to cover this case in several of
> > > > the tools. It also modifies the documented filename pattern in
> > > > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > > > But this breaks previous public filename "interfaces", seems rather
> > > > intrusive, and entirely inappropriate for a stable update, which means
> > > > it would not fix your immediate problems anyway, only starting with
> > > > Buster. :/
> > > Although this would not help us for stretch-security uploads, such a
> > > move starting from buster would be very appreciated!

Guillem, back in November Salvatore said they would appreciate this
"source+amd64 as the arch name" solution for this bug (see above), while
now (because nothing happened I believe) he suggests disabling source
all uploads for security builds, which IMO would be a *very* bad and sad
outcome, as I believe source only security uploads are even more desired
than regular source only uploads...

> We regularly get biten by this issue when contributors to security
> uploads, most recently with the bind9 upload but as well others.
> 
> Would it be possible to at least workaround this on dak's side?
> Disabling source-only uploads completely would seem to be a step back
> on that regards.
> 
> Though if that's the only way  out of having to regularly fetch the
> rejected builds, do manual renamings and resigning and reuploading of
> files, then we should then just disable source-only uploads for the
> security suites again.
> 
> So I think we pretty much would prefer to be able to continue so.
> 
> Just to be clear, thanks a lot for your work, this is not meant as
> critique, just hilighting that we have recurring issues due to this
> bug when people perform uploads for security.

sigh, understandable...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#929397: ftp.d.o: please upload LTS .buildinfo files to ftp-master

[Holger Levsen]

Package: ftp.debian.org
Severity: wishlist

hi,

from #-security today:

  * | h01ger wonders how to tackle #862538
 zwiebelbot | (#debian-security) Debian#862538: security.debian.org: Please
  POST .buildinfo files to buildinfo.debian.net
  - https://bugs.debian.org/862538
| for ftp.d.o there's a cronjob running as my user on coccia.d.o,
  which surely is a hack, but works for now. with security.d.o 
  i have little  idea how to implement this, as i dont know how
  embargoed updates get published and whether we could hook in
  then+their somehow
| h01ger: Well, they do get uploaded to ftp-master after some time.
| oh, really? so this bug is moot? do you have an example?
| h01ger: Hmm, though LTS doesn't get pushed to ftp-master. 
  But everything merged into stable releases just gets uploaded
  to ftp-master, so .buildinfo should be available
  | for variable amounts of "some time" :)


Besides #862538 there are also #862073 and #763822 which are all related
but slightly different details. (and as indicated, we have a workaround for
#862073 which publishes .buildinfo files to both buildinfo.debian.net as 
well as buildinfos.debian.net...
and if you ever forget the details we maintain an overview at
https://wiki.debian.org/ReproducibleBuilds#Big_outstanding_issues )

This new bug shall just be about not copying the .buildinfo files from LTS
uploads to ftp-master.d.o.

Also please note that this bug will only become relevant when Stretch
becomes LTS as only dpkg from stretch (and newer) produces .buildinfo
files.

Thanks!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

we'll all die. make a difference while you can. disobey. smile.


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

Re: what to do with stretch?

[Holger Levsen]

Hi,

Mattia, thanks for bringing this up!

On Sat, Jul 06, 2019 at 10:42:50AM +0200, Mattia Rizzolo wrote:
> Today buster is being released, and I think we will do some shuffling to
> copy the buster data into the new bullseye shortly after, so we can
> start test for that as well.

yup. (though i'm not sure i'll be able to get to this before arriving at
DebCamp...)

> That begs the question: what do we want to do with stretch?
> 
> I think it's not quite useful anymore to keep around, nothing is going
> to change anymore there, so I propose to drop it entirely (at most
> keeping the suite-wide stats and graphs, for reference).

yes, to both.

> Do anybody think there is any gain in an "archival" of sorts?  In that
> case I suppose we could do something to kind of hide the archived suites
> from the package pages (as IMHO it's already crowded enough) and keep
> everything there, without rebuilding anything anymore)

I think if the cost is just diskspace, we might be able to keep those
results, but then, I'm still not convinced its worth the little costs.
I'm curious what other people think..!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


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

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Holger Levsen]

Hi,

On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote:
> Shortly before the end of the 6th July, we released Debian 10, "buster".

*yay* *yay* & *yay*!

> No binary maintainer uploads for bullseye
> =
> 
> The release of buster also means the bullseye release cycle is about to begin.
> From now on, we will no longer allow binaries uploaded by maintainers to
> migrate to testing. This means that you will need to do source-only uploads if
> you want them to reach bullseye.
> 
> 
>   Q: I already did a binary upload, do I need to do a new (source-only) 
> upload?
>   A: Yes (preferably with other changes, not just a version bump).
> 
>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>  do I need to do a new (source-only) upload for it to reach bullseye?
>   A: Yes. We also suggest going through NEW in experimental instead of 
> unstable
>  where possible, to avoid disruption in unstable.

whh, that's *totally* awesome news! loving it.

> All autopkgtest failures considered RC for bullseye

also very yay!

exciting times ahead!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: testing migration aging and reproducible builds

[Holger Levsen]

On Sun, Jul 21, 2019 at 05:35:53PM -0300, Jonathan Wiltshire wrote:
> On Sun, Jul 21, 2019 at 11:55:59AM -0300, Vagrant Cascadian wrote:
> > This makes me think to decrease the delay for reproducible packages
> > rather than increase the delay for unreproducible ones? Though then
> > you'd want it to be a small increment...
> How about if the current bonus of three days is dependent on both
> autopkgtests *and* reproducibility? That keeps the incentive without ending
> up with same-day migrations.

/me likes!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


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

Re: testing migration aging and reproducible builds

[Holger Levsen]

On Mon, Jul 22, 2019 at 10:46:37AM -0300, Chris Lamb wrote:
> One question: Does your proposal also imply a source package being
> strictly reproducible in unstable or, alternatively, did you mean to
> imply it "not regressing" from being previously reproducible in
> unstable?
> 
> This latter idea could be said to be fairer but requires the storage
> of state on either your "end" or ours and thus complicates the
> technical machinery, but more importantly IMHO it makes it somewhat
> opaque from the perspective of package maintainers...
 
I think britney already can track regressions, it does that for piuparts
tests at least.

intrigeri brought up another interesting angle on this:

currently (un)reproducibility bugs are are of severity normal, so it
seems a bit premature to block or even delay testing migrations because
of that. if however we treated regressions as important bug, than maybe
we should treat *all* new important bugs as delaying migrations at
least. say each new important bug would/could delay migrations by 2 days.

what do you think?


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: "Reproducible Builds - aiming for bullseye" comments and a purpose

[Holger Levsen]

hi Jathan,

fun fact: if you don't cc: me, you usually get a faster reply from me.

On Sun, Jul 21, 2019 at 08:47:46PM -0500, jathan wrote:
> Today I attended the talk "Reproducible Builds - aiming for bullseye" at
> DebConf19 and I want to share some comments since some things I consider
> we are missing to have more contributors. I think it is very important
> to share every year the current status of the Reproducible Builds
> Project inside Debian, but besides giving new information about what
> have been done, we should do another kind of presentations more focused
> to technical introductions to everyone, since at every DebConf we have
> people that being new, Debian Maintainers or Developers, they ask
> questions that could not be answered with the necessary depth of details
> and the complexity of what is taking place in RB is really huge, 

true
 
> Regarding to this, I purpose we prepare training sessions about
> Reproducible Builds for every MiniDebConf or DebConf in a way that could
> be easy for anyone to understand and get involved, like to do a
> demonstration how to put in practice the "Reproducible Builds How to"
> https://wiki.debian.org/ReproducibleBuilds/Howto showing all the
> necessary steps, how to identify the problems, possible solutions and
> patching. I would propose myself to do these trainings, but I still find
> it very difficult and my technical knowledge is not enough. It would be
> good if Holger, lamby, Vagrant or any other member of the team with the
> experience and confidence they already have, could do this kind of
> sessions. 

indeed.

however, at least right now, i'm out of capacity as there are several
other areas which I need to work on (eg testing against packages from
ftp.d.o instead of just doing CI tests, preparing the next R-B summit,
and keeping the test infrastructure running, to name my current top 3
priorities.

I could however, review someone elses work on this.

> They would really help us a lot and make the Reproducible Team
> inside Debian look less hermetic and more friendly to people who have
> not idea about Reproducible Builds. 

indeed!

> Please answer me what do you think
> about it,

see above.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#932849: ftp.debian.org: NEW process looses .buildinfo files

[Holger Levsen]

Package: ftp.debian.org
Severity: normal

hi,

 
https://tracker.debian.org/news/1027072/accepted-liblogger-simple-perl-20-1-source-all-into-unstable-unstable/
 says this upload was made with a .buildinfo file, yet this .buildinfo file 
isnt available
 this was on 2019-02-04
 any idea why this could have happened?
 process_new loses them
 really?
 the buildinfo copying happens here 
https://salsa.debian.org/ftp-team/dak/blob/master/dak/process_upload.py#L270
 which isn't on the NEW->policy->ACCEPT path
 thanks. i would have accepted a 'yes' but this is "better" :/
 i guess i will file a bug now
 tar tf /srv/ftp-master.debian.org/queue/done/2019/02.tar.xz  | grep 
liblogger-simple-perl
 02/04/liblogger-simple-perl_2.0-1_amd64.changes
 02/04/liblogger-simple-perl_2.0-1_amd64.buildinfo
 they're still retrievable, just not as friendly
 lol/thank you!
   * h01ger lols at bremner mubling next to him
 jrtc27: may i quote you in that bug to be filed?
 yeah please do
 meant to report one last time I ran into this...
 thank you, again! :)
   * h01ger hopes that would be an easy patch
 probably, for someone who knows the detailed code structure for NEW
 that's one part of dak that I haven't really fully understood
 isnt it just adding a 'cp $buildinfofile $path/$date/' somewhere?
 sure
 (in python, of course)
 a call to the existing function
 the question is where exactly though
 :)


thanks for maintaining ftp.d.o!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Second build of kronosnet fails on i386

[Holger Levsen]

On Thu, Jul 25, 2019 at 06:17:23PM -0300, wf...@niif.hu wrote:
> As 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/kronosnet.html
> shows, the first build succeeds, but the second one hits a failure in
> the build time unit tests.  This has been rather consistent for several
> uploads.  What are my options for tracking down this problem?

not really that much helpful, but we had several cases where some
software would build fine X% of the time and failed (100-X)% of the
time, for a variety of reasons...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

[ty...@mit.edu: Re: And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?]

[Holger Levsen]

FYI,

(I guess we know already :)

- Forwarded message from "Theodore Y. Ts'o"  -

Date: Sun, 28 Jul 2019 19:44:34 -0400
From: "Theodore Y. Ts'o" 
To: Steffen Möller 
Cc: debian-de...@lists.debian.org
Subject: Re: And in 2019? Re: -flto to become more of a routine - any change in 
opinion since 2011?
Message-ID: <20190728234434.ga4...@mit.edu>
List-Id: 

On Wed, Jul 24, 2019 at 06:03:21PM +0200, Steffen Möller wrote:
> Hello,
> 
> We just had SuSE embracing LTO
> (https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html).
> I am not sure about the progress on issues summarised in
> http://blog.regehr.org/archives/1180 that Ian pointed to. But since I
> last asked in 2016 we have more pedantic compiler settings and more CI -
> and LTO, as much as compilers have improved on that, does not need to be
> applied everywhere. Any change in opinion?

I'm currently compiling e2fsprogs with LTO for Debian --- and I'm
seriously considering ditching that change.  The reason why is because
LTO breaks reproducible builds, and so it makes it harder when I'm
verifying whether a particular packaging change (say, moving to a new
debhelper compat level) is going to make any changes to the binary ---
because using LTO pretty much guarantees that it will.

Yeah, the binaries are a little bit smaller, and presumably a little
bit more CPU efficient, but 99% of the time, e2fsprogs binary are I/O
bound, not CPU bound, and the fact that my package builds aren't
reproducible is !@#?! annoying.

- Ted


- End forwarded message -

-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: [Git][qa/jenkins.debian.net] reproducible: vary BUILDDIR for 2nd build so that the path length also

[Holger Levsen]

Hi,

I've deployed the following change now. If this causes significantly
more breakage than before we should probably/maybe revert it again...

On Sun, Aug 04, 2019 at 03:13:56PM +, Vagrant Cascadian wrote:
> Vagrant Cascadian pushed to branch master at Debian QA / jenkins.debian.net
> 
> Commits:
> 94469490 by Vagrant Cascadian at 2019-08-04T15:13:41Z
> reproducible: vary BUILDDIR for 2nd build so that the path length also
> varies.
> 
> 
> 2 changed files:
> 
> - bin/reproducible_build.sh
> - bin/reproducible_common.sh
> 
> 
> Changes:
> 
> =
> bin/reproducible_build.sh
> =
> @@ -657,7 +657,7 @@ EOF
>   # build path is only varied on unstable and experimental
>   if [ "${SUITE}" = "unstable" ] || [ "$SUITE" = "experimental" ]; then
>   local src_dir_name="$(perl -mDpkg::Source::Package -e '$_ = 
> Dpkg::Source::Package->new(filename => $ARGV[0])->get_basename; s/_/-/g; 
> print' -- "${SRCPACKAGE}_${EVERSION}.dsc")"
> - echo "BUILDDIR=/build/$src_dir_name" >> "$TMPCFG"
> + echo "BUILDDIR=/build/2/$src_dir_name" >> "$TMPCFG"
>   echo "BUILDSUBDIR=2nd" >> "$TMPCFG"
>   else
>   echo "BUILDDIR=/build" >> "$TMPCFG"

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Bug#934405: debhelper: Please ignore binNMUs in get_source_date_epoch() function

[Holger Levsen]

Hi,

thanks for filing a bug report about this issue. However...

On Sat, Aug 10, 2019 at 09:24:37PM +0300, Dmitry Shachnev wrote:
> I figured out that these timestamps are coming from binNMU changelogs.

yes, binNMUs change the sources, despite their name. they are a hack.

see #894441: 'binNMUs should be replaced by easy 
"no-change-except-debian/changelog-uploads"'

though by now I've realized that binNMUs are needed by the releaseteam
to get transitions done, and thus binNMUs should be followed (once the
transition in question is done) by (easily triggered) sourceful uploads,
to get all archs in sync, also for multiarch.

> I think it would be nice if that function ignored binNMU changelog entries.

nope, please dont. using changelog entries inconsistently is a recipe
for desaster.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

On Fri, Aug 30, 2019 at 07:22:19AM +, Matthias Klose wrote:
> Package: src:koji
> Version: 1.16.2-1
[...]
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

koji 1.18 has been ported to python 3 and needs to be packaged to solve
this.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: pipeline | WIP: Integrate atomic reprotest into salsa-ci pipeline (!168)

[Holger Levsen]

On Tue, Sep 03, 2019 at 05:11:16PM +0200, Santiago Ruano Rincón wrote:
> To give you an example of atomic results, see the current salsa ci
> pipeline of konsole:
> 
> https://salsa.debian.org/qt-kde-team/kde/konsole/-/jobs/279499
> 
> and debugging it with atomic-reprotest
> 
> https://salsa.debian.org/santiago/atomic-reprotest/pipelines/67690

I dont think atomic-reprotest should be run by default and on every
commit, as it's quite expensive on ressources, if a package is
unreproducible.

Better would be a way to run it on demand.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Bug#939387: Please provide a way to rebuild the package with debian/changelog-only changes

[Holger Levsen]

On Thu, Sep 05, 2019 at 10:07:26AM +0200, Stéphane Glondu wrote:
> I see this is a native package. Why don't you use the version in
> debian/changelog to generate diffoscope/__init__.py? If this was not a
> native package, or if the version number would otherwise naturally split
> in two parts, I would suggest to compare only the first part (upstream
> version/major version/whatever).

this matches my notion that native packages cause more harm than good.
IMHO we should make diffoscope non-native.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

#763822: ftp.debian.org: please include .buildinfo files in the archive

[Holger Levsen]

Dear ftp team,

it would be very cool if you could comment on this bug, even though
there is https://buildinfos.debian.net/ftp-master.debian.org/ and
https://buildinfos.debian.net/buildinfo-pool/ now.

Distributing .buildinfo files is one requirement for making reproducible
builds a reality for our users and while buildinfos.debian.net is a
working proof-of-concept having .buildinfos in the archive and on the
mirrors is IMHO how we should distribute them 'for real'.

What do you think? I'd really appreciate some comments how to move
forward here.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

[Holger Levsen]

hi,

so I thought I'd be bold and add the srebuild wrapper to src:devscripts
in git this weekend...

So I re-read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415
rather completly and noticed, that

- the branch devscripts-srebuild from https://salsa.debian.org/yadd/devscripts
  for a long time used the 2014 srebuild script from josch and was only
  'recently' based on the 2016 debrebuild script from josch.
  (The last 4 commits on this branch have all this history and thus are
  easy to grasp.)

- the NYU rebuilders OTOH use a by now quite modified version of the
  2014 srebuild script (with support for in-toto etc), see
  
https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/blob/master/builder/srebuild

- the authoritive source/git repo for josch script(s) is the #774415 bug
  report? Or yadd's repo? ;)

- the 2016 debrebuild script doesn't do a rebuild by itself but produces
  a command which is to be run with sudo, so we need another wrapper
  here.

- there is also 
https://salsa.debian.org/reproducible-builds/attic/reprobuild/blob/master/repro-build.pl
  from Steven Chamberlain...

- for the sake of presenting a complete picture of this discussion I
  want to state that I also thought about packaging $name (srebuild,
  debrebuild, repro-build, whatever) as a seperate package, not part of
  devscripts. I've decided, at least for now, to first try to make it
  usable as part of the devscripts packages. Maybe however we want more
  configurability (like the in-toto support or other stuff which was
  added to NYU's srebuild fork) and this wont work in the long term.

- I think I'd like "something working most or even half the time"
  installable in Debian unstable by the end of the month. This is long
  overdue. (tm)
  (Only halfworking would be fine (for a start) for me cause there are
  quite some special cases, like binNMUs or support for unclean build
  envs or whatever.)

- I think I want(ed) to package the debrebuild script, as this is josch's
  reimplementation of the same problem. And I thought NYU had some
  patches on top of this and I was thinking to sort out this fork later
  (eg by making some of their features optional), but now I've seen that
  they forked the old srebuild script and I'm unsure what to do.

Comments, suggestions or any other feedback much welcome!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

bit by bit identical chroot creation (was Re: Debian and our frenemies of containers and userland repos)

[Holger Levsen]

Hi,

this just went by on debian-devel@l.d.o:

On Mon, Oct 07, 2019 at 01:43:18PM +0200, Johannes Schauer wrote:
[...]
> Downloading "random binary from the internet" is less of a problem if we can
> create images which are bit-by-bit identical to checksums that we can verify
> through a trusted service. This is also already provided by mmdebstrap:
> 
> $ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential unstable - 
> | sha256sum
> [...]
> f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6  -
> $ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential unstable - 
> | sha256sum
> [...]
> f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6  -

wow, neato, I wasn't aware of this. very cool!

I don't think debootstrap does this already, or does it?

And, does this work for mmdebstrap'ing buster too? (whether using
mmdebstrap from unstable or buster...)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: bit by bit identical chroot creation (was Re: Debian and our frenemies of containers and userland repos)

[Holger Levsen]

Hi josch,

On Tue, Oct 08, 2019 at 10:49:50AM +0200, Johannes Schauer wrote:
> > And, does this work for mmdebstrap'ing buster too? (whether using
> > mmdebstrap from unstable or buster...)
> lets find out!

hehe, thanks!

> $ sudo mmdebstrap --include=mmdebstrap,debootstrap,diffutils buster 
> ./debian-buster
> [...]
> $ sudo chroot ./debian-buster
> # cat /etc/apt/sources.list
> deb http://deb.debian.org/debian buster main
> deb http://deb.debian.org/debian buster-updates main
> deb http://security.debian.org/debian-security buster/updates main
> # SOURCE_DATE_EPOCH=1570522957 mmdebstrap --variant=minbase unstable - | 
> sha256sum
> [...]
> e43ab25109a1f9e73fcb9de698912e25d7402c2aef4445a46719621b517901bf  -
> # SOURCE_DATE_EPOCH=1570522957 mmdebstrap --variant=minbase unstable - | 
> sha256sum
> [...]
> e43ab25109a1f9e73fcb9de698912e25d7402c2aef4445a46719621b517901bf  -
> # SOURCE_DATE_EPOCH=1570522957 mmdebstrap --variant=minbase buster - | 
> sha256sum
> [...]
> a1f4bc1f1c8e4a8942a1cbeed61f02556533d0381de0f9befe618246fec08af7  -
> # SOURCE_DATE_EPOCH=1570522957 mmdebstrap --variant=minbase buster - | 
> sha256sum
> [...]
> a1f4bc1f1c8e4a8942a1cbeed61f02556533d0381de0f9befe618246fec08af7  -
> # SOURCE_DATE_EPOCH=1570522957 debootstrap --variant=minbase unstable 
> ./debian-unstable-A
> [...]
> # SOURCE_DATE_EPOCH=1570522957 debootstrap --variant=minbase unstable 
> ./debian-unstable-B
> [...]
> # diff -rq ./debian-unstable-A ./debian-unstable-B
> Files debian-unstable-A/var/cache/ldconfig/aux-cache and 
> debian-unstable-B/var/cache/ldconfig/aux-cache differ
> Files debian-unstable-A/var/log/alternatives.log and 
> debian-unstable-B/var/log/alternatives.log differ
> Files debian-unstable-A/var/log/bootstrap.log and 
> debian-unstable-B/var/log/bootstrap.log differ
> Files debian-unstable-A/var/log/dpkg.log and 
> debian-unstable-B/var/log/dpkg.log differ

I dont understand this:

a.) why do debian-unstable-A and -B differ, the sha256sums above are the
same? was that just typo and you ment stable?
b.) you boostrapped --variant=minbase here, while your original mail was
about --variant=essential. I take it that --variant=essential is
also unreproducible for buster?
c.) now I wonder if mmdebstrap from *stable* can also bootstrap a
reproducible unstable ?

& sorry for asking these questions instead of trying it myself...

> Since it is not crucial to have these files in a chroot after creating it 
> (they
> will all be re-created) mmdebstrap just removes them.

see above :)

> Obviously, mmdebstrap
> cannot do much about reproducibility coming from many other sources like
> database creation in maintainer scripts or issues like these:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917386
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917407

yeah, sure.

> Thanks!

very much likewise! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: bit by bit identical chroot creation (was Re: Debian and our frenemies of containers and userland repos)

[Holger Levsen]

Hi josch,

On Tue, Oct 08, 2019 at 11:34:23AM +0200, Johannes Schauer wrote:
> the sha256sums are the sums computed from the output of mmdebstrap on stdout
> (notice the pipe character in front of the sha256sum command). 

ah, thanks. Seems i got tricked into the thinking mmdebstrap would
output it results on stdout...

> Debootstrap is
> unable to produce a tarball by itself (which is sad because its easier to 
> check
> whether two tarballs are the same than checking whether two directories are 
> the
> same) so instead I put the debootstrap results into two directories and then
> diff them recursively.

right.

> > b.) you boostrapped --variant=minbase here, while your original mail was
> > about --variant=essential. I take it that --variant=essential is
> > also unreproducible for buster?
> 
> No, --variant=essential is also *reproducible* on buster.

oh, very nice!

> But I didn't use it
> this time because we are comparing with debootstrap and debootstrap doesn't
> know how to create a chroot with only Essential:yes packages in it, so the
> comparison would be unfair. With --variant=minbase give to both commands, we
> install the same package set and thus make the results a more fair comparison.

ah, thanks.

> > c.) now I wonder if mmdebstrap from *stable* can also bootstrap a
> > reproducible unstable ?
> Yes it can. You already wondered that in your earlier email so I included the
> test in my commands above.

ah, thanks. & very cool!

> > & sorry for asking these questions instead of trying it myself...
> No problem. :)

:)

I've now updated the draft for the 201910 report to read:

Johannes 'josch' Schauer explained that
[mmdebstrap](https://tracker.debian.org/mmdebstrap) can [create bit by
bid identical Debian chroots of unstable and
buster](https://lists.debian.org/debian-devel/2019/10/msg00101.html),
for both the --variant=essential and --variant=min
base variants.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: Cloning reproducible-builds environment

[Holger Levsen]

Hi Jeff,

thanks for caring about reproducible builds and getting back to us!

On Thu, Oct 24, 2019 at 06:35:15PM +0200, Jeff wrote:
> I'm trying to fix the FTBFS that is reported here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gscan2pdf.html
> 
> Having fixed the tests due to timezone issues, I am left with a couple
> of tests which are going to be really hard to debug without interactive
> access.
> 
> I already test in an unstable chroot with sbuild
> 
> How can I adapt this to use the environment from reproducible-builds?

it wont be exactly the same but reprotest (from the package with that
name) should let you test more variations than just using plain sbuild.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Bug#944882: diffoscope: please (at least) include hint in html that text version has no max report size

[Holger Levsen]

Package: diffoscope
Version: 1.30
Severity: minor

Dear diffoscope maintainers,

(some aspects of) the current behavior of diffoscope and 'max report size' is
as:

- only considered for html output, but not for text (where it is unlimited),
  default is 400kb max.

I'd like to suggest:

- increase the default max to 1024kb or maybe 2mb? (actually, why not
  more? why a limited default?)
- include a hint in the html output that the text output is not limited
  in size. (if html hits the max. not sure if once or at every truncated
  occasion.)


Thanks for your considerations & all the shiny code!

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: Cloning reproducible-builds environment

[Holger Levsen]

Hi Jeff,

sorry for the delay in responding...

On Tue, Dec 03, 2019 at 07:05:22PM +0100, Jeff wrote:
> On 24/10/2019 20:24, Holger Levsen wrote:
> > it wont be exactly the same but reprotest (from the package with that
> > name) should let you test more variations than just using plain sbuild.
> 
> Thanks for replying so quickly and for the pointer to reprotest. Now my
> package builds the first time, I still have the problem that the tests
> fail in the second build.
> 
> Making a change, and waiting for my package to build 1.5 times is not a
> fast debugging process!
> 
> How can I get reprotest to run the second build first?

what version of reprotest were you using? (newer versions dont use
faketime for the 2nd build, which likely has been causing your
problems.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: notes repository shared with all DDs

[Holger Levsen]

On Sat, Jan 11, 2020 at 03:33:08PM +0100, Mattia Rizzolo wrote:
> I just shared the notes repository¹ with the "Debian" group, therefore
> giving all DDs write access to it.
> It's my attempt to invite more direct contributions instead of MRs :)

neato, very & many thanks for doing this too!

(and a bit surprising how we havent done this four or two years ago already :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Bug#942146: koji: CVE-2019-17109

[Holger Levsen]

Hi Salvatore,

On Sun, Jan 05, 2020 at 09:02:20PM +0100, Salvatore Bonaccorso wrote:
> Any news on this issue? AFAICT, the issue is fixed as well in 1.16.3,
> so the smaller jump should be possible. Once fixed in unstable, can
> you adress the issue as well via point release?

I think it's pointless to have 1.16.x in unstable and newer koji needs
newer dnf (and some other stuff, iirc), which isnt packaged in Debian,
so this is not as straightforward as it seems.

I'm also not sure there are many (or any?) users of koji from stable. If
I were to use it, I would use koji from Fedora...
https://qa.debian.org/popcon.php?package=koji seems to confirm this.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Bug#942146: koji: CVE-2019-17109

[Holger Levsen]

On Thu, Jan 23, 2020 at 08:42:03PM +0100, Moritz Muehlenhoff wrote:
> Let's remove it in the upcoming stretch/buster point releases, then?

seems reasonable to me.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

On Tue, Jan 28, 2020 at 11:21:46PM -0500, Sandro Tosi wrote:
> ok, whos of the maintainers is working on packaging 1.18? i see
> there's even 1.20 released.

noone, I believe. Also because it needs dnf, which is not packaged for
Debian at all.

I was just going to remove myself from uploaders in git and pushed my
work-in-progress branch wip-python3. and then i also pushed it into the
master branch. sigh

> koji is keeping createrepo in the archive, which keeps python-lzma in
> the archive.

there's also mock, yum, rpm, deltarpm and yum-metadata-parser affected by this.

> upgrading koji will help getting rid of some old python2 packages.

dropping it, at least for now, seems to be the best way foreward here :/


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

On Thu, Jan 30, 2020 at 01:36:33AM -0500, Sandro Tosi wrote:
> yep i came across all of them starting from python-lzma -- do you know
> what's the status of the "RedHat infrastructure" in debian? many (if
> not all) of those tools are relatively old, not maintained (or just in
> life support mode) and most of all, python2 with no port to python3
> available

as said: dnf needs to be packaged first and foremost. (dnf is the yum
replacement.)

> Allright then, i'll just wait a week for allowing people to comment
> and then i'll file for koji removal.

RM bugs to remove koji from stable and oldstable have already been
filed, and it's not in bullseye.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

On Thu, Jan 30, 2020 at 09:55:58AM -0500, Sandro Tosi wrote:
> i was mostly querying the status of it, i cant even find an ITP for dnf.

exactly.

> i was talking about removing koji entirely from debian, an RM to
> ftp.d.o; is that not what you mean?

right, this is also in order.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



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

Re: Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

On Thu, Feb 13, 2020 at 08:14:11PM -0500, Sandro Tosi wrote:
> thanks! I'm gonna go ahead and file an RM bug for the following pkgs
> too: yum createrepo python-lzma yum-metadata-parser mock yum-utils
> dtc-xen deltarpm
> 
> they are a closed set

thank you for cleaning up after all of us, now that we reached containers.
(which used to be called virtualisation mainframes before... ;) 

I mean, rpm is definitly still useful to have on Debian, but yum and friends???


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


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

Re: Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

Hi,

On Fri, Feb 14, 2020 at 03:12:20AM +0100, Marek Marczykowski-Górecki wrote:
> > I mean, rpm is definitly still useful to have on Debian, but yum and 
> > friends???
> They are also useful in some cases. For example if you want to use
> Debian-based VM to download updates for your Qubes dom0...

hah, touche!

so for the record: while I can easily workaround the above problem by using a
Fedora based VM to download updates for my Qubes dom0, I'd be glad to help
people to get yum, dnf and rpm back into Debian, eg by sponsoring such uploads.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

hi Guillem,

On Fri, Nov 09, 2018 at 11:55:38AM +0100, Guillem Jover wrote:
> Actually, I guess the other option that might be an option for stable is
> to make dpkg-buildpackage generate the buildinfo file itself, and on
> source-only uploads force the name to be _source.buildinfo regardless
> of the options passed down to dpkg-genbuildinfo (even if the contents
> will end up not matching the name).
> 
> This would seem rather less intrusive, as that only changes the
> behavior in a "corner-case" (even though documented and recommended
> one), when using «dpkg-buildpackage --changes-option=-S». And while it
> could be considered to produce confusing filenames, it sticks to the
> current pattern. It would also fix the other bug where running
> dpkg-genbuildinfo leaves debian/files around, even on source only
> builds.
> 
> So, I might go with that instead.
 
any update on this?

the security team people still have to workaround this manually regularily, eg
today, and would really like to see this fixed...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


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

Re: Bug#936806: koji: Python2 removal in sid/bullseye

[Holger Levsen]

On Sun, Feb 23, 2020 at 04:06:23PM +0100, Marek Marczykowski-Górecki wrote:
> > so for the record: while I can easily workaround the above problem by using 
> > a
> > Fedora based VM to download updates for my Qubes dom0, I'd be glad to help
> > people to get yum, dnf and rpm back into Debian, eg by sponsoring such 
> > uploads.
> Mihai have prepared packages for all of them and sent mail about it to
> debian-devel here:
> https://lists.debian.org/debian-devel/2019/09/msg00218.html

ah, cool!

& thanks for the reminder, Marek!

> But he never get any response there...
> I guess the next step would be someone to help him upload the packages to
> Debian.

added to my list, though i suspect it will take two weeks until i get to it...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

we'll all die. make a difference while you can. disobey. smile.


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

Bug#955049: debrebuild: no manpage and no --help option

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: normal
x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

debrebuild has no manpage and no --help option, so it's a bit hard to get
started using it.

Please add both.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

we'll all die. make a difference while you can. disobey. smile.


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

Bug#955050: debrebuild: please accepted signed .buildinfo files

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: normal

Dear Maintainer,

please make debrebuild not fail on signed .buildinfo files:

$ debrebuild bash_5.0-6_amd64.buildinfo
debrebuild: error: syntax error in bash_5.0-6_amd64.buildinfo at line 1: 
OpenPGP signature not allowed here


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


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

Bug#955051: debrebuild: Build-Architecture fields are optional but debrebuild mandates them

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: normal

Dear Maintainer,

$ debrebuild bash_5.0-6_amd64.buildinfo
Use of uninitialized value in split at /usr/bin/debrebuild line 55.
need Build-Architecture field at /usr/bin/debrebuild line 70.
$

It seems that debrebuild needs a Build-Architecture field while not all
.buildinfo files have them.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...


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

Bug#955123: debrebuild: please provide --sbuild-output-only option

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: wishlist

Dear Maintainer,

when running debrebuild it produces output, first instructions how to rebuild
manually and second, how to rebuild using sbuild.

For automating this it would be very useful to have a --sbuild-output-only
switch, which would just do that.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


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

Bug#955280: debrebuild: please stop using the reproducible-builds.org apt repo

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: normal

Dear Maintainer,

$ grep reproducible /usr/bin/debrebuild 
my $armored_key   = "$tempdir/etc/apt/trusted.gpg.d/reproducible.asc";
my $dearmored_key = "$tempdir/etc/apt/trusted.gpg.d/reproducible.gpg";
"https://tests.reproducible-builds.org/debian/repository/reproducible.asc";,
die "got http $http_code when trying to retrieve reproducible.asc\n";
"https://tests.reproducible-builds.org/debian/repository/reproducible.gpg";,
die "got http $http_code when trying to retrieve reproducible.gpg\n";
deb https://tests.reproducible-builds.org/debian/repository/debian/ ./

The apt repo at https://tests.reproducible-builds.org/debian should not be
used by debrebuild at all, please drop all code related to it.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


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

Bug#955298: debrebuild: please switch from httpredir.d.o to deb.d.o

[Holger Levsen]

Package: devscripts
Version: 2.19.5+deb10u1
Severity: wishlist
x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

please switch from using httpredir.debian.org to deb.debian.org:

$ grep httpredir /usr/bin/debrebuild 
deb http://httpredir.debian.org/debian/ $base_dist main


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


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

Bug#955304: debrebuild: suggested sbuild command should use --no-run-lintian

[Holger Levsen]

Package: devscripts
Version: 2.19.5+deb10u1
Severity: wishlist

Dear Maintainer,

Subject says it all: debrebuild should suggest (or run, see #955123) to use
the --no-run-lintian switch for sbuild.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


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

Bug#955307: debrebuild: should avoid downgrades

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: normal

Dear Maintainer,

this bug report is a bit premature, as currently debrebuild does not setup
the chroot debrebuild (or rather the sbuild command generated by debrebuild),
but anyway, let's file a bug to track this problem and improve upon:

I just tried to rebuild bash 5.0.6 for amd64, which was built on February 25th
2020, using a sid schroot created today. This resulted in many downgrades by
sbuild (as invoked by debrebuild) which in this case (by luck) worked nicely,
but downgrading packages is neither supported by design nor testing, thus
should be avoided.

Thus it would be fantastic if debrebuild would start with a buster schroot
and upgrade that to the packages needed to build bash 5.0.6 for amd64. (With
the logic being: this is a rebuild for a package from unstable built in 
February 2020, thus the build base should be the stable release at that time.)

Currently this is nothing debrebuild can do, but for a future standalone
rebuilder tool this will be a very nice feature.

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...


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

Bug#955308: debrebuild: also explain *how* to use snapshot.d.o

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: wishlist

Dear Maintainer,

debrebuild uses snapshot.d.o to install packages and it also gives some hints
how to set up sbuild. However it doesn't tell that apt has to be instructured
to ignored expires signatures, as else snapshot.d.o is not usuable as an apt
repo.

So debrebuild should explain how to configure apt:

echo 'Acquire::Check-Valid-Until "false";' | sudo tee 
/srv/chroot/unstable-amd64/etc/apt/apt.conf.d/23-debrebuild


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


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

Bug#955434: tracker.d.o: please integrate information from buildinfos.debian.net

[Holger Levsen]

Package: tracker.debian.org
Severity: wishlist

Dear Maintainer,

please integrate information from buildinfos.debian.net into tracker.d.o,
which is a different view/aspect of reproducible builds of Debian packages than
the one currently integrated.

The current one is about the results from tests.reproducible-builds.org/debian
and shows the theoretical reproducibility of a given package. (Two builds are
done and compared.)

The information we would like to have integrated into tracker.d.o is a
link to .buildinfo files for source packages, based on the architecture
the build was done. These .buildinfo files are available on 
buildinfos.debian.net, here's some more background information on
that service:

https://buildinfos.debian.net/ provides .buildinfo files for packages
distributed on ftp.debian.org. Two views are available:

https://buildinfos.debian.net/ftp-master.debian.org/ is a public copy
of /srv/ftp-master.debian.org/buildinfo/ from ftp-master.debian.org.
This data is organized by build dates, which is little useful to most.

https://buildinfos.debian.net/buildinfo-pool/ provides a pool structure
of this data, for example to 
https://buildinfos.debian.net/buildinfo-pool/libf/libfakekey/libfakekey_0.1-10_hurd-i386.buildinfo

https://buildinfos.debian.net/buildinfo-pool.list is one 66mb file,
listing all currently known .buildinfo for Debian packages distributed
via ftp-master.d.o since 2016-12-22.

This excludes
- builds done before 2016-12-22.
- builds not done on buildds.
- security updates not yet re-released via a point update.
- and probably some more.

In future we probably would like to export a json dump of a postgresql
db, so that the data will become easier to parse. Not sure if this is
needed for the tracker.d.o side to get started?

Feedback welcome!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#958666: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning

[Holger Levsen]

package: lintian
version: 2.67.0
x-debbugs-cc: Debian Med Project List , Debian 
Developers , Debian Lintian Maintainers 
, reproducible-bui...@lists.alioth.debian.org

On Fri, Apr 24, 2020 at 09:56:24AM +0200, Andreas Tille wrote:
> today I've seen the first time this new lintian warning:
> 
>mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team 
> 
> 
> I wonder whether we could this set from severity Warning to Pedandic.

definitly, yes, filing this bug now.

> The point is that this address works not only as maintainer but rather
> as key in several infrastrutural use case like database queries etc.
> The only reason that would convince me that a change is needed would be
> that the redirect to alioth-lists.debian.net would not work any more at
> some foreseable point of time.  So please note:  I would not mind about
> automatically replacing that address with something non-obsolete since
> we try to do some turnover of all (about 1000) Debian Med packages per
> release.  But once we start this change several tools will stop working
> reliably.  This is to much effort for something that looks cosmetical in
> my eyes.  So if you insist that this should be at severity warning I'll
> probably rather add a lintian override automatically for all our
> packages rather than automatically change the maintainer address.

we also still use reproducible-bui...@lists.alioth.debian.org as our maintainer
address for Reproducible Builds related packages and it's our advertised point
of contact for Debian related Reproducible Builds stuff and we don't have
any plan to change this any time soon.

It's true that some @lists.alioth.debian.org stopped working but *many* have
been migrated to alioth-lists.debian.net and continue to work as 
@lists.alioth.debian.org so this lintian warning creates tons of non-actionable
and doubtful (not to say false-positive) warnings.

Please change this and thank you for maintaining lintian!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


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

Bug#958750: debrebuild: please add --standalone mode or --one-shot-mode

[Holger Levsen]

Package: devscripts
Version: 2.20.2
Severity: wishlist
x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

debrebuild expects a working sbuild setup, which is a sensible expectation.
It would however also be nice if it had a --standalone mode or --one-shot-mode
which would setup sbuild (or even pbuilder) as needed, use it and destroy
that configuration (the chroot or base.tgz) again.

Besides a nicer user experience for casual or first time users this would
also allow to be re-used for an 'debrebuild --init-setup' switch ;)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


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

Re: Update blacklist for armhf

[Holger Levsen]

Hi Vagrant,

On Tue, Apr 28, 2020 at 03:38:40PM -0700, Vagrant Cascadian wrote:
> As mentioned on irc to holger and mattia, I reviewed packages that ought
> to get blacklisted on armhf, as they almost always timeout on builds, so
> they consume CPU, RAM and disk that could be better used testing other
> packages. I'll probably propose more after further review, but figured
> I'd send these along now, since I already had the list and already
> reviewed them.

cool!

> Another point; while I have access to jenkins.debian.net, I apparently
> don't have the permissions and/or know-how necessary to update the
> database with the blacklists (tried running
> ./bin/reproducible_blacklist.sh, but got some database permission
> errors).

how exactly did you try to run it?

here's what I did:

jenkins@jenkins:~$ for suite in stretch buster bullseye unstable experimental ; 
do /srv/jenkins/bin/reproducible_blacklist.sh armhf $suite eigen3 flang 
freedict gcc-7 gcc-8 gcc-9 gcc-10 gcc-snapshot ; done

Wed 29 Apr 08:29:08 UTC 2020 - running 
/srv/jenkins/bin/reproducible_blacklist.sh (for job ) on jenkins, called using 
"armhf stretch eigen3 flang freedict gcc-7 gcc-8 gcc-9 gcc-10 gcc-snapshot" as 
arguments.
[...]
=
The following 2 source packages from stretch/armhf have been blacklisted: 
eigen3 freedict
=
[...]
=
The following 5 source packages from buster/armhf have been blacklisted: eigen3 
flang freedict gcc-7 gcc-8
=
[...]
=
The following 5 source packages from bullseye/armhf have been blacklisted: 
eigen3 freedict gcc-8 gcc-9 gcc-10
=
[...]
=
The following 7 source packages from unstable/armhf have been blacklisted: 
eigen3 flang freedict gcc-8 gcc-9 gcc-10 gcc-snapshot
=
[...]
jenkins@jenkins:~$ 

(For future reference: this is also documented in j.d.n.git/README.)

I'm pondering to also blacklist gcc* on i386... what do you think?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


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

Re: Update blacklist for armhf

[Holger Levsen]

hi,

On Wed, Apr 29, 2020 at 11:15:11AM -0700, Vagrant Cascadian wrote:
> Thanks! Should be able to handle future updates myself now!

:) great. feel free to also blacklist some big packages on i386, which is
also lagging quite a bit behind.
 
> Running as the "jenkins" user was what I was missing. I'll try to review
> the documentation and update to make this clearer, if needed.

I believe the whole reproducible-builds.org related part of this documentation
should probably be moved into README.reproducible-builds.org.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


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

Re: M2-Planet v1.6.0 and mescc-tools v1.0.0 released

[Holger Levsen]

On Sat, May 02, 2020 at 08:58:47AM +0200, Jan Nieuwenhuizen wrote:
> > A K+R C equivalent C compiler, assembler, linker, dwarf stub generator
> > and shell able to produce fully standards compliant ELF binaries for
> > Knight, x86, AMD64, armv7l and aarch64 and be bootstrapped from a sub
> > 250byte hex0 hex assembler and a 737byte shell
> Congratulations on this beautiful release; an amazing piece of work!

indeed! applause for reaching v1.0.0!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#961064: reprotest: use of faketime causes newly created file to have very old modified time

[Holger Levsen]

control: retitle -1 reprotest: should not default to vary time and date
thanks

Hi James,

thanks for your bug report!

On Tue, May 19, 2020 at 02:49:58PM -0400, James Valleroy wrote:
> time(): 1631998736
> touch($cacheFile);
> clearstatcache();  // has no effect
> filemtime($cacheFile): 1589907896
> touch("debug-reprotest");  // a new file, see that it behaves the same way
> filemtime("debug-reprotest"): 1589907896
> 
> The difference between time() and filemtime($cacheFile) is 487+ days,
> the same value is shown passed to faketime in the log.

I'm not sure if this is a bug in reprotest or faketime, however we know about
several scenarios where faketime breaks stuff, thus reprotest should not
vary time and date by default, so that reprotest can be run more easily
and more successfullly in CI tests.

Maybe it's worth to clone this bug and fix the underlying issue too, dunno.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


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

Re: [announce] diffoscope 144 released

[Holger Levsen]

Dear Chris,

On Thu, May 14, 2020 at 10:58:03PM -, Chris Lamb wrote:
> The diffoscope maintainers are please to announce the release of
> version 145 of diffoscope.

\o/
 
> diffoscope tries to get to the bottom of what makes files or
> directories different. [...]
> Version 145 includes the following changes: [...]

I also very much like this new verbose announcement! Thank you for this nice
new change!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#961857: reproducible-check: incomprehensive and too good results

[Holger Levsen]

Package: devscripts
Version: 2.20.3
x-debbugs-cc: reproducible-builds@alioth-lists.debian.net

Hi,

on a sid system I get this when running reproducible-check from devscripts:

$ reproducible-check
alsa-lib (1.2.2-2.1) is unreproducible (libasound2) 

apt (2.1.5) is unreproducible (apt, apt-utils, libapt-pkg6.0) 

autogen (1:5.18.16-4) is unreproducible (libopts25) 

bind9 (1:9.16.2-3) is unreproducible (bind9-host, bind9-libs) 

binutils (2.34-8) is unreproducible (binutils, binutils-common, 
binutils-x86-64-linux-gnu, libbinutils, libctf-nobfd0, libctf0) 

boost1.67 (1.67.0-18) is unreproducible (libboost-date-time1.67.0, 
libboost-filesystem1.67.0, libboost-iostreams1.67.0, libboost-locale1.67.0, 
libboost-system1.67.0, libboost-thread1.67.0) 

emacs (1:26.3+1-2) is unreproducible (emacs-bin-common) 

gcc-8 (8.4.0-4) is unreproducible (gcc-8-base, libmpx2) 

gcc-9 (9.3.0-13) is unreproducible (cpp-9, g++-9, gcc-9, gcc-9-base, libasan5, 
libgcc-9-dev, libstdc++-9-dev) 

gettext (0.19.8.1-10) is unreproducible (gettext, gettext-base) 

guile-2.2 (2.2.7+1-5) is unreproducible (guile-2.2-libs) 

libtheora (1.1.1+dfsg.1-15) is unreproducible (libtheora0) 

libtommath (1.2.0-3) is unreproducible (libtommath1) 

libtool (2.4.6-14) is unreproducible (libltdl-dev, libltdl7) 

m4 (1.4.18-4) is unreproducible 

mariadb-10.3 (1:10.3.22-1) is unreproducible (libmariadb3) 

perl (5.30.2-1) is unreproducible (libperl5.30, perl, perl-base) 

pkg-config (0.29.2-1) is unreproducible 

python2.7 (2.7.18-1) is unreproducible (libpython2.7, libpython2.7-minimal, 
libpython2.7-stdlib, python2.7, python2.7-minimal) 

python3.8 (3.8.3-1) is unreproducible (libpython3.8, libpython3.8-minimal, 
libpython3.8-stdlib, python3.8, python3.8-minimal) 

sudo (1.9.0-1) is unreproducible 

volume-key (0.3.12-3.1) is unreproducible (libvolume-key1) 

webkit2gtk (2.28.2-2) is unreproducible (libjavascriptcoregtk-4.0-18, 
libwebkit2gtk-4.0-37) 
xorg-server (2:1.20.8-2) is unreproducible (xserver-xorg-core, 
xserver-xorg-legacy) 
72/3141 (2.29%) of installed binary packages are unreproducible.
user@talk:~$ dpkg -l | wc -l
1472
user@talk:~$ 

IOW, I have 1472 packages installed, yet reproducible-check claims 72/3141 of 
installed binary packages are unreproducible.

This doesn't match up.

Then, I'm also not sure if I see 72 packages in the output above :)

And finally and foremost, 97.71% reproducible packages seems to be a bit high.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


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

Bug#961858: reproducible-check: should be explicit about just showing CI results

[Holger Levsen]

Package: devscripts
Version: 2.20.3
Severity: normal

hi,

reproducible-check shows how many of the installed binary packages are
(un)reproducible in our current CI framework, that is these results only
show the theoretical reproducibility of these Debian pacakges, they 
*do not* however show any real values. So this should be made very clear.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Bug#961859: reproducible-check: should not show results on Ubuntu and other distros != Debian

[Holger Levsen]

Package: devscripts
Version: 2.20.3
Severity: normal
x-debbugs-cc: reproducible-builds@alioth-lists.debian.net


hi, 

reproducible-check should not show any results on Ubuntu as Ubuntu is not
involved in Reproducible Builds and not doing any efforts. TTBOMK they also
don't publish their .buildinfo files so doing reproducible builds of 
Canonical released Ubuntu packages is also not possible at the moment.

Thus reproducible-check should not show results when running on Ubuntu
or actually any other distro != Debian.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


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

Bug#961861: debrebuild: should (optionally) download the source too

[Holger Levsen]

Package: devscripts
Version: 2.20.3
Severity: normal

Dear Maintainer,

even though current .buildinfo files in Debian don't contain the hashes of the
source package (as we mandated in our original design) it would be great if
debrebuild could, at least optionally also download the source packages.

The .buildinfo file contains the name of the source and the version, so this 
should be easy.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


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

Bug#961862: debrebuild: should assemble the source for binNMUs

[Holger Levsen]

package: devscripts
Version: 2.20.3
Severity: normal
x-debbugs-cc: reproducible-builds@alioth-lists.debian.net

Dear Maintainer,

TTBOMK currently there is no tool to assemble the source for a binNMU. The 
source for a binNMU has do be assembled like this:

- take the normal source package and unpack it
- extract the d/changelog stanza from the .buildinfo file in question and
  concatenate that with d/changelog from the source package.
- use dpkg-source to build the source package.

It would be great if debrebuild would this if instructed to.

"#961861 «debrebuild: should (optionally) download the source too»" is a
blocker/requirement to fix this bug.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


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

Bug#961864: debrebuild: creates wrong commandline for binNMUs

[Holger Levsen]

Package: devscripts
Version: 2.20.3
Severity: normal

Dear Maintainer,

debrebuild creates wrong commandlines for binNMU, because the source field
in .buildinfo files looks different for binNMUs than normal uploads.

Normal uploads have these entries:

Source: libqcow
Version: 20181227-1.1

binNMUs these:

Source: libqcow (20181227-1.1)
Version: 20181227-1.1+b1

and then debrebuilds creates instructions like these:

"And then build your package:

dpkg-source -x ./libqcow (20181227-1.1)_20181227-1.1+b1.dsc
" and similarily the constructed sbuild commandline refers to 
./libqcow (20181227-1.1)_20181227-1.1+b1.dsc which is not a legit filename here.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


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

Re: Enabling -ffile-prefix-map by default

[Holger Levsen]

Hi,

I'm very glad to see this moving forward!

On Sat, Jun 06, 2020 at 03:21:06PM -0700, Vagrant Cascadian wrote:
> We'd be able to get more accurate data if we remove the flag for
> bullseye and manually schedule all of those packages, at least
> temporarily... anyone have concerns with doing that and waiting for the
> builds to complete before bringing this up on debian-devel?

absolutly please go ahead!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


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

Re: Enabling -ffile-prefix-map by default

[Holger Levsen]

On Fri, Jun 12, 2020 at 02:27:50PM -0700, Vagrant Cascadian wrote:
> I've pushed to git:
>   
> https://salsa.debian.org/qa/jenkins.debian.net/-/commit/f2a447eacfe375951476f369c8b61f02891d97c7

cool, thanks.
 
> Refreshing my memory on how to deploy it by reading the docs... once
> that's done, we can reschedule builds for affected packages.

$ git push
$ ./deploy_jdn all

(the latter command just like the git push has to be run from inside the
jdn.git)

I've did this now.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Enabling -ffile-prefix-map by default

[Holger Levsen]

Hi Vagrant,

interesting findings!

On Tue, Jun 16, 2020 at 10:03:24PM -0700, Vagrant Cascadian wrote:
> > Many of them appear to go from FTBFS to reproducible, FWIW.

nice. what is your general recommendation/plan for the next action item here?

> The packages that seem to have been "fixed" were rebuilt recently (maybe
> Holger noticed this issue and triggered rebuilds for those too?).

I haven't done anything (here) :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"There's no glory in prevention." - well, yes, though *I* am thankful for it.


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

Re: Enabling -ffile-prefix-map by default

[Holger Levsen]

On Mon, Jun 22, 2020 at 05:04:54PM -0700, Vagrant Cascadian wrote:
> On 2020-06-17, Holger Levsen wrote:
> > interesting findings!
> >
> > On Tue, Jun 16, 2020 at 10:03:24PM -0700, Vagrant Cascadian wrote:
> >> > Many of them appear to go from FTBFS to reproducible, FWIW.
> >
> > nice. what is your general recommendation/plan for the next action item 
> > here?
> Well, the FTBFS would be if we enable the flag, so not exactly *nice*

I was referring to the low number of ftbfs and the fact that we have that
data now.

> ... but at least it's identified issues as opposed to unknowns.

exactlty.

> I'm not as confident about the data as my initial response in this
> thread (e.g. made some false assumptions at first) ... but we do have
> more data now, and we're looking at hunreds of packages building
> reproducibly vs. tens of packages FTBFS.

is there anything which can be done to increase your confidence?

> Personally a little shy about posting to debian-devel; I don't normally
> follow it at all.

just prepare a mail in a new thread to *this* list, and cc: -devel?! ;)

> Maybe we should also bring the dpkg folks back into the thread (or are
> they subscribed and still here? :)

Guillem replied in this thread three weeks ago, so I'm assuming he's reading
this list. :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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

Re: Debonf20 Online talk proposal?

[Holger Levsen]

On Sat, Jul 04, 2020 at 04:16:37PM -0700, Vagrant Cascadian wrote:
> Has anyone already submitted a Reproducible Builds talk proposal for
> Debconf20 (which is now, unsurprisingly, scheduled to take place
> online)?
[...]
> There is a dealine of July 5th!

not yet, but I will within the next 4h.

> I could put something together quick if needed, but timezone skew might
> make it hard to make the deadline...

I'll resubmit my proposal from the minidebconf online in May.

Also I'd be glad to try to do the talk with several people, like we
always did at DebConfs...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


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