> "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
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
> an
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
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)
Cur
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
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.
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 perspec
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 i
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 sol
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 ev
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 t
11 matches
Mail list logo
