Bug#610083: Remove requirement to document upstream source location in debian/copyright ?

[Russ Allbery]

Sean Whitton  writes:
> On Sat, Aug 26 2017, Russ Allbery wrote:

>> Seconded with or without the following nit.

>> Minor wording nit: I would put a period after "obtained" and make the
>> next part a separate sentence.  ("The copyright file should include a
>> name or contact address for the upstream authors.")  Otherwise, it
>> could be read as saying that the copyright file can only omit the
>> upstream source information if the URL pointed to by Homepage includes
>> name or contact information, but (a) that's not the point of your
>> change, and (b) we want that contact information to always be in the
>> copyright file if available because upstream URLs tend to disappear.

> I don't think this is so minor!

> The paragraph says that the upstream contact information can just be a
> URL, and if it is, then I think it could be omitted in favour of the
> Homepage: field.  It was deliberate that my addition applies to both the
> 'must' and the 'should' requirements.

> Do you disagree with this?

Well, it doesn't, exactly... it says that it can be a web forum or
bugtracker, but doesn't say anything about being a URL.  Hm.

Something about this sits wrong with me, in that I feel like we should
capture the upstream contact information directly rather than relying on a
URL remaining present on the web.  But I'm not sure it's that big of a
deal one way or the other, so I'm still okay with the wording you proposed
originally (and still second it).

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

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, tagging 679751 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was 
spwhit...@spwhitton.name).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> tags 679751 - patch + pending
Bug #679751 [debian-policy] please clarify package account and home directory 
location in policy
Removed tag(s) patch.
Bug #679751 [debian-policy] please clarify package account and home directory 
location in policy
Added tag(s) pending.
> usertags 679751 = normative
Usertags were: normative discussion.
Usertags are now: normative.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
679751: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679751
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#679751: Patch to close out this bug

[David Bremner]

Sean Whitton  writes:

> +.. _s-nonexistent:
> +
> +Non-existent home directories
> +~
> +
> +The canonical non-existent home directory is ``/nonexistent``.  Users
> +who should not have a home directory should have their home directory
> +set to this value.
> +
> +The Debian autobuilders set HOME to ``/nonexistent`` so that packages
> +which try to write to a home directory will fail to build.
> +
>  .. _s-sysvinit:
>  
>  System run levels and ``init.d`` scripts
>
>
> -- 
> Sean Whitton

Seconded.

d


signature.asc
Description: PGP signature

Bug#610083: Remove requirement to document upstream source location in debian/copyright ?

[Sean Whitton]

control: tag -1 -patch

On Sat, Aug 26 2017, Russ Allbery wrote:

