Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Holger Levsen]

On Thu, Apr 12, 2018 at 10:09:44PM +0200, Emilio Pozuelo Monfort wrote:
> On 12/04/18 21:41, Holger Levsen wrote:
> > control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy 
> > no-change-except-d/changelog-uploads"
> > # I hope this is correct, realistic and accurate ;)
> > # if not, please fixup?
> > #thanks
> Removing binNMUs would be a problem whenever we need to do a large amount of
> rebuilds on just one architecture, e.g. due to a toolchain bug, a baseline 
> bump,
> or other reasons.

sure, hence the word "easy" in the bug title.


-- 
cheers,
Holger


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

Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Holger Levsen]

control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy 
no-change-except-d/changelog-uploads"
# I hope this is correct, realistic and accurate ;)
# if not, please fixup?
#thanks

-- 
cheers,
Holger


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

Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Holger Levsen]

On Thu, Apr 12, 2018 at 02:10:37PM +0200, Guillem Jover wrote:
> Please, see my reply at . This is
> really a fundamental problem with binNMUs+multiarch-refcounting or how
> they are being issued. :)

FWIW I totally agree with what you wrote there, just that I dont see
other people agreeing so sadly I currently don't see this fixed anytime
soon. Which is pretty sad.


-- 
cheers,
Holger


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

Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Holger Levsen]

On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> So, during compilation:
> SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> because it breaks Multi-Arch:same on bin-nmu.
> 
> During dpkg-deb (:
> SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> because it would break software relying on files mtime.
> 
> Doh!

different ways of parsing debian/changelog to determine S_D_E is a road
to desaster, sorry.

> In https://bugs.debian.org/843773#75 Ian Jackson propose to introduce a 
> BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) be prefered over 
> SOURCE_DATE_EPOCH by dpkg-deb.
> 
> That would work, wouldn't it?

I'm also not convinced this would be a good solution.

Sadly I also don't have another idea than changing the way binNMUs are
done :( Them being no-source-changes-rebuilds with changes to
debian/changelog, which is part of the source, (IMNSHO) is poor design
and the root of this and other problems.


-- 
cheers,
Holger


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

Bug#893702: Please stop build-depending on pdftk

[Holger Levsen]

control: severity -1 important
thanks

On Wed, Mar 21, 2018 at 08:38:31PM +0800, Matthias Klose wrote:
> pdftk still still depends on GCJ, and is likely to be removed when gcj is
> removed. Please stop build-depending on pdftk.

thanks for warning us, Matthias! I'm lowering the severity until gcj has
been removed.


-- 
cheers,
Holger


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

Bug#893324: diffoscope: terminology used in docs about exclusion options

[Holger Levsen]

On Tue, Mar 20, 2018 at 10:20:45AM +0800, Paul Wise wrote:
> How about removing the "/ignore" and adding sentences like these:
> 
> Use this option to ignore files based on their names.
> Use this option to disable commands that use a lot of resources.
> Use this option to ignore permissions, timestamps, xattrs etc.

sounds good to me.


-- 
cheers,
Holger


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

Bug#893324: diffoscope: terminology used in docs about exclusion options

[Holger Levsen]

On Sun, Mar 18, 2018 at 01:26:32PM +0800, Paul Wise wrote:
> >  $ diffoscope --no-progress --exclude-directory-metadata a b
> Lets turn this into a bug about that instead. I would suggest replacing
> "Exclude" with "Exclude/ignore" within the docs about the options that 
> exclude some parts of the diffoscope output.

"Exclude/ignore" doesnt read nicely. Given the option is called
'exclude...' already, we could probably just explain that this causing
'ignore', so people will still find it using both terms.


-- 
cheers,
Holger


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

Re: pocl has reproducible test result: FTBFS

[Holger Levsen]

Hi Andreas,

thanks for reaching out!

On Sun, Mar 18, 2018 at 08:46:14AM +0100, Andreas Beckmann wrote:
> https://qa.debian.org/developer.php?login=pkg-opencl-devel%40lists.alioth.debian.org
> 
> lists pocl as FTBFS from reproducible test results ... which is correct
> (it does FTBFS on armhf/arm64) but worthless information (so far it
> never built successfully (due to testsuite failures) on !x86).
> 
> Where can this be fixed? No, not on the pocl side :-)

we can mark it with a special issue, which causes qa.debian.org to not
display this ftbfs case. i'm about to enter a plane so I wont do it
right now, but will do so later, unless someone else will do it til
then.


-- 
cheers,
Holger, quite sleepy


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

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

[Holger Levsen]

On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> Any news regarding this proposal from Ansgar? We were biten now
> several times already by this (e.g. php update, curl via
> security.d.o).

Guilem, what's your stance on this bug?

We (reproducible builds) really dont want "our" tools (=.buildinfo files)
to cause grief to other teams in Debian, and especially not on a regular
basis... so as a first step to fix this, I'd like to collect opinions
how to best fix this issue here.


-- 
cheers,
Holger


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

Re: Fwd: [migration of alioth list reproducible-commits]

[Holger Levsen]

On Mon, Jan 29, 2018 at 09:55:36PM +0100, Mattia Rizzolo wrote:
> So, I'm going to ask them to skip our list, and then in the next weeks
> work on moving stuff to rb-commits@ instead (this will also include
> moving the subscribers once the mails moved).

explicitly cc:ing lunar (for potager.org), for confirmation that this plan is
sensible and doable.


-- 
cheers,
Holger


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

Re: Fwd: [migration of alioth list reproducible-commits]

[Holger Levsen]

On Sun, Jan 28, 2018 at 11:58:34PM +0100, Mattia Rizzolo wrote:
> It's my opinion that we should kill
> reproducible-comm...@lists.alioth.debian.org and instead start to more
> effectively use rb-comm...@lists.reproducible-builds.org.
> 
> After all most of the commits we do are not directly tied to debian
> itself.  Alright, the most prominent user of that list is the notes.git
> repo, which currently it's still debian-only, but I still believe we
> should move stuff there.

agreed. thanks for presenting the options clearly.


-- 
cheers,
Holger


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

Re: Migration plans for lists.alioth.debian.org

[Holger Levsen]

Hi Dominic,

full quote for the benefit of
reproducible-builds@lists.alioth.debian.org

On Sat, Jan 27, 2018 at 02:29:46PM +, Dominic Hargreaves wrote:
> Dear fellow developers,
> 
> Following on from the announcement in September[1] and subsequent
> discussions[2] we are now in a position to announce further details
> of the replacement service for lists.alioth.debian.org.
> Whilst we recognise that most use cases will eventually served by
> other systems, given the widespread use of these lists it is
> desirable to provide some continuity beyond the alioth shutdown
> date.
> 
> The new service will be called alioth-lists.debian.net and will
> handle email sent to lists.alioth.debian.org after shutdown. It
> will be run by Debian Developers (currently Dominic Hargreaves,
> Alex Muntada and Bernhard Schmidt). Migration of lists will be to
> another mailman installation, with config, subscribers and archives
> all intact. An HTTP redirector will be provided by the DSA team so
> that existing archive URLs continue to work.
> 
> The date of the migration is yet to be fixed but will need
> to be be in late March or early April to ensure it is complete before
> the alioth system needs to be shut down.
> 
> This is not intended to supercede the advice to make use of other
> services where appropriate, such as lists.debian.org for eligible
> lists, tracker.debian.org or salsa, but does enable other lists
> such as package team maintenance lists, to have a home in the
> short term. The service will be reviewed for viability and
> usefulness after one release cycle, as the expectation is that
> over time many lists will find a natural home elsewhere.
> 
> Both to avoid migrating unused lists, and to ensure we migrate
> data with consent, we will only migrate lists where this has been
> specifically requested:
> 
> * One of the list owners must reply to the email we will sending in the
>   next few days to confirm they would like the list to be migrated.

yes, please migrate our list, reproducible-builds@lists.alioth.debian.org
to the new setup.

and thank you (all) very much for doing this (all)!

> * Such requests will need to be received no later than March 15th 2018.
> * Lists that have no active list owners will need to appoint
>   some new list owners to take control of the list first. If you believe
>   this applies to a list you use and that you would like to see migrated,
>   please let us know by emailing .
> 
> Requesting a migration in this way will ensure that your mailing
> list @lists.alioth.debian.org will continue to work after the
> migration date.
> 
> For more information, see
> , and to
> contact the team, use .
> 
> Best wishes,
> the alioth-lists migration team.
> 
> [1] 
> [2] 



-- 
cheers,
Holger


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

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Holger Levsen]

hi,

I also strongly believe we, a group of 30-40 people using alioth
workflows right now, should *not* be betatesting this new Debian
service, as it will be disruptive to our work.

betatesting of salsa.d.o should IMO be done by individuals (or by teams
where *everybody* wants to participate in those betatests).

I certainly don't want to betatest salsa right now. Maybe in March or
April. (Alioth shutdown is planned for May iirc.)


-- 
cheers,
Holger


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

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Holger Levsen]

On Wed, Dec 27, 2017 at 05:03:11PM +0100, Holger Levsen wrote:
> On Tue, Dec 26, 2017 at 08:56:18AM +, Chris Lamb wrote:
> > I believe there are enough people in (or around) our community who dislike
> > Github (for a variety reasons not productive to debate/repeat again here)
> > that moving there would be problematic.
> 
> ack.
> 
> > However, as you imply, this would be the ideal time to somehow a bunch of
> > non Debian-specific repos to something outside of the Debian namespace.
> > It would be more convenient for me to to use salsa.debian.org, but I can
> > really see the appeal of moving to, for example,
> > https://gitlab.com/ReproducibleBuilds for anything not Debian-specific.
> 
> gitlab.com is run+owned by Gitlab Inc., another company. Can you explain
> why people seem to like this better than this other thing by another
> company?

ping?

to me its just two companies. I'd like to understand why gitlab.com is
better than github.com.

meanwhile, https://salsa.debian.org/salsa/support/issues/29 has been
filed, which i have at least three issues with:

- i think the group name should be "reproducible-builds" not
  "reproducible"
- i'm not sure we should use salsa at all, see this very thread, we have
  many non-Debian contributors…
- why file this issue before this thread has ended?


-- 
cheers,
Holger


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

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

[Holger Levsen]

On Wed, Dec 27, 2017 at 08:25:42AM +, Chris Lamb wrote:
> > Which makes me wonder if we'll need to update all the old posts as well
> > to still have valid links...
> Nope. :)

not yet :/


