Re: nocheck (don't run) vs nodoc (don't build)

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> On Wed, 26 Apr 2023 at 18:59:46 +0200, Christian Kastner wrote:
>> Policy 4.9.1 states that (emphases mine): * "[nocheck] says not
>> to *run* any build-time test suite" * "[nodoc] says to skip any
>> *build* steps"
>> 
>> My reading with regards to 'nocheck' was that where tests were
>> available and needed to be built, then they should always be
>> built, just not run.
>> 
>> A typical example might be a C library package that builds those
>> tests and ships them as autopkgtests, maybe even in a dedicated
>> package.
>> 
>> I thought this line of reasoning was sound, but then I remembered
>> the 'nodoc' tag and now I am no longer sure. Maybe I'm taking the
>> 'nocheck' description too literally.

Simon> With RFC 2119 terms, my opinion would be:

Simon> - packages built with the nocheck option SHOULD NOT run tests

Agreed.

Simon> - the nocheck option SHOULD NOT alter the contents of any
Simon> binary package

I agree this is true--possibly even as a MUST--for the nocheck build
profile, but
I think DEB_BUILD_OPTIONS are allowed to modify the contents of binary
packages.
As an example nostrip certainly modifies the size of things, and noopt
can modify the behavior and performance.

My assumption was that if you were specifying the nocheck build option,
you don't want to run tests, possibly because they are flaky and/or you
are trying a build for some local reason even though you know the tests
will fail.

If you actually want to avoid building the tests, use the nocheck build
profile (assuming that can be done without modifying binary packages).

If my reasoning is correct, my interpretation is that nocheck option
can build tests or not, depending on whatever is convenient.

I guess that's consistent with RFC 2119.
And RFC 2119 SHOULD means that the requirement is RECOMMENDED, and an
implementation that does not follow the SHOULD needs to have a reason
for not following the recommendation.

Re: nocheck (don't run) vs nodoc (don't build)

[Simon McVittie]

On Wed, 26 Apr 2023 at 18:59:46 +0200, Christian Kastner wrote:
> Policy 4.9.1 states that (emphases mine):
>   * "[nocheck] says not to *run* any build-time test suite"
>   * "[nodoc] says to skip any *build* steps"
> 
> My reading with regards to 'nocheck' was that where tests were available
> and needed to be built, then they should always be built, just not run.
> 
> A typical example might be a C library package that builds those tests
> and ships them as autopkgtests, maybe even in a dedicated package.
> 
> I thought this line of reasoning was sound, but then I remembered the
> 'nodoc' tag and now I am no longer sure. Maybe I'm taking the 'nocheck'
> description too literally.

With RFC 2119 terms, my opinion would be:

- packages built with the nocheck option SHOULD NOT run tests
- the nocheck option SHOULD NOT alter the contents of any binary package
- packages built with the nocheck option MAY avoid building the tests at
  all, but only if that doesn't change the binary packages

The nocheck option (in Policy) is related to the nocheck build-profile
(not part of Policy). https://wiki.debian.org/BuildProfileSpec documents
that DEB_BUILD_PROFILES=nocheck SHOULD NOT change either the contents of
any binary package or the set of binary packages that are compiled, and
also documents that DEB_BUILD_PROFILES=nocheck MUST be accompanied by
DEB_BUILD_OPTIONS=nocheck.

