Sorry for the delay, I've waited for docker.io to get fixed. Me being a
disorganised fool doesn't have any relation to the delay, no siree...
On Wed, Feb 14, 2018 at 04:39:20PM -0300, Agustin Henze wrote:
> Hi Adam,
>
> On 06/25/17 20:35, Adam Borowski wrote:
> > Control: severity -1 serious
> >
> > Hi!
> > I've tried to build this package many times (5 on armhf, 10 on amd64, once
> > on arm64), and it fails every single time.
> >
> > Either Santiago's systems differ from those three of mine enough for the
> > fail to be only random for him, or something else changed -- but the present
> > state is that I have yet to see a successful build.
> >
> >> The bug should be reproducible with sbuild on a single CPU virtual machine,
> >> provided you try enough times (as the failure happens randomly).
> >
> > All the machines I tried it on have multiple cores (4, 6 and 4,
> > respectively).
> I have tried to reproduce it with no success. Could you tell me more about
> your
> setup please?
Regular sbuild -- same as on official buildds.
All of build machines ran modern kernels (current gregkh's stable or linus'
-rc), but I've tried with oldLTS (4.9), and with Debian official packages,
same result.
The machines are, plus retry count from today (2018-04-10) only:
* amd64, AMD Phenom II 6x, btrfs, vanilla 4.16
✗ 20×amd64
✗ 1×i386
✗ 1×riscv64 (qemu-user)
✗ 1×arm64 (qemu-user)
* i386 lxc on amd64 host, Intel Braswell 4x, btrfs, 4.14.0-0.bpo.3-amd64
✓ 38×i386
✓ 10×amd64
* i386, Intel Pentium 4 (non-nx) 1x2(HT), ext4, 4.14.0-0.bpo.3-686
✗ 1×i386
* armhf, Odroid-U2 (Exynos 4412) 4x, btrfs, vanilla 4.16
✗ 10×armhf
* arm64, Pine64 (Allwinner A64) 4x, btrfs, anarsoul's 4.16
✗ 1×arm64
✗ 1×armhf
So there's no randomness at all. All machines are on the same network
segment, all but the Pentium4 use exactly identical (% arch) sbuild config:
btrfs backend, eatmydata. Current unstable (except for the Pentium4, and
the Braswell's host outside lxc). DEB_BUILT_OPTIONS is parallel=# where #
is the number of cores/hyperthreads on that machine.
So the machine that succeeds differs only by being inside lxc and on a 2017
Intel CPU with all the newest extensions.
> I'm using the following command for testing it
>
> set -e && for i in $(seq 10); do docker run --rm -it debian:stretch bash -c
> 'echo "deb-src http://deb.debian.org/debian stretch main" >
> /etc/apt/sources.list.d/sources.list && apt-get update && apt-get install
> eatmydata -y && eatmydata apt-get install dpkg-dev -y && apt-get source
> aiocoap; eatmydata apt-get build-dep aiocoap -y && cd aiocoap-0.1+9ae36f4/ &&
> dpkg-buildpackage -j$(getconf _NPROCESSORS_ONLN) -A'; done
docker.io is currently broken: uninstallable:
The following packages have unmet dependencies:
docker.io : Depends: containerd (>= 0.2.1~) but it is not going to be installed
Depends: runc (>= 0.1.0~) but it is not going to be installed
and doesn't build from source either (BD-Uninst on armhf, fails during
testsuite on amd64). I see 6 long-standing RC bugs, and no one has touched
it for ages, thus it doesn't look like we'll see docker.io working again
anytime soon.
In theory, I could use a virtual machine with stretch somewhere, but it's
buster that's relevant.
> Also I've tried using schroot and it finished correctly as well. As you can
> see, I ran the command successfully 10 times, with multiple cores, with only
> one core, etc. Please let me know if there is anything special on your setup
> to
> be able to reproduce it. Or could you provide a single command to reproduce
> it?
"sbuild aiocoap", on all my machines but one. :/
But, despite the error message being identical, the way Santiago triggers it
differs from me: he sees it randomly on 1-way machines, I see it
deterministically on multi-threaded.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back. What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda? Łambinowice? Most ex-German KLs? If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska? Sikorski's camps in UK (thanks Brits!)?