-- 
cheers,
Holger


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

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Holger Levsen]

On Tue, Dec 26, 2017 at 08:56:18AM +, Chris Lamb wrote:
> I believe there are enough people in (or around) our community who dislike
> Github (for a variety reasons not productive to debate/repeat again here)
> that moving there would be problematic.

ack.

> However, as you imply, this would be the ideal time to somehow a bunch of
> non Debian-specific repos to something outside of the Debian namespace.
> It would be more convenient for me to to use salsa.debian.org, but I can
> really see the appeal of moving to, for example,
> https://gitlab.com/ReproducibleBuilds for anything not Debian-specific.

gitlab.com is run+owned by Gitlab Inc., another company. Can you explain
why people seem to like this better than this other thing by another
company?


-- 
cheers,
Holger


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

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Holger Levsen]

Hi reproducible Debian folks,

I guess you have seen
https://lists.debian.org/debian-devel-announce/2017/12/msg3.html
which lead to this on -devel:

On Mon, Dec 25, 2017 at 06:59:21PM +0100, Alexander Wirt wrote:
> On Mon, 25 Dec 2017, Holger Levsen wrote:
> > On Mon, Dec 25, 2017 at 11:45:37AM +0100, Alexander Wirt wrote:
> > > External users are invited to create an account on salsa.
> > do you plan importing the current -guest accounts from alioth?
> No. 

For us this could mean that  we'll need to ask a bunch of non-Debian people to
recreate accounts on salsa.d.o, at which point I expect a lot of "why don't we
use github" questions, to which I'm not sure I have a good answer...

Do you?


-- 
cheers,
Holger


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

Re: packages that FTBFS twice in a row ...

[Holger Levsen]

On Fri, Dec 22, 2017 at 10:43:34PM +0100, Mattia Rizzolo wrote:
> Actually, Guillem went ahead and did this himself.  He also thought it
> would be hard, but after trying only few changes to dpkg were needed.
> Look:
[...] 
> So, yes, source packages can be built reproducibly!

neat, thanks for pointing this out! In which version of dpkg was that
feature?


-- 
cheers,
Holger


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

Re: packages that FTBFS twice in a row ...

[Holger Levsen]

On Fri, Dec 22, 2017 at 04:59:35PM +, Thorsten Glaser wrote:
> >On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote:
> >> Does the reproducible build effort currently test for reproducibility of
> >> source packages?
> >
> >no. the creation of Debian source packages is not reproducible at the
> >moment. I don't recall whether we found a fundamental problem with it or
> 
> Debian source packages are the *source* form of everything in Debian;
> therefore, they are (per definitionem) “correct”, as they are taken
> and copied, not (re)created.

yes. the question was, whether it's possible to do this in a bit by bit
reproducible way. as became clear again here, this ain't easy and doesn't
get us much anyway, so we didnt pursue it further.


-- 
cheers,
Holger


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

Re: packages that FTBFS twice in a row ...

[Holger Levsen]

On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote:
> Does the reproducible build effort currently test for reproducibility of
> source packages? 

no. the creation of Debian source packages is not reproducible at the
moment. I don't recall whether we found a fundamental problem with it or
if simply we had other fishes to fry. 

(I guess it's probably that this would require pristine-tar which would
be a fundamental change if we'd make this a must)


-- 
cheers,
Holger


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

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

[Holger Levsen]

On Sun, Nov 19, 2017 at 09:53:12AM +, Holger Levsen wrote:
> On Sun, Nov 19, 2017 at 05:32:37AM +, Chris Lamb wrote:
> >   https://reproducible.alioth.debian.org/blog/drafts/134/
> >   $ date -d 'Tue, 21 Nov 2017 08:00:00 +'
> please wait at least til Tuesday 18 UTC before publishing this.

thursday, please.

and apologies for the mess on irc.


-- 
cheers,
Holger


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

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

[Holger Levsen]

On Sat, Nov 18, 2017 at 05:03:00PM +, Ximin Luo wrote:
> Holger Levsen:
> > On Thu, Nov 16, 2017 at 10:06:00AM +, Ximin Luo wrote:
> >> Ping, are you ready? I don't see any commits from you in the log...
> > 
> > not yet & on a very bad internet connection atm.
> > 
> > i will publish 133 once it's ready.

i added some more content but dont have time finishing formatting it
now. further help welcome.



-- 
cheers,
Holger


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

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

[Holger Levsen]

On Sun, Nov 19, 2017 at 05:32:37AM +, Chris Lamb wrote:
>   https://reproducible.alioth.debian.org/blog/drafts/134/
>   $ date -d 'Tue, 21 Nov 2017 08:00:00 +'

please wait at least til Tuesday 18 UTC before publishing this.

133 still needs polishing too.

and we should probably write up something about Berlin for 134.


-- 
cheers,
Holger


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

Bug#881987: pepper fails with "all points y value undefined!"

[Holger Levsen]

Package: pepper
Version: 0.3.3-3
Severity: normal

Hi,

pepper on stretch doesnt work for me at all:

user@debian-9-dvm:~/diffoscope$ pepper authors
Fetching revisions... done

gnuplot> plot '-' using 1:2 title "Chris Lamb" with lines, '' using 1:2 title 
"Jérémy Bobbio" with lines, '' using 1:2 title "Ximin Luo" with lines, '' using 
1:2 title "Reiner Herrmann" with lines, '' using 1:2 title "Mattia Rizzolo" 
with lines, '' using 1:2 title "Emanuel Bronshtein" with lines



  ^
 line 8628: all points y value undefined!

user@debian-9-dvm:~/diffoscope$ LANG=C pepper authors
Fetching revisions... Loading cache index... done
Fetching revisions... done

gnuplot> plot '-' using 1:2 title "Chris Lamb" with lines, '' using 1:2 title 
"Jérémy Bobbio" with lines, '' using 1:2 title "Ximin Luo" with lines, '' using 
1:2 title "Reiner Herrmann" with lines, '' using 1:2 title "Mattia Rizzolo" 
with lines, '' using 1:2 title "Emanuel Bronshtein" with lines



  ^
 line 8628: all points y value undefined!

user@debian-9-dvm:~/diffoscope$ echo $LANG
en_US.UTF-8

Steps leading to this:

user@debian-9-dvm:~$ sudo apt install pepper
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  aglfn gnuplot gnuplot-data gnuplot-x11 libjs-excanvas liblua5.1-0 
libwxbase3.0-0v5 libwxgtk3.0-0v5 lua5.1 mercurial
  mercurial-common
Suggested packages:
  gnuplot-doc qct kdiff3 | kdiff3-qt | kompare | meld | tkcvs | mgdiff wish 
python-mysqldb python-pygments
The following NEW packages will be installed:
  aglfn gnuplot gnuplot-data gnuplot-x11 libjs-excanvas liblua5.1-0 
libwxbase3.0-0v5 libwxgtk3.0-0v5 lua5.1 mercurial
  mercurial-common pepper
0 upgraded, 12 newly installed, 0 to remove and 0 not upgraded.
Need to get 9,272 kB of archives.
After this operation, 36.9 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian stretch/main amd64 aglfn all 1.7-3 [29.2 kB]
Get:2 http://deb.debian.org/debian stretch/main amd64 gnuplot-data all 
5.0.5+dfsg1-6+deb9u1 [127 kB]
Get:3 http://deb.debian.org/debian stretch/main amd64 liblua5.1-0 amd64 
5.1.5-8.1+b2 [111 kB]
Get:4 http://deb.debian.org/debian stretch/main amd64 libwxbase3.0-0v5 amd64 
3.0.2+dfsg-4 [1,073 kB]
Get:5 http://deb.debian.org/debian stretch/main amd64 libwxgtk3.0-0v5 amd64 
3.0.2+dfsg-4 [4,493 kB]
Get:6 http://deb.debian.org/debian stretch/main amd64 gnuplot-x11 amd64 
5.0.5+dfsg1-6+deb9u1 [954 kB]
Get:7 http://deb.debian.org/debian stretch/main amd64 gnuplot all 
5.0.5+dfsg1-6+deb9u1 [70.8 kB]
Get:8 http://deb.debian.org/debian stretch/main amd64 libjs-excanvas all 0.r3-4 
[45.3 kB]
Get:9 http://deb.debian.org/debian stretch/main amd64 lua5.1 amd64 5.1.5-8.1+b2 
[99.3 kB]
Get:10 http://deb.debian.org/debian stretch/main amd64 mercurial-common all 
4.0-1+deb9u1 [1,962 kB]
Get:11 http://deb.debian.org/debian stretch/main amd64 mercurial amd64 
4.0-1+deb9u1 [75.5 kB]
Get:12 http://deb.debian.org/debian stretch/main amd64 pepper amd64 0.3.3-3 
[232 kB]
Fetched 9,272 kB in 1s (6,992 kB/s)
Selecting previously unselected package aglfn.
(Reading database ... 117898 files and directories currently installed.)
Preparing to unpack .../00-aglfn_1.7-3_all.deb ...
Unpacking aglfn (1.7-3) ...
Selecting previously unselected package gnuplot-data.
Preparing to unpack .../01-gnuplot-data_5.0.5+dfsg1-6+deb9u1_all.deb ...
Unpacking gnuplot-data (5.0.5+dfsg1-6+deb9u1) ...
Selecting previously unselected package liblua5.1-0:amd64.
Preparing to unpack .../02-liblua5.1-0_5.1.5-8.1+b2_amd64.deb ...
Unpacking liblua5.1-0:amd64 (5.1.5-8.1+b2) ...
Selecting previously unselected package libwxbase3.0-0v5:amd64.
Preparing to unpack .../03-libwxbase3.0-0v5_3.0.2+dfsg-4_amd64.deb ...
Unpacking libwxbase3.0-0v5:amd64 (3.0.2+dfsg-4) ...
Selecting previously unselected package libwxgtk3.0-0v5:amd64.
Preparing to unpack .../04-libwxgtk3.0-0v5_3.0.2+dfsg-4_amd64.deb ...
Unpacking libwxgtk3.0-0v5:amd64 (3.0.2+dfsg-4) ...
Selecting previously unselected package gnuplot-x11.
Preparing to unpack .../05-gnuplot-x11_5.0.5+dfsg1-6+deb9u1_amd64.deb ...
Unpacking gnuplot-x11 (5.0.5+dfsg1-6+deb9u1) ...
Selecting previously unselected package gnuplot.
Preparing to unpack .../06-gnuplot_5.0.5+dfsg1-6+deb9u1_all.deb ...
Unpacking gnuplot (5.0.5+dfsg1-6+deb9u1) ...
Selecting 

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

[Holger Levsen]

On Thu, Nov 16, 2017 at 10:06:00AM +, Ximin Luo wrote:
> Ping, are you ready? I don't see any commits from you in the log...

not yet & on a very bad internet connection atm.

i will publish 133 once it's ready.

thanks.


-- 
cheers,
Holger


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

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

[Holger Levsen]

On Tue, Nov 14, 2017 at 01:34:00PM +, Ximin Luo wrote:
> This week's blog post draft is now available for review:
> https://reproducible.alioth.debian.org/blog/drafts/133/
[...] 
> I'll wait at least 24 hours from the time of this email for any comments, and 
> if everything is good then I will publish it soon after that.

please hold off publishing this blog for another 24h.


-- 
cheers,
Holger


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

Re: Bug#876901: QFINDTESTDATA uses __FILE__

[Holger Levsen]

hi,

dropping the bug and the qt mailinglist from cc:...

On Tue, Nov 14, 2017 at 11:14:00AM +, Ximin Luo wrote:
> Whatever, I don't care about having such a pointless long discussion.
[...]
> You can either accept my one line patch suggestion, or fix it some other way. 
> I'm not going to change the GCC patch, it does nothing wrong.
> 
> Not going to spend any more time on this.

SIGH.

I'm not convinced  such messages will help getting the current
implementation widely adopted & merged into GCC :/

We evidently *need* to spend more time on this. (or give up and go shopping 
because
it's hard.)


-- 
cheers,
Holger


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

Re: Bug#876901: QFINDTESTDATA uses __FILE__

[Holger Levsen]

On Tue, Nov 14, 2017 at 07:22:07AM +0100, Pino Toscano wrote:
> > There are quite a lot of packages that use __FILE__ so forgive me for
> > not checking every single use-case of it.
> 
> This.  When something is used so widely, then changing its behaviour
> blindly is simply a no-no.

I tend to agree.

> > This will require us to patch hundreds of packages, and isn't
> > realistic.
> 
> If "hundreds of packages" misuse __FILE__, then simply *fix them*.
> Sure, it will require time, energy, etc, but I do not see other ways
> around that without breaking standard behaviours.

also agreed.

> > Please, you try sending hundreds of patches, then I will take your
> > "solution" more seriously.
> My *solution* (without quotes) is more realistic than your blind
> breakage.

Pino, could you be so kind and repeat your proposed solution here again,
for the sake of clarity?!


-- 
cheers,
Holger


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

Re: Bug#876901: QFINDTESTDATA uses __FILE__

[Holger Levsen]

On Tue, Nov 14, 2017 at 11:34:00AM +, Ximin Luo wrote:
> > Sorry, it is not realistic to force us to have a delta from upstream for no 
> > direct gain.
> None of the solutions I suggested involve patching upstream, they would be 
> done in d/rules.

"we do not only care about Debian but free software in general" - so how
to do you propose this should be handled for non Debian, eg rpms or
plain building from source?

A Debian only solution for this problem is pretty bad or rather, not a
real solution. 


-- 
cheers,
Holger


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

Re: Bug#876901: QFINDTESTDATA uses __FILE__

[Holger Levsen]

control: severity -1 wishlist

On Mon, Nov 13, 2017 at 07:15:44PM +0100, Pino Toscano wrote:
> Exactly, this is the source of the problem.  OTOH, the problem was
> created by changing __FILE__: it has a well-defined meaning:
> https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
> changing this behaviour is only going to create problems, because
> people rely on such well-defined (and standard) behaviours.
[...] 
> No, the solution is:
> a) *not* break what __FILE__ means
> b) remove the misuses of __FILE__ in packages (not the case of
>QFINDTESTDATA)
[...]
> What I see it is happening here is: you (= people working on
> reproducible builds) see __FILE__, and the problems that arise from its
> abuse; to overcome this issue, you use the sledgehammer solution,
> basically changing what __FILE__ means, and thus breaking even valid
> use cases.  Sorry, but I do not see how this is useful.
> 
> A better approach here is to work on removing the invalid & abusing
> usages of __FILE__ from packages, just like it was done for __DATE__.