> Seconded with or without the following nit.
>
> Minor wording nit: I would put a period after "obtained" and make the next
> part a separate sentence.  ("The copyright file should include a name or
> contact address for the upstream authors.")  Otherwise, it could be read
> as saying that the copyright file can only omit the upstream source
> information if the URL pointed to by Homepage includes name or contact
> information, but (a) that's not the point of your change, and (b) we want
> that contact information to always be in the copyright file if available
> because upstream URLs tend to disappear.

I don't think this is so minor!

The paragraph says that the upstream contact information can just be a
URL, and if it is, then I think it could be omitted in favour of the
Homepage: field.  It was deliberate that my addition applies to both the
'must' and the 'should' requirements.

Do you disagree with this?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Bug#610083: Remove requirement to document upstream source location in debian/copyright ?

[Debian Bug Tracking System]

Processing control commands:

> tag -1 -patch
Bug #610083 [debian-policy] Remove requirement to document upstream source 
location in debian/copyright ?
Removed tag(s) patch.

-- 
610083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610083
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#610083: Remove requirement to document upstream source location in debian/copyright ?

[Russ Allbery]

Sean Whitton  writes:

> I am seeking seconds for the following patch.  Given what Julian pointed
> out, it only permits Homepage: to be used, not d/watch.

> diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
> index dc02bc6..d79f732 100644
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -186,8 +186,10 @@ information and distribution license in the file
>  ``/usr/share/doc/package/copyright``. This file must neither be
>  compressed nor be a symbolic link.
>  
> -In addition, the copyright file must say where the upstream sources (if
> -any) were obtained, and should include a name or contact address for the
> +In addition, except in the case where the information would duplicate
> +exactly the contents of the :ref:`Homepage ` field, the
> +copyright file must say where the upstream sources (if any) were
> +obtained, and should include a name or contact address for the
>  upstream authors. This can be the name of an individual or an
>  organization, an email address, a web forum or bugtracker, or any other
>  means to unambiguously identify who to contact to participate in the

Seconded with or without the following nit.

Minor wording nit: I would put a period after "obtained" and make the next
part a separate sentence.  ("The copyright file should include a name or
contact address for the upstream authors.")  Otherwise, it could be read
as saying that the copyright file can only omit the upstream source
information if the URL pointed to by Homepage includes name or contact
information, but (a) that's not the point of your change, and (b) we want
that contact information to always be in the copyright file if available
because upstream URLs tend to disappear.

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

Bug#679751: Patch to close out this bug

[Russ Allbery]

Sean Whitton  writes:

> During DebConf, Russ and I reviewed this bug and believe that the only
> remaining issue is to document /nonexistent.  So I am seeking seconds
> for the following patch.

> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index e4ed008..7d9e20a 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -296,6 +296,18 @@ The UID and GID numbers are divided into classes as 
> follows:
>  ``(uid_t)(-1) == (gid_t)(-1)`` *must not* be used, because it is the
>  error return sentinel value.
>  
> +.. _s-nonexistent:
> +
> +Non-existent home directories
> +~
> +
> +The canonical non-existent home directory is ``/nonexistent``.  Users
> +who should not have a home directory should have their home directory
> +set to this value.
> +
> +The Debian autobuilders set HOME to ``/nonexistent`` so that packages
> +which try to write to a home directory will fail to build.
> +
>  .. _s-sysvinit:
>  
>  System run levels and ``init.d`` scripts

Seconded.

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

Bug#679751: Patch to close out this bug

[Sean Whitton]

control: tag -1 +patch

Hello,

During DebConf, Russ and I reviewed this bug and believe that the only
remaining issue is to document /nonexistent.  So I am seeking seconds
for the following patch.

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index e4ed008..7d9e20a 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -296,6 +296,18 @@ The UID and GID numbers are divided into classes as 
follows:
 ``(uid_t)(-1) == (gid_t)(-1)`` *must not* be used, because it is the
 error return sentinel value.
 
+.. _s-nonexistent:
+
+Non-existent home directories
+~
+
+The canonical non-existent home directory is ``/nonexistent``.  Users
+who should not have a home directory should have their home directory
+set to this value.
+
+The Debian autobuilders set HOME to ``/nonexistent`` so that packages
+which try to write to a home directory will fail to build.
+
 .. _s-sysvinit:
 
 System run levels and ``init.d`` scripts


-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Patch to close out this bug

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +patch
Bug #679751 [debian-policy] please clarify package account and home directory 
location in policy
Added tag(s) patch.

-- 
679751: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679751
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#873346: Updating the developers-reference Uploaders list

[Mattia Rizzolo]

Source: developers-reference
Version: 3.4.18
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Marc 'HE' Brockschmidt  has not been working on
the developers-reference package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Processed: Re: Bug#610083: Remove requirement to document upstream source location in debian/copyright ?

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +patch
Bug #610083 [debian-policy] Remove requirement to document upstream source 
location in debian/copyright ?
Added tag(s) patch.

-- 
610083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610083
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#610083: Remove requirement to document upstream source location in debian/copyright ?

[Sean Whitton]

control: tag -1 +patch

On Mon, Jan 17, 2011 at 10:39:15AM +0900, Charles Plessy wrote:
> The difference between both sources of information is that Homepage is
> parseable, and debian/copyright is not. DEP-5 will not solve this
> problem: the Source field is more or less free-form. It may contain an
> URL, but not necessarly, and if there is an URL it is not guaranteed
> to be the one to the sources.

Indeed.

> When the information is redundant, I would like the Policy to permit
> it to be in a single place. This will give a bit of flexibility to
> allow for evolutions.  I think that the requirement to have the
> download URL in the debian/copyright file is one of the reasons why
> there is temptation to add other meta-data to it, and I think that it
> is not the place for this. Let's remember one of the last sentences of
> §12.5: ‘You should not use the copyright file as a general README
> file’.

Agreed.

I am seeking seconds for the following patch.  Given what Julian pointed
out, it only permits Homepage: to be used, not d/watch.

diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
index dc02bc6..d79f732 100644
--- a/policy/ch-docs.rst
+++ b/policy/ch-docs.rst
@@ -186,8 +186,10 @@ information and distribution license in the file
 ``/usr/share/doc/package/copyright``. This file must neither be
 compressed nor be a symbolic link.
 
-In addition, the copyright file must say where the upstream sources (if
-any) were obtained, and should include a name or contact address for the
+In addition, except in the case where the information would duplicate
+exactly the contents of the :ref:`Homepage ` field, the
+copyright file must say where the upstream sources (if any) were
+obtained, and should include a name or contact address for the
 upstream authors. This can be the name of an individual or an
 organization, an email address, a web forum or bugtracker, or any other
 means to unambiguously identify who to contact to participate in the

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870915: debian-policy: [5.6.30] Testsuite: There are much more defined values

[Russ Allbery]

Sean Whitton  writes:

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 61f2b23..2bc7a07 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -1009,12 +1009,12 @@ reference whose name matches ``refs/dgit/*``. See the 
> manual page of
>  
>  Simple field containing a comma-separated list of values allowing test
>  execution environments to discover packages which provide tests.
> -Currently, the only defined value is ``autopkgtest``.
>  
> -This field is automatically added to Debian source control files by
> -``dpkg`` when a ``debian/tests/control`` file is present in the source
> -package. This field may also be used in source package control files if
> -needed in other situations.
> +This field is automatically added to Debian binary control files by
> +``dpkg``, with the value ``autopkgtest``, when a
> +``debian/tests/control`` file is present in the source package. This
> +field may also be used in source package control files if needed in
> +other situations.
>  
>  .. _s5.7:

This seems okay, so seconded, although it would be nice to be more
specific about when this is used and what its allowable values are.  But
I'm also okay with leaving that for future work.

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

Bug#688251: #688251: Built-Using description too aggressive

[Sean Whitton]

control: tag -1 +patch

Hello,

On Sun, Oct 06, 2013 at 05:30:12PM +0900, Charles Plessy wrote:
> The attached patch is a third attempt, which underlines that the Built-Using
> field is particularly useful when a given package, contributing contents
> included in another package, can not be replaced by a later version.  It also
> explains that the Debian archive uses the Built-Using field to retain source
> packages.

Here is a patch for which I am seeking seconds.

- try to improve explanation of "cannot be replaced by a later version"

- state that built-using is NOT for tracking packages that need to be
  rebuilt

  The release team have made it clear that they don't want built-using
  used for this purpose as it generates work close to the release.

diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 3a73f7b..499bed9 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -598,17 +598,26 @@ earlier for binary packages) in order to invoke the 
targets in
 Additional source packages used to build the binary - ``Built-Using``
 -
 
-Some binary packages incorporate parts of other packages when built but
-do not have to depend on those packages. Examples include linking with
-static libraries or incorporating source code from another package
-during the build. In this case, the source packages of those other
-packages are a required part of the complete source (the binary package
-is not reproducible without them).
-
-A ``Built-Using`` field must list the corresponding source package for
-any such binary package incorporated during the build,  [#]_ including
-an "exactly equal" ("=") version relation on the version that was used
-to build that binary package.  [#]_
+Some binary packages incorporate parts of other packages when built
+but do not have to depend on those packages. Examples include linking
+with static libraries or incorporating source code from another
+package during the build. In this case, the source packages of those
+other packages are part of the complete source (the binary package is
+not reproducible without them).
+
+When the license of either the incorporated parts or the incorporating
+binary package requires that the full source code of the incorporating
+binary package be made available, the ``Built-Using`` field must list
+the corresponding source package for any binary package incorporated
+during the build, [#]_ including an "exactly equal" ("=") version
+relation on the version that was used to build that version of the
+incorporating binary package.  [#]_
+
+This causes the Debian archive to retain the versions of the source
+packages that were actually incorporated.  In particular, if the
+versions of the incorporated parts are updated but the incorporating
+binary package is not rebuilt, the older versions of the incorporated
+parts will remain in the archive in order to satisfy the license.
 
 A package using the source code from the gcc-4.6-source binary package
 built from the gcc-4.6 source package would have this field in its
@@ -625,6 +634,11 @@ field in its control file:
 
 Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 
+This field should not be used for purposes other than satisfying
+license requirements to provide full source code.  In particular, it
+should not be used to enable finding packages that should be rebuilt
+against newer versions of their build dependencies.
+
 .. [#]
The relations ``<`` and ``>`` were previously allowed, but they were
confusingly defined to mean earlier/later or equal rather than

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Bug#688251: #688251: Built-Using description too aggressive

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +patch
Bug #688251 [debian-policy] Built-Using description too aggressive
Added tag(s) patch.

-- 
688251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#870915: debian-policy: [5.6.30] Testsuite: There are much more defined values

[Sean Whitton]

control: tag -1 +patch

Hello Ondřej,

On Sun, Aug 06, 2017 at 03:07:24PM +0200, Ondřej Nový wrote:
> In 5.6.30. Testsuite
> ...
> Currently, the only defined value is autopkgtest.
> 
> Which is not true, because we have autodep8. Look to:
> https://anonscm.debian.org/git/lintian/lintian.git/tree/checks/testsuite.pm#n60

Thanks.  Seeking seconds for the patch below.

> And if you want to use autodep8, you need to explicitly add this to
> d/control.

Actually, this depends on which autodep8 module you want to use.  I know
that my elpa module runs the tests even if the Testsuite: field is
missing, for example.

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 61f2b23..2bc7a07 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -1009,12 +1009,12 @@ reference whose name matches ``refs/dgit/*``. See the 
manual page of
 
 Simple field containing a comma-separated list of values allowing test
 execution environments to discover packages which provide tests.
-Currently, the only defined value is ``autopkgtest``.
 
-This field is automatically added to Debian source control files by
-``dpkg`` when a ``debian/tests/control`` file is present in the source
-package. This field may also be used in source package control files if
-needed in other situations.
+This field is automatically added to Debian binary control files by
+``dpkg``, with the value ``autopkgtest``, when a
+``debian/tests/control`` file is present in the source package. This
+field may also be used in source package control files if needed in
+other situations.
 
 .. _s5.7:

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Bug#870915: debian-policy: [5.6.30] Testsuite: There are much more defined values

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +patch
Bug #870915 [debian-policy] debian-policy: [5.6.30] Testsuite: There are much 
more defined values
Added tag(s) patch.

-- 
870915: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870915
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: debian/upstream/signing-key.asc in policy 4.1.0

[Osamu Aoki]

Hi,

On Wed, Aug 23, 2017 at 09:27:25AM -0700, Russ Allbery wrote:
> Osamu Aoki  writes:
> > The updated uscan will support debian/upstream/signing-key.asc only and
> > internally convert it /signing-key.gpg.  I will make uscan to
> > convert other formats to this policy compliant *.asc.  Also make noise
> > to the maintainer to push them to policy 4.1.0
> 
> Note that this Policy language is carefully written to make it perfectly
> fine for uscan to support all the things it currently supports, since it
> only talks about what Policy recommends the maintainer does.  So don't
> feel any obligation to change what uscan is doing on Policy's account
> here.

Maybe I should have been a bit careful with my words:

The updated uscan will support debian/upstream/signing-key.asc only as
the recommended keyring.  It will accept other historic keyrings but
also internally converts them to /signing-key.gpg to guide
people to the new recommended format with some reminder noise.

> That said, as discussed elsewhere, I'm a huge fan of there being only one
> way to do something like this, with some easy tools to convert other
> methods into that one method.  It reduces everyone's cognitive load in the
> future.

Yes.

Osamu

Re: Debian Policy 4.1.0.0 released

[Aurelien Jarno]

On 2017-08-22 09:42, Russ Allbery wrote:
> Aurelien Jarno  writes:
> > On 2017-08-21 14:35, Sean Whitton wrote:
> 
> >> 9.1.1
> >> Only the dynamic linker may install files to /lib64/.
> 
> > How is that supposed to work for the multilib glibc? For example
> > libc6-amd64:i386 installs all its libraries into /lib64. We don't want
> > to install these files in the multiarch path, as they will collide with
> > the libc6:amd64 package. This is actually forbidden by the same
> > paragraph of the policy (and that's a good thing).
> 
> > In the long term we should get ready of multilib now that we have
> > multiarch, but it seems it's not something we are ready to do yet. I
> > have added debian-...@lists.debian.org in Cc: as GCC is the main user of
> > the multilib glibc.
> 
> Ack, thank you, we just didn't know about this and it didn't come up in
> the discussion.  We can add an additional exception.  The goal here wasn't
> to change any behavior of packages like that, only to keep ordinary
> non-glibc, non-toolchain packages from using that directory because of
> what Red Hat does or because of what the FHS says.
> 
> Would it resolve this to just make a general exception for libc?

Yes, that would solve the issue.

Thanks,
Aurelien

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


signature.asc
Description: PGP signature