Bug#835360: rkt: FTBFS on several architectures
Hello Andreas, On Tue, 25 Oct 2016 13:25:18 +0200 Andreas Henriksson wrote: > As already mentioned the offending ppc64el binaries was removed. I just fixed created a debdiff to fix golang-github-shirou-gopsutil. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820466 I hope to have the debdiff accepted soon, so, we can re-enable ppc64el.
Bug#835360: rkt: FTBFS on several architectures
Hello all. A final status update. As already mentioned the offending ppc64el binaries was removed. (Would be great in the future if gopsutil was changed from Arch: all to the architectures where it can actually parse process information on in reality.) This bug was also lowered in severity because of the above mentioned action, to avoid this bug report from blocking testing migration. There was one final blocker, appc-spec 0.8.7 needed to enter testing first but it failed to build on s390x. I just asked for a give-back to attempt building again. It happened to build on the same buildd machine as where it last succeded on, so things should now start migrating towards testing if there isn't any other blocker I've missed. Having said that, it seems that golang upstream defines "s390 support" differently to the range of hardware supported by the Debian s390x port. Having go packages succeed to build when they happen to run on one of the newer buildds is in my opinion very unconvenient (and also ending up with SIGILL in go when appc-spec was built on zemlinsky is an RC bug in itself). I think the golang maintainers need to think a bit about which architectures (and their range of supported hardware as defined by debian architecture porters) is actually supportable. Then limit the arch field of golang (and in some cases like gopsutil maybe even further) to those architectures. Just saying "any" and relying on "when it builds it's supported" is not going to work. In other words there might be a need for a Mass-RM of golang and all rdeps on s390x (and possibly other architectures). What's said above isn't based on any real knowledge on my part only my percetion. Partially influenced by for example: https://github.com/golang/go/issues/16637 Hopefully this issue is not as bad as I fear. If it can be fixed only by tweaking the optimization flags used on certain architectures that would be awesome. I still fear the worst though. SIGILL is definitely not something we should be running into on official buildd machines atleast. Feedback appreciated. Unless someone gives me some information that changes my view on this I'll be filing an RC bug against golang about this soon (as I promised the release team member I bribed to do the give-back of appc-spec that I would do in exchange). Regards, Andreas Henriksson
Bug#835360: rkt: FTBFS on several architectures
On Friday, 14 October 2016 5:24:53 PM AEDT Andreas Henriksson wrote: > (Despite this debdiff, asking for removal could possibly be a better > idea as there's obviously not enough backing to properly support ppc64le > right now and thus probably not for the lifetime of stretch.) Andreas, thank you so much for testing. If not too much troubles could you please request removal of affected packages on all failing architectures? Thank you and apologies for not handling removal myself... -- Regards, Dmitry Smirnov. --- If liberty means anything at all, it means the right to tell people what they do not want to hear. -- George Orwell signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
Hello all.
On Thu, Oct 13, 2016 at 01:29:31PM +, Luca BRUNO wrote:
> On Thursday, 13 October 2016 13:59:27 UTC Andreas Henriksson wrote:
>
> > Fwiw, there's a chain of {build-,}dependencies that would need to be
> > removed on ppc64el
>
> Ah, when I wrote my previous answer I didn't realize that.
> Upon further inspection, it looks like it may be just enough to cherry-pick
> this fix on top of gopsutil:
> https://github.com/shirou/gopsutil/pull/261
I've tested applying PR 259 and 261 which indeed fixes the build on ppc64le
but the test-suite still fails.
The problem seems to boil down to gopsutil parsing of /proc/cpuinfo being
extremely (x86 centricly) naive, as cpuinfo content is very architecture
specific. Furter discussion on that topic is probably needed upstream...
Just satisfying what the testsuite needs to call it success is quite
simple though by treating "cpu" field as meaning the same as "model name".
I'm attaching a debdiff which I've testbuilt on the debian ppc64le porterbox.
(Despite this debdiff, asking for removal could possibly be a better
idea as there's obviously not enough backing to properly support ppc64le
right now and thus probably not for the lifetime of stretch.)
Regards,
Andreas Henriksson
diff -Nru golang-github-shirou-gopsutil-2.1/debian/changelog
golang-github-shirou-gopsutil-2.1/debian/changelog
--- golang-github-shirou-gopsutil-2.1/debian/changelog 2016-07-14
07:23:30.0 +
+++ golang-github-shirou-gopsutil-2.1/debian/changelog 2016-10-14
08:43:23.0 +
@@ -1,3 +1,15 @@
+golang-github-shirou-gopsutil (2.1-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add debian/patches/259.patch and debian/patches/261.patch
+- upstream PR 259 + 261, should fix build on ppc64el.
+ * Add debian/patches/gopsutil-ppc64le-model-name.patch
+- ppc64le /proc/cpuinfo doesn't follow the same style as x86 and
+ test-suite require atleast the "model name" field. Map that
+ to the "cpu" field which exists on ppc64le for now.
+
+ -- Andreas Henriksson Fri, 14 Oct 2016 08:43:23 +
+
golang-github-shirou-gopsutil (2.1-2) unstable; urgency=medium
* Extend "01-Disable_failing_tests.patch" to disable failing
diff -Nru golang-github-shirou-gopsutil-2.1/debian/patches/259.patch
golang-github-shirou-gopsutil-2.1/debian/patches/259.patch
--- golang-github-shirou-gopsutil-2.1/debian/patches/259.patch 1970-01-01
00:00:00.0 +
+++ golang-github-shirou-gopsutil-2.1/debian/patches/259.patch 2016-10-14
08:43:23.0 +
@@ -0,0 +1,83 @@
+From eb4a57117f5b734246226c9b6d6b1f9edca2e4f2 Mon Sep 17 00:00:00 2001
+From: Thomas Hipp
+Date: Fri, 16 Sep 2016 09:04:52 +0200
+Subject: [PATCH] process: determine page sizes via function
+
+Instead of hard-coding the page size for linux systems, use Go's
+`Getpagesize` function.
+
+This resolves #258.
+
+Signed-off-by: Thomas Hipp
+---
+ process/process_linux.go | 5 -
+ process/process_linux_386.go | 3 +--
+ process/process_linux_amd64.go | 3 +--
+ process/process_linux_arm.go | 3 +--
+ process/process_linux_arm64.go | 3 +--
+ 5 files changed, 8 insertions(+), 9 deletions(-)
+
+diff --git a/process/process_linux.go b/process/process_linux.go
+index 158cb04..9eb4f44 100644
+--- a/process/process_linux.go
b/process/process_linux.go
+@@ -20,7 +20,10 @@ import (
+ "github.com/shirou/gopsutil/net"
+ )
+
+-var ErrorNoChildren = errors.New("process does not have children")
++var (
++ ErrorNoChildren = errors.New("process does not have children")
++ PageSize= uint64(os.Getpagesize())
++)
+
+ const (
+ PrioProcess = 0 // linux/resource.h
+diff --git a/process/process_linux_386.go b/process/process_linux_386.go
+index 541b854..c4df213 100644
+--- a/process/process_linux_386.go
b/process/process_linux_386.go
+@@ -4,6 +4,5 @@
+ package process
+
+ const (
+- ClockTicks = 100 // C.sysconf(C._SC_CLK_TCK)
+- PageSize = 4096 // C.sysconf(C._SC_PAGE_SIZE)
++ ClockTicks = 100 // C.sysconf(C._SC_CLK_TCK)
+ )
+diff --git a/process/process_linux_amd64.go b/process/process_linux_amd64.go
+index b4a4ce8..99b6659 100644
+--- a/process/process_linux_amd64.go
b/process/process_linux_amd64.go
+@@ -4,6 +4,5 @@
+ package process
+
+ const (
+- ClockTicks = 100 // C.sysconf(C._SC_CLK_TCK)
+- PageSize = 4096 // C.sysconf(C._SC_PAGE_SIZE)
++ ClockTicks = 100 // C.sysconf(C._SC_CLK_TCK)
+ )
+diff --git a/process/process_linux_arm.go b/process/process_linux_arm.go
+index c6123a4..8aef44c 100644
+--- a/process/process_linux_arm.go
b/process/process_linux_arm.go
+@@ -4,6 +4,5 @@
+ package process
+
+ const (
+- ClockTicks = 100 // C.sysconf(C._SC_CLK_TCK)
+- PageSize = 4096 // C.sysconf(C._SC_PAGE_SIZE)
++ ClockTicks = 100 // C.sysconf(C._SC_CLK_TCK)
+ )
+diff --git a/process/process_linux_arm64.go b/process/process_linux_arm64.go
+index 529aeaa..493197c 100644
+--- a/process/process_lin
Bug#835360: rkt: FTBFS on several architectures
On Thursday, 13 October 2016 13:59:27 UTC Andreas Henriksson wrote:
> Fwiw, there's a chain of {build-,}dependencies that would need to be
> removed on ppc64el
Ah, when I wrote my previous answer I didn't realize that.
Upon further inspection, it looks like it may be just enough to cherry-pick
this fix on top of gopsutil:
https://github.com/shirou/gopsutil/pull/261
Ciao, Luca
--
«Доверяй, но проверяй»
signature.asc
Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
Hello all.
On Thu, Oct 13, 2016 at 10:42:37AM +, Luca BRUNO wrote:
> On Thursday, 13 October 2016 21:18:07 UTC Dmitry Smirnov wrote:
> > Rkt 1.16.0 FTBFS on ppc64el and s390x:
> >
> > https://buildd.debian.org/status/package.php?p=rkt
> >
> > Any ideas what we can do about it?
>
> s390(x) is not supported upstream for the moment, but this shouldn't be a
> blocker as it has never been built there before anyway.
>
> Regarding ppc64el, it looks like you hit again
> https://github.com/shirou/gopsutil/issues/230
> Given that upstream is not planning to fix it anytime soon, I'd recommend to
> ask for a removal for rkt (1.9.1+dfsg-1) on ppc64el for now, so that it can
> transition to stretch without being blocked by that arch until some porters
> get to it.
Fwiw, there's a chain of {build-,}dependencies that would need to be
removed on ppc64el which if I'm not mistaken looks like this:
golang-github-coreos-rkt-dev (from src:rkt)
<-(dep)-
golang-github-google-cadvisor-dev (from src:cadvisor)
<-(build-dep)-
gitlab-ci-multi-runner
(src:cadvisor has no other {build-}dependencies)
So as far as I can tell a asking for removal of ppc64 binaries for
cadvisor, gitlab-ci-multi-runner and rkt should be doable.
(AFAIK those processing removal requests prefer/require separate RM bug
reports per source package, so 3 RM bug reports.)
Regards,
Andreas Henriksson
Bug#835360: rkt: FTBFS on several architectures
On Thursday, 13 October 2016 21:18:07 UTC Dmitry Smirnov wrote: > Rkt 1.16.0 FTBFS on ppc64el and s390x: > > https://buildd.debian.org/status/package.php?p=rkt > > Any ideas what we can do about it? s390(x) is not supported upstream for the moment, but this shouldn't be a blocker as it has never been built there before anyway. Regarding ppc64el, it looks like you hit again https://github.com/shirou/gopsutil/issues/230 Given that upstream is not planning to fix it anytime soon, I'd recommend to ask for a removal for rkt (1.9.1+dfsg-1) on ppc64el for now, so that it can transition to stretch without being blocked by that arch until some porters get to it. Cheers, Luca -- «Доверяй, но проверяй» signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
Rkt 1.16.0 FTBFS on ppc64el and s390x: https://buildd.debian.org/status/package.php?p=rkt Any ideas what we can do about it? -- Cheers, Dmitry Smirnov. --- Free speech is the bedrock of liberty and a free society. And yes, it includes the right to blaspheme and offend. -- Ayaan Hirsi Ali, 2010 signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
On Tuesday, 11 October 2016 8:03:28 PM AEDT Andreas Henriksson wrote: > Excuse me for being very naive here, but this is my first encounter > with (packaging) go. > > The attached patch seems to make the appc-spec package build for me Awesome. Thank you very much Andreas. On my own I could not see this obvious solution to the problem... I've just uploaded appc-spec v0.8.7 and rkt should be ready for upload by the time when appc-spec propagates to mirrors. -- Regards, Dmitry Smirnov. --- In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual. -- Galileo Galilei signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
On Tuesday, 11 October 2016 3:41:59 PM AEDT Jonathan Boulle wrote: > Dmitry, could you point me towards the "golang-github-appc-spec" 0.8.7 > FTBFS? Thank you for following our progress, Jonathan. This problem happened on my dev box when I tried to prepare new upload of appc-spec: src/github.com/appc/spec/schema/image.go:25:2: code in directory /build/ golang-github-appc-spec-0.8.7+dfsg/_build/src/github.com/appc/spec/Godeps/ _workspace/src/go4.org/errorutil expects import "go4.org/errorutil" Apparently something changed in golang(?) that invalidated sub-vendoring of "go4.org/errorutil"... Luckily Andreas Henriksson provided a solution to this. -- All the best, Dmitry Smirnov. --- Democracy is a pathetic belief in the collective wisdom of individual ignorance. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
Hello all!
On Tue, Oct 11, 2016 at 03:41:59PM +0200, Jonathan Boulle wrote:
> Dmitry, could you point me towards the "golang-github-appc-spec" 0.8.7
> FTBFS?
Excuse me for being very naive here, but this is my first encounter
with (packaging) go.
The attached patch seems to make the appc-spec package build for me
following this procedure:
cd /tmp
debcheckout --git-track '*' appc-spec
cd appc-spec
git clean -fdx
gbp import-orig --uscan
git am attached-appc-spec.patch
gbp buildpackage --git-pristine-tar '--git-builder=pdebuild --debbuildopts
'\''-i -I -j5'\'' --pbuilder pbuilder '
Build log attached.
Regards,
Andreas Henriksson
>From 7a67febfcffdd112a3bb9f3bd4da5b844c6eae3b Mon Sep 17 00:00:00 2001
From: Andreas Henriksson
Date: Tue, 11 Oct 2016 18:48:45 +0200
Subject: [PATCH] Add debian/patches/subvendor2.patch
---
debian/changelog| 7 +++
debian/patches/series | 1 +
debian/patches/subvendor2.patch | 25 +
3 files changed, 33 insertions(+)
create mode 100644 debian/patches/subvendor2.patch
diff --git a/debian/changelog b/debian/changelog
index 3ebd46a..701fcf4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+golang-github-appc-spec (0.8.7+dfsg-1) UNRELEASED; urgency=medium
+
+ * New upstream release.
+ * Add debian/patches/subvendor2.patch
+
+ -- Andreas Henriksson Tue, 11 Oct 2016 18:48:34 +0200
+
golang-github-appc-spec (0.8.6+dfsg-1) unstable; urgency=medium
* New upstream release [July 2016].
diff --git a/debian/patches/series b/debian/patches/series
index a97e958..783a84c 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
subvendor.patch
+subvendor2.patch
diff --git a/debian/patches/subvendor2.patch b/debian/patches/subvendor2.patch
new file mode 100644
index 000..6ffdd48
--- /dev/null
+++ b/debian/patches/subvendor2.patch
@@ -0,0 +1,25 @@
+From ceae3a035869a9c63b92e38a4157b40e914c0c73 Mon Sep 17 00:00:00 2001
+From: Andreas Henriksson
+Date: Tue, 11 Oct 2016 19:51:13 +0200
+Subject: [PATCH] more private libs for 0.8.7
+
+---
+ vendor/go4.org/errorutil/highlight.go | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/vendor/go4.org/errorutil/highlight.go b/vendor/go4.org/errorutil/highlight.go
+index 1b1efb0..a88a359 100644
+--- a/vendor/go4.org/errorutil/highlight.go
b/vendor/go4.org/errorutil/highlight.go
+@@ -15,7 +15,7 @@ limitations under the License.
+ */
+
+ // Package errorutil helps make better error messages.
+-package errorutil // import "go4.org/errorutil"
++package errorutil // import "github.com/appc/spec/Godeps/_workspace/src/go4.org/errorutil"
+
+ import (
+ "bufio"
+--
+2.9.3
+
--
2.9.3
gbp:info: All Orig tarballs 'golang-github-appc-spec_0.8.7+dfsg.orig.tar.gz'
found at '../'
gbp:info: Extracting golang-github-appc-spec_0.8.7+dfsg.orig.tar.gz to
'/tmp/foo/build-area/golang-github-appc-spec-tmp'
gbp:info: Exporting 'HEAD' to '/tmp/foo/build-area/golang-github-appc-spec-tmp'
gbp:info: Moving '/tmp/foo/build-area/golang-github-appc-spec-tmp' to
'/tmp/foo/build-area/golang-github-appc-spec-0.8.7+dfsg'
[0mI: using pbuilder as pbuilder[0m
dpkg-checkbuilddeps: error: Unmet build dependencies: golang-go
golang-go-semver-dev | golang-github-coreos-go-semver-dev
golang-github-gogo-protobuf-dev golang-github-spf13-pflag-dev
golang-golang-x-net-dev golang-speter-go-exp-math-dec-inf-dev
[1;33mW: Unmet build-dependency in source[0m
dpkg-buildpackage: info: source package golang-github-appc-spec
dpkg-buildpackage: info: source version 0.8.7+dfsg-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Andreas Henriksson
dpkg-source -i -I --before-build golang-github-appc-spec-0.8.7+dfsg
dpkg-source: info: applying subvendor.patch
dpkg-source: info: applying subvendor2.patch
fakeroot debian/rules clean
dh clean --buildsystem=golang --with=golang --builddirectory=_build
dh_testdir -O--buildsystem=golang -O--builddirectory=_build
dh_auto_clean -O--buildsystem=golang -O--builddirectory=_build
debian/rules override_dh_clean
make[1]: Entering directory
'/tmp/foo/build-area/golang-github-appc-spec-0.8.7+dfsg'
dh_clean
## Remove Files-Excluded (when built from checkout or non-DFSG tarball):
rm -f -rv `perl -0nE 'say $1 if
m{^Files\-Excluded\:\s*(.*?)(?:\n\n|Files:|Comment:)}sm;' debian/copyright`
find vendor -mindepth 1 -type d -empty -delete -printf 'removed %p\n'
removed vendor/gopkg.in
removed vendor/golang.org/x
removed vendor/golang.org
removed vendor/github.com/spf13
removed vendor/github.com/gogo
removed vendor/github.com/coreos
removed vendor/github.com
make[1]: Leaving directory
'/tmp/foo/build-area/golang-github-appc-spec-0.8.7+dfsg'
dpkg-source -i -I -b golang-github-appc-spec-0.8.7+dfsg
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building golang-github-appc-spec using existing
./golang-github-appc-spec_0.8.7+dfsg.orig.tar.gz
dpkg-source:
Bug#835360: rkt: FTBFS on several architectures
Dmitry, could you point me towards the "golang-github-appc-spec" 0.8.7 FTBFS? On 11 October 2016 at 04:24, Dmitry Smirnov wrote: > On Saturday, 8 October 2016 10:56:05 PM AEDT Andreas Henriksson wrote: > > Is there anything holding back uploading a new version (which should > > resolve the issues)? > > Unfortunately rkt is held by "golang-github-appc-spec" 0.8.7 which FTBFS > due > to sub-vendored "go4.org/errorutil". At the moment I do not know how to > address this problem... > > > > Please note that the freeze is approaching quickly so > > if you'd like to see the package shipped in stretch it needs to happen > > very soon. > > Currently I work at 100% of my capacity and I don't have any hidden > reserves > to activate. Freeze or not I'm doing my best even though right now this > issue > is not my top priority while I'm swamped with other things... > > > > If you need any help, tell me! > > I'd appreciate any help. Thank you. > > -- > All the best, > Dmitry Smirnov. > > --- > > A man does what he must - in spite of personal consequences, in spite of > obstacles and dangers and pressures - and that is the basis of all human > morality. > -- Winston Churchill >
Bug#835360: rkt: FTBFS on several architectures
On Saturday, 8 October 2016 10:56:05 PM AEDT Andreas Henriksson wrote: > Is there anything holding back uploading a new version (which should > resolve the issues)? Unfortunately rkt is held by "golang-github-appc-spec" 0.8.7 which FTBFS due to sub-vendored "go4.org/errorutil". At the moment I do not know how to address this problem... > Please note that the freeze is approaching quickly so > if you'd like to see the package shipped in stretch it needs to happen > very soon. Currently I work at 100% of my capacity and I don't have any hidden reserves to activate. Freeze or not I'm doing my best even though right now this issue is not my top priority while I'm swamped with other things... > If you need any help, tell me! I'd appreciate any help. Thank you. -- All the best, Dmitry Smirnov. --- A man does what he must - in spite of personal consequences, in spite of obstacles and dangers and pressures - and that is the basis of all human morality. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
Hello! On Fri, Sep 16, 2016 at 01:29:39AM +, Potter, Tim (HPE Linux Support) wrote: > PPC support looks like it has been added in rkt 1.14 and above [1]. > According to the > release notes on golang.org, experimental support has been added for s390 > systems > in Go 1.7. We're currently up to Go 1.7 in unstable so we could have rkt > building on > all architectures pretty soon. Is there anything holding back uploading a new version (which should resolve the issues)? Please note that the freeze is approaching quickly so if you'd like to see the package shipped in stretch it needs to happen very soon. If you need any help, tell me! Regards, Andreas Henriksson
Bug#835360: rkt: FTBFS on several architectures
On 29 Aug 2016, at 8:59 PM, Luca BRUNO wrote: > > 1.13.0+dfsg-1 has been built without issues on i386: > https://buildd.debian.org/status/fetch.php?pkg=rkt&arch=i386&ver=1.13.0%2Bdfsg-1&stamp=1472188080 > > ppc64 and s390x are in progress upstream and should hopefully > be back in the next releases. > > Ciao, Luca PPC support looks like it has been added in rkt 1.14 and above [1]. According to the release notes on golang.org, experimental support has been added for s390 systems in Go 1.7. We're currently up to Go 1.7 in unstable so we could have rkt building on all architectures pretty soon. Tim. [1] https://github.com/coreos/rkt/blob/v1.14.0/configure.ac#L49 [2] https://golang.org/doc/go1.7 signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#835360: rkt: FTBFS on several architectures
1.13.0+dfsg-1 has been built without issues on i386: https://buildd.debian.org/status/fetch.php?pkg=rkt&arch=i386&ver=1.13.0%2Bdfsg-1&stamp=1472188080 ppc64 and s390x are in progress upstream and should hopefully be back in the next releases. Ciao, Luca -- «Доверяй, но проверяй» signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
On Wednesday, 24 August 2016 8:50:33 PM AEST Adrian Bunk wrote: > The i386 failure looks like upstream #2926 (fixed in the 1.11.0 release), > the failures on other architectures look like similar problems that > require similar fixes. 1.13.0 still FTBFS on i386 for another reason: https://github.com/coreos/rkt/issues/3112 and until hours ago upload of new release of "rkt" was not possible due to absence of some dependencies. Now when protobuf3 and gRPC are finally uploaded I can try to upload latest release of "rkt"... -- Cheers, Dmitry Smirnov. --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#835360: rkt: FTBFS on several architectures
Source: rkt Version: 1.10.0+dfsg-1 Severity: serious rkt FTBFS on several architectures: https://buildd.debian.org/status/package.php?p=rkt The i386 failure looks like upstream #2926 (fixed in the 1.11.0 release), the failures on other architectures look like similar problems that require similar fixes.