downgrading the severity based on this.


-- 
cheers,
Holger


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

Re: QFINDTESTDATA uses __FILE__

[Holger Levsen]

On Mon, Nov 13, 2017 at 05:35:00PM +, Ximin Luo wrote:
> Our patched dpkg tells GCC to map $PWD to "$srcpkg-$version" when expanding 
> __FILE__. That is the source of the problem, because this path doesn't exist 
> at test-time. You have the following options:
> 
> 1. Unset BUILD_PATH_PREFIX_MAP. This is not great because things that use 
> __FILE__ will become unreproducible.

actually I tend to think this is the best option currently. Our
modification of gcc currently only exists in a test/development environment and
it seems totally unclear whether this implementation will be used or
another. so basing other changes in unstable (which will become buster
sooner or later) seems less than ideal to me.

> 2. Symlink "$srcpkg-$version" -> ".", so that the files can be accessed under 
> the paths that __FILE__ was expanded to.
> 
> 3. Set BUILD_PATH_PREFIX_MAP to map $PWD to . instead. You do this by doing 
> `export BUILD_PATH_PREFIX_MAP=$BUILD_PATH_PREFIX_MAP:.=$PWD`, then the tests 
> should work. This makes any other uses of __FILE__ in this package, 
> inconsistent with other Debian packages (built with our patched dpkg).
> 
> (maybe there are other options)

4. just ignore the ftbfs in unstable in tests.r-b.o setup.


-- 
cheers,
Holger


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

Re: Making schleuder build reproducibly

[Holger Levsen]

On Tue, Nov 07, 2017 at 05:02:02PM +0100, Georg Faerber wrote:
> Is it possible to get temporary access to a armhf dev machine, to debug
> this further?

some raspi2 or 3 should do ;)


-- 
cheers,
Holger


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

Re: Making schleuder build reproducibly

[Holger Levsen]

Hi Georg,

thanks for your summary and the work leading to it!

On Mon, Oct 30, 2017 at 06:21:39PM +0100, Georg Faerber wrote:
> @dkg: It seems, there is still a bug / race in dirmngr, which leads to
> errors like "can't connect to '127.0.0.1': no IP address for host" and
> in turn "marking host '127.0.0.1' as dead". See the attached debug log for
> details, the log was taken on October 1st with dirmrngr out of unstable.
> I'm happy to debug this further, if needed.

indeed, random success+failure is visible for 3.2.1-1 on armhf:

https://tests.reproducible-builds.org/debian/rb-pkg/buster/armhf/schleuder.html


-- 
cheers,
Holger


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

Re: First Spanish Debian Reproducible Builds talk in Mexico City

[Holger Levsen]

¡hola jathan!

On Fri, Oct 27, 2017 at 11:57:52PM -0500, jathan wrote:
> Hi everyone. I glad to share tomorrow at 11:00 hrs. of Mexico City Local
> Time Zone, I will be presenting my first talk about Debian Reproducible
> Builds (based on some h0lger, lamby and lunar previous talks) in the
> Mexico Hackmeeting 2017 at the Hackerspace "Rancho Electronico":
> 
> https://ranchoelectronico.org/hackmitin-2017-call4nodos/
> https://calc.mazorca.org/parillanodoshm17

cool, thanks for sharing! & how did it go?

> I have pushed already my slides to our repo:
> https://anonscm.debian.org/cgit/reproducible/presentations.git/tree/2017-10-28-HackmitinCDMX17

cool!

> And I will base on these slides my presentation for CubaConf :) Maybe
> tomorrow's talk will be live streamed through CoAA TV platform
> https://coaa.tv/ if someone wants to try to watch. Best regards!

do you know whether there's a recording of your talk online?


-- 
cheers,
Holger


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

Re: RFC: FontForge reproducible font generation

[Holger Levsen]

Hi Gioele,

On Tue, Oct 24, 2017 at 09:07:54PM +0200, Gioele Barabucci wrote:
> FontForge is discussing merging support for ‎SOURCE_DATE_EPOCH & Co in order
> to support the reproducible creation of fonts files.
 
awesome!

> Could you please have a look the pull request [1] and chime in if you thing
> that it looks correct or if something has been overlooked?

done, the implemented logic and decissions look good to me - though I'm
not familar with this code base :)

Thank you!


-- 
cheers,
Holger


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

Re: 3rd Reproducible Builds summit

[Holger Levsen]

Hi,

I've replied off-list to Mykola (and welcomed him).


-- 
cheers,
Holger


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

Re: 3rd Reproducible Builds summit

[Holger Levsen]

Hi Mykola,

On Fri, Oct 20, 2017 at 09:47:26PM +0300, Mykola Nikishov wrote:
> I hope to pay you a visit as this topic (reproducible builds) is quite
> interesting for me personally. 

that's great! and may I ask why? (Cause I'm a curious person ;)

> Am I right that registration is not
> required? 

No, you're wrong. But registrations is a simple as sending a mail to 
rws3-registrat...@reproducible-builds.org and stating you want to come,
possibly explaining the reasons for that, usually by stating what you 
are working on…

So: please register! :)

> At least, I've found nothing on that matter.

Ahah, I will update the webpage to reflect that, thanks!

-- 
cheers,
Holger


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

Re: Non-determinism in the LLVM compiler

[Holger Levsen]

Hi Mandeep,

