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
Attachment:
signature.asc
Description: This is a digitally signed message part