Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
On Wed, 16 Sep 2020, Thorsten Glaser wrote: > Finn Thain dixit: > > >I think it would be helpful to everyone if nocheck could be avoided > >where possible. I wonder where is that possible. > > I'd prefer if it could be added only for problematic packages, or done > in porter uploads, but on the buildds not for all packages. > If the problem was build time, one solution could be to enable 'make check' at random (for slow packages) with some predetermined probability needed to reach the desired average buildd throughput. > >Which architectures are using nocheck? > > According to the list in, I think, GCC, which I copied, that is on m68k > and sh4. (The package I copied from ignores nocheck on these > architectures as well, as protection from greater issues.) > I wonder whether sh4 and m68k have the same reason for using nocheck. > >Would it help if test failures could be triaged, such that an "ENOMEM" > >result could be treated as "undecided", since that is what it is? > > I highly doubt that. Test failures abort the build, and you can't just > carry on afterwards. > It's normal for the build to carry on after a "skipped" test. And nocheck just means skip all tests, right? Treating "ENOMEM" like "skipped" for certain tests is probably more correct in many instances than treating it like "failed". The implementation of that logic would probably have to be made acceptable to upstream developers however. > Plus I think these aren't even the problems; problematic is when the > testsuite hangs the buildd. (But even so, builds are killed after some > time of inactivity, normally.) > I can see that being a problem at 66 MHz but is it still a problem for qemu-user or qemu-system?
Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
Finn Thain dixit: >I think it would be helpful to everyone if nocheck could be avoided where >possible. I wonder where is that possible. I’d prefer if it could be added only for problematic packages, or done in porter uploads, but on the buildds not for all packages. >Which architectures are using nocheck? According to the list in, I think, GCC, which I copied, that is on m68k and sh4. (The package I copied from ignores nocheck on these architectures as well, as protection from greater issues.) >Why is it needed for qemu-user on m68k? It is not needed to build mksh under qemu-user on m68k. (In fact, mksh’s build process uses the testsuite to determine whether the klibc-built, musl-built, and/or dietlibc-built binary of mksh-static works well enough to promote it to /bin/ and uses the same library to compile the lksh binary as well; if nocheck is given or all three other libraries fail, glibc (the system libc) is used but it’s… much less suitable, for static linking especially; this works, e.g. on kfreebsd/hurd, but glibc is… a moloch.) >Would it help if test failures could be triaged, such that an "ENOMEM" >result could be treated as "undecided", since that is what it is? I highly doubt that. Test failures abort the build, and you can’t just carry on afterwards. Plus I think these aren’t even the problems; problematic is when the testsuite hangs the buildd. (But even so, builds are killed after some time of inactivity, normally.) I’d prefer the reason to add nocheck for m68k and sh4 qemu buildds to be revisited. (Also, do any ARAnyM and bare-metal buildds use this as well?) Unless needed for qemu-specific reasons, it was a great tool while helping to get the port back into shape, and I occasionally need it on porter uploads where the broken functionality is less important than having the library available as build depen‐ dency, but that is rare and always manual. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
On Tue, 15 Sep 2020, John Paul Adrian Glaubitz wrote: > > > >> On m68k and sh4, the buildds are currently configured to pass > >> "nocheck" > > > > Precisely for this reason, some packages in the archive ignore that on > > these architectures. > > > > Without the testsuite we cannot reliably build due to bugs in the > > toolchain, and it doesn’t run for long anyway. > > I understand the reasoning but it's nevertheless incorrect. > > If you want to see a testsuite being run, you can ask the buildd > maintainers or test the package yourself. But you shouldn't arbitrarily > override policy-defined mechanisms so that a package behaves > unexpectedly. > Arguably, downstream should try to avoid arbitrarily overriding upstream policy. But instead of arbitrating the arbiters, perhaps we can discuss the root cause. > "nocheck" will remain activated as long as we're using qemu-user over > qemu-system which will be the case until the kernel on the affected > architectures can use more RAM on emulated systems. > I think it would be helpful to everyone if nocheck could be avoided where possible. I wonder where is that possible. Which architectures are using nocheck? Why is it needed for qemu-user on m68k? Would it help if test failures could be triaged, such that an "ENOMEM" result could be treated as "undecided", since that is what it is?
Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
On 9/15/20 4:42 PM, Thorsten Glaser wrote: > Control: severity -1 wishlist > Control: tags -1 wontfix > > John Paul Adrian Glaubitz dixit: > >> On m68k and sh4, the buildds are currently configured to pass "nocheck" > > Precisely for this reason, some packages in the archive ignore that > on these architectures. > > Without the testsuite we cannot reliably build due to bugs in the > toolchain, and it doesn’t run for long anyway. I understand the reasoning but it's nevertheless incorrect. If you want to see a testsuite being run, you can ask the buildd maintainers or test the package yourself. But you shouldn't arbitrarily override policy-defined mechanisms so that a package behaves unexpectedly. "nocheck" will remain activated as long as we're using qemu-user over qemu-system which will be the case until the kernel on the affected architectures can use more RAM on emulated systems. 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#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
Control: severity -1 wishlist Control: tags -1 wontfix John Paul Adrian Glaubitz dixit: >On m68k and sh4, the buildds are currently configured to pass "nocheck" Precisely for this reason, some packages in the archive ignore that on these architectures. Without the testsuite we cannot reliably build due to bugs in the toolchain, and it doesn’t run for long anyway. Release architectures aren’t affected. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
Source: mksh Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! On m68k and sh4, the buildds are currently configured to pass "nocheck" to DEB_BUILD_OPTIONS. However, looking at the build logs, the testuite is run nevertheless [1]. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=mksh=m68k=59b-2=1600126781=0 -- .''`. 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