On Fri, Oct 20, 2017 at 01:42:10PM -0700, Grang, Mandeep Singh wrote:
> I contribute to the LLVM compiler (https://llvm.org) and my recent work has
> been to uncover and fix instances of *non-determinism in LLVM*.

very nice & thanks a lot for sharing here.

> I recently presented a poster titled /"Non-determinism in LLVM Code
> Generation"/ at this year's LLVM Dev Meet: 
> /https://github.com/mgrang/non-determinism/blob/master/poster_non_determinism_llvm_codegen.pdf/
> 
> It would be great to know if my work is of interest to the reproducible
> builds community

absolutly!

> and if someone has already done/doing something similar.

I sadly dont know how to answer that. (I generally don't know much about
LLVM…)


-- 
cheers,
Holger


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

3rd Reproducible Builds summit

[Holger Levsen]

Hi,

I hope that this mail is no news for all of you, and that all of you working
on reproducible builds have got an invitation via email to your personal email
address. If not: apologies and please contact me if you want to attend!


URL
===

https://reproducible-builds.org/events/berlin2017/


Location


   Betahaus
   Berlin, Germany
   Coordinates: Prinzessinnenstrasse 19-20, 10969, Kreuzberg, Berlin
   https://www.betahaus.com/berlin/space/

   
https://www.google.com/maps/place/Prinzessinnenstraße+19,+10969+Berlin,+Germany/
   Nearest train station: Moritzplatz (U8), then Kottbusser Tor (U1)

Dates
=

   October 31 2017
   November 1+2 2017

These dates are inclusive, ie. the summit will be 3 full days from "9 to 5".
Best arrive on Monday October 30th and leave on the evening of Thursday, 3rd
at the earliest.


Meeting content
===

The exact content of the meeting is going to be shaped by the
participants, but here are the main goals:

 - Update & exchange about the status of reproducible builds in various
   projects.
 - Establish spaces for more strategic and long-term thinking than is possible
   in virtual channels.
 - Improve collaboration both between and inside projects.
 - Expand the scope and reach of reproducible builds to more projects.
 - Brainstorming / Designing several things, eg:
  - designing tools enabling end-users to get the most benefits from
reproducible builds.
  - design of back-ends needed for that.
 - Work together and hack on solutions.

There will be a huge variety of topics to be discussed. To give a few
examples:
- continuing design and development work on .buildinfo infrastructure
- build-path issues everywhere
- future directions for diffoscope, reprotest & strip-nondeterminism
- reproducing signed artifacts such as RPMs
- discussing formats and tools we can share
- sharing proposals for standards and documentation helpful to spreading the
  reproducible effort
- and many many more.

Please think about what you want discuss, brainstorm & learn about at this
meeting!


Schedule


Preliminary schedule for the three days:

9:00 Welcome and breakfast
9:30 Meeting starts
12:30 Lunch
17:00 End of the official schedule

Gunner and Beatrice from Aspiration will help running the meeting. We will
collect your input in subsequent emails to make the best of everyone's time.
Feel free to start thinking about what you want to achieve there. We will also
adjust topics as the meeting goes.

Please note that we are very likely to spend large parts of the meeting away
from laptops and closer to post-it notes. So make sure you've answered any
critical emails *before* Tuesday morning! :)


Sponsors


We are happy to have these sponsors confirmed, so we know this event will happen
(and with some reimbursements too): 

- Debian
- Ford Foundation

We are currently still finalising some additional sponsors and will update the
event website ASAP.

Thanks a lot for making this event possible & thus helping spread the ideas and
practices of Reproducible Builds further!


Reimbursements
==

In an effort to expand the diversity of the community, we are offering
additional travel support to first-time attendees from groups traditionally
underrepresented in free software. These funds are open to:

* Women (cis and trans), trans men, and genderqueer people.
* Individuals from Latin America, Africa, South Asia and Southeast Asia.
* Other: We welcome additional rationale for underrepresentation. Please
  include a short justification in our email.



Looking much forward to seeing you there! And please do reply if you have any
other questions or suggestions…!


-- 
cheers,
Holger


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

Re: Reproducible Builds at CubaConf 2017

[Holger Levsen]

Hi Jathan,

On Mon, Oct 09, 2017 at 12:21:30AM -0500, jathan wrote:
> Hi. I will go to Cuba to attend the CubaConf http://www.cubaconf.org/

awesome! Have lots of fun there! I really wish I could be there too…

As Chris hinted, please commit your talk to our presentations.git - I
suppose you'll give it in Spanish, and I think its very cool to add
Spanish content there! ;)


-- 
cheers,
Holger


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

Bug#874250: udd: use reproducible-tracker.json, or to ignore unstable

[Holger Levsen]

Package: qa.debian.org
Severity: normal
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org

Dear UDD-Maintainer,

please either use reproducible-tracker.json, or ignore unstable, but 
really, please dont parse reproducible.json as there are more filters
in place for reproducible-tracker.json.

we *really really* do not want reproducibility results for unstable show
up on UDD, as our unstable results are a.) currently flaky, which is 
annoying (but inevitable due to gcc-7 work…) b.) also contain problems
for which we dont know the solution yet, so they are unactionable and
demotivating.


thanks for maintaining UDD & DMD!

-- 
cheers,
Holger


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

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

[Holger Levsen]

On Sun, Sep 03, 2017 at 11:40:53AM +0200, Philipp Kern wrote:
> Git is an interesting thought for incremental mirroring. But then it also
> seems to be a poor choice for something that is an only growing repository
> of data.

the nice thing with git is that you get a signed tree for free (or rather, very
easily with tools almost everybody understands), even though it atm only uses
sha1 hashes. IOW: it's a very simple blockchain, which has better properties
than a simple file based mirror.
 
> What I think should be a requirement is that the data is pushed out before
> the mirror pulse. Otherwise you end up with a race where you try to mirror
> the data including the buildinfo but can't access it. (It's a little
> unfortunate that we don't simply put them onto the mirrors.

agreed.


-- 
cheers,
Holger


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

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

[Holger Levsen]

On Mon, Jul 03, 2017 at 07:23:29PM +0200, Philipp Kern wrote:
> > Not yet.  We people from the reproducible team couldn't find a way to
> > usefully talk to ftp-masters people, whom never replied to any of the
> > questions in the thread at #763822 (they only did some quick comments on
> > IRC, and we have been left on guessing what they would like…).
> > 
> > Anyhow, .buildinfo files are stored in ftp-master, just not exported to
> > the mirrors, you can find them in
> > coccia.debian.org:/srv/ftp-master.debian.org/.
> 
> So I suppose we talk about 13 GB[1] of static content in about 1.7M
> files. Is that something that could be distributed through
> static.debian.org if there are concerns around inodes for the main
> mirrors? Given that they would be accessed mostly rarely[2]?
> 
> [1] 7.7kB (75%ile as mentioned in the referenced bug) * 55000 binary
> packages * 10 architectures * 3 versions - so quite conservatively
> [2] So supposedly a CDN wouldn't bring a lot of benefit as individual
> files aren't likely to be hit frequently.

using static.debian.org seems to be a good idea to me, what would be needed to 
make
this happen?

or, we could put them in a git repo instead, and use git.debian.org…

feedback welcome.


-- 
cheers,
Holger


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

Re: Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

[Holger Levsen]

Hi Guillem,