For the use-case of choosing whether to build tests and ship them
in a .deb for autopkgtest or manual testing, we have the noinsttest
build-profile ("Disable binary packages consisting entirely of automated
tests, manual tests, example/demo programs and test tools").

For example, see dbus, which uses GLib in many of its automated tests,
but not in its production code. It build-depends on

libglib2.0-dev  

which means it usually needs GLib, but if it is built with *both* nocheck
and noinsttest (meaning don't run build-time tests, *and* don't build
dbus-tests_*.deb for later use by autopkgtest) then GLib isn't required.

smcv

Re: nocheck (don't run) vs nodoc (don't build)

[Christian Kastner]

Hi Russ,

thanks for the fast reply!

On 2023-04-26 20:42, Russ Allbery wrote:
> Christian Kastner  writes:
>> I thought this line of reasoning was sound, but then I remembered the
>> 'nodoc' tag and now I am no longer sure. Maybe I'm taking the 'nocheck'
>> description too literally.
> 
> I think this may be semi-accidental stemming from the affect on build
> dependencies.  One of the points of nodoc is to avoid needing to install
> (and thus have available) all the build dependencies that are used only
> for building the documentation, which often involves a full TeXLive
> installation and thus poses time, space, and bootstrapping issues.  So I
> think we made specific note that the documentation wouldn't be built so
> that those build dependencies wouldn't be required.

Yep, that was my understanding, too.

> The same argument probably applies to the test suite, I think?  It's just
> less common (although certainly not unheard of) for test suites to have
> test-suite-only build dependencies (as opposed to test-only runtime
> dependencies, which are very common in at least the Perl world).

We (the ROCm team) have a few instances of such test suites, namely
header-only libraries. Upstream ships tests that require compilation,
and we'd like to ship these tests for autopkgtest purposes.

[Tangential: our autopkgtests cannot be run on official infra yet as
they require an AMD GPU to run, but that's another avenue we're working
on. The issue here should also apply to any other header-only library.]

> Anyway, I think this warrants a bug and some work on figuring out what we
> really want to say, and I'd want the folks working on bootstrapping and
> build profiles to weigh in.  The nocheck build profile sort of implies
> that the test suite shouldn't be built either:
> 
> No test suite should be run, and build dependencies used only for that
> purpose should be ignored. Builds that set this profile must also add
> nocheck to DEB_BUILD_OPTIONS
> 
> It still doesn't say this explicitly, but it says build dependencies
> should be ignored, so presumably the build would fail if it required any
> build dependcies, implying that it shouldn't be run.

Strictly speaking, it says build dependencies for the purposes of
_running_ should be ignored, which makes perfect sense of course. But
what if there is another purpose, specifically shipping autopkgtests?
Like packages 'systemd-tests', or 'fwupd-tests'?

For a Python package, this is easy: I can skip any build dependencies
needed for build-time testing (eg: python3-pytest), and since Python
test suites generally don't need builds, I can still ship full test
suite as an autopkgtest. So nocheck "just works".

For a C or C++ library though, skipping build dependencies for tests
means empty autopkgtests. So far, I just assumed that this was
wrong/contradictory, and thus always built them.

But then I remembered nodoc, and how that too can lead to possibly empty
and thus unusable packages. And how that's ok, since such builds aren't
meant for general use, but for the specific use of the caller who
explicitly requested nocheck/nodoc in the first place, so they know what
they are doing.

> Anyway, I think this warrants a bug

I'll try to improve and to compact my reasoning, and will file one when
it's done -- unless you'd prefer me not to do it myself, or somebody
else beats me to it.

But that will take me a while, as I clearly need to think this through a
bit more. Because it just dawned me that for a header-only library, the
argument could be made that autopkgtests should always build the tests
from scratch anyways. Or maybe even both (run, and build-and-run).

Best,
Christian

Re: Bug #1013195: base-files: Please add AGPL-3 license

[Russ Allbery]

Robert Ernst  writes:

> Also I kindly remark my still open questions regarding:

> - Is there enough manpower in the debian policy team?

No, not really.

> - Who is part of the debian policy team besides of the two delegates
>     - Russ Allbery (rra)
>     - Sean Whitton (spwhitton)

Currently, that is the entirety of the Policy team, although anyone can do
any of the steps of driving policy changes except for the final merge and
uploads (and Sean has been doing a great job getting those uploaded).  I
personally have been absolutely swamped with non-Debian stuff for quite
some time and have managed only very rare bursts of activity.

I had at one point planned out next steps for resolving all the requests
to add new licenses to base-files.  The root problem is that it's not
clear what the rest of the project expects in terms of license inclusion
in base-files, and we need to pin that down so that we have a somewhat
objective criteria.  That should likely be a debian-devel conversation
that's actively guided to reach some sort of consensus, and I suspect some
sort of straw polling would be useful since there are a lot of opinions
and it's the sort of topic where we may not be able to judge the consensus
of the project purely from the discussion.

Things that I think need to be resolved:

* What criteria should be used to decide on inclusion?  Pure number of
  packages that use a license (plus it needing to be DFSG of course)?  Or
  something else instead or in addition, and if so, what, and how do we
  judge it?  If we're using number of packages, is that number of source
  packages or number of binary packages?

* Should we include or exclude "short" licenses (by some definition of
  short)?  At one point (if any) is a license so brief that the
  indirection to common-licenses is more trouble than it's worth?

* What do we do about "templated" licenses whose exact wording changes
  from package to package?  We already include one of those in base-files
  (BSD), which contains language specific to the Regents of the University
  of California, and therefore technically the BSD common-license file is
  arguably unusable by any package where the sole copyright holder is not
  the Regents of the University of California even if it has the same
  licensing terms.  Do we rule out templated licenses entirely and not
  include them (except maybe grandfathering the BSD license because
  removing them is hard)?  Is it a bug to reference the current BSD
  license file because of this?

* If we are basing inclusion on number of packages, what's the number of
  packages threshold we should use?

If we get consensus on those, I think we can plow through the dozen or so
open bug reports about common-licenses inclusion pretty quickly, but I
don't like making these decisions ad hoc about each individual license.
We're long-overdue for making a project-wide decision about what does and
doesn't go into common-licenses.

It would probably be helpful to start that discussion with a straw-man
proposal that asserts possible answers to each of those questions.  That
tends to make the discussion more concrete and drive more quickly to the
points of disagreement.  (I personally would exclude both short and
templated licenses and otherwise decide purely on the number of binary
packages that use a given license.  I'd need to do some research on the
best threshold, but my guess is that something between 200 and 500
packages would be a conservative choice.)

I personally do not currently have the bandwidth to try to guide that
consensus discussion.  Anyone who does should feel free to use or repeat
anything in this message if it's helpful.

-- 
Russ Allbery (r...@debian.org)  

Re: nocheck (don't run) vs nodoc (don't build)

[Russ Allbery]

Christian Kastner  writes:

> Policy 4.9.1 states that (emphases mine):
>   * "[nocheck] says not to *run* any build-time test suite"
>   * "[nodoc] says to skip any *build* steps"

> My reading with regards to 'nocheck' was that where tests were available
> and needed to be built, then they should always be built, just not run.

> A typical example might be a C library package that builds those tests
> and ships them as autopkgtests, maybe even in a dedicated package.

> I thought this line of reasoning was sound, but then I remembered the
> 'nodoc' tag and now I am no longer sure. Maybe I'm taking the 'nocheck'
> description too literally.

I think this may be semi-accidental stemming from the affect on build
dependencies.  One of the points of nodoc is to avoid needing to install
(and thus have available) all the build dependencies that are used only
for building the documentation, which often involves a full TeXLive
installation and thus poses time, space, and bootstrapping issues.  So I
think we made specific note that the documentation wouldn't be built so
that those build dependencies wouldn't be required.

The same argument probably applies to the test suite, I think?  It's just
less common (although certainly not unheard of) for test suites to have
test-suite-only build dependencies (as opposed to test-only runtime
dependencies, which are very common in at least the Perl world).

Anyway, I think this warrants a bug and some work on figuring out what we
really want to say, and I'd want the folks working on bootstrapping and
build profiles to weigh in.  The nocheck build profile sort of implies
that the test suite shouldn't be built either:

No test suite should be run, and build dependencies used only for that
purpose should be ignored. Builds that set this profile must also add
nocheck to DEB_BUILD_OPTIONS

It still doesn't say this explicitly, but it says build dependencies
should be ignored, so presumably the build would fail if it required any
build dependcies, implying that it shouldn't be run.

-- 
Russ Allbery (r...@debian.org)  

nocheck (don't run) vs nodoc (don't build)

[Christian Kastner]

Hi,

Policy 4.9.1 states that (emphases mine):
  * "[nocheck] says not to *run* any build-time test suite"
  * "[nodoc] says to skip any *build* steps"

My reading with regards to 'nocheck' was that where tests were available
and needed to be built, then they should always be built, just not run.

A typical example might be a C library package that builds those tests
and ships them as autopkgtests, maybe even in a dedicated package.

I thought this line of reasoning was sound, but then I remembered the
'nodoc' tag and now I am no longer sure. Maybe I'm taking the 'nocheck'
description too literally.


Is there some established consensus on this that just needs to be
codified? Or are there some common practices?

Is is something worth opening a wishlist bug for?

Best,
Christian

Re: Bug #1013195: base-files: Please add AGPL-3 license

[Bill Allombert]

On Wed, Apr 26, 2023 at 10:49:32AM +, Robert Ernst wrote:
> Hello Bill,
> 
> thank you for the swift reply!
> 
> Excuse me if I do err, but even after consulting others, this bug seems to
> be open.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013195
> 
> And from an uninitiated perspective it seems like the policy team never
> looked at this bug.
> So the best solution for this specific bug would be to leave a comment with
> a hint to the history and then close it?

This bug is duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884223

Cheers,
Bill.

Re: Bug #1013195: base-files: Please add AGPL-3 license

[Robert Ernst]

Hello Bill,

what speaks against closing the bug, independent of being a duplicate?
This whole thread and conversation plus the time spent on it would not 
have been necessary if it would just have been closed.


Also I kindly remark my still open questions regarding:

- Is there enough manpower in the debian policy team?
- Who is part of the debian policy team besides of the two delegates
    - Russ Allbery (rra)
    - Sean Whitton (spwhitton)

Greets Ernst

On 04/26/2023 6:31 PM, Bill Allombert wrote:

On Wed, Apr 26, 2023 at 10:49:32AM +, Robert Ernst wrote:

Hello Bill,

thank you for the swift reply!

Excuse me if I do err, but even after consulting others, this bug seems to
be open.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013195

And from an uninitiated perspective it seems like the policy team never
looked at this bug.
So the best solution for this specific bug would be to leave a comment with
a hint to the history and then close it?

This bug is duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884223

Cheers,
Bill.


OpenPGP_0x2868F0A15BA19C08.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug #1013195: base-files: Please add AGPL-3 license

[Robert Ernst]

Hello Bill,

thank you for the swift reply!

Excuse me if I do err, but even after consulting others, this bug seems 
to be open.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013195

And from an uninitiated perspective it seems like the policy team never 
looked at this bug.
So the best solution for this specific bug would be to leave a comment 
with a hint to the history and then close it?


Greets Ernst

On 04/26/2023 4:21 PM, Bill Allombert wrote:

On Wed, Apr 26, 2023 at 09:03:14AM +, Robert Ernst wrote:

Hello,

I found this bug because I was asking myself why we don't include more
licenses in the /usr/share/common-licenses/ folder.
While I am open to have the big topic (of why we don't just put all licenses
know to man in every language put into the common-licences folder and then
refer from the debian/copyright file to that folder/files instead of putting
the whole license text into every package itself) I prefer to keep it at a
specific example in case of this bug.

This bug was assigned at Mon, 03 Oct 2022 22:03:07 GMT to debian-policy. It
seems it was not getting attention from the debian-policy team since 6
months.

The rule we follow is that the license need to be used by a non negligible
percentage of packages. It is not the first time a bug report ask to add the
AGPL. Last time the statistic was computed, the AGPL did not cut it, so the bug
was closed.

Cheers,
Bill


OpenPGP_0x2868F0A15BA19C08.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug #1013195: base-files: Please add AGPL-3 license

[Bill Allombert]

On Wed, Apr 26, 2023 at 09:03:14AM +, Robert Ernst wrote:
> Hello,
> 
> I found this bug because I was asking myself why we don't include more
> licenses in the /usr/share/common-licenses/ folder.
> While I am open to have the big topic (of why we don't just put all licenses
> know to man in every language put into the common-licences folder and then
> refer from the debian/copyright file to that folder/files instead of putting
> the whole license text into every package itself) I prefer to keep it at a
> specific example in case of this bug.
> 
> This bug was assigned at Mon, 03 Oct 2022 22:03:07 GMT to debian-policy. It
> seems it was not getting attention from the debian-policy team since 6
> months.

The rule we follow is that the license need to be used by a non negligible
percentage of packages. It is not the first time a bug report ask to add the
AGPL. Last time the statistic was computed, the AGPL did not cut it, so the bug
was closed.

Cheers,
Bill

Bug #1013195: base-files: Please add AGPL-3 license

[Robert Ernst]

Hello,

I found this bug because I was asking myself why we don't include more 
licenses in the /usr/share/common-licenses/ folder.
While I am open to have the big topic (of why we don't just put all 
licenses know to man in every language put into the common-licences 
folder and then refer from the debian/copyright file to that 
folder/files instead of putting the whole license text into every 
package itself) I prefer to keep it at a specific example in case of 
this bug.


This bug was assigned at Mon, 03 Oct 2022 22:03:07 GMT to debian-policy. 
It seems it was not getting attention from the debian-policy team since 
6 months.


As https://salsa.debian.org/dbnpolicy/policy/blob/master/README.md 
states, I try to shepherd this bug as an example.

I have the following questions:

- Is there enough manpower in the debian policy team?

- Who is part of the debian policy team besides of the two delegates
        - Russ Allbery (rra)
        - Sean Whitton (spwhitton)

- What can I do to bring the AGPL-3 license into the 
/usr/share/common-licenses/ folder?


- What would speak against to bring the AGPL-3 license into that folder?

Greets Ernst



OpenPGP_0x2868F0A15BA19C08.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature