Bug#893702: Please stop build-depending on pdftk

Control: affects 892539 diffoscope On 2018-03-21, 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. FWIW, there's a reference to a fork of pdftk that doesn't require gcj:

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

On 2017-12-26, Ximin Luo wrote: > This week's blog post draft is now available for review: > > https://reproducible.alioth.debian.org/blog/drafts/139/ The links to some of alioth's git repositories (maybe only jenkins related ones) are apparently not valid at the moment; I'm assuming this is due

Re: Making schleuder build reproducibly

On 2017-11-04, Holger Levsen wrote: > 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".

Bug#876239: reproducible: re-deploy odxu4 (disk failure)

Package: jenkins.debian.org Severity: normal X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org odxu4-armhf-rb.debian.net had a critical disk failure. It's been reinstalled, so the ssh keys have changed: 256 SHA256:qdZCQDO2crGdXaDopH9OP5qen3XHml3Y68/BsEmmP8I root@odxu4a (ECDSA) 256

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

On 2017-09-24, Mattia Rizzolo wrote: > On Sun, Sep 24, 2017 at 07:14:22PM +0100, Chris Lamb wrote: >> Naturally, please let know if there are other things like this. > > What I was about, is that the sentence implies that what's *right after* > is all the changelog of the release, which is not

Bug#876239: reproducible: re-deploy cbxi4a (disk failure)

Package: jenkins.debian.org Severity: normal X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org cbxi4a-armhf-rb.debian.net had a critical disk failure. It's been reinstalled, so the ssh keys have changed: 256 SHA256:C8nL+YAOEhjWYH2tkeoP00sfiWi4bI2ZlI400idPBqU root@cbxi4a (ECDSA) 256

Bug#876212: reproducible: re-add armhf node ff64a

Package: jenkins.debian.org Severity: normal Tags: patch X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Welcome back ff64a-armhf-rb.debian.net. Specs and fingerprints are unchanged. With the 4.14-rc1 kernel, the firefly-rk3399 boards have working cpufreq support, and so the CPU can

Re: Bug#876055: Environment variable handling for reproducible builds

On 2017-09-18, Vagrant Cascadian wrote: > On 2017-09-18, Russ Allbery wrote: >> Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: >>> On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote: >>> Does everything in policy need to be rigorously testable? or

Re: [Pkg-zsh-devel] Bug#764650: zsh: FTBFS with noatime mounts

On 2017-09-18, Axel Beckert wrote: > Control: retitle -1 zsh: FTBFS with noatime mounts (e.g. on reproducible > builds armhf nodes) ... > We still see this issue with reproducible builds on armhf in unstable as > well as stretch: >

Bug#874682: reproducible: New and old armhf/arm64 nodes (Jetson-tx1, Jetson-tk1)

Package: jenkins.debian.org Severity: normal Tags: patch X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org One new machine ready for incorporation into the armhf build network, and one old one ready to be reactivated. Welcome back jtk1a-armhf-rb.debian.net. Specs and fingerprints are

Re: GCC build-path patch getting blocked

On 2017-08-16, 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. > The original patch fixed ~1800

Bug#868569: New armhf/arm64 nodes (Jetson-tx1, Jetson-tk1)

an.net.git/ https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git/commit/?h=new-armhf-jtk1b-jtx1b Hopefully it's everything needed to deploy to the new machines. Thanks for working on Debian's jenkins infrastructure! live well, vagrant On 2017-07-13, Vagrant Cascadian wrote:

New armhf/arm64 nodes (Jetson-tx1, Jetson-tk1)

Two new machines ready for incorporation into the armhf build network. Thanks to Nvidia, Debian and Freegeek for the donations that made this expansion phase possible! jtk1b-armhf-rb.debian.net: Jetson-TK1, nvidia tegra-k1 (cortex-a15) quad-core, 2GB ram ssh port: 2252 ssh fingerprints: 256

Re: source-only builds and .buildinfo

On 2017-06-21, Ian Jackson wrote: > Daniel Kahn Gillmor writes ("Re: source-only builds and .buildinfo"): >> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote: >> > A .buildinfo file is not useful for a source-only upload which is >> > veried to be identical to the intended source as present in

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

On 2017-06-03, Holger Levsen wrote: > On Sat, Jun 03, 2017 at 09:27:38AM -0700, Vagrant Cascadian wrote: >> 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 th

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

On 2017-06-02, Holger Levsen wrote: > 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

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