On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote:
> > during discussing #844431 it became clear, that some information about the
> > running kernel should be included in .buildinfo files, as this can affect 
> > the
> > build.
> 
> It is actually not very clear to me. The examples provided there seem
> bogus:
> 
> * Any build that relies on the currently running kernel for the
>   resulting object is broken, and needs to be fixed. The host kernel
>   might/should/will have nothing to do with the build one.
> * Builds that embed build kernel information should be fixed to not
>   do that, as that information should be irrelevant for the generated
>   object.
> * Builds breaking on kernel changing the version schema should only
>   affect things such as kernel modules or similar, anything else is
>   also broken. Any kernel version checks, if at all, should always
>   be done at run-time.
> * Builds breaking due to disabled functionality in the current running
>   kernel should be considered broken. In case of the test suite
>   failing, that should be fixed to skip those tests gracefully. In
>   case of the build system breaking, that should be reworked to not
>   use that functionality (which I'd assume is unportable?).

good points. (just having information on the kernel *can* be helpful, even
though it *should* not matter, but when it (wrongly) does, it is helpful…)
 
> > For a start, including the output of "uname -s -r -v -m -i -o" (so basically
> > uname -a without the hostname) would be better than the current status quo,
> > though it would probably be even nicer to also include a hash of
> > /proc/config.gz or maybe even the whole thing.
> 
> In addition to the above, I'm actually somewhat uncomfortable with this
> request, as it looks like a massive privacy leak. Compared to package
> lists and versions, which are actually requested by the package being
> built and might not have anything to do with the main system this
> build was being run on (say a chroot for example), or might get deleted
> immediately after the build. The kernel tends to be a system-wide
> resource, that even if upgraded does not mean it will be running (until
> a reboot).

on reflection I agree that the privacy implications are too bad.

[more insightful stuff I cannot disagree with removed.]
 
> Given all the above, I'm inclined to just close the report? :)

Probably, maybe, just please keep it open for another week or two for now, so 
others can chime in…

Thanks!


-- 
cheers,
Holger


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

normal bugs (Re: Raising the severity of reproduciblity issues to "important")

[Holger Levsen]

On Fri, Sep 01, 2017 at 09:34:53AM +0300, Adrian Bunk wrote:
> On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
> >...
> > However, based on an informal survey at DebConf (and to reflect the
> > feeling towards software reproducibility in the free software community
> > in general) unless there are strong objections I intend to raise the
> > severity of these wishlist issues to "important" once the toolchain
> > changes to dpkg and debhelper land in sid.
> I would strongly object to raising the severity to "important" for 
 
sigh. you are replying to a mail from 2015, were you aware of that?

Last thing Chris (and we all) said (at+during DebConf, so just 2 weeks ago),
is that we plan to treat such bugs as severity "normal" bugs.


-- 
cheers,
Holger


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

Re: [rb-general] GCC build-path patch getting blocked

[Holger Levsen]

Hi Ximin,

On Wed, Aug 16, 2017 at 03:40:00PM +, Ximin Luo wrote:
> It looks like the GCC reviewer that looked at my patch this time around,
> really doesn't like environment variables. They seem to be happy to
> support the variable (including the syntax) as a command-line flag however.

that sounds more good than bad to me.
 
> For these reasons, I have the following proposal, as a work around for the 
> time being:
> 1. Patch GCC to support BUILD_PATH_PREFIX_MAP as a command-line flag. this 
> will at least fix packages affected by (a).
> 2. Add `gcc` (et al) wrappers to strip-nondeterminism:
> 3. Add a Makefile snippet to strip-nondeterminism:
[... ] 
> This idea is similar to hardening-wrapper. That is now deprecated, but was
> useful as a stepping-stone to more "proper" fixes. Likewise, this shouldn't
> be thought of as "the proper fix", [...]

when reading this at first, I didnt like the idea of working it around as you
described, but then you have a valid point with hardening-wrapper, so I'm now
inclined to accept this. What do other think?

also: should we have this discussion in/cc:ed to some Debian bug?


-- 
cheers,
Holger


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

Reproducible Builds World Summit 3 dates announcement

[Holger Levsen]

Hi,

I'm very glad to announce that the next Reproducible Builds summit
will happen on:

  Tuesday October 31st -> Thursday November 2nd 2017 (inclusive)

The location will be:

   Berlin, Germany.

Please note that the venue itself has not been fully confirmed yet
and are still in the process of aquiring sponsorship / travel
reimbusements.

Despite that, we are are optimistic the event will take place and we
therefore invite you to to attend to discuss various aspects around
Reproducible Builds and plan future directions!


What you need to do
===

Please start planning your travel arrangements now. You should arrive
on Monday 30th so we can start the next morning, and leave no earlier
than 18h00 on Thursday 2nd.

We will shortly send out another invitation mail with details how to
register.


-- 
cheers,
Holger


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

Re: Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Tue, Aug 15, 2017 at 09:05:29PM +0300, Adrian Bunk wrote:
> Is identical building on any kernel required (and tested)?

no and no.

it's only required that the results is reproducible, that is bit by bit 
identical…
 
> Will every reproducible package in buster build identical on the
> bullseye+1 kernel 2022.11.321 ? [1]

my crystal ball is broken, sorry…
 
> [1] the wheezy LTS updates are now built on buildds running stretch
> kernels, and in buster we will have the similar situation that
> nearly everyting in the initial release will be built on stretch
> kernels while post-release updates will be built on buster,
> bullseye and bullseye+1 kernels
 
there surely are situations where different kernels (much like different
libraries) will cause variations in the build artifacts. many times it
will not matter and sometimes it will and we don't really have much experience
with that *yet*.

I'm inclined to file a bug report against dpkg to document the kernel 
used in the .buildinfo files and (hereby) am asking the reproducible builds team
for comments / advice on this.

And probably we should amend debian-policy for this too, but I also 
think we'd rather do this via a new bug report at some later point in time.

Thanks, Adrian, for making sure we don't forget (this pretty old aspect).


-- 
cheers,
Holger


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

Re: Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Tue, Aug 15, 2017 at 10:09:30PM +0300, Adrian Bunk wrote:
> > > I would expect the reproducible builds team to not submit any bugs
> > > regarding varied environment variables as long as as the official
> > > definition of reproducibility in policy states that this is not required
> > > for a package to be reproducible.

I believe we'll continue to file sensible bug reports like we have done in
the last four years.

> Another example is that a package that is reproducible according to the 
> policy definition must not show up as non-reproducible in tracker/DDPO 
> based on results from the reproducible infrastructure.
 
I disagree that we should modfiy the results of actual tests based on wishful
thinking or some definition somewhere, even if it's our beloved debian-policy.

It's certainly possible that a package becomes unreproducible, for known or
unknown reasons (hopefully by now we understand most of them (or have the means
to find out)), at any point in time. And then tracker/DDPO should certainly
show that…

Also what you are saying ("a package that is reproducible according to the
policy definition must not show up as non-reproducible in tracker/DDPO based
on results from the reproducible infrastructure") doesnt really makes sense:
if a package shows up as unreproducible somewhere, it's not reproducible
according to our definition!


-- 
cheers,
Holger


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

Re: Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
> Here is an updated patch addressing these.  I reworded it to use
> 'recommended' and changed the tone to better suit policy.
> 
> Thank you Ximin, Russ and Johannes!
> 
> > "precisification" -> "more precise version"
> 
> Our definition is not actually a /version/ of the
> reproducible-builds.org definition -- that would imply that our
> definition could replace the reproducible-builds.org definition, like
> upgrading a package.
> 
> 'precisification' means roughly "filling out the missing specification
> when it is appropriate to fill it out", which is what the r-p.org
> definition instructs distributors to do.
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or 
> build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
> See the file ``upgrading-checklist`` for information about policy
> which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
> often creates either static linking or shared library conflicts, and,
> most importantly, increases the difficulty of handling security
> vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition `_.

seconded & thanks for these improvements!


-- 
cheers,
Holger


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

Re: Bug#844431: Revised patch: seeking seconds

[Holger Levsen]

On Sat, Aug 12, 2017 at 01:18:23PM -0700, Russ Allbery wrote:
> > +Packages are encouraged to produce bit-for-bit identical binary packages 
> > even
> > +if most environment variables and build paths are varied. This is 
> > technically
> > +more difficult at the time of writing, but it is intended that this 
> > stricter
> > +definition would replace the above one, when appropriate in the future.
> 
> > If this type of "intent" wording is not appropriate for Policy then
> > disregard what I'm saying, I don't wish to block this patch for this
> > reason.
> 
> Oh, that's a good way to capture that.  This seems fine to me, and I have
> no objections to adding this advice.  Seconded the original with or
> without this addition.
 
I'm also seconding the original with or without this addition.


-- 
cheers,
Holger


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

Re: d-d-a draft, please review

[Holger Levsen]

On Tue, Jul 18, 2017 at 08:42:11AM +, Mattia Rizzolo wrote:
> I don't want to put in d-d-a something that could potentially be unpopular
> or be the spark of any heated discussion.
> 
> The plan is to follow up to this report with our nmu proposal in d-d.

awesome, thanks. (still havent read the post but almost there…)


-- 
cheers,
Holger


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

Re: deleting old patched packages from our repository

[Holger Levsen]

On Fri, Jun 30, 2017 at 01:54:31PM +0200, Mattia Rizzolo wrote:
> Therefore, I'd like to delete that directory, and also change the
> "policy" to "move old packages to ../old-packages" to "delete old
> packages" when they are superseded by a newer version.

fine with me and thanks for bringing this up here first!


-- 
cheers,
Holger


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

Re: source-only builds and .buildinfo

[Holger Levsen]

On Wed, Jun 21, 2017 at 02:16:00PM +0300, Adrian Bunk wrote:
> Based on how many broken binaries get uploaded from developers, 

we should disallow binary uploads for everybody for all packages by default.
those porters who need it, should get that enabled for those packages where
they need it, when they need.


-- 
cheers,
Holger


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

Re: source-only builds and .buildinfo

[Holger Levsen]

Hi,

trigger warning: nitpicking.

On Wed, Jun 21, 2017 at 11:34:17AM +0300, Adrian Bunk wrote:
> > I do source-only uploads because i don't want the binaries built on my
> > own personal infrastructure to reach the public.  But i want to upload
> > the .buildinfo because i want to provide a corroboration of what i
> > *expect* the buildds to produce.
> If you expect that, then your expectation is incorrect.
 
I actually think that dkg's expectation is right, "just" that reality is wrong.

The design of the Debian buildd network is from times when machines were much
less powerful than what we have today and it shows.

I'd rather have deterministic builds than the current unpredictable mess.


-- 
cheers,
Holger


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

Re: testing buster now

[Holger Levsen]

On Mon, Jun 19, 2017 at 10:04:31AM +, Mattia Rizzolo wrote:
> It seems we broke the DDPO once again…

whom do we contact to get this fixed?

 > Thanks to Mattia for helping me renaming "testing" to stretch on Saturday
> > and adding buster yesterday.
> s/Saturday/Friday/ :)

indeed! :)


-- 
cheers,
Holger


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

testing buster now

[Holger Levsen]

Hi,

as you might have seen, we're testing four Debian suites now: stretch, buster,
unstable and experimental.

We've added Buster yesterday and this broke at least the dashboard, which I'm
going to fix today. If you notice any other breakage, please do tell, either 
in this thread or via irc.

Thanks to Mattia for helping me renaming "testing" to stretch on Saturday and
adding buster yesterday.


-- 
cheers,
Holger


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

build nodes upgrades to stretch

[Holger Levsen]

hi,

so I've upgraded profitbricks-build2-i386 to stretch last night and so far it
*seems* everything went well and continues to go well.

so I plan to upgrade the other *i386* build nodes to stretch today, and also
have asked Phil to upgrade the jenkins-test-vm to stretch.

then I plan to do upgrade the *amd64* nodes to stretch *tomorrow* or the day
after, so that we have some more time to evaluate that indeed nothing broke
on the i386 nodes, before we upgrade more nodes…

after the amd64 nodes, I would like to upgrade the armhf nodes, possible on
Wednesday.

note: all upgrades should be done by keeping the old configuration files 
when prompted.


-- 
cheers,
Holger


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

poll for a date for another Reproducible Builds Summit

[Holger Levsen]

Hi,

we're finally having a quick poll for a date for the next Reproducible Summit,
to (hopefully) happen some at the end of this year. (read on below for why
"hopefully"…)

The choices in 2017 are basically
- October 30th til November 2nd 2017
- November 7th til November 9th 2017

https://framadate.org/GRiauaLT94hi7lYm has the actual poll, though the dates
are presented somewhat differently there: 

Please note that we are aiming for an 3 day event again, most likely from
Tuesday to Thursday. This is presented very badly as the poll offers you to
choose between ten days, while it's ment to be as a choice between two weeks.
Feel free to only choose Tuesdays to Thursday ;-)

Please also note that funding for this event has not been discussed with
potential sponsors yet and that we need funding to make it happen. 
IOW: these dates are totally preliminary and if you are interested in
funding this meeting, please contact hol...@layer-acht.org

Also if you are aware of (even somewhat) conflicting events at these dates,
please let us know.


-- 
cheers,
Holger


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

Re: LeMaker HiKey960 boards arrived (was: Re: [Reproducible-builds] arm64 reproducible build network)

[Holger Levsen]

On Tue, Jun 13, 2017 at 01:18:27AM +0200, Axel Beckert wrote:
> Long story short: 14 months passed and we didn't get any LeMaker Cello
> boards (http://www.96boards.org/product/cello/). But around pentecost
> we got a mail that we will get LeMaker HiKey960 boards
> (http://www.96boards.org/product/hikey960/) instead and that they
> more or less already got shipped.
> 
> The boards were sponsored by Hewlett Packard Enterprise
> (https://www.hpe.com/) and will be hosted by the students association
> SOSETH (https://sos.ethz.ch/) at ETH Zurich (https://www.ethz.ch/).
 
awesome, thanks to everyone involved!

> But the most severe implication of this switch from a EE to a CE board
> I noticed only at home when I got my hands dirty on one of the boards:
> The Consumer Edition does not have any Ethernet RJ45 port, only wifi.
> :-(
 
eeks

> I don't think we want to rely on wifi, so we likely will also need 8x
> USB 3.0 (A, not C) Gigabit Ethernet adapters, probably around 20€-30€
> each. *sigh*

yup.

> > For those we will need to get SSDs too, so leaving some funds for that
> > would be useful.
> 
> They have an PCIe M.2 slot, but also 32 GB "UFS Flash" on board. The
> current idea (by Holger) is to add a 120GB/128GB M.2 SSD to each board
> for additional storage.

and format those 120gb so that we'll use 90gb of it for /srv and keep the
rest unused for the SSD to wear out…

> I've tried to get Debian installed on one of these HiKey960 boards.

did you manage? :)

> * Flashing a new OS needs to be done over the USB C OTG socket with
>   Android style fastboot/adb methods. :-( As far as I understand it,
>   that means I have to flash an image and can't use the Debian
>   Installer for that. (Please correct me if I'm wrong.)

eeks. I'll leave this for others to shed a light on… 

> * As I don't have an appropriate USB-A to USB-C cable I'll first have
>   to buy one. Afterwards I can see if I can get anything working on
>   these boards.
 
more sigh :)

> So far for today. More maybe tomorrow.

Thanks a lot for all your work so far!


-- 
cheers,
Holger


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

nodes health overview

[Holger Levsen]

Hi!

I'm quite happy about 
https://tests.reproducible-builds.org/debian/index_nodes_health.html
for a start & please see the very first paragraph there.

Next: link to all the workers logs of each host, and as such, also display how 
many build
jobs a host has.

Feedback much appreciated.


-- 
cheers,
Holger


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

Re: Fwd: teams input for stretch release coverage

[Holger Levsen]

On Mon, Apr 17, 2017 at 10:26:37PM +0100, Chris Lamb wrote:
> - Original message -
> From: Cédric Boutillier 
> To: debian-proj...@lists.debian.org
> Subject: teams input for stretch release coverage
> 
> > […]
> > 
> > If your team has:
> > - packaged important applications,
> > - gathered impressive statistics,
> > - achieved some amazing goal,
> > - performed very well in terms of translation, bugs handling, design,...
> > - got anything you want to share with us,
> 
> I think we've hit some of these, despite stretch itself not being
> reproducible :)

/me too.


-- 
cheers,
Holger


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

Re: Old and New armhf/arm64 nodes (Firefly-rk3399, Jetson-tx1, Odroid-C2, Raspberry PI2)

[Holger Levsen]

On Sat, Jun 03, 2017 at 03:23:35PM -0700, Vagrant Cascadian wrote:
> Hrm. Several hours later, jtx1a and ff64a still appear to be idle,
> according to munin. *sigh*
 
thanks for checking…! (I also wondered why 14 jobs where shown as down
in the performance page but was busy doing some last minute changes for
Stretch…)

the ssh host key is wrong/unknown (because I made a mistake when setting
it up, basically did ssh $host instead of ssh -p $port $host…) and then
I didnt notice because aborting the maintenance+setup jobs didnt work
as it should, by properly changing the job result "to aborted", instead
they were shown as successful…

I've now changed the jenknis_master_wrapper to actually exit with error
in such cases, nowadays that we are not constantly running jenkins
build jobs anymore, the mail flood from this should be handable - and useful.

> We'll get them working eventually. :)

surely!


(havent yet fixed the ssh keys, as I'm still on the properly aborting/exiting
fix first… on it.)

-- 
cheers,
Holger


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

Re: Old and New armhf/arm64 nodes (Firefly-rk3399, Jetson-tx1, Odroid-C2, Raspberry PI2)

[Holger Levsen]

On Sat, Jun 03, 2017 at 09:27:38AM -0700, Vagrant Cascadian wrote:
> > what's your plan for this machine now? I've currently disabled it's build 
> > jobs.
> Keep troubleshooting it... push the issue upstream and/or put it on the
> back burner... haven't found anything really informative yet.

ok, cool, thanks!
 
> linux 4.11 works with haveged, but not with USB or eMMC (where the
> rootfs is). Kernel 4.12-rc2/rc3 work fine with rootfs, but down't work
> with haveged... I've been running the same kernel on a different machine
> (p64c) without obvious problems, so it is either specific to odroid-c2,
> or maybe to that particular board.

ic

> > also https://tests.reproducible-builds.org/debian/index_performance.html now
> > nicely shows how many build jobs are down due to remote build node problems…
> That's nice, thanks!
 
:) glad you find it useful!

> On a related note, I haven't noticed any builds on ff64a or jtx1a... did
> all their partner machines happen to be marked as disabled?

there was a problem with the (new) build service with commented out "jobs"
which I fixed today, thus those builds should pour in now…


-- 
cheers,
Holger


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

Re: Old and New armhf/arm64 nodes (Firefly-rk3399, Jetson-tx1, Odroid-C2, Raspberry PI2)

[Holger Levsen]

On Fri, Jun 02, 2017 at 08:46:14AM -0700, Vagrant Cascadian wrote:
> > <  h01ger> | ff64a seems quite slow
> Yes, disk i/o seems likely, although shouldn't be hugely worse than any
> of the other systems...  

I'm not so sure of this but let's see what stats we'll have in a week or so…

> Waiting on native sata hardware to become
> available... so it's currently using a usb-sata adapter. Hopefully that
> will resolve the issue.

*nods*

> > <  h01ger> | odc2a is faster than jtx1a (also io wise, but both are 
> > rather fine…)
> > <  h01ger> | odc2a takes ages to generate the gpg key for the jenkins 
> > user, somehow haveged fails to start…
> Will experiment with combinations of stretch, kernel versions, etc. and
> see if it behaves the same.
 
what's your plan for this machine now? I've currently disabled it's build jobs.

also https://tests.reproducible-builds.org/debian/index_performance.html now
nicely shows how many build jobs are down due to remote build node problems…


-- 
cheers,
Holger


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

Re: Old and New armhf/arm64 nodes (Firefly-rk3399, Jetson-tx1, Odroid-C2, Raspberry PI2)

[Holger Levsen]

Hey Vagrant,

On Fri, May 26, 2017 at 01:56:54PM -0700, Vagrant Cascadian wrote:
> Got one old machine freshly reinstalled after a disk failure (rpi2c),
> and three newly readied machines (ff64a, jtx1a, odc2a) that are arm64
> capable, but configured with armhf userspace to be armhf build nodes.

those are now all set up for tests.reproducible-builds.org, but…

<  h01ger> | ff64a seems quite slow
<  h01ger> | it is, now that i can compare to jtx1a and odc2a
 * | h01ger assumes disk io
<  h01ger> | odc2a is faster than jtx1a (also io wise, but both are rather 
fine…)
<  h01ger> | odc2a takes ages to generate the gpg key for the jenkins user, 
somehow haveged fails to start…
<  h01ger> | root@odc2a:~# /usr/sbin/haveged --Foreground --verbose=1 
--write=1024
<  h01ger> | haveged starting up
<  h01ger> | Segmentation fault
 * | h01ger sighs
<  h01ger> | root@odc2a:~# uname -a
<  h01ger> | Linux odc2a 4.12.0-rc2+ #4 SMP Wed May 24 23:18:20 UTC 2017 
aarch64 GNU/Linux
<  h01ger> | hui ui ui :)

so while I have added 10 new builder jobs, I've also disabled 5 of them again 
for now:

commit 3621042 in jenkins.debian.net.git:
  bin/reproducible_build_service.sh reproducible Debian: disable all 
build jobs on odc2a 
  (haveged dies with segfault…) and disable all but two build jobs on 
ff64a due to its 
  IO-slowness
 
> Thanks to Rockchip, Nvidia, Debian and Freegeek for the donations that
> made this expansion phase possible!

many thanks indeed!


-- 
cheers,
Holger


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

Re: Old and New armhf/arm64 nodes (Firefly-rk3399, Jetson-tx1, Odroid-C2, Raspberry PI2)

[Holger Levsen]

hey,

On Fri, May 26, 2017 at 01:56:54PM -0700, Vagrant Cascadian wrote:
> rpi2c-armhf-rb.debian.net:

should be back and building packages any moment now… :) the rest hopefully
tomorrow…


-- 
cheers,
Holger


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

Bug#843811: downgrading severity

[Holger Levsen]

control: severity -1 normal
thanks

Hi,

downgrading the severity because not being able to strip determinism from
a few files present in very few packages doesn't have a major impact on the
usability of this package. (It's actually closer to wishlist…)


-- 
cheers,
Holger


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

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

[Holger Levsen]

Hi Chris,

On Sun, May 21, 2017 at 06:51:30AM +0100, Chris Lamb wrote:
> I am very happy to reword and/or rework prior to publishing. I intend
> to publish it no earlier than:
>   https://time.is/compare/0800_23_May_2017_in_CEST

can you please postpone this by 12h? thanks already! :)


-- 
cheers,
Holger


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

Bug#863033: strip-nondeterminism: Only print log messages by default if a file has been modified

[Holger Levsen]

control: severity -1 important
thanks

On Sat, May 20, 2017 at 02:05:20PM +0100, Chris Lamb wrote:
> This is not only noisy in-of itself (!) and somewhat misleading, it also
> defeats the point of adding these particular log messages in the first place;
> we should only be printing if we modified the file so we can start to remove
> normalizers from strip-nondeterminism.

thus raising the severity of this bug, as this has a major impact without
making it unusable for everyone.


-- 
cheers,
Holger


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

Re: policy: packages should be reproducible

[Holger Levsen]

On Sun, May 07, 2017 at 06:15:38PM +0100, Chris Lamb wrote:
> > unsurprisingly I'm also in favor of making this policy change, now.
> Actually, yes, why were we waiting for stretch to be released? :)

good question. I guess because of a mental barrier against doing changes
targeted post-stretch now :)
 
> > Last and least for now: the wording of
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17
> > IMO is almost good as it is, though I'll try to amend it to include the
> > definition of reproducible builds from reproducible-builds.org. 
> That seems the next concrete step.

indeed! Will see to work on this the next days…


-- 
cheers,
Holger


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

Re: #862112: r-base-dev: Generate reproducible output independently of the build path

[Holger Levsen]

On Sun, May 14, 2017 at 01:19:44PM +0200, Holger Levsen wrote:
> According to 
> https://tests.reproducible-builds.org/debian/index_performance.html
> (top row labeled "oldest build result) in the first table on the right) this
> means we've almost done a full rebuild with the patch on amd64+arm64 (probably
> 85% done now) and pretty close to that on i386…
> 
> According to this, this patch seems to work well…

actually, we've done a full rebuild of all r-* packages on amd64, not just 85%:
Ximin scheduled them all manually on amd64 before filing this bug… :)


-- 
cheers,
Holger


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

re: #862112: r-base-dev: Generate reproducible output independently of the build path

[Holger Levsen]

control: found -1 3.4.0-1
control: notfound -1 3.4.0-1.0~reproducible2

Hi Dirk,

I've asked Ximin to file this bug so that we have something to track and to
refer in discussions…

you wrote:

> At work now with limited time, but I think I already told you twice that
> there were two of the three parts of the patch you proposed to upstream that
> I would not take, were I upstream (which I am not).

Dirk, could you please point out (here in this bug report) which of the two 
parts
you consider unsuitable?

Ximin, looking at 
https://anonscm.debian.org/cgit/reproducible/r-base.git/log/?h=pu/reproducible_builds
I believe it would be best to merge those two (top most) commits into one?

> A decent longer-term strategy may well to stress-test the patch by including
> it in our builds for a while.  We can work on that.

actually we've been using Ximin's patches on tests.reproducible-builds.org
since the 2nd of May on amd64 and since the 3rd on arm64, armhf and i386.

According to https://tests.reproducible-builds.org/debian/index_performance.html
(top row labeled "oldest build result) in the first table on the right) this
means we've almost done a full rebuild with the patch on amd64+arm64 (probably
85% done now) and pretty close to that on i386…

According to this, this patch seems to work well…


-- 
cheers,
Holger


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

Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

[Holger Levsen]

On Sat, May 13, 2017 at 10:48:18PM +0200, Aurelien Jarno wrote:
> The above change should now be deployed on most jessie based buildds,
> it's only missing on the buildds that are currently down.

cool, thank you!


-- 
cheers,
Holger


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

Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

[Holger Levsen]

On Sat, May 13, 2017 at 05:52:04PM +0200, Mattia Rizzolo wrote:
> On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> >  a) Has anything changed in the meantime?
> 
> Yes: sbuild stopped repeating the changelog time taking it from the last
> entry, and will instead generate a new timestamp based on the current
> time:
> 
>   * For binNMUs, instead of copying the timestamp of the last changelog entry,
> generate a new one (closes: #843773)
> 
> In version 0.73.0-1.

this is correct, but AFAIK this hasnt been deployed on the buildd yet.
I'd be glad to be corrected about this…
 
> >  b) Will this affect stretch? If so, what do we need to do now?
> IMHO, nothing.

we might need to reschedule some packages…


-- 
cheers,
Holger


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

Re: [rb-general] Unreproducible test logs in output

[Holger Levsen]

On Wed, May 10, 2017 at 02:28:57PM +0100, Chris Lamb wrote:
> Devil's advocate for a second - it is sufficient that the output
> appears on https://buildd.debian.org so anyone interested enough can
> look there.

totally agreed. (except for the URL, that could be whereever…)

putting build logs in the binary packages because they are unreliable/have too
many failures seems like a gross hack to me.

Nothing to be fixed (and probably not even discussed within Debian) *now*, but
I think we should bring this up on debian-devel once Stretch has been released.

For now, I'd suggest filing bugs so these issues are not forgotten.
(Alternativly, though IMO less prefered, putting notes in notes.git could also
serve as a reminder for us.)


-- 
cheers,
Holger (and yes, I've read the replies…)


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

policy: packages should be reproducible

[Holger Levsen]

hi,

unsurprisingly I'm also in favor of making this policy change, now.

I also believe there is quite a consensus (definitly a rough one…) in Debian
for making this change, judging by the feedback we got at 3 DebConfs since 2013,
several mini Debconfs and other events, plus the general feedback in the form
of code merges and uploads.

At the Reproducible Builds Hackathon in Hamburg we were reminded of the former
DPL asking DDs to be "more bold" doing sensible changes forward, and as such
we plan that starting with the development phase of "buster" we'll consider
bugs about reproducible builds issues to be of severity "normal", not 
"wishlist".

This shall be announced on d-d-a soon & given there is no disagrement on this
procedure on this bug.

Last and least for now: the wording of
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17
IMO is almost good as it is, though I'll try to amend it to include the
definition of reproducible builds from reproducible-builds.org. 


-- 
cheers,
Holger


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

Bug#862031: strip-nondeterminism: output a warning when underministic data is removed

[Holger Levsen]

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

Dear Maintainer,

it would be nice if strip-nondeterminism would output a warning when
underministic data is removed, so it's trivially visibly where+when
strip-nodeterminism is still needed to make a package is reproducible…

it should probably also mention which handler is being used…


-- 
cheers,
Holger


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

Bug#862029: strip-nondeterminism: clarify package description this is just a workaround which should go away

[Holger Levsen]

Package: strip-nondeterminism
Version: 0.032-1
Severity: normal

hi,

as discussed in Hamburg and brought up there by Justin Cappos, we consider
strip-nondeterminism to be a temporary workaround which should not be needed
in the long term. Upstream software should be reproducible even without
using strip-nondeterminism.


-- 
cheers,
Holger


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

hamburg hackathon

[Holger Levsen]

Hi,

I've send out a mail today to everybody on that wiki page about the
Reproducible Builds Hackathon in Hamburg.

If you know you are on that page and didn't get that mail, please contact me.

If you werent and still want to attend, please add yourself to that wiki page 
now.

And if you have no idea what I'm talking about, please see
https://wiki.debian.org/ReproducibleBuilds/HamburgHackathon2017


-- 
cheers,
Holger


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

Re: [rb-general] Reproducible Builds Hackathon Hamburg 2017, May 5-7

[Holger Levsen]

Hi,

On Thu, Mar 09, 2017 at 08:26:12PM +, Holger Levsen wrote:
> with some more delay, there's finally a wiki page announcing the hackathon:
> 
> https://wiki.debian.org/ReproducibleBuilds/HamburgHackathon2017
> 
> It should have all the information needed, so I wont repeat much here, except
> the very basic:
> 
> when: 2017, May 5-7
> where: Hamburg, Germany, inside+outside the CCC Hamburg hackerspace
> why: to hack on reproducible builds everyhwere
> 
> If you have questions not answered on that wiki page, please ask and I'll try
> to answer :)
> 
> If you plan to attend, or want, please add your name to that wiki page. And
> if you cannot edit that wiki page, because it's in the Debian wiki and you
> don't have an account there, please mail me, and I'll happily add you there :)
> 
> I've also been wondering whether to add this to 
> https://reproducible-builds.org/events/
> and have to decided to rather quickly (+finally) get this started, using a
> Debian wiki page… we can still add it to the webpage at any time.
> 
> Further suggestions and help much welcome, especially with getting sponsoring
> for the event.
> 
> Looking forward to see you in Hamburg! (or elsewhere! :)

if you're considering attending, please add yourself to the wiki page now, as
I'll need to give some estimate for needed accomodation tomorrow. Obviously you
can still choose to attend later, but then accomodation might be harder to get…


-- 
cheers,
Holger


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

Re: [PATCH] Prefer experimental over unstable/sid when calculating "diffoscope in Debian" version.

[Holger Levsen]

On Sat, Mar 18, 2017 at 07:15:23PM +, Chris Lamb wrote:
>   diffoscope_distribution_test.sh: Prefer experimental over unstable/sid 
> when calculating "diffoscope in Debian" version.
>   diffoscope_distribution_test.sh: Match distribution exactly (eg. reject 
> "buildd-experimental")
> You can also merge from the "pypi-diffoscope-experimental" branch of
> https://github.com/lamby/jenkins.debian.net if that is more convenient.

cool, thanks! picked & deployed!


-- 
cheers,
Holger


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

Bug#857944: diffoscope: release 79 has a python version of VERSION = "78"

[Holger Levsen]

Package: diffoscope
Version: 79
Severity: normal

hi,

 so the current release 79 has a python version of VERSION = "78" :P


-- 
cheers,
Holger


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

Reproducible Builds Hackathon Hamburg 2017, May 5-7

[Holger Levsen]

Hi,

with some more delay, there's finally a wiki page announcing the hackathon:

https://wiki.debian.org/ReproducibleBuilds/HamburgHackathon2017

It should have all the information needed, so I wont repeat much here, except
the very basic:

when: 2017, May 5-7
where: Hamburg, Germany, inside+outside the CCC Hamburg hackerspace
why: to hack on reproducible builds everyhwere

If you have questions not answered on that wiki page, please ask and I'll try
to answer :)

If you plan to attend, or want, please add your name to that wiki page. And
if you cannot edit that wiki page, because it's in the Debian wiki and you
don't have an account there, please mail me, and I'll happily add you there :)

I've also been wondering whether to add this to 
https://reproducible-builds.org/events/
and have to decided to rather quickly (+finally) get this started, using a
Debian wiki page… we can still add it to the webpage at any time.

Further suggestions and help much welcome, especially with getting sponsoring
for the event.

Looking forward to see you in Hamburg! (or elsewhere! :)


-- 
cheers,
Holger


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

Re: binutils/ld.bfd, -fdebug-prefix-map, FILE entries (was: Re: dietlibc; build path issue on ARM despite -fdebug-prefix-map)

[Holger Levsen]

Hi Christian,

On Sat, Feb 18, 2017 at 02:19:52PM +0100, Christian Seiler wrote:
[...]
> I believe the issue stems from this code in binutils/bfd:
> 
> http://sources.debian.net/src/binutils/2.27.90.20170218-1/bfd/elflink.c/#L9757-L9778
> 
> The file name at this point is just the argument passed to the linker,
> irrespective of whether it's an absolute path or a relative one, and
> no prefix is applied at all.
> 
> The initial problem with dietlibc is that on ARM paltforms the
> startup code has local symbols in the assembly, which it doesn't
> on x86, so the problem has never surfaced on x86 in the past.
> 
> Which means this is a broader class of bugs that every time one
> has an assembly file that doesn't contain a ".file" directive
> and contains local symbols, ld.bfd will output a FILE entry
> which may contain an absolute path of the object file (depending on
> how the file name was passed to the linker), which can break
> reproducibility.
> 
> 
> For dietlibc (after Stretch), I can just add .file directives
> everywhere, so I can work around this issue.
> 
> But to make sure this doesn't happen at all anymore (there might
> be other software with hand-crafted assembly out there that has
> similar issues), I believe binutils should also be altered to
> support SOURCE_PREFIX_MAP in these cases.
> 
> Unfortunately, I know way too little about the details of binutils
> to feel comfortable in creating a patch (it was hard enough to find
> the suspected place where the path is injected), so all I can do 
> here is report my findings. Hopefully someone with more binutils-fu
> is able to pick this up.

do you know whether this has been fixed in the recent binutils uploads?

if not maybe you can file these findings as a bug, so they don't get lost 
on the mailinglist?


-- 
cheers,
Holger


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

Re: buildinfo.debian.net is throwing internal server errors (500)

[Holger Levsen]

On Wed, Feb 22, 2017 at 10:19:46PM +0800, Chris Lamb wrote:
> For now I've just dropped storing the Installed-Build-Depends as rows in
> Postgres; was 196,486,803 rows (from ~900,000 .buildinfo files).
 
*g* & thanks for fixing this!

> I've also moved away from the Startcom certificate to a letsencrypt one.

:)


-- 
cheers,
Holger


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

Re: [PATCH] reproducible Debian: move cleanup and (eg.) SIGBUS errors to #-changes

[Holger Levsen]

On Wed, Feb 22, 2017 at 03:51:14AM +1300, Chris Lamb wrote:
> > The notifications about artifacts OTOH were requested by users
> I didn't realise this. They currently just look like somewhat
> unremarkable ": done: unreproducible" messages; just adding
> some extra suffix or prefix would help.
 
let's keep an eye on this and probably revisit this issue.

> > If this was about artifacts being dropped because diffoscope
> > crashed, the logfile approach might work as well.
> That would also work, yes. Probably ideal actually…  Thanks.

ok, added to my near future TODO list.


-- 
cheers,
Holger


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

Re: buildinfo.debian.net is throwing internal server errors (500)

[Holger Levsen]

On Wed, Feb 22, 2017 at 03:53:47AM +1300, Chris Lamb wrote:
> > what disk space requirements are we talking about here? 20g? 100g? 10g?
> The 60GB disk is currently full.
 
so thats 50gb of data in 2 months?
 
> > > I will either drop these for now or come up with a clever solution.
> > any eta for this?
> Alas, inspiration for clever solutions rarely fits a schedule. And then
> there's playing Towers of Hanoi with the existing data...

hehe, ok, "no ETA" is an ETA, thanks ;) 

I could offer you 100gb in the profitbricks cloud or you could probably ask
DSA for some Debian ressources as well?


-- 
cheers,
Holger


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

Re: buildinfo.debian.net is throwing internal server errors (500)

[Holger Levsen]

On Tue, Feb 21, 2017 at 03:23:00PM +1300, Chris Lamb wrote:
> Indeed, due to disk space issues on this server. I'd made a bunch of
> optimisations over the past few weeks to reduce the disk usage (ie.
> storing .buildinfo files on S3) but the Postgres parts that are
> storing the Installed-Build-Depends tuples are huge.
 
what disk space requirements are we talking about here? 20g? 100g? 10g?

> I will either drop these for now or come up with a clever solution.

any eta for this?

> (I already have in-depth monitoring for buildinfo.debian.net so feel
> free to drop these).

Is your monitoring publically accessable? Or non-publically? :)

As tests.r-b.o is a shared setup and since buildinfo.d.n is or should
become a core part of this I'd like to know when it's not working…


-- 
cheers,
Holger


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

Re: [NetBSD] Can we have another run please?

[Holger Levsen]

On Mon, Feb 20, 2017 at 12:02:29PM -0500, Christos Zoulas wrote:
> | Guess we really need to introduce more variations now! ;-)
> Yes, please do! Here's the little blurb I promised:
> http://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_builds

wow, that's rather long :) (still need to read it…)

Also it will probably take some time until I'll find time to introduce more
variations for testing NetBSD - patches very much welcome!


-- 
cheers,
Holger


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

Re: buildinfo.debian.net is throwing internal server errors (500)

[Holger Levsen]

On Mon, Feb 20, 2017 at 04:23:12PM +, Holger Levsen wrote:
> I've now deployed b199226 for jenkins.debian.net bin/reproducible_build.sh
> to "improve debugging buildinfo.debian.net"…

and 361771a5 - so normally there should be no mails send about this. And if,
it's one per day.


-- 
cheers,
Holger


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

Re: buildinfo.debian.net is throwing internal server errors (500)

[Holger Levsen]

On Mon, Feb 20, 2017 at 03:57:04PM +, Holger Levsen wrote:
> https://jenkins.debian.net/job/reproducible_builder_amd64_12/67405/console
> show an internal server error on buildinfo.debian.net upon submitting
> .buildinfo files. Please fix! :)

the log actually shows two problems: a.) a bus error when running diffoscope
(which I thought was filed with "bus" in the subject but now I couldnt find
it in the BTS) and b.) the above problem, which I believe are unrelated…

I've now deployed b199226 for jenkins.debian.net bin/reproducible_build.sh
to "improve debugging buildinfo.debian.net"…


-- 
cheers,
Holger


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

buildinfo.debian.net is throwing internal server errors (500)

[Holger Levsen]

Hi Chris,

https://jenkins.debian.net/job/reproducible_builder_amd64_12/67405/console
show an internal server error on buildinfo.debian.net upon submitting
.buildinfo files. Please fix! :)


-- 
cheers,
Holger


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

Re: [NetBSD] Can we have another run please?

[Holger Levsen]

On Mon, Feb 20, 2017 at 08:34:25AM -0500, Christos Zoulas wrote:
> Thank you! We are fully reproducible now :-)
> https://tests.reproducible-builds.org/netbsd/netbsd.html

wow, this is totally awesome! Congrats to everyone involved!

Guess we really need to introduce more variations now! ;-)


-- 
cheers,
Holger


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

package removed (Re: package uploaded to our repo)

[Holger Levsen]

On Tue, Feb 14, 2017 at 06:21:11PM +, Holger Levsen wrote:
> I really want to see a bug number here.
 
I would have loved to send this mail to such a bug…

> > > also, you uploaded python2.7_2.7.13-3~reproducible1 for amd64, do you 
> > > plan to
> > > do upload the other architectures as well?
> > Let's just start with amd64 for now and see what happens. 
 
so, this happened:

https://tests.reproducible-builds.org/debian/unstable/amd64/stats_pkg_state.png

because, from #debian-reproducible a few minutes ago:

 | bah
 | i've found the cause…
 | Err http://reproducible.alioth.debian.org/debian ./ 
python2.7-minimal 2.7.13-3~reproducible1
 |   Hash Sum mismatch
 | eg in 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-tooz.html
 uh…
 ah, so maybe the depwait are not so related to the other thing.
 | python-tooz is depwait because of exactly this
 | oh
 | come on
 | those files are also mode 644
   * | h01ger could move them away \o/
 could you please write a mail too? (following up on the previous 
thread?)
   * | h01ger is still cleaning up the mess atm
 | triggering maint+setup jobs

IOW: I've moved these python2.7 packages to 
/home/groups/reproducible/python2.7_7_2.7.13-3
on alioth…


-- 
cheers,
Holger


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

Re: New armhf node (Pine64+)

[Holger Levsen]

On Thu, Feb 16, 2017 at 12:25:15PM -0800, Vagrant Cascadian wrote:
> Just purged the un-unsed kernel packages which didn't have support for
> these boards.

ah!

> I guess you must have installed something that triggered
> an "update-initramfs" call on the older kernel versions...

I wonder what this was…

> Removed your workaround, and re-ran update-initramfs. Should be working
> now.

thanks. (I had to add two workarounds…)

> >> This one is interesting in that it's running an arm64 kernel with armhf
> >> userland (like the i386 builders that run amd64 kernels).
> > nice! is this the same for p64c too?
> Yup.
 
very nice!

> Thanks for getting themn into production!

my pleasure! :)


-- 
cheers,
Holger


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

Re: New armhf node (Pine64+)

[Holger Levsen]

On Thu, Feb 16, 2017 at 01:31:55PM +, Holger Levsen wrote:
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Can you fix this up ("somehow" on the host…), please?!

"fixed" this for now by adding "exit 0" at the beginning of 
/etc/initramfs/post-update.d//flash-kernel …


-- 
cheers,
Holger


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

Re: Another new armhf node (Pine64+)

[Holger Levsen]

On Tue, Feb 14, 2017 at 03:52:06PM -0800, Vagrant Cascadian wrote:
> Yet Another arm board ready to be configured for the build farm!

set up as well. 

(I've only configured maintenance and setup jobs so far, but no builder jobs
as p64b aint setup fully yet due to the linux-image install problem…)


-- 
cheers,
Holger


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

Re: New armhf node (Pine64+)

[Holger Levsen]

Hi Vagrant,

sorry for the delay in getting these boards used…!

On Mon, Feb 06, 2017 at 01:39:47PM -0800, Vagrant Cascadian wrote:
> Another arm board ready to be configured for the build farm!
 
this is now basically setup, however this is quite annoying (as we
expect "apt install" to exit 0…)

on p64b-armhf-rb.debian.net:

linux-image-4.10.0-rc6-arm64-unsigned (4.10~rc6-1~exp1) wird eingerichtet ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.10.0-rc6-arm64
DTB: sun50i-a64-pine64-plus.dtb
Couldn't find 
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: Fehler beim Bearbeiten des Paketes linux-image-4.10.0-rc6-arm64-unsigned 
(--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 linux-image-4.10.0-rc6-arm64-unsigned
E: Sub-process /usr/bin/dpkg returned an error code (1)

Can you fix this up ("somehow" on the host…), please?!

> Running a non-Debian kernel, but built from the linux-next tree, so
> should be possible to switch to experimental and/or stretch-backports
> when the time comes.
 
cool!

> This one is interesting in that it's running an arm64 kernel with armhf
> userland (like the i386 builders that run amd64 kernels).

nice! is this the same for p64c too?

> We may not
> have enough of these to do this systematically yet unless we divert some
> of the other arm64 builders, though I'll likely get a few more in this
> configuration set up "soon" regardless.

cool!

> Space is getting a little tight, so if this one
> performs well, I'll probably want to decomission one of the slower
> boards. I've got another Pine64+ that should be ready soon, and *maybe*
> an odroid-c2 as well, and likely some additional board donations
> coming... maybe I should get a bigger UPS and another network switch to
> support another 8 boards...

sounds like it!
 
> I think it is only configured with ssh keys for holger, but if someone
> else is able to configure it and has the time I can add them as well.

mattia's keys should be there as well now…


-- 
cheers,
Holger


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

Re: Bug#855282: debsign: support .buildinfo files

[Holger Levsen]

user reproducible-builds@lists.alioth.debian.org
usertag 855282 toolchain
thanks


-- 
cheers,
Holger


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