Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

2024-04-05 Thread Sean Whitton
Hello,

On Sat 06 Apr 2024 at 12:15pm +08, Sean Whitton wrote:

> Hi Russ,
>
> We have two seconded solutions, so you and I should perhaps break the
> tie.  I prefer the Bill's 'Autobuild: no' solution as the more
> conservative change: we only have data about packages that are currently
> autobuilt, not those that aren't, so we might be making those buggy if
> we just ban network access for all non-free packages.  How about you?

(It's not actually a tie in terms of number of seconds, but we don't do
this quantatively.)

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

2024-04-05 Thread Sean Whitton
Hi Russ,

We have two seconded solutions, so you and I should perhaps break the
tie.  I prefer the Bill's 'Autobuild: no' solution as the more
conservative change: we only have data about packages that are currently
autobuilt, not those that aren't, so we might be making those buggy if
we just ban network access for all non-free packages.  How about you?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1068022: Document the Testsuite-Triggers field

2024-04-05 Thread Sean Whitton
Hello,

On Fri 05 Apr 2024 at 11:30am +02, Christian Kastner wrote:

> Hi again,
>
> On 2024-03-29 20:30, Christian Kastner wrote:
>> Policy 5.6.30 lists the Testsuite field, but it doesn't list the
>> Testsuite-Triggers field that seems to be part of Sources files and is
>> generated by dpkg-source >= 1.18.8.
>>
>> This field is quite useful, as given my package src:foo, I can find out
>> which packages have autopkgtests that depend on it, and are thus in the
>> set of reverse dependencies that I could check for breakage.
>
> I've read up on the change process [1], and I guess my proposal to
> submit a patch was too far into the process.
>
> Thus, I take a step back, and seek discussion first.
>
> In addition to what I've said above, I think documenting this field
> would not only enhance discoverability, but give more weight to it for
> tooling that makes use of these fields.
>
> For discussion context, I'd like to quote dsc(5) on this field:
>> Testsuite-Triggers: package-list
>>
>> This field declares the comma-separated union of all test dependencies
>> (Depends fields in debian/tests/control file), with all restrictions
>> removed, and OR dependencies flattened (that is, converted to separate AND
>> relationships), except for binaries generated by this source package and its
>> meta-dependency equivalent @.
>>
>> Rationale: this field is needed because otherwise to be able to get the test
>> dependencies, each source package would need to be unpacked.

Sounds good to me.  If you'd like to propose wording, there's some more
guidance in our README.md.  Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

2024-04-05 Thread Sam Hartman
> "Aurelien" == Aurelien Jarno  writes:

Aurelien> If we go that route, here is a proposed alternative patch:

Aurelien> --- a/policy/ch-source.rst
Aurelien> +++ b/policy/ch-source.rst
Aurelien> @@ -338,7 +338,8 @@
Aurelien>  For example, the build target should pass 
``--disable-silent-rules``
Aurelien>  to any configure scripts.  See also :ref:`s-binaries`.
 
Aurelien> -For packages in the main archive, required targets must not 
attempt
Aurelien> +Except for packages in the non-free archive with the 
``Autobuild``
Aurelien> +control field unset or set to ``no``, required targets must not 
attempt
Aurelien>  network access, except, via the loopback interface, to services 
on the
Aurelien>  build host that have been started by the build.

Seconded.


signature.asc
Description: PGP signature


Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

2024-04-05 Thread Aurelien Jarno
On 2024-04-04 22:38, Bill Allombert wrote:
> On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote:
> > I'm not sure what I think about that.  We have a general escape hatch
> > already for non-free packages in Policy 2.2.3 that says they may not fully
> > comply with Policy, which may be sufficient. 
> 
> But precisely, we _do_ want non-free packages that are built on the 
> autobuilders
> to comply with this requirement. So we do not want 2.2.3 to apply in that
> specific case. It seems cleaner to say that the requirement only apply if
> Autobuild: yes is declared.

If we go that route, here is a proposed alternative patch:

--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -338,7 +338,8 @@
 For example, the build target should pass ``--disable-silent-rules``
 to any configure scripts.  See also :ref:`s-binaries`.
 
-For packages in the main archive, required targets must not attempt
+Except for packages in the non-free archive with the ``Autobuild``
+control field unset or set to ``no``, required targets must not attempt
 network access, except, via the loopback interface, to services on the
 build host that have been started by the build.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net



Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

2024-04-05 Thread Holger Levsen
On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote:
> Thanks Philipp. Following that result, please find a patch proposal: 
> 
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -338,9 +338,9 @@
>  For example, the build target should pass ``--disable-silent-rules``
>  to any configure scripts.  See also :ref:`s-binaries`.
>  
> -For packages in the main archive, required targets must not attempt
> -network access, except, via the loopback interface, to services on the
> -build host that have been started by the build.
> +Required targets must not attempt network access, except, via the
> +loopback interface, to services on the build host that have been started
> +by the build.
>  
>  Required targets must not attempt to write outside of the unpacked
>  source package tree.  There are two exceptions.  Firstly, the binary

thanks, this looks good to me as well. seconded.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bananas are berries.


signature.asc
Description: PGP signature


Bug#1068022: Document the Testsuite-Triggers field

2024-04-05 Thread Christian Kastner
Hi again,

On 2024-03-29 20:30, Christian Kastner wrote:
> Policy 5.6.30 lists the Testsuite field, but it doesn't list the
> Testsuite-Triggers field that seems to be part of Sources files and is
> generated by dpkg-source >= 1.18.8.
> 
> This field is quite useful, as given my package src:foo, I can find out
> which packages have autopkgtests that depend on it, and are thus in the
> set of reverse dependencies that I could check for breakage.

I've read up on the change process [1], and I guess my proposal to
submit a patch was too far into the process.

Thus, I take a step back, and seek discussion first.

In addition to what I've said above, I think documenting this field
would not only enhance discoverability, but give more weight to it for
tooling that makes use of these fields.

For discussion context, I'd like to quote dsc(5) on this field:
> Testsuite-Triggers: package-list
> 
> This field declares the comma-separated union of all test dependencies 
> (Depends fields in debian/tests/control file), with all restrictions removed, 
> and OR dependencies flattened (that is, converted to separate AND 
> relationships), except for binaries generated by this source package and its 
> meta-dependency equivalent @.
> 
> Rationale: this field is needed because otherwise to be able to get the test 
> dependencies, each source package would need to be unpacked.
Best,
Christian

[1] https://www.debian.org/doc/debian-policy/ap-process.html