Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
On 2/5/21 7:57 PM, Adrian Bunk wrote: > The only problem for testing migration are stale old binaries on an > architecture On a release architecture, that is. Anything in ports doesn't affect testing migration at the moment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
On Fri, Feb 05, 2021 at 07:55:50AM +0100, Rafael Laboissière wrote: >... > 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. >... This was never the correct action, and since the start of the bullseye release cycle, binaries that were not built on the buildds are blocked from entering testing.[1] The only problem for testing migration are stale old binaries on an architecture, if a package never built on a release architecture or after removal of the stale binaries FTBFS on some architectures are not a problem for testing migration. > Best, > > Rafael cu Adrian [1] packages in contrib and non-free are exceptions
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
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 [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
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
Hello Rafael! On 1/27/21 6:12 PM, Rafael Laboissière wrote: > I am the responsible person for the build architecture limitation. It was an > attempt > to get octave-iso2mesh into bullseye, at least for a limited set of > release-official > architectures. However, the package did not yet migrated into testing, even > though a > request for the removal of the binary packages for armel, armhf, and mipsel > have been > filed (see Bug#979623). It would have been better to contact the architecture maintainers first and ask for help to get the package built on all architectures, so people get at least a chance to help you. Also, Debian Ports architectures don't affect testing migration. So a package failing to build on alpha, hppa, hurd-i386, ia64, kfreebsd-*, m68k, powerpc, ppc64, sh4, sparc64 and x32 won't affect testing migration. > Those architectures have been removed because the CGAL-dependent building > consumes lots > of memory. I think that other packages in Debian are been hit by the same > problem. The package builds fine even on m68k: > https://buildd.debian.org/status/logs.php?pkg=octave-iso2mesh=m68k So, it doesn't seem as bad as one would think from the bug report. > I fully agree that this is not an ideal situation. I think that, once > Bug#979623 is fixed, > we should remove the architecture restriction. I think it would have been fair to give architecture maintainers at least a chance first to look into the problem before solving it with a hammer. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
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 signature.asc Description: This is a digitally signed message part
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
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. hi Adrian, 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. thanks Qianqian cu Adrian
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
On Wed, Jan 27, 2021 at 06:12:40PM +0100, Rafael Laboissière wrote: >... > * John Paul Adrian Glaubitz [2021-01-22 12:10]: >... > > The last upload octave-iso2mesh arbitrarily limited the list of build > > architectures on the assumption that only certain architectures have > > buildds with enough disk spaces which is certainly not true. The > > available disk space depends on the buildd used, not the architecture. 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. >... > I am the responsible person for the build architecture limitation. It was > an attempt to get octave-iso2mesh into bullseye, at least for a limited set > of release-official architectures. However, the package did not yet > migrated into testing, even though a request for the removal of the binary > packages for armel, armhf, and mipsel have been filed (see Bug#979623). >... > I fully agree that this is not an ideal situation. I think that, once > Bug#979623 is fixed, we should remove the architecture restriction. > > What do the others think? 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. > Best, > > Rafael Laboissière cu Adrian
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
On 1/27/21 12:12 PM, Rafael Laboissière wrote: N.B.: I am moving this discussion into the mailing list of the Debian Octave Group and also adding Qianqian Fang (the original developer of the package and also upstream author) to the Cc list. * John Paul Adrian Glaubitz [2021-01-22 12:10]: Source: octave-iso2mesh Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org The last upload octave-iso2mesh arbitrarily limited the list of build architectures on the assumption that only certain architectures have buildds with enough disk spaces which is certainly not true. The available disk space depends on the buildd used, not the architecture. Furthermore, it may happen that the buildd disk space fills up which can happen if the machine crashes, gets automatically rebooted and the previous builds are therefore not cleaned up. This is something observed on the buildd blaauw which crashes regularly due to a bug in the kernel [1]. Could you therefore remove the architecture limitation list or - at least - re-add the Debian Ports architectures (e.g. alpha, hppa, ia64, m68k, powerpc, ppc64, riscv64, sh4, sparc64 and x32)? hi Rafael, thanks for looping me in. @Adrian, as Rafael mentioned, the crash was caused by is compiling libCGAL based executables when building iso2mesh-tools, which is a dependency of octave-iso2mesh. Most of these errors were caused by "*virtual memory exhausted*" error by gcc during compilation. I've seen similar errors when submitting iso2mesh for Fedora previously, see https://bugzilla.redhat.com/show_bug.cgi?id=1758626#c11 one of the failed builds can be found at the below link, but the log files seems to no longer exist https://koji.fedoraproject.org/koji/taskinfo?taskID=38115425 occasionally, the build may go through, but often times, it comes back in the next build attempt. I'd love to make iso2mesh available on all supported platforms (which it should compile if given enough virtual memory), but given the unreliable compilation, excluding some of these platform is just practical workaround. Eventually, we can either solve this issue by fine tuning the build system virtual memory parameters, or work with CGAL developers to find out if there is a flag to reduce memory overhead. I suppose this issue is not alone, and should appear on other utilities that depend on libcgal-dev. if anyone knows other workarounds to build libcgal-based binaries on embedded processors, we are happy to know and implement. Qianqian I am the responsible person for the build architecture limitation. It was an attempt to get octave-iso2mesh into bullseye, at least for a limited set of release-official architectures. However, the package did not yet migrated into testing, even though a request for the removal of the binary packages for armel, armhf, and mipsel have been filed (see Bug#979623). Those architectures have been removed because the CGAL-dependent building consumes lots of memory. I think that other packages in Debian are been hit by the same problem. I fully agree that this is not an ideal situation. I think that, once Bug#979623 is fixed, we should remove the architecture restriction. What do the others think? Best, Rafael Laboissière
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
N.B.: I am moving this discussion into the mailing list of the Debian Octave Group and also adding Qianqian Fang (the original developer of the package and also upstream author) to the Cc list. * John Paul Adrian Glaubitz [2021-01-22 12:10]: Source: octave-iso2mesh Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org The last upload octave-iso2mesh arbitrarily limited the list of build architectures on the assumption that only certain architectures have buildds with enough disk spaces which is certainly not true. The available disk space depends on the buildd used, not the architecture. Furthermore, it may happen that the buildd disk space fills up which can happen if the machine crashes, gets automatically rebooted and the previous builds are therefore not cleaned up. This is something observed on the buildd blaauw which crashes regularly due to a bug in the kernel [1]. Could you therefore remove the architecture limitation list or - at least - re-add the Debian Ports architectures (e.g. alpha, hppa, ia64, m68k, powerpc, ppc64, riscv64, sh4, sparc64 and x32)? I am the responsible person for the build architecture limitation. It was an attempt to get octave-iso2mesh into bullseye, at least for a limited set of release-official architectures. However, the package did not yet migrated into testing, even though a request for the removal of the binary packages for armel, armhf, and mipsel have been filed (see Bug#979623). Those architectures have been removed because the CGAL-dependent building consumes lots of memory. I think that other packages in Debian are been hit by the same problem. I fully agree that this is not an ideal situation. I think that, once Bug#979623 is fixed, we should remove the architecture restriction. What do the others think? Best, Rafael Laboissière
Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures
Source: octave-iso2mesh Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! The last upload octave-iso2mesh arbitrarily limited the list of build architectures on the assumption that only certain architectures have buildds with enough disk spaces which is certainly not true. The available disk space depends on the buildd used, not the architecture. Furthermore, it may happen that the buildd disk space fills up which can happen if the machine crashes, gets automatically rebooted and the previous builds are therefore not cleaned up. This is something observed on the buildd blaauw which crashes regularly due to a bug in the kernel [1]. Could you therefore remove the architecture limitation list or - at least - re-add the Debian Ports architectures (e.g. alpha, hppa, ia64, m68k, powerpc, ppc64, riscv64, sh4, sparc64 and x32)? Thanks, Adrian > [1] https://bugzilla.kernel.org/show_bug.cgi?id=206669 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