On 2017-05-26, Chris Lamb wrote: >> jtx1a-armhf-rb.debian.net: >> Jetson-tx1, quad-core (big.LITTLE Cortex-A53/A57), ~3.5GB ram, > > Hm? _Approximately_ 3.5GB ram? :) I think the kernel is overly agressive reserving some ram(there was a recent thread about it on one of the kernel lists), and with

Bug#861109: diffoscope: Please add support for .dtb (device tree blob) files.

Control: tag 861109 pending On 2017-04-24, Chris Lamb wrote: > Thanks for implementing this. :) I'd just check two things: > > a) Unused subprocess import in test_dtb.py Tested that it works without; committed and pushed. > b) Whether the tests pass with jessie's device-tree-compiler >

Bug#861109: diffoscope: Please add support for .dtb (device tree blob) files.

c55c67da65ed37bd4268005fbdede27767b1331b Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian <vagr...@debian.org> Date: Mon, 24 Apr 2017 10:21:21 -0700 Subject: [PATCH 1/2] Add support for .dtb (device tree blob) files. --- diffoscope/comparators/__init__.py | 1 + diffoscope/comparators/dtb.py

Bug#856248: trydiffoscope: traceback with "500 Server Error"

Package: trydiffoscope Version: 64 Severity: important I haven't been able to use trydiffoscope for some weeks now, getting tracebacks like the following: $ date > a $ # wait a bit... $ date > b $ trydiffoscope a b Traceback (most recent call last): File "/usr/bin/trydiffoscope",

Re: Moving towards a deb-buildinfo(5) Format 1.0

On 2017-02-19, Guillem Jover wrote: >> * .buildinfo files are not generated when creating source-only uploads > > Fixed. Now always generated. On a related note, is it currently possible to create a .buildinfo with both the source and binary, but a corresponding .changes with only the source?

Re: New armhf node (Pine64+)

On 2017-02-16, Holger Levsen wrote: > On Mon, Feb 06, 2017 at 01:39:47PM -0800, Vagrant Cascadian wrote: > 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

Another new armhf node (Pine64+)

Yet Another arm board ready to be configured for the build farm! p64c-armhf-rb.debian.net: Pine64+, Allwinner A64 (cortex-a53) quad-core, 2GB ram ssh port: 2248 ssh fingerprints: 2048 7e:11:62:84:b2:e8:cd:2b:52:f5:41:c1:98:bf:7a:d2 (RSA) 256 83:48:b1:c2:11:45:5c:51:9d:67:d1:58:0a:95:3d:33 (ECDSA)

Re: diffoscope 77 in stretch or not?

On 2017-02-13, Mattia Rizzolo wrote: > On Mon, Feb 13, 2017 at 01:32:55PM -0800, Vagrant Cascadian wrote: >> The other obvious option is to not ship a version in stretch and rely on >> stretch-backports, if diffoscope development hasn't yet settled down >> enough (will it ever

Re: diffoscope 77 in stretch or not?

On 2017-02-13, Chris Lamb wrote: > Mattia Rizzolo wrote: >> Then, if the unblock is accepted, I'd say we should either freeze >> diffoscope development […] > > Strongly against this. :) > >> or stop uploading to unstable > > We can always upload to experimental to keep release momentum. Or just >

New armhf node (Pine64+)

Another arm board ready to be configured for the build farm! p64b-armhf-rb.debian.net: Pine64+, Allwinner A64 (cortex-a53) quad-core, 2GB ram ssh port: 2247 ssh fingerprints: 2048 19:26:31:fa:7b:ff:96:ae:14:20:b8:25:36:59:37:df /etc/ssh/ssh_host_rsa_key.pub (RSA) 256

Re: What do we really mean by "reproducible"?

On 2017-01-16, Santiago Vila wrote: > Before I use this rationale more times in some discussions out there, I'd > like to be sure that there is a consensus. > > What's the definition of reproducible? It is more like A or more like B? I don't know if you're aware of the recently created:

Re: [Reproducible-builds] arm64 reproducible build network

On 2016-12-06, Axel Beckert wrote: > Holger Levsen wrote: >> On Tue, Dec 06, 2016 at 09:24:50AM -0800, Martin Michlmayr wrote: >> > I heard from a Linaro contact that LeMaker wasn't able to fix the PCIE >> > issue and was going to produce the board without, but that update is >> > from October and

Re: Buildinfo in the Debian archive, updates

