[Debian-med-packaging] Bug#1001614: odil: FTBFS on armhf: 91 - MoveSCU_Move (Failed)

[Nilesh Patra]

Hi Julien,

On 12/14/21 11:32 PM, Julien Lamy wrote:
> Hi list,
> I tried to solve #1001614 but I can't reproduce the error: on an armhf box, sbuild environment targeting sid, no error occurs. Since the build error is supposed to happen during network-related unit tests in which I'm starting a server listening on a fixed port of the loopback interface, I'm suspecting that something specific to the build environment interferes.

I have couple of comments:

- Probably ports are not available in the build, I remember disabling tests in the past that needed some ports to be open.
It passes in an armhf porter machine because the environment is different from chroot/sbuild env used on setup. But then this
also makes me wonder what causes the test to pass on other archs, so the followup:

- Try to build in a armhf chroot in an arm64 box, maybe something stems from there (thats the setup on a few buildd machines IIRC)

- IIRC, buildd machines have similar specs as debci ones, and actually buildd machines are very powerful ones, and if they have too many ports available, it can sometimes cause errors
like this. I once was working on an R package that opened a huge number of ports made a number of connections and choked after that since it did not assume
the machine to be of that high spec.
I even have the logs somehow

|
| root at autopkgtest-lxc-mcfdoq:/tmp/autopkgtest-lxc.ewl0h2r2/downtmp/build.qgs/src# tail -n3 ../..//autopkgtest_tmp/segmentByCBS,futures.Rout
|   Cannot create 160 parallel PSOCK nodes. Each node needs one connection but there are only 124 connections left out of the maximum 128 available on this R installation
| Calls: plan ... <Anonymous> -> ClusterRegistry -> makeCluster -> makeClusterPSOCK
| Execution halted
|

Does odil have some assumption like this?
  
> I can think of three possible ways to go:
> 1. Skip all network-related tests. The networking tests are run during CI upstream, but on x86 only.

Just do this, IMO.

> 2. Have the server listen on a random port. The error may however pop back randomly.

No, because this fix is unreliable and may come knocking on the door in future which we don't want.

> 3. Restrict the architectures to avoid armhf.

This is usually okay, but
since it works in an armhf porter machine for you you probably should keep it in architecture list since in principle it is usable on armhf.
Asking for removals also takes really long time for ftp masters to process, so I would advice against waiting that long
for this fix.

Regards,
Nilesh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20211216/cff76533/attachment.sig>