Re: [Reproducible-builds] Juniper ScreenOS backdoor
Holger Levsen wrote: > https://github.com/hdm/juniper-cve-2015-7755/tree/master/firmware has links > to > the actual firmware images, I would appreciate if someone could throw them > against (my.)diffoscope.org and share the links…! Oh, didn't think of that! It may be a nice demo of diffoscope if it can do this, although it might not know how to disassemble this properly. I uploaded the firmwares here but I think something broke... it has been "in queue, please wait" for over an hour :( The files were 25MB each. https://try.diffoscope.org/quvzskqbuysh Regards, -- Steven Chamberlain ste...@pyro.eu.org 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] Juniper ScreenOS backdoor
Hi, One of the reproducible builds talk slides, showed a diff of OpenSSH before and after some off-by-one vulnerability was fixed. Here's a real-world malicious backdoor in Juniper ScreenOS's sshd: https://community.rapid7.com/servlet/JiveServlet/showImage/38-7376-36434/ssh.png The yellow highlighted string allows login as any user. Full article: https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor Whilst this may have been added in source code, it was well-disguised in the disassembly and just 7 instructions long. I thought this was a good example of the current state-of-the-art, and why we'd like our binaries and eventually, installer and VM images reproducible IMHO. Regards, -- Steven Chamberlain ste...@pyro.eu.org 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] Bug#808675: liwc: FTBFS: strutil.h:67:7: error: expected identifier or '(' before '__extension__' char *strndup(const char *, size_t)
Source: liwc
Version: 1.21-1
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Dear Maintainer,
liwc fails to build from source in unstable/amd64:
[..]
dh_auto_build -- \
CPPFLAGS="-D_FORTIFY_SOURCE=2" \
CFLAGS="-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security" \
LDFLAGS="-Wl,-z,relro"
make -j1 CPPFLAGS=-D_FORTIFY_SOURCE=2 "CFLAGS=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security" LDFLAGS=-Wl,-z,relro
make[2]: Entering directory
'/home/lamby/temp/cdt.20151221183809.aJRPcooGBx/liwc-1.21'
gcc -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wl,-z,relro -o ccmtcnvt ccmtcnvt.c -lpub
In file included from /usr/include/string.h:634:0,
from ccmtcnvt.c:82:
/usr/include/publib/strutil.h:67:7: error: expected identifier or '(' before
'__extension__'
char *strndup(const char *, size_t);
^
Makefile:40: recipe for target 'ccmtcnvt' failed
make[2]: *** [ccmtcnvt] Error 1
make[2]: Leaving directory
'/home/lamby/temp/cdt.20151221183809.aJRPcooGBx/liwc-1.21'
dh_auto_build: make -j1 CPPFLAGS=-D_FORTIFY_SOURCE=2 CFLAGS=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security LDFLAGS=-Wl,-z,relro
returned exit code 2
debian/rules:7: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory
'/home/lamby/temp/cdt.20151221183809.aJRPcooGBx/liwc-1.21'
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2
[..]
The full build log is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
liwc.1.21-1.unstable.amd64.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#806911: Second build on failures
On 2015-12-21 19:02, Holger Levsen wrote: > Hi, > > cc:ing the bug and thus leaving some more context… > > On Montag, 21. Dezember 2015, Vagrant Cascadian wrote: > > On 2015-12-21, Holger Levsen wrote: > > >> For now, relying on the fact that there are different actual kernels on > > >> various builds (4.x vs. 3.x) will hopefully be good enough to detect the > > >> issue that using "linux64 --uname-2.6" was trying to solve. > > > > > > yeah. what I don't like about this is that it forces us to do that. I > > > liked the flexibility using --uname-2.6 gave us… > > > > The impression I got was the patch implementation was rejected upstream, > > but in theory a better patch could be written. Aurelian wasn't planning > > on working on it. > > I've got the same impression. I still have it on my todo list, but with very low priority. So if someone wants to provide a patch, that would be welcome. Also note that we have re-enabled 2.6.32 support on amd64 and i386, so you should not need any patch to get these architectures working. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808667: libmouse-perl: please make the build reproducible
Source: libmouse-perl
Version: 2.4.5-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Hi!
While working on the "reproducible builds" effort [1], we have noticed
that libmouse-perl could not be built reproducibly.
During build a file is generated with references to other files.
The file list is embedded in readdir order, which is not deterministic.
The attached patch sorts the list before the filenames are embedded.
Regards,
Reiner
[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch
new file mode 100644
index 000..450b6fb
--- /dev/null
+++ b/debian/patches/reproducible_build.patch
@@ -0,0 +1,11 @@
+--- a/tool/generate-mouse-tiny.pl
b/tool/generate-mouse-tiny.pl
+@@ -78,7 +78,7 @@
+ # tell Perl we already have all of the Mouse files loaded:
+ EOF
+
+-for my $file (@files) {
++for my $file (sort @files) {
+ (my $inc = $file) =~ s{^lib/}{};
+ printf { $handle } "%-45s = __FILE__;\n", "\$INC{'$inc'}";
+ }
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..b2026fe
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+reproducible_build.patch
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Juniper ScreenOS backdoor
Hi Steven, On Montag, 21. Dezember 2015, Steven Chamberlain wrote: > One of the reproducible builds talk slides, showed a diff of OpenSSH > before and after some off-by-one vulnerability was fixed. > > Here's a real-world malicious backdoor in Juniper ScreenOS's sshd: > https://community.rapid7.com/servlet/JiveServlet/showImage/38-7376-36434/ss > h.png The yellow highlighted string allows login as any user. Full > article: > https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-77 > 55-juniper-screenos-authentication-backdoor "neato" :/ https://github.com/hdm/juniper-cve-2015-7755/tree/master/firmware has links to the actual firmware images, I would appreciate if someone could throw them against (my.)diffoscope.org and share the links…! > Whilst this may have been added in source code, it was well-disguised in > the disassembly and just 7 instructions long. I thought this was a good > example of the current state-of-the-art, and why we'd like our binaries > and eventually, installer and VM images reproducible IMHO. indeed! thanks for sharing this here! cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#806911: Second build on failures
Hi Aurelien, On Montag, 21. Dezember 2015, Aurelien Jarno wrote: > Also note that we have re-enabled 2.6.32 support on amd64 and i386, so > you should not need any patch to get these architectures working. nice! but this is not available yet in sid+testing yet, or is it? (or maybe rather: what does "2.6.32 support" mean here???) cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Juniper ScreenOS backdoor
Steven Chamberlain wrote: > I uploaded the firmwares here but I think something broke... it has been > "in queue, please wait" for over an hour :( The files were 25MB each. > https://try.diffoscope.org/quvzskqbuysh Okay, I did eventually finish. As suspected, diffoscope (or file or binutils) don't know how to disassemble this automatically, and neither do I. The ssh500*.bin files should be x86 code, already decompressed. The differences are too numerous for diffoscope to show all of it anyway. I guess Juniper didn't implement reproducible builds yet ;) Regards, -- Steven Chamberlain ste...@pyro.eu.org 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] Bug#808711: ca-certificates: please make the build reproducible
Source: ca-certificates Version: 20150426 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: fileordering X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi! While working on the "reproducible builds" effort [1], we have noticed that ca-certificates could not be built reproducibly. It embeds an unsorted list of crt files in a config file. The attached patch fixes this by sorting the list before it is embedded. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/debian/rules b/debian/rules index ddd7cee..fd4632b 100755 --- a/debian/rules +++ b/debian/rules @@ -44,7 +44,7 @@ install: build $(MAKE) install DESTDIR=$(CURDIR)/debian/ca-certificates (cd $(CURDIR)/debian/ca-certificates/usr/share/ca-certificates; \ crts=""; \ - for crt in $$(find . -type f -name '*.crt' -print); \ + for crt in $$(find . -type f -name '*.crt' -print | LC_ALL=C sort); \ do \ crt=$$(echo $$crt | sed -e 's/\.\///'); \ if test "$$crts" = ""; then \ ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#806911: Second build on failures
On 2015-12-21 22:24, Holger Levsen wrote: > Hi Aurelien, > > On Montag, 21. Dezember 2015, Aurelien Jarno wrote: > > Also note that we have re-enabled 2.6.32 support on amd64 and i386, so > > you should not need any patch to get these architectures working. > > nice! but this is not available yet in sid+testing yet, or is it? (or maybe > rather: what does "2.6.32 support" mean here???) I meant 2.6.32 kernel support, and it's already in testing and sid. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net 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] Patch V2 for build nodes pools
Hi Vagrant,
On Montag, 21. Dezember 2015, Vagrant Cascadian wrote:
> > put some 4cores in one pool, and 2cores in another?
> It could be done any number of ways, I merely added it to show how it
> would work with the code I was proposing.
well, I don't think we should develop an example here, but rather actual
working code :) Thus we need to settle on one way.
Thus it occurred to me what the main differating attribute is: whether it's
running in future or not. Additionally I would try to also differate other
attributes along the same line (but this is bound to fail, still lets keep the
impact of this failure small):
- have two pools, "future machines", "todays machines"
- distribute cpu power roughly evenly among them
- _ideally_ by having all 2 core machines be one (or the other)
- then also, have machines in one pool run the normal jessie kernel and have
machines in the other pool run the bpo kernel or newer.
This should achieve the best possible variation while utilising maximum build
power.
> I was hoping the pool code
> could be ready enough to use with the new nodes that should be coming by
> the end of the year, and they'd be reasonable first tests...
I'd rather not do that for two reasons:
- we want to use the new nodes fast, so lets use them. the existing scheduling
is really not that bad.
- also, developing new stuff tends to break. if we throw more ressources at
this while development, the breakage will be bigger, thus the fallout.
Thus, let's stay with the plan to develop this with one builder job first.
> >> - Split load estimating into it's own script, and add support for
> >> available memory.
> >
> > I'd still suggest to measure the load constantly by a job outside the
> > build script… (then it's also easy to read "not updated node load since
> > $time" as "node is to busy to be scheduled on…)
> >
> >> - Call timeout so that the ssh processes don't take too long to
> >> complete.
> >
> > see above, don't ssh from the build script please.
>
> Implementing that outside of the build script would make this much more
> complicated...
Implementing this inside the build script makes the build script more error
prone. As I understand your proposal, you want to check 15 nodes via ssh at
each build, that means 15 times watching an ssh connection, waiting til this
ends… and I dont want to even think about doing this in parallel in shell.
This is bound to break, IMO.
> The second build needs to check for load when it is about to be run, as
> it doesn't make sense to check when build_rebuild is run (unless you run
> both build1 and build2 in parallel... but that's a whole different
> proposal), as the load of the machines is likely to change between the
> first and second build.
Then run the job to check the load every 5min. Or every 2min. But provide
something the build script can *consume* in *no time*. We currently have 15
armhf builder jobs, the new hardware should make this 40 or so jobs in one or
two months. And each job should crawl the nodes? NO.
> I'm not sure how to do all that outside the build script and keep the
> code reasonably simple.
Your prososal aint simple. Or rather: the environment it needs to fit in.
> What's the primary concern with ssh from within the build script? Taking
> too long to get a response?
see above.
> >> diff --git a/bin/reproducible_build.sh b/bin/reproducible_build.sh
> >
> > I'll only comment on the most "pressing" issues now.
> >
> >> build_rebuild() {
> >>
> >>FTBFS=1
> >>mkdir b1 b2
> >>
> >> + local selected_node
> >> + selected_node=$(select_least_loaded_node $NODE1_POOL)
> >
> > please make this somehow conditional so that this code path is not used
> > for "normal operation" (=without this new pooling), so we can test this
> > easily on one builder job, but not on all.
>
> It basically is conditional in that the select_least_loaded_node
> function simply returns the node if only one argument is passed.
Please make it "conditionally", not "basically conditionally". The code is run
to build 5-10k packages on amd64 too, I neither want to fork it, nor risk
destablisation.
> > …reproducible_build.sh should probably be called with
> > "experimental-pooling" as first param, which is then shifted away…
> That shouldn't be too hard, sure.
:-)
> Could alternately use something like:
>
>- '16': { my_node1: 'pool,wbd0-armhf-rb:2223,wbq0-armhf-rb:2225',
> my_node2: 'pool,bpi0-armhf-rb:,odxu4-armhf-rb:2229' }
no. rather: "pool" as $1 for the script, not as part of $2+$3.
> Maybe this should be written in two stages, first implementing a simpler
> patch just providing failover, and then adding the load checks later.
small patches are easier to take, yes.
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Re: [Reproducible-builds] Second build on failures
Hi, cc:ing the bug and thus leaving some more context… On Montag, 21. Dezember 2015, Vagrant Cascadian wrote: > On 2015-12-21, Holger Levsen wrote: > >> For now, relying on the fact that there are different actual kernels on > >> various builds (4.x vs. 3.x) will hopefully be good enough to detect the > >> issue that using "linux64 --uname-2.6" was trying to solve. > > > > yeah. what I don't like about this is that it forces us to do that. I > > liked the flexibility using --uname-2.6 gave us… > > The impression I got was the patch implementation was rejected upstream, > but in theory a better patch could be written. Aurelian wasn't planning > on working on it. I've got the same impression. > So if it's wanted for reproducible builds purposes, probably need to > come up with a patch that would get accepted upstream... Yup. Any takers? :-) cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808652: nexuiz-data: please make the build reproducible
Source: nexuiz-data
Version: 2.5.2-6
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Hi!
While working on the "reproducible builds" effort [1], we have noticed
that nexuiz-data could not be built reproducibly.
During build a checksum over configuration settings is calculated and
embedded in some files. The lines are sorted before generating the
checksum, but sort behaves differently depending on the configured
locale.
The attached patch sorts with the locale set to C, so that the same
values are generated independent of the current locale.
Regards,
Reiner
[1]: https://wiki.debian.org/ReproducibleBuilds
diff -uprN 1/debian/patches/reproducible_build.diff 2/debian/patches/reproducible_build.diff
--- 1/debian/patches/reproducible_build.diff 1970-01-01 01:00:00.0 +0100
+++ 2/debian/patches/reproducible_build.diff 2015-12-21 15:37:37.0 +0100
@@ -0,0 +1,16 @@
+--- a/data/update-cvarcount.sh
b/data/update-cvarcount.sh
+@@ -2,10 +2,10 @@
+
+ balance_cfgs="balanceHavoc.cfg balance25.cfg balanceSamual.cfg"
+
+-countd=`awk '/^seta? g_/ { print $2; }' defaultNexuiz.cfg | sort -u | tr -d '\r' | md5sum | cut -c 1-32`
+-countw=`awk '/^seta? g_/ { print $2; }' balance.cfg | sort -u | tr -d '\r' | md5sum | cut -c 1-32`
++countd=`awk '/^seta? g_/ { print $2; }' defaultNexuiz.cfg | LC_ALL=C sort -u | tr -d '\r' | md5sum | cut -c 1-32`
++countw=`awk '/^seta? g_/ { print $2; }' balance.cfg | LC_ALL=C sort -u | tr -d '\r' | md5sum | cut -c 1-32`
+ for b in $balance_cfgs; do
+- countb=`awk '/^seta? g_/ { print $2; }' "$b" | sort -u | tr -d '\r' | md5sum | cut -c 1-32`
++ countb=`awk '/^seta? g_/ { print $2; }' "$b" | LC_ALL=C sort -u | tr -d '\r' | md5sum | cut -c 1-32`
+ if [ "$countw" != "$countb" ]; then
+ echo "Mismatch between balance.cfg and $b. Aborting."
+ exit 1
diff -uprN 1/debian/patches/series 2/debian/patches/series
--- 1/debian/patches/series 2011-06-29 15:33:05.0 +0200
+++ 2/debian/patches/series 2015-12-21 15:37:03.0 +0100
@@ -5,3 +5,4 @@
05_disable_development_warning.diff
exclude_textures_from_data.pk3.diff
windowed_by_default.diff
+reproducible_build.diff
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808589: cplay: FTBFS: dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both"
Source: cplay Version: 1.49-10 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, cplay fails to build from source in unstable/amd64: [..] dh_installmanpages: This program is deprecated, switch to dh_installman. dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both" debian/rules:33: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 25 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- cplay.1.49-10.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808592: rinetd: FTBFS: dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both"
Source: rinetd Version: 0.62-5.1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, rinetd fails to build from source in unstable/amd64: [..] dh_installmanpages dh_installmanpages: This program is deprecated, switch to dh_installman. dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both" debian/rules:35: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 25 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- rinetd.0.62-5.1.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Juniper ScreenOS backdoor
Hi, Chris Lamb wrote: > It actually finished in about 2 seconds but there was just a small bug: > > https://github.com/lamby/trydiffoscope/commit/3ed0ba502bf3f89d4c0599e3bcd390b3bb40f9f2 Thanks! And I was just about to point out the typo, but... https://github.com/lamby/trydiffoscope/commit/302190ac958b35fe95a0c2bc2d2a30f214822fc1 Regards, -- Steven Chamberlain ste...@pyro.eu.org 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] Bug#808714: yaml-cpp: please make the build reproducible
Source: yaml-cpp
Version: 0.5.2-3
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Hi!
While working on the "reproducible builds" effort [1], we have noticed
that yaml-cpp could not be built reproducibly.
A list of source files in CMakeLists.txt is unsorted.
The attached patch fixes this.
Regards,
Reiner
[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..e718fdf
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,10 @@
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -100,6 +100,7 @@
+ ${contrib_private_headers}
+ )
+ add_sources(${library_sources})
++list(SORT library_sources)
+
+ if(VERBOSE)
+ message(STATUS "sources: ${sources}")
diff --git a/debian/patches/series b/debian/patches/series
index 099bc08..17b37b4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
pkgconfig.patch
install-cmake-dev-files.patch
+reproducible-build.patch
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808713: mozilla-devscripts: please sort file list in preferences files
Source: mozilla-devscripts Version: 0.42 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: fileordering toolchain X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi! While working on the "reproducible builds" effort [1], we have noticed that mozilla-devscripts embeds file lists in undeterministic readdir order into .js files. The attached patch fixes this by sorting the list of files. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/install-xpi b/install-xpi index 4e7c674..aba8773 100755 --- a/install-xpi +++ b/install-xpi @@ -131,7 +131,7 @@ def install_xpi(script_name, package, xpi_file, exclude, install_dir, links, (script_name, xpi_file), file=sys.stderr) sys.exit(XPI_FILE_DOES_NOT_EXISTS) zfobj = zipfile.ZipFile(xpi_file) -xpi_content = zfobj.namelist() +xpi_content = sorted(zfobj.namelist()) # determine installation directory if get_arch(package, debian_directory) == "all": ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808591: netpipe: FTBFS: make[1]: mpicc.mpich2: Command not found
Source: netpipe Version: 3.7.2-7.1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, netpipe fails to build from source in unstable/amd64: [..] cp debian/netpipe.1 NPlam.1 /usr/bin/make mpi MPICC=mpicc.openmpi make[1]: Entering directory '/home/lamby/temp/cdt.20151221104738.kA4etOPo4p/netpipe-3.7.2' mpicc.openmpi -O -g -DMPI ./src/netpipe.c ./src/mpi.c -o NPmpi -I./src make[1]: Leaving directory '/home/lamby/temp/cdt.20151221104738.kA4etOPo4p/netpipe-3.7.2' mv NPmpi NPopenmpi cp debian/netpipe.1 NPopenmpi.1 # /usr/bin/make mpi MPICC=mpicc.mpich # mv NPmpi NPmpich # cp debian/netpipe.1 NPmpich.1 /usr/bin/make mpi MPICC=mpicc.mpich2 make[1]: Entering directory '/home/lamby/temp/cdt.20151221104738.kA4etOPo4p/netpipe-3.7.2' mpicc.mpich2 -O -g -DMPI ./src/netpipe.c ./src/mpi.c -o NPmpi -I./src make[1]: mpicc.mpich2: Command not found makefile:134: recipe for target 'mpi' failed make[1]: *** [mpi] Error 127 make[1]: Leaving directory '/home/lamby/temp/cdt.20151221104738.kA4etOPo4p/netpipe-3.7.2' debian/rules:24: recipe for target 'build-stamp' failed make: *** [build-stamp] Error 2 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- netpipe.3.7.2-7.1.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808588: code2html: FTBFS: dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both"
Source: code2html Version: 0.9.1-4 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, code2html fails to build from source in unstable/amd64: [..] dh_installmanpages dh_installmanpages: This program is deprecated, switch to dh_installman. dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both" debian/rules:22: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 25 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- code2html.0.9.1-4.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808590: funny-manpages: FTBFS: dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both"
Source: funny-manpages Version: 1.3-5.1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, funny-manpages fails to build from source in unstable/amd64: [..] dh_installmanpages: getpackages: First argument must be one of "arch", "indep" or "both" debian/rules:58: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 25 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- funny-manpages.1.3-5.1.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Patch V2 for build nodes pools
Hi Vagrant,
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 in another?
> - Split load estimating into it's own script, and add support for
> available memory.
I'd still suggest to measure the load constantly by a job outside the build
script… (then it's also easy to read "not updated node load since $time" as
"node is to busy to be scheduled on…)
> - Call timeout so that the ssh processes don't take too long to complete.
see above, don't ssh from the build script please.
> diff --git a/bin/reproducible_build.sh b/bin/reproducible_build.sh
I'll only comment on the most "pressing" issues now.
> build_rebuild() {
> FTBFS=1
> mkdir b1 b2
> + local selected_node
> + selected_node=$(select_least_loaded_node $NODE1_POOL)
please make this somehow conditional so that this code path is not used for
"normal operation" (=without this new pooling), so we can test this easily on
one builder job, but not on all.
so for builder_armhf_16…:
> +++ b/job-cfg/reproducible.yaml
> +- '16': { my_node1: 'wbd0-armhf-rb:2223
> wbq0-armhf-r:2225', my_node2: 'bpi0-armhf-rb: odxu4-armhf-rb:2229' } +
>my_shell: '/srv/jenkins/bin/reproducible_build.sh "{my_node1}"
…reproducible_build.sh should probably be called with "experimental-pooling"
as first param, which is then shifted away…
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Second build on failures
Hi, 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://sourceware.org/ml/libc-alpha/2015-12/msg00028.html ok, cool, thanks! > So it might get fixed in future versions ...although we'd need to run > From within sid (or backport util-linux) to run on jenkins any time > soon... yeah :/ > For now, relying on the fact that there are different actual kernels on > various builds (4.x vs. 3.x) will hopefully be good enough to detect the > issue that using "linux64 --uname-2.6" was trying to solve. yeah. what I don't like about this is that it forces us to do that. I liked the flexibility using --uname-2.6 gave us… cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808619: jboss-xnio: FTBFS: duplicate class: org.xnio._private.Messages_$logger
Source: jboss-xnio Version: 3.3.2-1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, jboss-xnio fails to build from source in unstable/amd64: [..] [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ xnio-api --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 213 source files to /home/lamby/temp/cdt.20151221145508.zCMvSaaMTY/jboss-xnio-3.3.2/api/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /home/lamby/temp/cdt.20151221145508.zCMvSaaMTY/jboss-xnio-3.3.2/api/target/generated-sources/annotations/org/xnio/_private/Messages_$logger.java:[45,8] duplicate class: org.xnio._private.Messages_$logger [INFO] 1 error [INFO] - [INFO] [INFO] Reactor Summary: [INFO] [INFO] XNIO Parent POM SUCCESS [ 0.002 s] [INFO] XNIO API ... FAILURE [ 3.515 s] [INFO] XNIO NIO Implementation SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3.680 s [INFO] Finished at: 2015-12-21T14:57:54+00:00 [INFO] Final Memory: 13M/298M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on project xnio-api: Compilation failure [ERROR] /home/lamby/temp/cdt.20151221145508.zCMvSaaMTY/jboss-xnio-3.3.2/api/target/generated-sources/annotations/org/xnio/_private/Messages_$logger.java:[45,8] duplicate class: org.xnio._private.Messages_$logger [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :xnio-api dh_auto_test: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/home/lamby/temp/cdt.20151221145508.zCMvSaaMTY/jboss-xnio-3.3.2 -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/home/lamby/temp/cdt.20151221145508.zCMvSaaMTY/jboss-xnio-3.3.2/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/home/lamby/temp/cdt.20151221145508.zCMvSaaMTY/jboss-xnio-3.3.2/debian -Dmaven.repo.local=/home/lamby/temp/cdt.20151221145508.zCMvSaaMTY/jboss-xnio-3.3.2/debian/maven-repo test returned exit code 1 debian/rules:5: recipe for target 'build' failed make: *** [build] Error 1 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- jboss-xnio.3.3.2-1.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808617: datanommer.commands: FTBFS: KeyError: 'fas'
Source: datanommer.commands
Version: 0.4.6-2
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Dear Maintainer,
datanommer.commands fails to build from source in unstable/amd64:
[..]
==
ERROR: test_latest_topic (test_commands.TestCommands)
--
Traceback (most recent call last):
File
"/home/lamby/temp/cdt.20151221145726.FFUwNwbRUW/datanommer.commands-0.4.6/.pybuild/pythonX.Y_2.7/build/tests/test_commands.py",
line 497, in test_latest_topic
eq_(json_object[0]['fas']['msg'], 'Message 2')
KeyError: 'fas'
--
Ran 15 tests in 18.542s
FAILED (errors=7)
E: pybuild pybuild:274: test: plugin distutils failed with: exit code=1: cd
/home/lamby/temp/cdt.20151221145726.FFUwNwbRUW/datanommer.commands-0.4.6/.pybuild/pythonX.Y_2.7/build;
python2.7 -m nose tests
dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 --dir .
returned exit code 13
debian/rules:3: recipe for target 'build' failed
make: *** [build] Error 25
[..]
The full build log is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
datanommer.commands.0.4.6-2.unstable.amd64.log.txt.gz
Description: Binary data
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808621: umbrello: FTBFS: qtestcase.h:293:30: error: cannot convert 'QString' to 'char*' for argument '3' to 'bool QTest::compare_helper(bool, const char*, char*, char*, const
Source: umbrello Version: 4:15.08.2-1 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, umbrello fails to build from source in unstable/amd64: [..] /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_cppwriter.cpp:54:19: warning: variable 'op' set but not used [-Wunused-but-set-variable] UMLOperation* op; ^ In file included from /usr/include/x86_64-linux-gnu/qt5/QtTest/qtest.h:38:0, from /usr/include/x86_64-linux-gnu/qt5/QtTest/QtTest:7, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/testbase.h:26, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_cppwriter.h:24, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_cppwriter.cpp:21: /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h: In instantiation of 'bool QTest::qCompare(const T&, const T&, const char*, const char*, const char*, int) [with T = Uml::ProgrammingLanguage::Enum]': /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_cppwriter.cpp:44:5: required from here /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h:293:30: error: cannot convert 'QString' to 'char*' for argument '3' to 'bool QTest::compare_helper(bool, const char*, char*, char*, const char*, const char*, const char*, int)' return compare_helper(t1 == t2, "Compared values are not the same", ^ /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_pythonwriter.cpp: In member function 'void TEST_pythonwriter::test_writeClass()': /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_pythonwriter.cpp:51:19: warning: variable 'attr' set but not used [-Wunused-but-set-variable] UMLAttribute* attr; ^ In file included from /usr/include/x86_64-linux-gnu/qt5/QtTest/qtest.h:38:0, from /usr/include/x86_64-linux-gnu/qt5/QtTest/QtTest:7, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/testbase.h:26, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_umlobject.h:24, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_umlobject.cpp:21: /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h: In instantiation of 'bool QTest::qCompare(const T&, const T&, const char*, const char*, const char*, int) [with T = Uml::Visibility::Enum]': /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_umlobject.cpp:203:5: required from here /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h:293:30: error: cannot convert 'QString' to 'char*' for argument '3' to 'bool QTest::compare_helper(bool, const char*, char*, char*, const char*, const char*, const char*, int)' return compare_helper(t1 == t2, "Compared values are not the same", ^ In file included from /usr/include/x86_64-linux-gnu/qt5/QtTest/qtest.h:38:0, from /usr/include/x86_64-linux-gnu/qt5/QtTest/QtTest:7, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/testbase.h:26, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_pythonwriter.h:24, from /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_pythonwriter.cpp:21: /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h: In instantiation of 'bool QTest::qCompare(const T&, const T&, const char*, const char*, const char*, int) [with T = Uml::ProgrammingLanguage::Enum]': /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/unittests/TEST_pythonwriter.cpp:44:5: required from here /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h:293:30: error: cannot convert 'QString' to 'char*' for argument '3' to 'bool QTest::compare_helper(bool, const char*, char*, char*, const char*, const char*, const char*, int)' return compare_helper(t1 == t2, "Compared values are not the same", ^ unittests/CMakeFiles/TEST_cppwriter.dir/build.make:65: recipe for target 'unittests/CMakeFiles/TEST_cppwriter.dir/TEST_cppwriter.cpp.o' failed make[4]: *** [unittests/CMakeFiles/TEST_cppwriter.dir/TEST_cppwriter.cpp.o] Error 1 make[4]: *** Waiting for unfinished jobs [ 97%] Building CXX object unittests/CMakeFiles/TEST_basictypes.dir/TEST_basictypes_automoc.cpp.o cd /home/lamby/temp/cdt.20151221145637.utNwdYl7Jw/umbrello-15.08.2/obj-x86_64-linux-gnu/unittests && /usr/bin/c++
[Reproducible-builds] Bug#808618: diod: FTBFS: "4 of 7 tests failed"
Source: diod Version: 1.0.24-2 Severity: serious Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Dear Maintainer, diod fails to build from source in unstable/amd64: [..] > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_compat-2.21.so: > --6171-- Ignoring non-Dwarf2/3/4 block in .debug_info > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_compat-2.21.so: > --6171-- Last block truncated in .debug_info; ignoring > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_compat-2.21.so: > --6171-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_nis-2.21.so: > --6171-- Ignoring non-Dwarf2/3/4 block in .debug_info > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_nis-2.21.so: > --6171-- Last block truncated in .debug_info; ignoring > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_nis-2.21.so: > --6171-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_files-2.21.so: > --6171-- Ignoring non-Dwarf2/3/4 block in .debug_info > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_files-2.21.so: > --6171-- Last block truncated in .debug_info; ignoring > --6171-- WARNING: Serious error when reading debug info > --6171-- When reading debug info from /lib/x86_64-linux-gnu/libnss_files-2.21.so: > --6171-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 ** SKIP: t15 == 4 of 7 tests failed (9 tests were not run) == Makefile:773: recipe for target 'check-TESTS' failed make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory '/home/lamby/temp/cdt.20151221145735.qajKNcyzIy/diod-1.0.24/tests/misc' Makefile:896: recipe for target 'check-am' failed make[3]: *** [check-am] Error 2 make[3]: Leaving directory '/home/lamby/temp/cdt.20151221145735.qajKNcyzIy/diod-1.0.24/tests/misc' Makefile:369: recipe for target 'check-recursive' failed make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory '/home/lamby/temp/cdt.20151221145735.qajKNcyzIy/diod-1.0.24/tests' Makefile:428: recipe for target 'check-recursive' failed make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory '/home/lamby/temp/cdt.20151221145735.qajKNcyzIy/diod-1.0.24' dh_auto_test: make -j8 check returned exit code 2 debian/rules:15: recipe for target 'build' failed make: *** [build] Error 2 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diod.1.0.24-2.unstable.amd64.log.txt.gz Description: Binary data ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
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://sourceware.org/ml/libc-alpha/2015-12/msg00028.html > > ok, cool, thanks! > >> So it might get fixed in future versions ...although we'd need to run >> From within sid (or backport util-linux) to run on jenkins any time >> soon... > > yeah :/ > >> For now, relying on the fact that there are different actual kernels on >> various builds (4.x vs. 3.x) will hopefully be good enough to detect the >> issue that using "linux64 --uname-2.6" was trying to solve. > > yeah. what I don't like about this is that it forces us to do that. I liked > the flexibility using --uname-2.6 gave us… The impression I got was the patch implementation was rejected upstream, but in theory a better patch could be written. Aurelian wasn't planning on working on it. So if it's wanted for reproducible builds purposes, probably need to come up with a patch that would get accepted upstream... live well, vagrant 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] 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 in another?
It could be done any number of ways, I merely added it to show how it
would work with the code I was proposing. I was hoping the pool code
could be ready enough to use with the new nodes that should be coming by
the end of the year, and they'd be reasonable first tests...
>> - Split load estimating into it's own script, and add support for
>> available memory.
>
> I'd still suggest to measure the load constantly by a job outside the build
> script… (then it's also easy to read "not updated node load since $time" as
> "node is to busy to be scheduled on…)
>
>> - Call timeout so that the ssh processes don't take too long to complete.
>
> see above, don't ssh from the build script please.
Implementing that outside of the build script would make this much more
complicated...
The second build needs to check for load when it is about to be run, as
it doesn't make sense to check when build_rebuild is run (unless you run
both build1 and build2 in parallel... but that's a whole different
proposal), as the load of the machines is likely to change between the
first and second build.
I'm not sure how to do all that outside the build script and keep the
code reasonably simple.
What's the primary concern with ssh from within the build script? Taking
too long to get a response?
>> diff --git a/bin/reproducible_build.sh b/bin/reproducible_build.sh
>
> I'll only comment on the most "pressing" issues now.
>
>> build_rebuild() {
>> FTBFS=1
>> mkdir b1 b2
>> +local selected_node
>> +selected_node=$(select_least_loaded_node $NODE1_POOL)
>
> please make this somehow conditional so that this code path is not used for
> "normal operation" (=without this new pooling), so we can test this easily on
> one builder job, but not on all.
It basically is conditional in that the select_least_loaded_node
function simply returns the node if only one argument is passed.
> so for builder_armhf_16…:
>
>> +++ b/job-cfg/reproducible.yaml
>> +- '16': { my_node1: 'wbd0-armhf-rb:2223
>> wbq0-armhf-r:2225', my_node2: 'bpi0-armhf-rb: odxu4-armhf-rb:2229' } +
>>my_shell: '/srv/jenkins/bin/reproducible_build.sh "{my_node1}"
>
> …reproducible_build.sh should probably be called with "experimental-pooling"
> as first param, which is then shifted away…
That shouldn't be too hard, sure.
Could alternately use something like:
- '16': { my_node1: 'pool,wbd0-armhf-rb:2223,wbq0-armhf-rb:2225',
my_node2: 'pool,bpi0-armhf-rb:,odxu4-armhf-rb:2229' }
Maybe this should be written in two stages, first implementing a simpler
patch just providing failover, and then adding the load checks later.
live well,
vagrant
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
