Hi,

During a rebuild of all packages in testing (trixie), your package failed
to build on i386.


Relevant part (hopefully):
The full build log is available from:
http://qa-logs.debian.net/2025/04/14/libmina-sshd-java_2.13.2-2_testing-i386.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20250414;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20250414&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

retitle 1103106 libmina-sshd-java: FTBFS: flaky tests
thanks

Hello.

I can reproduce this as well on amd64, so it's not i386-specific.

This fails randomly in my setup, with the following approximate failure rates:

90% of the time on machines with 1 CPU
45% of the time on machines with 2 CPUs

I've put a bunch of failed build logs here:

https://people.debian.org/~sanvila/build-logs/libmina-sshd-java/

See also:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libmina-sshd-java.html

As always, I can offer a VM to reproduce, but given the above statistics,
I recommend that you try GRUB_CMDLINE_LINUX="nr_cpus=1" first.

Thanks.

severity 1103106 important
thanks

Hello.

This package used to ftbfs for me some time ago, but its status
seems to have changed a little bit in the last months.

Currently, I have it in the category "ftbfs randomly on single-cpu
systems" and also "builds ok on machines with 2 cpus", but the build
history on single-cpu is like this:

Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250412T044806.335Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250413T045013.222Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250414T044802.062Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250415T044801.538Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250416T044807.142Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250417T044805.941Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250419T043803.148Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250420T043703.327Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250421T043804.535Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250423T041114.822Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250424T043803.440Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250425T043702.920Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250426T043703.449Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250427T043806.248Z
Status: failed      libmina-sshd-java_2.13.2-2_amd64-20250428T043806.768Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250503T051134.191Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250614T174517.455Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250620T044012.895Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250620T044013.769Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250802T100714.828Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250820T094416.981Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250821T040830.119Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20250822T040855.400Z
Status: successful  libmina-sshd-java_2.13.2-2_amd64-20251004T032435.217Z
Status: successful  libmina-sshd-java_2.13.2-3_amd64-20251005T085803.892Z


This can be due to a series of factors:

It could be that it does not fail anymore when using the kernel of
trixie.

It could also be that some build-dependency which triggered this
failure has been fixed in the meantime.

Ot it could be that it does not fail anymore when using sbuild and the
unshare backend, to which I switched some time ago as the default.

In fact, in the above build history, the latest build logs are most
probably using the unshare backend, while the older ones are probably
using the old file backend, so this is my current best theory.


So, I'm going do some additional checks to understand the true nature
of the bug. In the meantime I'm downgrading to important, as I feel a
serious severity does not fit with available data.

Thanks.

Hi.

The package builds ok now. I tried all these combinations:

- Machines with 1 CPU and 2 CPUs.
- In trixie and also in unstable.
- Using the old file backend and the new unshare backend.

(That makes 8 combinations, and I tried building the package 25 times
in each of them with zero failures in total).

My current theory is now that the failures happened only when using
the kernel of bookworm. The build logs I have are consistent with that.
(The kernel of bookworm is what everybody was using to build packages
just before the release of trixie, because autobuilders, either official
or the ones used by Lucas or myself, usually run stable).

Now, if the package existed in bookworm, still a supported
distribution, we could maybe investigate the case where we try to
build the package in bookworm from a machine using bookworm
(i.e. using the kernel of bookworm).

But the package does not even exist in bookworm... so I would say it's
fair enough to close the bug at this point (I leave that to you).

Thanks.

Hi,

As per the discussion in the bug thread, I am now closing as the bug is
not showing up anymore.

Thanks Santiago for having helped confirming that,