On 2016-12-07, Jonathan McDowell wrote: > On Tue, Dec 06, 2016 at 09:24:20PM +, Holger Levsen wrote: >> On Mon, Nov 14, 2016 at 02:57:00PM +, Ximin Luo wrote: >> > This email is a summary of some discussions that happened after the >> > last post to bug #763822, plus some more of my own

Use lazy unmount for disorderfs on jenkins.debian.net

Retrying without the diff, since that got moderated... Using lazy unmount *might* allow the disorderfs filesystems to unmount if a file descriptor is held open but later releases... worst case is it shouldn't make anything worse. available in "lazy-unmount" branch at:

Help with SCALE 15x submission *today*

Hi, Just heard about the SCALE CfP this weekend, and it's due *today*, so am working on re-doing the talk I did at SeaGL, but could use help on the long description. I've put up a pad for this with links to my SeaGL slides: https://pad.riseup.net/p/1Q5KsaDJnnis If anyone could help extending

opi2a back! init system variations?

opi2a is back! Not sure how to rearrange build jobs off the top of my head, but we've got several cores just sittle idle again. :) For some reason, systemd wasn't starting consistantly, hanging on systemd-logind. Oddly, it worked well enough to still run build jobs, but restarting daemons and

New armhf node (Jetson-TK1)

New armhf board up and ready for configuration. Thanks to Nvidia for the donation, and to Martin Michlmayr and Eric Brower for making the arrangements! jtk1a-armhf-rb.debian.net: Jetson-TK1, nvidia tegra-k1 (cortex-a15) quad-core, 2GB ram ssh port: 2246 ssh fingerprints: 256

Re: [Reproducible-builds] Bug#834016: ddd: please make the build reproducible

