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!)?
