Sorry for the delay, I've waited for 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 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 is currently broken: uninstallable:
The following packages have unmet dependencies: : 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 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.

⢀⣴⠾⠻⢶⣦⠀ 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!)?

Reply via email to