On 2016-08-11, Chris Lamb wrote: > +--- ddd-3.3.12.orig/ddd/config-info > ddd-3.3.12/ddd/config-info > +@@ -59,6 +59,10 @@ esac > + month=`date '+%m'` > + day=`date '+%d'` > + date=${year}-${month}-${day} > ++if [ -n "${SOURCE_DATE_EPOCH}" ] > ++then > ++date=`date --utc

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

On 2016-07-25, Jonathan McDowell wrote: > I propose instead a Buildinfo.xz (or gz or whatever) file, which is > single text file with containing all of the buildinfo information that > corresponds to the Packages list. What is lost by this approach are the > OpenPGP signatures that .buildinfo

Re: [Reproducible-builds] Remaining reprotest variations

On 2016-07-27, Ceridwen wrote: > For most of the variations I've done so far, I've been either > depending on external utilities or had POSIX-compliant ways to execute > them.  The rest of the variations pose more problems. ... > 5. kernel: While `uname` is in the POSIX standard, mechanisms for >

Re: [Reproducible-builds] Notes to mariadb-10.0

On 2016-07-10, Otto Kekäläinen wrote: > Diffs reveal that the issue is expressed in products that stem from > storage/tokudb/*. We are not able to poinpoint what it is exactly, and > we are not even able to reproduce the unreproducible build. > > Here's what we've done in a sid amd64 VM: > >

[Reproducible-builds] [PATCH] Respect SOURCE_DATE_EPOCH when building FIT images.

-by: Vagrant Cascadian <vagr...@debian.org> --- tools/default_image.c | 14 +- tools/fit_image.c | 6 -- tools/imagetool.c | 20 tools/imagetool.h | 16 4 files changed, 41 insertions(+), 15 deletions(-) diff --git a

[Reproducible-builds] [PATCH] Use C locale when setting CC_VERSION_STRING and LD_VERSION_STRING.

is consistant regardless of the build environment. Thanks to HW42 for debugging the issue: https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20160606/005722.html For more information about reproducible builds: https://reproducible-builds.org/ Signed-off-by: Vagrant

[Reproducible-builds] ff2b and opi2c back online

On 2016-06-11, Holger Levsen wrote: > This shall give us some more time+ease while deciding if/when to remove > all ff2b and opi2c related jobs… Both should be back online now! So no need to rearrange the jobs anymore. Whew. live well, vagrant signature.asc Description: PGP signature

Re: [Reproducible-builds] [PATCH] Reassign jobs for ff2b-armhf-rb to other nodes

On 2016-06-11, Holger Levsen wrote: > On Fri, Jun 10, 2016 at 09:18:40AM -0700, Vagrant Cascadian wrote: >> > thanks for the patch, before I apply something similar I have a >> > question: does that mean ff2b is gone *forever*? >> >> Not 100% sure just yet; it

[Reproducible-builds] [PATCH] Reassign jobs for ff2b-armhf-rb to other nodes

Reassign jobs for ff2b-armhf-rb to other nodes, as it is down for the forseeable future. Available in the ff2b-reassign branch: https://anonscm.debian.org/git/users/vagrant/jenkins.debian.net.git --- job-cfg/reproducible.yaml | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-)

[Reproducible-builds] u-boot locale variations with it_*.UTF-8

Well, I've been debugging why u-boot stopped building reprodicbly, and it appears to be that the recent fix that really switches armhf to build with it_CH.UTF-8 locale actually breaks u-boot reproducibility. So, just for comparison, I also tested with other locales, including some with non-latin

Re: [Reproducible-builds] diskspace probs on opi3c (was Re: New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)

On 2016-06-02, Holger Levsen wrote: > opi2c already has too little diskspace, from > > https://jenkins.debian.net/view/reproducible/view/Debian_setup_armhf/job/reproducible_setup_schroot_experimental_armhf_opi2c/1/console > > tee: /tmp/schroot-create-8VxOVXtl: No space left

Re: [Reproducible-builds] New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)

On 2016-06-02, Holger Levsen wrote: > Hi Vagrant, > > On Sun, May 29, 2016 at 09:13:20AM -0700, Vagrant Cascadian wrote: >> odu3a-armhf-rb.debian.net: >> cb3a-armhf-rb.debian.net: > > those I can reach nicely… Yay! >> opi2c-armhf-rb.debian.net: >> ssh port

[Reproducible-builds] New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)

Three new build nodes ready to be added to the build network: odu3a-armhf-rb.debian.net: Odroid-U3, exynos4122 quad-core (cortex-a9), 2GB ram, ~60GB USB2 SSD ssh port: 2243 ssh fingerprints: 256 96:13:3b:ec:45:72:45:bc:c7:78:29:73:56:81:4e:ae /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) 2048

Re: [Reproducible-builds] bpi0 armhf node disk failure

On 2016-05-04, Holger Levsen wrote: > On Tue, May 03, 2016 at 11:35:07PM -0700, Vagrant Cascadian wrote: >> I think bpi0's SSD may be in a very bad state. It's one of the oldest >> nodes, so it's no huge surprise to see disk failures there... Yup, disk seemed to be in a pretty ba

[Reproducible-builds] bpi0 armhf node disk failure

I think bpi0's SSD may be in a very bad state. It's one of the oldest nodes, so it's no huge surprise to see disk failures there... I do have an extra SSD on hand to replace it with, but it will mean a clean re-install and then jenkins setup code run, so probably best to suspend scheduling jobs

Re: [Reproducible-builds] Performance of armhf boards

On 2016-04-17, Steven Chamberlain wrote: > I was wondering what is the performance of various armhf boards, for > package building. Of course, the reproducible-builds team have a lot of > stats already. Below I'm sharing the query I used and the results in > case anyone else is interested in

[Reproducible-builds] Blacklist packages for armhf

Doing some sql queires and a bit of eyeball heuristics, I've determined the packages listed below frequently FTBFS due to timeout on armhf. I was hoping we could drop blacklisting altogether as the build network grew, but I'm not sure that's realistic with the current infrastructure. Please

Re: [Reproducible-builds] jenkins.debian.net: [PATCH] Disable download of package descriptions

So, basically, nevermind, apparently pbuilder already does this automatically: < mapreri> I added acquire::languages="none" 6/7 months ago, i think < mapreri> vagrantc: since pbuilder 0.216, 26 august 2015 And looks like the builders are using 0.223~bpo8+1, and I checked the config on one of

[Reproducible-builds] jenkins.debian.net: [PATCH] Disable download of package descriptions

l... Keep on reproducibilitizing! live well, vagrant From ff8da4f3ef9674503da93e38be565c3a7837c7d2 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian <vagr...@debian.org> Date: Sat, 9 Apr 2016 16:43:31 -0700 Subject: [PATCH] Disable download of package descripts by setting apt.conf languages to n

[Reproducible-builds] arm64 reproducible build network

On 2016-03-06, Holger Levsen wrote: > On Sonntag, 6. März 2016, Axel Beckert wrote: >> I now wonder if a bunch of Raspberry Pi 3 -- since they have 64-bit >> CPUs (IIRC an Allwinner A53T) -- would make us able to check >> reproducible-builds for Debian arm64, too. > > as far as I know, yes. Though

Re: [Reproducible-builds] Number of CPUs for armhf builds

On 2016-03-07, Holger Levsen wrote: > On Sonntag, 6. März 2016, Vagrant Cascadian wrote: >> > I'm also pondering to change it to use CPUs+1 for the first builds and >> > CPUs for the 2nd ones. >> That would be interesting, although I was thinking we might want to d

[Reproducible-builds] Number of CPUs for armhf builds

On 2016-03-06, Holger Levsen wrote: > On Sonntag, 6. März 2016, Vagrant Cascadian wrote: >> Ah, looking at: >> >> https://tests.reproducible-builds.org/reproducible.html ... >> I guess it must just use the number of CPUs for first build, and number >> of CPUs

Re: [Reproducible-builds] Raspi 3 suitable for arm64?

Cc'ed correct debian-arm address... On 2016-03-06, Holger Levsen wrote: > On Sonntag, 6. März 2016, Axel Beckert wrote: >> I now wonder if a bunch of Raspberry Pi 3 -- since they have 64-bit >> CPUs (IIRC an Allwinner A53T) -- would make us able to check >> reproducible-builds for Debian arm64,

Re: [Reproducible-builds] Raspi 3 suitable for arm64?

On 2016-03-06, Holger Levsen wrote: > On Sonntag, 6. März 2016, Axel Beckert wrote: >> I now wonder if a bunch of Raspberry Pi 3 -- since they have 64-bit >> CPUs (IIRC an Allwinner A53T) -- would make us able to check >> reproducible-builds for Debian arm64, too. I got the impression it was

Re: [Reproducible-builds] new armhf nodes (Firefly-4gb, BeagleBoard-X15)

On 2016-03-05, Holger Levsen wrote: > On Donnerstag, 3. März 2016, Vagrant Cascadian wrote: >> This new board recognizes all 4GB of ram, yay! >> >> ff4a-armhf-rb.debian.net: >> Firefly-RK3288, quad-core rockchip 3288 (A12/A17?), 4GB ram > > yay indeed & a

Re: [Reproducible-builds] new armhf node (BeagleBoard-X15)

On 2016-03-03, Vagrant Cascadian wrote: > I need to do some more testing with the BeagleBoard-X15 board to get > support in the kernel and debian-installer, and try to enable eSATA > support, but should be ready real soon now... Well, got eSATA working finally, so decided to run with i

[Reproducible-builds] new armhf node (Firefly-4gb)

This new board recognizes all 4GB of ram, yay! ff4a-armhf-rb.debian.net: Firefly-RK3288, quad-core rockchip 3288 (A12/A17?), 4GB ram ssh port: 2241 ssh fingerprints: 2048 87:3e:d4:f7:00:65:bd:39:ea:47:81:16:55:d6:cf:66 /etc/ssh/ssh_host_rsa_key.pub (RSA) 256

Re: [Reproducible-builds] licencing reproducible/presentations.git

On 2016-02-04, Holger Levsen wrote: > I'd like to add proper licencing to the presentations in > git.debian.org/git/reproducible/presentations.git and you in the to: headers > of the mail are a git commiter to this repository, so I would like you to > (re-)licence your contributions under the

Re: [Reproducible-builds] new armhf node (Cubox-i4x4), part 2

On 2016-02-01, Vagrant Cascadian wrote: > cbxi4a-armhf-rb.debian.net: > Cubox-i4x4, imx6 quad-core, 2GB ram, ~60GB SATA SSD Upgraded cbxi4a to 3.8GB of ram! And added another node to join it: cbxi4b-armhf-rb.debian.net: Cubox-i4x4, imx6 quad-core, 3.8GB ram, ~60GB SATA SSD ssh port: 22

Re: [Reproducible-builds] new armhf node (Cubox-i4x4)

On 2016-02-02, Holger Levsen wrote: > thanks for setting it up, but: > > jenkins@jenkins:~$ ssh -v -p 2239 cbxi4a-armhf-rb.debian.net > OpenSSH_6.7p1 Debian-5+deb8u1, OpenSSL 1.0.1k 8 Jan 2015 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: Applying

[Reproducible-builds] new armhf node (Cubox-i4x4)

Here's another board, in theory with more ram, but in practice... cbxi4a-armhf-rb.debian.net: Cubox-i4x4, imx6 quad-core, 2GB ram, ~60GB SATA SSD ssh port: 2239 ssh fingerprints: 256 dc:9a:85:0a:d5:85:72:26:9b:5b:b8:89:24:8a:fb:46 /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) 2048

Re: [Reproducible-builds] new armhf node (OrangePi Plus2)

On 2016-01-14, Holger Levsen wrote: > On Mittwoch, 13. Januar 2016, Vagrant Cascadian wrote: >> opi2b-armhf-rb.debian.net: >> OrangePi Plus2, Allwinner H3 (cortex-a7) quad-core, 2GB ram, ~60GB USB2 >> SATA SSD ssh port: 2238 > > thanks, added to the jenkins setup. Once

Re: [Reproducible-builds] new armhf node (OrangePi Plus2)

This one has been rather finicky, but appears to be working now... opi2b-armhf-rb.debian.net: OrangePi Plus2, Allwinner H3 (cortex-a7) quad-core, 2GB ram, ~60GB USB2 SATA SSD ssh port: 2238 ssh fingerprints: 256 3e:b4:a4:f3:3a:c1:ba:75:3a:4b:4f:c6:80:e6:04:5b /etc/ssh/ssh_host_ecdsa_key.pub

Re: [Reproducible-builds] new armhf nodes (Firefly/OrangePi Plus2)

On 2016-01-05, Holger Levsen wrote: > On Dienstag, 5. Januar 2016, Vagrant Cascadian wrote: >> Two more quad-core systems ready to join the fun! > > awesome, thanks a lot! > > I'm setting them up right now, pbuilder/schroot/maintenance jobs are > basically > there

Re: [Reproducible-builds] new armhf nodes (Firefly/OrangePi Plus2)

Two more quad-core systems ready to join the fun! ff2b-armhf-rb.debian.net: Firefly, rockchip rk3288 (cortex-a12(?)) quad-core, 2GB ram, ~60GB USB2 SATA SSD ssh port: 2237 ssh fingerprints: 256 ca:65:9c:9c:df:6e:8c:b8:00:10:dc:f0:71:b0:57:ab /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) 2048

Re: [Reproducible-builds] new armhf node (Raspberry PI 2B)

On 2016-01-01, Holger Levsen wrote: > On Mittwoch, 30. Dezember 2015, Vagrant Cascadian wrote: >> Got a second Raspberry PI 2 set up, awaiting configuration... >> rpi2c-armhf-rb.debian.net: > > I've set it up now and am in the process of integrating it into the jenkins >

Re: [Reproducible-builds] new armhf node (Raspberry PI 2B)

Got a second Raspberry PI 2 set up, awaiting configuration... rpi2c-armhf-rb.debian.net: Raspberry PI 2B, broadcom(?) quad-core, 1GB ram, ~60GB USB3 SATA SSD ssh port: 2235 ssh fingerprints: 256 85:c9:4c:6a:99:6a:d0:61:26:4b:00:2d:19:0c:67:a2 /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) 2048

Re: [Reproducible-builds] new armhf node (Firefly)

On 2015-12-25, Vagrant Cascadian wrote: > Have been working a bit on two firefly boards, but need to > sort out issues with MMC and USB, but at least u-boot is able to boot a > debian kernel (built with a few config options added)... Well, today was productive! Figured out the kerne

Re: [Reproducible-builds] new armhf node (Odroid-XU4)

Ok, got the first of the armhf build network upgrade plan machines up and running, awaiting integration into the network... odxu4b-armhf-rb.debian.net: Odroid-XU4, exynos5422 quad-core, 2GB ram, ~60GB USB3 SATA SSD ssh port: 2232 ssh fingerprints: 256

Re: [Reproducible-builds] Second build on failures

On 2015-12-21, Holger Levsen wrote: > On Donnerstag, 3. Dezember 2015, Vagrant Cascadian wrote: >> Filed against libc-bin: >> https://bugs.debian.org/806911 >> Aurelian Jarno filed a patch upstream to support using the uname26 >> personality: >> https://sou

Re: [Reproducible-builds] Patch V2 for build nodes pools

On 2015-12-21, Holger Levsen wrote: > On Samstag, 19. Dezember 2015, Vagrant Cascadian wrote: >> I didn't spend any time really figuring out which nodes to add to the >> example 16th build job, so that might need some adjusting. > > put some 4cores in one pool, and 2cores

[Reproducible-builds] Patch for build nodes pools

, or other functions that run outside of reproducible_build.sh that need to know those variables. live well, vagrant commit 200c45bbb5768dce5649b05ad599c85c6bb14b50 Author: Vagrant Cascadian <vagr...@debian.org> Date: Fri Dec 18 15:02:32 2015 -0800 Implement support for build pools, a

Re: [Reproducible-builds] new armhf node (Odroid-C1+)

On 2015-12-05, Vagrant Cascadian wrote: > It might not come online for real until Sunday evening (just need to > move it into place with all the others), but figured I'd announce it > now: > > odc1-armhf-rb.debian.net: ... > This is the first one running an older version of linu

[Reproducible-builds] new armhf node (Odroid-C1+)

It might not come online for real until Sunday evening (just need to move it into place with all the others), but figured I'd announce it now: odc1-armhf-rb.debian.net: Odroid-C1+, quad-core Amlogic (meson8b? cortex-a5), 1GB ram, ~60GB USB3 SATA SSD ssh port: 2231 ssh fingerprints: 256

Re: [Reproducible-builds] blacklist armhf: vxl qtbase-opensource-src

On 2015-12-03, Holger Levsen wrote: > On Donnerstag, 3. Dezember 2015, Vagrant Cascadian wrote: >> Both hit the 12 hour timeout at least once, and armhf is slow enough, >> and hasn't neared 100% enough to keep building these... > > no need to justify things, I assume you k

[Reproducible-builds] blacklist armhf: vxl qtbase-opensource-src

Please (add to the growing) blacklist on armhf: vxl qtbase-opensource-src Both hit the 12 hour timeout at least once, and armhf is slow enough, and hasn't neared 100% enough to keep building these... live well, vagrant signature.asc Description: PGP signature

Re: [Reproducible-builds] Second build on failures

On 2015-12-01, Reiner Herrmann <rei...@reiner-h.de> wrote: > On Tue, Dec 01, 2015 at 02:13:07PM -0800, Vagrant Cascadian wrote: >> Hey, I think all of the second builds on armhf are failing to set up the >> build environment: >> >> >> https://repr

[Reproducible-builds] Bug#806911: libc-bin: ldconfig segfaults when run using "setarch uname26"

Package: libc-bin Version: 2.21-1 Severity: normal X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Apparently, when run with "setarch uname26" or "linux64 --uname-2.6", ldconfig segfaults. setarch uname26 ldconfig FATAL: kernel too old Segmentation fault libc-bin version 2.19-22

[Reproducible-builds] Second build on failures

Hey, I think all of the second builds on armhf are failing to set up the build environment: https://reproducible.debian.net/logs/unstable/armhf/gb_0.3.2-1.build2.log.gz I: Installing the build-deps I: user script /srv/workspace/pbuilder/5651/tmp/hooks/D01_modify_environment starting

[Reproducible-builds] new armhf node (Raspberry PI 2B)

And another! rpi2b-armhf-rb.debian.net: Raspberry PI 2B, broadcom(?) quad-core, 1GB ram, ~60GB USB3 SATA SSD ssh port: 2230 ssh fingerprints: 256 42:3a:92:86:e8:a9:db:2f:1e:86:9b:f2:07:fa:87:97 /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) 2048 d1:a8:26:2a:0a:c9:1b:67:0d:c9:48:95:23:4b:9f:31

[Reproducible-builds] new armhf node (Wandboard Dual)

And another one! wbd0-armhf-rb.debian.net: Wandboard-Dual, imx6 dual-core, 1GB ram, ~60GB USB2 SATA spinning disk ssh port: 2223 ssh fingerprints: 256 d9:50:c6:3b:f8:1d:38:ac:97:ea:62:ea:37:cd:98:ed /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) 2048 48:4c:9c:b4:b7:41:76:6f:36:0d:eb:b5:83:bf:66:4c

Re: [Reproducible-builds] new armhf node (Odroid-XU4)

On 2015-11-09, Holger Levsen wrote: > thanks a lot for this new node. I've set it up and included in the machinery > now That was fast... yay! > btw, how will you attach the sdd? > http://archlinuxarm.org/platforms/armv7/samsung/odroid-xu4 only speaks about > sd-cards as far as I could see.

Re: [Reproducible-builds] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH

On 2015-09-28, Paul Kocialkowski wrote: > Le jeudi 24 septembre 2015 à 09:05 -0700, Vagrant Cascadian a écrit : >> I think the use of "time = mktime(time_universal);" is where the problem >> lies: > > […] > >> According to the mktime manpage: >> >&

Re: [Reproducible-builds] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH

On 2015-07-26, Paul Kocialkowski wrote: > In order to achieve reproducible builds in U-Boot, timestamps that are defined > at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH > environment > variable allows setting a fixed value for those timestamps. ... > However, some other

Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH

On 2015-08-25, Andreas Bießmann wrote: On 07/28/2015 05:00 PM, Tom Rini wrote: On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: In order to achieve reproducible builds in U-Boot, timestamps that are defined at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH

Re: [Reproducible-builds] dpkg_1.18.1.0~reproducible5 ftbfs

On 2015-07-31, Guillem Jover wrote: On Fri, 2015-07-31 at 16:49:13 +0200, Holger Levsen wrote: so yesterday I tried to build http://reproducible.alioth.debian.org/debian/dpkg_1.18.1.0~reproducible5.dsc with pbuilder on sid/armhf and that failed _exactly_ like

Re: [Reproducible-builds] ARM build machines

On 2015-08-03, Holger Levsen wrote: On Samstag, 1. August 2015, Vagrant Cascadian wrote: wbq0-armhf-rb.debian.net: $ host wbq0-armhf-rb.debian.net Host wbq0-armhf-rb.debian.net not found: 3(NXDOMAIN) Oops. Accidentally dropped it on one of the debian.net updates. Re-added just now, got

Re: [Reproducible-builds] ARM build machines

On 2015-07-27, Vagrant Cascadian wrote: The current specs: bpi0-armhf-rb.debian.net: Banana PI, dual-core, 1GB ram, ~20GB mSATA. ssh port: ssh fingerprints: 2048 8f:0a:d0:77:a8:59:c0:bb:d0:76:de:14:13:5b:a6:56 (RSA) 256 af:b4:13:04:21:30:46:b3:e8:79:ff:7d:99:20:86:f0 (ECDSA) hb0

Re: [Reproducible-builds] ARM build machines

On 2015-07-28, Holger Levsen wrote: do you need to be cc:ed? I am subscribed to the list as of a few weeks ago. On Montag, 27. Juli 2015, Vagrant Cascadian wrote: So I set about trying to patch u-boot and test reproducibility myself, only to discover that the reproducible toolchain didn't

Re: [Reproducible-builds] [PATCH] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH

On 2015-07-20, Paul Kocialkowski wrote: In order to achieve reproducible builds in U-Boot, timestamps that are defined at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment variable allows setting a fixed value for those timestamps. ... diff --git a/Makefile

Re: [Reproducible-builds] [U-Boot] [PATCH] build: create time and date independent binary

On 2015-07-19, Holger Levsen wrote: All this said, if you send me patches, I will probably deploy them as I'm very curious and more reproducibility efforts are good :-) We can can always decide to remove or move them later. I wish to make all contributions upstream. What would really help

[Reproducible-builds] [U-Boot] [PATCH] build: create time and date independent binary

Thanks for sharing the patches to set U_BOOT_DATE/U_BOOT_TIME/U_BOOT_TZ. I happened to independently work on a similar patch in the last few days: Index: u-boot/Makefile === --- u-boot.orig/Makefile +++ u-boot/Makefile @@ -1231,10

[Reproducible-builds] Bug#778571: sbuild: predictible build location for reproducible builds

does this by setting the build dir to /build/PACKAGE-VERSION rather than /build/PACKAGE-XX: From 15b77405a67faaea7bc3974a4e7a3862620d0b42 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian vagr...@debian.org Date: Fri, 13 Feb 2015 23:18:23 -0800 Subject: [PATCH 1/2] Make predictible build dir

[Reproducible-builds] Bug#778570: sbuild: ignore .buildinfo files in .changes

/workaround this: From 8468411099b8ec28641df015742784b63b98b573 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian vagr...@debian.org Date: Fri, 13 Feb 2015 23:51:11 -0800 Subject: [PATCH 2/2] Ignore .buildinfo files produced by reproducible builds. --- lib/Sbuild/Build.pm | 2 ++ 1 file changed, 2

Re: [Reproducible-builds] Patches for sbuild reproducible builds

On 2015-02-16, Holger Levsen wrote: On Samstag, 14. Februar 2015, Vagrant Cascadian wrote: One patch sets the build dir to a static location based on the package version, rather than a tempdir with a random string. The other patch ignores .buildinfo files in the .changes when displaying