Acknowledgement sent
to Thorsten Glaser <[email protected]>:
Extra info received and forwarded to list.
(Tue, 15 Sep 2020 14:57:05 GMT) (full text, mbox, link).
Subject: Re: Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
Date: Tue, 15 Sep 2020 14:42:38 +0000 (UTC)
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⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
Acknowledgement sent
to John Paul Adrian Glaubitz <[email protected]>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <[email protected]>.
(Tue, 15 Sep 2020 15:03:04 GMT) (full text, mbox, link).
Subject: Re: Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
Date: Tue, 15 Sep 2020 16:58:44 +0200
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 - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Acknowledgement sent
to Finn Thain <[email protected]>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <[email protected]>.
(Tue, 15 Sep 2020 23:45:02 GMT) (full text, mbox, link).
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?
Acknowledgement sent
to Thorsten Glaser <[email protected]>:
Extra info received and forwarded to list.
(Wed, 16 Sep 2020 00:03:02 GMT) (full text, mbox, link).
Subject: Re: Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
Date: Wed, 16 Sep 2020 00:00:33 +0000 (UTC)
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
--
<ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo │ fault (core dumped)
<ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh
Changed Bug title to 'mksh: Ignores “nocheck” in DEB_BUILD_OPTIONS on m68k and sh4' from 'mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS'.
Request was from Thorsten Glaser <[email protected]>
to [email protected].
(Wed, 16 Sep 2020 00:09:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Finn Thain <[email protected]>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <[email protected]>.
(Wed, 16 Sep 2020 00:45:02 GMT) (full text, mbox, link).
Subject: Re: Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS
Date: Wed, 16 Sep 2020 10:41:51 +1000 (AEST)
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?
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.