Hi all,
Thanks to Adrian Bunk, Adrian Glaubitz, and Sébastien for the
clarifications in this thread.
The discussion regarding the current Bug#980794 was triggered by my
decision of limiting the set of architectures of package octave-iso2mesh.
I agree that this hammer-like solution (in Adrian Glaubitz's words) is
not the right thing to do and I will revert the change (and hence close
this bug report).
However, we will get back to the previous situation, in which the
autobuild of the package was failing systematically on armel, armhf and
mipsel. If I understand correctly, the right way to cope with the issue
is to contact individually the maintainers of each architecture with
FTBFS and ask them to upload a correctly built binary package. This will
have to be done for each new release of the package. Of course, I find
this very counterproductive and time consuming. If there is no better way
of coping with the problem, then we will have to stick to this
sub-optimal solution, unless you see other ways of proceeding.
Best,
Rafael
* Sébastien Villemot <sebast...@debian.org> [2021-02-03 22:03]:
Dear Qianqian,
Le mercredi 03 février 2021 à 13:24 -0500, Qianqian Fang a écrit :
On 2/1/21 4:10 AM, Adrian Bunk wrote:
Physical RAM or disk space are not the problem, the problem is the
virtual address space of processes on 32bit architectures.
On mipsel, where every process has 2 GB of address space, both
"g++ -O0 -g0" and "clang++ -O0 -g0" fail because they run out
of address space.
For Debian testing migration purposes it only matters whether stale old
binaries are in the archive, for that it does not make any difference
whether binaries are missing due to architecture restrictions or FTBFS.
thanks for the comment, can you clarify a little bit more? are you
suggesting us to remove the arch restriction or exclude all i386
platforms? sorry it wasn't very clear to me.
What Adrian means is that you have to request the removal of the old
armhf binary from unstable, otherwise the latest version of octave-
iso2mesh won’t migrate to testing. Restricting the architecture list
does not automatically remove the old binaries. As far as I can see,
the removal request has not yet been done (the one Rafael mentioned is
about another package).
More generally, it is true that restricting the architecture list is
usually not the right thing to do. Making build failures visible is
always more helpful to the porters.
There might however be one situation in which the restriction may make
sense: if the failures are random. Because once a build succeeds on a
release architecture, then subsequent failures prevent migration to
testing until the binary has been removed from unstable. But I don’t
know if octave-iso2mesh is in that situation.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
