Bug#841877: Don't recommend contacting base-passwd maintainer for dynamic UIDs

[gregor herrmann]

On Mon, 24 Oct 2016 07:23:30 +0100, Colin Watson wrote:

> I (obviously) agree.  How about this patch?  I'm seeking seconds for
> this proposal.
> 
> diff --git a/policy.sgml b/policy.sgml
> index 9cd182b..ab4f736 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -9610,9 +9610,7 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
> that a dynamically allocated id can be used.  In this case
> you should choose an appropriate user or group name,
> discussing this on debian-devel and checking
> -   with the  -   they do not wish you to use a statically allocated id
> -   instead.  When this has been checked you must arrange for
> +   that it is unique.  When this has been checked you must arrange for
> your package to create the user or group if necessary using
> adduser in the preinst or
> postinst script (again, the latter is to be

Seconded.


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Kings of Convenience: Scars On Land


signature.asc
Description: Digital Signature

Bug#850646: [copyright-format] Allow https version of Format URI

[gregor herrmann]

On Sun, 08 Jan 2017 12:02:38 -0800, Russ Allbery wrote:

> Here's an updated patch that also fixes the other examples.

Thanks!
 
> diff --git a/copyright-format/copyright-format-1.0.xml 
> b/copyright-format/copyright-format-1.0.xml
> index 8b72e10..f33c5a2 100644
> --- a/copyright-format/copyright-format-1.0.xml
> +++ b/copyright-format/copyright-format-1.0.xml
> @@ -260,7 +260,7 @@
>  
>
>  Example header paragraph
> -Format: 
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> +Format: 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>  Upstream-Name: SOFTware
>  Upstream-Contact: John Doe 
>  Source: http://www.example.com/software/project
> @@ -414,7 +414,15 @@ License: MPL-1.1
>
>  Single-line: URI of the format specification.  The field that
>  should be used for the current version of this document is:
> +Format: 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> +  
> +  
> +The original version of this specification used the non-https
> +version of this URL as its URI, namely:
>  Format: 
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> +Both versions are valid and refer to the same specification, and
> +parsers should interpret both as referencing the same format.  The
> +https URI is preferred.
>
>  
>  
> @@ -1225,7 +1233,7 @@ also delete it here.
>  correct copyright file for the actual xsol
>  package):
>  

Bug#175064: DocBook XML conversion is read with this script

[gregor herrmann]

On Sun, 15 Jan 2017 20:51:07 +0100, Guillem Jover wrote:

> Subject: [PATCH 1/7] Use entities instead of literal <, > and &

It seems you've converted some '>' to '>' but not all?
 
> -if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q 
> upstart
> +if [ "$1" = start ] && which initctl >/dev/null && initctl 
> version | grep -q upstart
^

> -  if dpkg-statoverride --list $i >/dev/null 2>&1
> +  if dpkg-statoverride --list $i >/dev/null 2>&1
^

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles


signature.asc
Description: Digital Signature

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[gregor herrmann]

On Wed, 28 Jun 2017 13:13:31 +0200, Andreas Henriksson wrote:

> I also think a really good upgrade notice for this is needed. Should be
> very clearly mentioned people adjusting their packages should not forget
> to also file a bug against ftp.debian.org to align the overrides. 

My guess is that the ftp-masters would run an SQL statement like
UPDATE packages SET priority='optional' WHERE priority='extra';
in the database behind dak just once (or something similar with the
same effect). Filing individual bugs and fixing them separately on
the archive side doesn't sound very efficient to me.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #264:  Your modem doesn't speak English. 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[gregor herrmann]

On Sat, 01 Jul 2017 08:52:29 -0700, Russ Allbery wrote:

> Sean Whitton  writes:
> 
> > Some people frown upon this practice, but there are more than one of us
> > that do it, so probably worth mentioning in policy as a secondary use of
> > native packages (possibly a footnote, due to lack of consensus?  There
> > is certainly not a consensus that it's terrible).
> I thought there actually was a consensus that it's terrible.  I certainly
> think it's not good practice.  I would recommend against anyone doing
> this, speaking as someone who maintains lots of upstream software that I
> also package for Debian, and therefore would rather not document it in
> Policy, unless we're going to say not to do it.

FWIW, I agree, and I also think that this as close to a consensus as
any issue in Debian can get.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: U2: When I Look At The World


signature.asc
Description: Digital Signature

Bug#835520: Andreas Henriksson's 11 patches are awesome

[gregor herrmann]

On Wed, 02 Aug 2017 18:57:03 +, Holger Levsen wrote:

> $ git log master..for-holger --oneline -11
> a8e08d5 Bug#835520: [PATCH v2 11/11] Drop entire section 9.4 Console messages 
> from init.d scripts
> dfa8fae Bug#835520: [PATCH v2 10/11] Add reference to systemd integration 
> examples
> 658c3c2 Bug#835520: [PATCH v2 09/11] Drop obsolete paragraph about rc.boot
> 5364c04 Bug#835520: [PATCH v2 08/11] Add note about invoke-rc.d normally used 
> via dh
> 24d45b9 Bug#835520: [PATCH v2 07/11] Drop legacy code from invoke-rc.d example
> 6964322 Bug#835520: [PATCH v2 06/11] Add "or equivalent" to must use 
> invoke-rc.d paragraph
> 8ab2800 Bug#835520: [PATCH v2 05/11] Add note about update-rc.d normally used 
> via dh
> 5103414 Bug#835520: [PATCH v2 04/11] Drop outdated paragraph about sequence 
> numbers
> 5314e48 Bug#835520: [PATCH v2 03/11] Drop obsolete paragraph about static 
> runlevels and update-rc.d
> e553ef7 Bug#835520: [PATCH v2 02/11] Update init-system title to be more 
> agnostic
> 5965214 Bug#835520: [PATCH v2 01/11] Drop outdated "/run needs initscripts 
> dependency"
> 
> Hereby I'm formally seconding them and thus I'm attaching those commits signed
> by myself.

I'm seconding this patchset as well.
 
Including below to have the actual diff signed.

Cheers,
gregor

--- boq ---

5965214 Bug#835520: [PATCH v2 01/11] Drop outdated "/run needs initscripts 
dependency"
diff --git a/policy.sgml b/policy.sgml
index 9cd182b..81df4a3 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7053,12 +7053,6 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
  in /run should be stored on a temporary
  file system.

-   
- Packages must not assume the /run
- directory exists or is usable without a dependency
- on initscripts (>= 2.88dsf-13.3) until the
- stable release of Debian supports /run.
-   
  
  

e553ef7 Bug#835520: [PATCH v2 02/11] Update init-system title to be more 
agnostic
diff --git a/policy.sgml b/policy.sgml
index 81df4a3..07b7e4f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7648,7 +7648,7 @@ test -f program-executed-later-in-script || 
exit 0

 

- Interfacing with the initscript system
+ Interfacing with init systems
 
  
Maintainers should use the abstraction layer provided by
5314e48 Bug#835520: [PATCH v2 03/11] Drop obsolete paragraph about static 
runlevels and update-rc.d
diff --git a/policy.sgml b/policy.sgml
index 07b7e4f..32e1efc 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7691,19 +7691,6 @@ test -f program-executed-later-in-script || 
exit 0

 

- By default update-rc.d will start services in
- each of the multi-user state runlevels (2, 3, 4, and 5)
- and stop them in the halt runlevel (0), the single-user
- runlevel (1) and the reboot runlevel (6).  The system
- administrator will have the opportunity to customize
- runlevels by simply adding, moving, or removing the
- symbolic links in /etc/rcn.d if
- symbolic links are being used, or by modifying
- /etc/runlevel.conf if the file-rc method
- is being used.
-   
-
-   
  To get the default behavior for your package, put in your
  postinst script
  
5103414 Bug#835520: [PATCH v2 04/11] Drop outdated paragraph about sequence 
numbers
diff --git a/policy.sgml b/policy.sgml
index 32e1efc..d1108be 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7708,15 +7708,6 @@ test -f program-executed-later-in-script || 
exit 0

 

- This will use a default sequence number of 20.  If it does
- not matter when or in which order the init.d
- script is run, use this default.  If it does, then you
- should talk to the maintainer of the sysvinit
- package or post to debian-devel, and they will
- help you choose a number.
-   
-
-   
  For more information about using update-rc.d,
  please consult its man page .
8ab2800 Bug#835520: [PATCH v2 05/11] Add note about update-rc.d normally used 
via dh
diff --git a/policy.sgml b/policy.sgml
index d1108be..37cac8a 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7712,6 +7712,14 @@ test -f program-executed-later-in-script || 
exit 0
  please consult its man page .

+
+   
+ Note that the packaging should normally not call update-rc.d
+ directly but through debhelper programs that add the required
+ update-rc.d calls automatically.
+ (See dh_installinit,
+ dh_systemd_enable, etc.)
+   
  
 
  
6964322 Bug#835520: [PATCH v2 06/11] Add "or equivalent" 

Bug#835520: Seconding nine patches & seeking seconds for two more

[gregor herrmann]

On Thu, 03 Aug 2017 10:55:30 -0400, Sean Whitton wrote:

> I've spoken to h01ger and gregoa IRL and they say that they missed the
> magic word "should" which is what makes debhelper required by these
> patches.  So I'm seeking seconds for the following replacement for
> Andreas' 5th and 8th patches:

Indeed, I missed the magic "should" which unfortunately didn't come
in friendly bold red blinking letters :)

Thanks for catching this glitch, and I'm happy to second the improved
version:
 
> diff --git a/policy.xml b/policy.xml
> index 3daa532..c6c7412 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -8525,6 +8525,14 @@ fi
>  update-rc.d, please consult its man page
>  
> update-rc.d8.
>
> +  
> +It is easiest for packages not to call
> +update-rc.d directly, but instead use
> +debhelper programs that add the required
> +update-rc.d calls automatically.  See
> +dh_installinit,
> +dh_systemd_enable, etc.
> +  
>  
>  
>  
> @@ -8573,6 +8581,14 @@ invoke-rc.d package 
> action
>  invoke-rc.d, please consult its man page
>  
> invoke-rc.d8.
>
> +  
> +It is easiest for packages not to call
> +invoke-rc.d directly, but instead use
> +debhelper programs that add the required
> +invoke-rc.d calls automatically.  See
> +dh_installinit,
> +dh_systemd_start, etc.
> +  
>  
>  
>
> 


Cheers,
gregor




-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Thu, 03 Aug 2017 21:25:32 +0200, Christian Seiler wrote:

Thanks for your long and elaborate email.
Unfortunately I find myself disagreeing with your two main points:

> I wonder whether we are framing this in the right way anyway. There
> are two orthogonal questions in my mind:
>  - is a specific person MIA?
>  - is a package still maintained?

Ack, separating these questions makes sense to me.
 
> On the other hand you could have a package that has
> Maintainer: some team and Uploaders: some person, where "some
> person" is actually MIA, but the rest of the team is still actively
> maintaining the package.

Right, I think that's the situation that the proponents of this
change have in mind.
 
> The main problem I see with Uploaders: is that it's often not really
> up to date. So I do think that it might be a good idea to track the
> people who are responsible for a package outside of the package
> itself in some kind of central database that is not tied to package
> uploads. […] So I don't think the Uploaders:
> field in a package is useless, I just think the current way of
> storing that information is not the best way to do so. But until
> such a central database is ready for usage, I don't think it would
> be wise to drop Uploaders: at the moment, because otherwise that
> information can't be tracked at all.

Here I disagree: This database would just shift the outdated
information to another place; and more generally: I fail to see which
problem it solves.

I guess this is the general difference in perception we have in this
discussion: Some people start from the idea of "responsibility of a
human for a team package" while others are happy and have good
experiences in teams where all (or enough) members take
responsibility for the team packages and feel that a "dedicated human
responsible" doesn't make sense in their workflow.

What I don't understand in the point of view of the "keep Uploaders"
proponents: What does this information, whether correct or not,
actually give others? Are they going to email or phone these persons
privately when emails to the BTS or the maintainer/team list are
ignored? And what happens if they ignore these communications as
well?
 
> To help with the question of whether a package is still being
> actively maintained, let me frame it in this way: I think it is
> not completely unreasonable to say that _most_ packages will be
> updated at least once every 12 months in sid or experimental. (The
> precise number is subject to bikeshedding.) Of course that's not
> true for every package, there are some packages which don't require
> updates that often. So what one could do is the following: a
> package is considered to be actively maintained if a maintainer (or
> team) upload has happened in the last 12 months. (NMUs don't count.)
> If that is not the case, after 12 months an email is automatically
> sent to the maintainer/uploaders to ask whether they are still
> actively maintaining the package. 

I'm sorry but this feels like loads of paperwork for active teams
with tons of package which might not need an upload each $months.

I mean, in the worst case we could script the replies to the pings but
I'd rather not go there :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:

> Tobias Frost  writes:
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did not recognize that the
> > (sole) Uploader wasn't there anymore and the packages were
> > bitrotting. Without the Uploader field there would have been excactly
> > zero change to find those packages and get them back into maintainance
> > again.
> I'm dubious about this assertion and would like to dig into it a bit more.

[…]

Thanks for putting my thoughts (again!) into better words than I ever
could!
 
> (I am entirely in favor of giving the MIA team more actual power.)

(Me too. And, tangential to this discussion but still: maybe also to
packaging teams, like for salvaging un(der)-maintained packages.)


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:

> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > What I don't understand in the point of view of the "keep Uploaders"
> > proponents: What does this information, whether correct or not,
> > actually give others? Are they going to email or phone these persons
> > privately when emails to the BTS or the maintainer/team list are
> > ignored? And what happens if they ignore these communications as
> > well?
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> 
> These "Updating the  Uploaders list" bugs.
> 
> When the MIA team has determined that a person is MIA,[1]
> it can send bugs informing all packages where that person
> is listed in Uploaders that the person is no longer active.

Ok, that's a good example:

So, when we (pkg-perl) get such a list of bug reports (or, which is
less work, a single mail from the MIA team about XY being inactive)
what happens is that
- we probably know that already (but it's still good to have the
  offical confirmation)
- we remove them from Uploaders in git
- nothing else changes: the package will be uploaded when there's any
  reason for it (new release, bugfix) as before when XY was still
  mentioned in Uploaders

Dropping the Uploaders field would mean that we save the work (which
can be quite tedious when we have to add the right bug numbers to the
right packages' changelog entry) without any other changes to the
maintenance of the package.


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Sat, 05 Aug 2017 21:39:40 +0300, Adrian Bunk wrote:

> Regarding the first point, most large teams do have have the concept of 
> package ownership inside the team. 

Maybe, maybe not.
So far I've seen mostly voices from people working in teams in this
thread who are in favour of dropping the required Uploaders field.

> A reason why "generate Uploaders based on team member information 
> stored in a core package of the team" sounds like a reasonable solution
> to me is that I think a solution is required only for a handful large
> teams.

- Team membership is easily available for teams which use Alioth. [0]
- Does this suggestion mean we should put 140 people in Uploaders? [0]
  And/or sync Alioth project membership to a package regularly?

[0] https://alioth.debian.org/projects/pkg-perl/


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Sat, 05 Aug 2017 21:20:37 +0200, Ole Streicher wrote:

> > So far I've seen mostly voices from people working in teams in this
> > thread who are in favour of dropping the required Uploaders field.
> So, if you want to count votes: I am working in teams (mainly Debian
> Astro), and I would favour keeping it -- 

Perfectly fine, thanks for adding your point of view.

(And just to be sure: The proposal is not to forbid or drop the
field, just to make it optional instead of required for teams, so
each team would be free to keep it and use it according to their
policy and needs.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#844431: Revised patch: seeking seconds

[gregor herrmann]

On Sat, 12 Aug 2017 15:34:35 -0700, Sean Whitton wrote:

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or 
> build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
> See the file ``upgrading-checklist`` for information about policy
> which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
> often creates either static linking or shared library conflicts, and,
> most importantly, increases the difficulty of handling security
> vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition `_.


Seconded.

Thanks to everyone for their work on this.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#873001: [debian-policy] get-orig-source documentation should include a pointer to devref and a minimal example

[gregor herrmann]

On Thu, 24 Aug 2017 22:10:15 +0200, Bill Allombert wrote:

> How do you plan to instruct uscan how repacking should be done ?

Adding files to be removed to Files-Excluded in d/copyright covers
about (rough guess) 95% of the cases, without any further changes
needed.
And for the remaining cases, uscan honours a parameter in
d/watch to call a repacking script.

What I've seen about get-orig-source targets are very rare esoteric
cases. And I guess using the target is not forbidden, as well as
converting the makefiles runes from d/rules to a shell script called
by uscan+d/watch should just do the same.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Trio: Da da da


signature.asc
Description: Digital Signature

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

[gregor herrmann]

On Sat, 26 Aug 2017 12:49:46 -0700, Sean Whitton wrote:

> 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:
> 

Seconded.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#459427: changelog vs. NEWS handling

[gregor herrmann]

On Wed, 29 Nov 2017 11:34:21 +, Simon McVittie wrote:

> > Most of my Debian and Ubuntu work involves GNOME packaging. For the
> > most part, GNOME components ships NEWS files which are much more
> > interesting for users or developers to read for highlights of what
> > changed when.
> This is in line with the roles of NEWS and ChangeLog in the GNU Coding
> Standards, which is perhaps a more canonical reference than "what
> GNOME does".

From the Perl world, looking at roughly ~3400 packages I have locally
cloned:

28 have a NEWS file (most of them with a Gnome/GTK background), 1
News, 1 news.

3368 have a Changes, CHANGES, Changelog, ChangeLog, (and some other
variations like Change{s,Log}.{pod,ini,1,txt}); and those files are the
manually created user-facing summaries of relevant changes of the
release (in almost all cases).

For 10 packages we have `dh_installchangelogs NEWS' in debian/rules.


I'm all for installing NEWS if it's a summary in the GNU style; but
assuming that ChangeLog etc. are detailed/auto-generated/boring
doesn't reflect reality in the Perl universe.


> > I think the idea of renaming NEWS to changelog (as is done by
> > dh_installchangelogs NEWS) is wrong, because it goes against people's
> > understanding of what a changelog generally looks like.
> At the risk of making more packages immediately buggy, I think I agree
> with this, and hence prefer option 2 over option 3. 

I think that depends on where the people are coming from; if they've
used Debian for long enough they might be familiar with the practice
that /usr/share/doc//changelog.gz contains user-focused
summaries. -- But I'm fine with installing NEWS as
/usr/share/doc//NEWS.gz instead of renaming it when it
exists.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: In My Secret Life


signature.asc
Description: Digital Signature

Bug#459427: changelog vs. NEWS handling

[gregor herrmann]

On Thu, 30 Nov 2017 20:45:51 -0800, Russ Allbery wrote:

> I think
> the most valuable starting point would to be to standardize on
> /usr/share/doc/package/NEWS.gz for the human-readable summary and
> explicitly say to never install that as
> /usr/share/doc/package/changelog.gz.  

That would mean that we have to manually add something to d/rules for
thousands of perl packages in order to make ChangeLog, Changes etc.
getting installed as /usr/share/doc/package/NEWS.gz.
(Unless dh_installchangelogs gets some logic to install ChangeLog,
Changes etc. as NEWS.gz if there is no NEWS in the upstream tarball.
But that might be confusing …)


On Fri, 01 Dec 2017 13:34:01 -0700, Sean Whitton wrote:

> We can at least make dh_installchangelogs capable of installing both
> changelog.gz and NEWS.gz before we change Policy.  Otherwise, fixing the
> minor bugs is significantly more annoying.

Ack, this would be a good start.
 
> If we are going to add something that says that upstream NEWS/release
> notes should also be installed, why not standardise on the location?  It
> seems odd to have a standard location for upstream changelogs but not
> for upstream NEWS/release notes.
> 
> Or perhaps we should drop the standard location for upstream changelogs.
 
Having some standardization makes it easier for both users and their
tools to quickly find what they are looking for. But yeah, I think we
have at least 2 problems in this area:
- no single standard on the upstream side (c.f. the GNU style vs. the
  CPAN style(s))
- needed changes in our tooling (dh_installchangelogs)

And we have 2 questions to answer:
1) Which files to install?
2) Under what name?

What policy could say is:
1) - If there is a human-facing summary, install it.
   - If there is a human-facing summary and a VCS-style log, install
 the former but not the latter.
   - If there is no human-facing summary but a a VCS-style log,
 consider installing the latter.
   (Without mentioning file names, or maybe as examples, as they are
   not standardized).
2) Install NEWS as /usr/share/doc/package/NEWS.gz and /Change.*/i as
   /usr/share/doc/package/changelog.gz if you install them.
   (That's also something dh_installchangelogs could do easily.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Jim Croce: Time In A Bottle


signature.asc
Description: Digital Signature

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

[gregor herrmann]

On Wed, 13 Dec 2017 19:59:15 +0100, Markus Koschany wrote:

(Just as a side note, I'm in favour of adding more licenses to
common-licenses):

> Take a stopwatch,
> find a plain-text version of this license on the internet, format the
> file according to copyright format 1.0 and stop the time.

% time cme modify dpkg-copyright 'License:"AGPL-3"' -save 
cme: using Dpkg::Copyright model
License AGPL-3 is not used in Files: section
License AGPL-3 is not used in Files: section
Warning in 'License': Unused license: AGPL-3

Changes applied to dpkg-copyright configuration:
- License: added entry AGPL-3

cme modify dpkg-copyright 'License:"AGPL-3"' -save  0.95s user 0.04s system 99% 
cpu 0.990 total


(Admittedly it doesn't work or needs different runes for AGPL-3+.)


If you have the file lying around:

% time cme run paste-license  --arg license=AGPL-3+ --arg file=AGPL-3.0 
cme: using Dpkg::Copyright model
License AGPL-3+ is not used in Files: section

Changes applied to dpkg-copyright configuration:
- License: added entry AGPL-3+
- License:"AGPL-3+" text has new value: ' Copyright (C) 2007 Free 
Software Foundation, Inc. <[...]'

cme run paste-license --arg license=AGPL-3+ --arg file=AGPL-3.0  0.93s user 
0.03s system 99% cpu 0.957 total



Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Pink Floyd: The Great Gig In The Sky


signature.asc
Description: Digital Signature

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

[gregor herrmann]

On Sun, 22 Jul 2018 11:35:48 +0800, Sean Whitton wrote:

> > +If an upstream release notes file is available, containing a summary
> > +of changes between upstream releases intended for end users of the
> > +package and often called ``NEWS``, it should be accessible as
> > +``/usr/share/doc/package/NEWS.gz``.  An older practice of installing
> > +the upstream release notes as ``/usr/share/doc/package/changelog.gz``
> > +is permitted but deprecated.
> > +
> > +If there is no release notes file available, but there is an upstream
> > +changelog, it should be accessible as
> > +``/usr/share/doc/package/changelog.gz``.  If there are both upstream
> > +release notes and an upstream changelog available, it is recommended
> > +to install the former but not the latter.

Let me see if I got this right, and apply it to the typical pkg-perl
package:

CPAN distributions usually contain no NEWS file, and do contain a
Changes/ChangeLog/... file which is "an upstream release notes file"
per the above definition (hand-written by the upstream maintainer,
targetted at end users). (Numbers in message #65 in this bug report.)

Currently we (i.e. typically dh_installchangelogs) install this
Changes file as /usr/share/doc/package/changelog.gz. In the future
we'd need to install it as /usr/share/doc/package/NEWS.gz; or still
as changelog.gz if we can live with the deprecation (will this be
allowed "forever"?).

Did I get this right so far?

If we want to install it as NEWS.gz we either have a tremendous
amount of work or we can wait for dh_installchangelogs to grow some
magic to do it for us (pr provide patches of course :)). And then
probably everyone who knows CPAN habits and/or has used Debian in the
last 25 years will still be at least slightly confused.

If we continue to install it as changelog.gz we hit the "deprecated"
case, and we might confuse other users, who - as per the change above
- expect changelog.gz to be the source-level changelog.


As written in message #140 in December, I still think we have two
questions: which kind of files to install, and under which names.
I think there's consensus for the first one, and this is expressed
well in this patch. As for the second one, I have to admit that (if
I'm reading the patch correctly) I'm still not happy of this forced
rename of (CPAN) ChangeLogs to (GNU) NEWS.gz ...


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   BOFH excuse #421:  Domain controller not responding 

Bug#904608: Support specifying upstream VCS location in debian/control

[gregor herrmann]

On Wed, 25 Jul 2018 18:20:52 -0700, Jonathan Nieder wrote:

> > In fact, there is: the Repository field in debian/upstream/metadata.[1]
> 
> Neat!
> 
> I would have expected to find this information in debian/copyright.  The
> Source field there sometimes names an upstream VCS but isn't required to
> do so; I'd be in favor of some tightening of the requirements in
> copyright-format based on how packages in the archive have been using
> the field (for example, encouraging a list of lines each of which has
> the same format as Vcs-* fields).

Just sharing my experience (pkg-perl again :)):
We're tracking upstream VCS (well, just Git) locations since about 4
years. The default is to record them in debian/upstream/metadata. [0]
That was based on the simple fact that there was a specification for
it (with the Repository: key) and that writing and reading YAML is
trivial.
A group of packages uses the Source field in debian/copyright, which
in my experience is a bit of a pain since parsing out the Git
location from a list of URLs in a multiline field is not trivial.

Summary: I'm a happy consumer of upstream git locations, I'm all for
standardizing, keeping debian/upstream/metadata is easiest for us; if
we decide on anything else, be it d/control or d/copyright, then I
very much suggest to use a new single unambiguous field for the
information.
 

Cheers,
gregor

[0]
And we've built tools around it, as dpt subcommands.

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Beny More: Que Bueno Baila Usted


signature.asc
Description: Digital Signature

Bug#883950: Next steps on "[GPL-3+]" proposal

[gregor herrmann]

On Thu, 02 Aug 2018 15:13:26 +0800, Markus Koschany wrote:

> Nothing will break because no tool besides Lintian checks
> debian/copyright for copyright format 1.0 compatibility. 

This is not correct.

There are at least cme (with libconfig-model-dpkg-perl), decopy,
probably some of licensecheck/license-reconcile/cdbs (or whatever
consumes copyright_hints), dh-make-perl refresh,
libdebian-copyright-perl, and probably others which check and/or
create/update copyright-format 1.0 files.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: In A Little While


signature.asc
Description: Digital Signature

Bug#904248: Beginnings of a patch to add netbase to build-essential

[gregor herrmann]

On Fri, 12 Oct 2018 13:45:06 +0200, Mattia Rizzolo wrote:

> I think we also need a wider request for /etc/services and
> /etc/protocols.  Till now I only heard Ian asking for it, so I believe
> there needs to be a wider request.

As a data point: I've seen interesting test failures that were caused
by a missing /etc/{services,protocols}, which took me some time to
find out the cause. Since I became aware of the issue, trying to add
netbase as a build dependency happens much faster :)

In general I have no strong opinion but having netbase in
build-essential would for sure have saved me and probably others some
time. 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: The Land Of Plenty


signature.asc
Description: Digital Signature

Re: Keeping master releaseable without posting to d-d-a

[gregor herrmann]

On Sat, 27 Oct 2018 12:51:53 -0700, Sean Whitton wrote:

> This might mean we have to manually merge d/changelog, but I think
> that's a reasonable price to pay.

As a side note: merging d/changelog works reasonably well with
dpkg-mergechangelogs(1). 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: Stay (Faraway, So Close!)


signature.asc
Description: Digital Signature

Bug#850171: Recommend that manpages contain an EXAMPLES section

[gregor herrmann]

On Sat, 03 Nov 2018 14:00:51 -0700, Sean Whitton wrote:

> Hence I am seeking seconds for this patch I've written:
> 
> diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
> index e990f34..a9b297f 100644
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -61,6 +61,12 @@ by a note at the beginning of the manual page or by 
> showing the missing
>  or changed portions in the original language instead of the target
>  language.
> 
> +It is recommended that manual pages contain an EXAMPLES section,
> +containing working syntax that uses the functionality documented by
> +the manual page.  For example, command-line invocations of a utility
> +for some of its standard usages, or an example call to an API
> +function.
> +
>  .. _s12.2:
> 
>  Info documents

No objections from me, just 2 nits:

- The typical .3pm manpage (for perl modules) doesn't contain an
  EXAMPLES section but contains working and copypastable code in the
  SYNOPSIS section. [0]
- I'm not really convinced that a "duty" to patch upstream manpages
  in order to add EXAMPLE sections, which would follow from this
  recommendation, is sustainable or desirable …


Cheers,
gregor


[0] If you're interested in an amendment, maybe:
"It is recommended that manual pages contain examples of working
syntax that uses the functionality documented by the manual page.  For
example, …"

or

"It is recommended that manual pages contain examples of working
syntax, e.g. in an EXAMPLES section, that uses the functionality
documented by the manual page.  For example, …"

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Billy Joel: Captan Jack


signature.asc
Description: Digital Signature

Bug#913659: Document that not all bugs are policy violations

[gregor herrmann]

On Tue, 13 Nov 2018 19:11:02 -0700, Sean Whitton wrote:

> On Tue 13 Nov 2018 at 05:51PM GMT, Ian Jackson wrote:
> > I suggest adding something like this to s1.1, "Scope", as a new 3rd
> > paragraph:
> >
> >   This manual cannot and does not prohibit every possible bug or
> >   undesirable behaviour.  The fact that something is not forbidden by
> >   Debian policy does not mean that it is not a bug, let alone that it
> >   is desirable.  Questions not covered by policy should be evaluated
> >   on their merits.
> 
> Good idea.
> 
> This seems strictly informative rather than normative, but I'd like to
> see some reviews/seconds so that we can confirm that this is how the
> wider project understands the role of the Policy Manual.
> 
> (If no seconds but also no objections are forthcoming, I'll just apply
> it as an informative change.)

This sounds good to me.
I concur that this is probably just informative but in case it's
considered normative: 'seconded'. 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Treibhaus: Gianni Coscia/Glianluigi Trove


signature.asc
Description: Digital Signature

Bug#850156: Patch implementing CTTE decision

[gregor herrmann]

On Sat, 17 Nov 2018 09:14:52 -0700, Sean Whitton wrote:

> Seeking seconds:
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 3c6c9d5..821010f 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -787,6 +787,13 @@ according to this convention, the C source code of an 
> executable
>  ``checksum/util`` is to be located at
>  ``debian/missing-sources/checksum/util.c``.
> 
> +Vendor-specific patch series
> +
> +
> +Packages in the Debian archive using the 3.0 (quilt) source package
> +format should not contain a non-default series file.  That is, there
> +should not exist a file ``debian/patches/foo.series`` for any ``foo``.
> +
>  .. [#]
> Rationale:
> 
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index 70b31bd..97ae91a 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -56,6 +56,11 @@ Unreleased.
>  Required targets must not write outside of the unpacked source
>  package tree, except for TMPDIR (or /tmp if that is not set).
> 
> +4.17
> +Packages should not contain a non-default series file.  That is,
> +dpkg's vendor-specific patch series feature should not be used for
> +packages in the Debian archive.
> +
>  10.1
>  Binaries should be stripped using
>  ``strip --strip-unneeded --remove-section=.comment 
> --remove-section=.note``
> 

As this simply implements the ctte decision in #850156:
seconded.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Astrud Gilberto: The Girl From Ipanema


signature.asc
Description: Digital Signature

Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus

[gregor herrmann]

On Fri, 07 Dec 2018 19:26:50 -0700, Sean Whitton wrote:

> Thanks.  Seeking seconds:
> 
> diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
> index ab2662e..f7626ef 100644
> --- a/virtual-package-names-list.yaml
> +++ b/virtual-package-names-list.yaml
> @@ -106,6 +106,10 @@ virtualPackages:
> description: anything that is capable of controlling an UPS
>   - name: cron-daemon
> description: Any cron daemon that correctly follows policy requirements
> + - name: dbus-session-bus
> +   description: provides the D-Bus well-known session bus for most or all 
> user login sessions
> + - name: default-dbus-session-bus
> +   description: Debian's preferred implementation of dbus-session-bus, 
> possibly architecture-specific
> 
>  # Documentation
> 
> @@ -435,3 +439,7 @@ virtualPackages:
>  # virtual-mysql-server-core
>  # virtual-mysql-testsuite
>  #   08 Jan 2017 Added adventure
> +#
> +# Sean Whitton:
> +#   xx Dec 2018 Added dbus-session-bus
> +#   Added default-dbus-session-bus
> 

This looks all good to me, hence: seconded.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Uriah Heep: Stealin'


signature.asc
Description: Digital Signature

Bug#798476: Heads-up: new lintian error: no-human-maintainers

[gregor herrmann]

On Mon, 22 Apr 2019 15:13:35 +, Holger Levsen wrote:

> On Sat, Apr 20, 2019 at 11:02:49PM +0200, Cyril Brulebois wrote:
> > My personal policy regarding this (carried over from my X.Org days) is
> > to ignore it entirely; I see no gain in having specific people being
> > listed in Uploaders. Feel free to do the same when you're about to
> > upload a package with pending l10n changes, or with various bug fixes
> > that were awaiting an upload in git…
> I've not really made up my mind of what I think about the general case,
> I do think there are some merrits knowing/documenting human maintainers.
> I also do think that this doesnt make that much sense for d-i packages.
> (And I also think that policy should be changed (and not merely ignored) 
> if we find that we disagree with whats written in it.)
> Shall I file a bug against debian-policy?

/me has a déjà-vu … We've discussed thhis before, the last time I
remember was during DebCamp/Conf17 in Montréal.

Ah, here we go: #798476


Cheers,
gregor, cc'ing the bug

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Aimee Mann: I've Had It


signature.asc
Description: Digital Signature

Bug#761219: debian-policy: document versioned Provides

[gregor herrmann]

On Thu, 20 Jun 2019 11:00:58 +0100, Sean Whitton wrote:

> On Fri 07 Jun 2019 at 10:50AM +01, Dominic Hargreaves wrote:
> 
> > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
> > index 1d790e8..3b68420 100644
> > --- a/policy/ch-relationships.rst
> > +++ b/policy/ch-relationships.rst
> > @@ -17,15 +17,16 @@ package names, separated by vertical bar (pipe) symbols 
> > ``|``. In such a
> >  case, that part of the dependency can be satisfied by any one of the
> >  alternative packages.  [#]_
> >
> > -All of the fields except for ``Provides`` may restrict their
> > -applicability to particular versions of each named package. This is done
> > -in parentheses after each individual package name; the parentheses
> > -should contain a relation from the list below followed by a version
> > -number, in the format described in :ref:`s-f-Version`.
> > +All of the fields may restrict their applicability to particular versions
> > +of each named package. This is done in parentheses after each individual
> > +package name; the parentheses should contain a relation from the list
> > +below followed by a version number, in the format described in
> > +:ref:`s-f-Version`.
> >
> >  The relations allowed are ``<<``, ``<=``, ``=``, ``>=`` and ``>>`` for
> >  strictly earlier, earlier or equal, exactly equal, later or equal and
> > -strictly later, respectively.  [#]_
> > +strictly later, respectively. The exception is the Provides field, for
> > +which only ``=`` is allowed.  [#]_
> >
> >  Whitespace may appear at any point in the version specification subject
> >  to the rules in :ref:`s-controlsyntax`, and must appear
> > @@ -446,17 +447,43 @@ they can say:
> >  and the ``bar-plus`` package will now also satisfy the dependency for
> >  the ``foo`` package.
> >
> > -If a relationship field has a version number attached, only real
> > -packages will be considered to see whether the relationship is satisfied
> > -(or the prohibition violated, for a conflict or breakage). In other
> > -words, if a version number is specified, this is a request to ignore all
> > -``Provides`` for that package name and consider only real packages. The
> > -package manager will assume that a package providing that virtual
> > -package is not of the "right" version. A ``Provides`` field may not
> > -contain version numbers, and the version number of the concrete package
> > -which provides a particular virtual package will not be considered when
> > -considering a dependency on or conflict with the virtual package name.
> > -[#]_
> > +A ``Provides`` field may contain version numbers, and such a version number
> > +will be considered when considering a dependency on or conflict with the
> > +virtual package name.  [#]_ For example, given the following packages:
> > +
> > +::
> > +
> > +Package: foo
> > +Depends: bar (>= 1.0)
> > +
> > +Package: bar
> > +Version: 0.9
> > +
> > +Package: bar-plus
> > +Provides: bar (= 1.0)
> > +
> > +the ``bar-plus`` package will again satisfy the dependency for
> > +the ``foo`` package with the virtual package name.  [#]_ If the 
> > ``Provides``
> > +field does not specify a version number, it will not satisfy versioned
> > +dependencies or violate versioned ``Conflicts`` or ``Breaks``. For example,
> > +given the following packages:
> > +
> > +::
> > +
> > +Package: foo
> > +Depends: bar (>= 1.0)
> > +
> > +Package: bar
> > +Version: 0.9
> > +
> > +Package: bar-plus
> > +Provides: bar (= 1.0)
> > +
> > +Package: bar-clone
> > +Provides: bar
> > +
> > +the ``bar-plus`` package will satisfy the dependency for the ``foo``
> > +package, but the ``bar-clone`` package will not.
> >
> >  To specify which of a set of real packages should be the default to
> >  satisfy a particular dependency on a virtual package, list the real
> > @@ -670,10 +697,8 @@ dependencies.
> > together and then configured in their dependency order.
> >
> >  .. [#]
> > -   It is possible that a future release of ``dpkg`` may add the ability
> > -   to specify a version number for each virtual package it provides.
> > -   This feature is not yet present, however, and is expected to be used
> > -   only infrequently.
> > +   This functionality was introduced in dpkg 1.17.11 and newer and
> > +   full support has been provided in the Debian archive since 2018.
> >
> >  .. [#]
> > To see why ``Breaks`` is normally needed in addition to ``Replaces``,
> 
> Seconded.  Thank you again.

Seconded as well.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: With our Without You


signature.asc
Description: Digital Signature

Re: Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[gregor herrmann]

On Mon, 22 Jul 2019 20:54:29 +0100, Ian Jackson wrote:

> > Unfortunately , doing something extensible within the field requires adding
> > a separator, which in turn requires dealing with escaping, and thus is
> > kind of a mess.  Given that, what if you instead used two fields:
> > 
> > Git-Tag-Info: fingerprint=FINGERPRINT
> > Git-Tag-Tagger: Firstname Surname 
> 
> This LGTM if other people like the look.

I wonder if just

Git-Tag-Fingerprint: FINGERPRINT

for the first field might be not only simpler but also enough?
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#944296: debian-policy: Source provenance requirement is WET

[gregor herrmann]

On Thu, 07 Nov 2019 09:00:29 -0800, Russ Allbery wrote:

> > IMO, ideally the requirement in policy would be lifted by clarifying
> > that the information should be provided in *either* debian/copyright
> > or debian/watch.
> 
> Personally, I usually find they're not the same thing.  debian/watch wants
> a very specific technical URL (the path to the download location), whereas
> I usually use the Source file to specify a higher-level view of the
> project.
> 
> That's not an argument against your point that this is duplicative; it's
> just that I find Source to more normally duplicate Homepage in
> debian/control than duplicate debian/watch.

Just as an additional data point: For the average perl package, the
URL is the same in all three places (Homepage in d/control, Source in
d/copyright, and d/watch). [0]
Not a big deal, especially since we handle this mostly automatically,
but still this triplication (is this a word?) doesn't make too much
sense.
 
> I'm in favor of dropping this information from debian/copyright and
> instead writing some language saying that packages should include this
> information in Homepage in debian/control and, if there's a substantial
> non-obvious difference between the package home page and how to download
> it, put download information in debian/watch.

Sounds good to me.


Cheers,
gregor 


[0] https://metacpan.org/release/Foo-Bar

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Soluna Samay: Sing Out Loud


signature.asc
Description: Digital Signature

Bug#904246: developers-reference: section 6.4 should recommend command -v, not which

[gregor herrmann]

On Sat, 16 Nov 2019 18:58:12 +0100, Holger Levsen wrote:

> > Additionally see the discussion in #747320, where Jakub Wilk does point
> > out that maintainer scripts may assume /usr is mounted, so I'm not sure
> > about this.
> how is it relevant if /usr is mounted? if its not, both 'which' and '-v' can
> fail...

`command' is a shell builtin (at least for dash, bash, zsh).

(Interestingly `which' seems to be a shell builtin in zsh; but not in
bash or dash where /usr/bin/which is used.)

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Donovan: Remember the Alamo


signature.asc
Description: Digital Signature

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[gregor herrmann]

On Sun, 17 Nov 2019 17:01:21 -0700, Sean Whitton wrote:

> On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote:
> > How about:
> >
> > This field should only be used when there are license or DFSG
> > requirements to retain the referenced source package.  It should not
> > be added solely as a way to locate packages that need to be rebuilt
> > against newer versions of their build dependencies.
> 
> Thanks, I think this is good -- would be good to hear from Nicholas too
> though.

(Not Nicholas but) As a non-native speaker I think that's clear and
easy to read.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Koko Taylor: Wang Dang Doodle


signature.asc
Description: Digital Signature

Bug#959909: debian-policy: complete implementation of ctte decision to forbid vendor-specific series files

[gregor herrmann]

On Wed, 06 May 2020 13:28:53 -0700, Sean Whitton wrote:

> Quoting from #904302:
> 
> > The Committee therefore resolves that:
> >
> > 1. Any use of dpkg's vendor-specific patch series feature is a bug for
> >packages in the Debian archive (including contrib and non-free).
> >
> >This should be implemented in Debian Policy by declaring that a
> >package SHOULD NOT contain a non-default series file.
> >
> > 2. After Buster is released, use of the vendor-specific patch series
> >feature is forbidden in the Debian archive.
> >
> >This should be implemented in Debian Policy by declaring that a
> >package MUST NOT contain a non-default series file.
> 
> Here is a patch to finish implementing this; I am seeking seconds:
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 1a4e871..58da61e 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -811,8 +811,8 @@ Vendor-specific patch series
>  
> 
>  Packages in the Debian archive using the 3.0 (quilt) source package
> -format should not contain a non-default series file.  That is, there
> -should not exist a file ``debian/patches/foo.series`` for any ``foo``.
> +format must not contain a non-default series file.  That is, there
> +must not exist a file ``debian/patches/foo.series`` for any ``foo``.
> 
>  .. [#]
> Rationale:
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index 2a8cc99..cae05c7 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -39,6 +39,18 @@ The sections in this checklist match the values for the
>  except in the two anomalous historical cases where normative
>  requirements were changed in a minor patch release.
> 
> +Version 4.5.1
> +-
> +
> +Unreleased.
> +
> +4.17
> +Packages must not contain a non-default series file.  That is,
> +dpkg's vendor-specific patch series feature must not be used for
> +packages in the Debian archive.
> +
> +(previously a "should not")
> +
>  Version 4.5.0
>  -
> 


Seconded.


Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: La Tresca: Caravanserraglio


signature.asc
Description: Digital Signature

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[gregor herrmann]

On Fri, 23 Sep 2022 01:03:28 +0200, Guillem Jover wrote:

> In the end nothing will match exactly, and we need to choose some
> terminology. In this case, as previously mentioned, «stanza» has the
> good properties of not usually applying to prose, being short, distinct
> from the other terms and the less ambiguous of them all. It also makes
> constructing sentences to describe things less cumbersome.

FWIW, and knowing this is not a popularity vote, as yet another
non-native speaker-with a different first language-I also like
"stanza" and agree with Guillem's arguments.

Additionally I'd like to mention that also some software uses this
term:

/usr/share/perl5/Debian/Control/Stanza
/usr/share/perl5/Debian/Control/Stanza.pm
/usr/share/perl5/Debian/Control/Stanza/Binary.pm
/usr/share/perl5/Debian/Control/Stanza/CommaSeparated.pm
/usr/share/perl5/Debian/Control/Stanza/Source.pm
/usr/share/perl5/Debian/Copyright/Stanza
/usr/share/perl5/Debian/Copyright/Stanza.pm
/usr/share/perl5/Debian/Copyright/Stanza/Files.pm
/usr/share/perl5/Debian/Copyright/Stanza/Header.pm
/usr/share/perl5/Debian/Copyright/Stanza/License.pm
/usr/share/perl5/Debian/Copyright/Stanza/OrSeparated.pm

(That's dh-make-perl and libdebian-copyright-perl. Also
libparse-debcontrol-perl talks about "stanzas" in its documentation.)
 

Cheers
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#609160: DEP5: CANDIDATE and ready for use in squeeze+1

[gregor herrmann]

On Sat, 15 Jan 2011 23:38:12 +0100, Stefano Zacchiroli wrote:

> I still don't get how the versioned Format URL will look like once DEP5
> will be shipped by debian-policy though. Would it use the Vcs-Browser of
> the debian-policy package or ...? Just curious.

From the attached diff in the first message in #609160:

+ * **`Format`**
+   * Required
+   * Syntax: single line
+   * URI of the format specification, such as:
+ * http://www.debian.org/doc/standards/copyright-format/1.0.html


Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Rod Stewart


signature.asc
Description: Digital signature

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

[gregor herrmann]

On Sat, 15 Jan 2011 18:17:03 -0800, Russ Allbery wrote:

> I think it might be okay to make the indication of the origin of the
> upstream source in debian/copyright optional *if* Homepage clearly
> provides the same information for that package.  (Note: this will not be
> the case for all packages with a Homepage setting, since in some cases
> it's hard or impossible to figure out how to get the upstream source when
> starting from the URL in Homepage.)

I agree. I think it's definitively helpful to quickly see where the upstream
code comes from.

What is boring (like for all CPAN modules) is to have the very same
information in 3 places (copyright, control, watch), therefore I'd
support a change like you sketched above ("may be skipped if Homepage
is clear enough") or maybe also "if uscan just works and d/watch is
sufficiently clear" (not a proper wording for Policy but as a rough
idea).


Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Red Hot Chili Peppers: Wet Sand


signature.asc
Description: Digital signature

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

[gregor herrmann]

On Sun, 16 Jan 2011 08:14:06 +, Julian Gilbey wrote:

> > maybe also "if uscan just works and d/watch is
> > sufficiently clear" (not a proper wording for Policy but as a rough
> > idea).
> Not the latter please: it is not useful if you only have the binary
> package installed but not the source.

Good point, thanks.

Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Bruce Springsteen & The E Street Band: Atlantic City


signature.asc
Description: Digital signature

Bug#610298: phasing out tar-in-tar in source packages

[gregor herrmann]

On Mon, 17 Jan 2011 19:29:42 +0100, Luk Claes wrote:

> > tar-in-tar source packages, i.e. Debian source packages which contains 
> > upstream
> > sources in compressed form and uncompress them on the fly during the build
> > process, are a bit of a PITA. 

Indeed, they are -- we have a couple in the pkg-perl group.

> There are a couple of reasons for tar-in-tar source packages that I
> remember coming across: multiple upstream sources combined as one Debian
> source package, 

And we have them for this reason; or put otherwise, we'd like to get
rid of them which requires at least one of two things:
- ftp-masters accept very small packages (which they have declined to
  do in the past, a recent request for the current policy is #606411)
- build tools provide a mechanism to build different sub-packages
  separately. dpkg with source format v3 alone does not help here (beyond
  unpacking etc. the tarballs), http://packages.qa.debian.org/pkg-components
  is a first step but still very "young" [0]


I don't mind deprecating bundles with tarballs but just recommending
against them is not enough to make them go away :)


Cheers,
gregor


[0]
cf. also
http://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/#comments
http://lists.debian.org/debian-devel/2010/09/msg00208.html
http://lists.debian.org/debian-devel/2010/09/msg00411.html
etc.
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Tori Amos: Yes, Anastasia


signature.asc
Description: Digital signature

Bug#610298: phasing out tar-in-tar in source packages

[gregor herrmann]

On Thu, 20 Jan 2011 11:39:26 +0100, Stefano Zacchiroli wrote:

> On Mon, Jan 17, 2011 at 08:24:25PM +0100, gregor herrmann wrote:
> > And we have them for this reason; or put otherwise, we'd like to get
> > rid of them which requires at least one of two things:
[..]
> > I don't mind deprecating bundles with tarballs but just recommending
> > against them is not enough to make them go away :)
> That is of course a very good point. However, even this argument seems
> to be orthogonal to my proposal, in the following sense. *If* ftpmaster
> disallow too small packages, you need a technical way to coalesce
> several small upstream tarballs into a single Debian source
> package. That is something which you can do with source formats 3.0, so
> you would have a way to adhere to a SHOULD requirement against
> tar-in-tar. What am I missing here?

Nothing technically; maybe you overlooked my implicit point that
replacing a huge PITA (tar-in-tar plus home-grown building scripts)
with a lesser PITA (unpacked tarballs plus an evolving build system
that still won't overcome the fundamental problems of bundles)
doesn't look like a huge benefit to me :)

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Sting: If You Love Somebody Set Them


signature.asc
Description: Digital signature

Re: re buildd's resolver and package's build deps

[gregor herrmann]

On Tue, 22 Feb 2011 17:08:18 +, Roger Leigh wrote:

> · Standard alternative use in the form "concrete|virtual", as used for
>   normal deps on virtual packages.  Is this sensible?
> · Architecture-specific dependencies
> · Broken uses.  Dependencies on multiple different libraries which will
>   lead to inconsistent builds.  This affects only a tiny minority of
>   packages.  The most obviously broken one I found is already fixed.
 
> · Pointless and/or broken
[..]
>   perl (>= 5.10) | libmodule-build-perl

Could you please explain what's "pointless and/or broken" about that
one?

(Except that it's old since even lenny has 5.10.0. More recent
exmples:
perl (>= 5.10.1) | libtest-simple-perl (>= 0.88)
perl (>= 5.12.3) | libmodule-build-perl (>= 0.3601)
etc.)

> My take on this is that anything other than arch-specific alternatives
> should be strongly discouraged, if not outright banned, and that this
> should be put into Policy.  Alternative viewpoints, with examples and
> rationale would be useful to hear.

For perl packages: if Module::Build, Test::More, etc. (as dual-lifed
modules) are in two packages, I see no point in not allowing them
both. And this makes backporting, building "at home" etc. easier.
 

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Police: King Of Pain


signature.asc
Description: Digital signature

Re: [buildd-tools-devel] re buildd's resolver and package's build deps

[gregor herrmann]

On Tue, 22 Feb 2011 22:28:05 +, Roger Leigh wrote:

> > >   perl (>= 5.10) | libmodule-build-perl
> > Could you please explain what's "pointless and/or broken" about that
> > one?
> > (Except that it's old since even lenny has 5.10.0.
> Yes, that's exactly the reason.  Because the perl (>= 5.10) is
> satisfied under all circumstances, the libmodule-build-perl
> alternative is entirely redundant.

Right, and we (as in the pkg-perl team) update those routinely when
we do new uploads for newer upstream releases or bugfixes.
 
> > perl (>= 5.10.1) | libtest-simple-perl (>= 0.88)
> > perl (>= 5.12.3) | libmodule-build-perl (>= 0.3601)
> These are more recent, but even for these cases the versioned
> perl dependency without the alternative is entirely adequate for
> building purposes.

Depends on the target -- the second example would only build with the
perl version from experimental. It's a way to achieve:
- avoid installing libmodule-build-perl if someone has already perl
  5.12 on their machine
- prepare for the perl 5.12 move to unstable  
 
> > For perl packages: if Module::Build, Test::More, etc. (as dual-lifed
> > modules) are in two packages, I see no point in not allowing them
> > both. And this makes backporting, building "at home" etc. easier.
> That's definitely something we should not be making harder.  One
> problem with the alternatives is bitrot though, if they are just
> left.  They should be actively tested, and dropped eventually.

Agreed, that "cleanup" needs to be part of the maintainance routine.

> For the examples above, it definitely makes sense for backporting.
> For others, it's not quite so useful.

Ok, I can agree on that, too :)


Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Big Bill Broonzy: How do you want it done


signature.asc
Description: Digital signature

Bug#587991: perl-policy: /etc/perl missing from Module Path

[gregor herrmann]

On Fri, 04 Mar 2011 20:15:28 -0600, Jonathan Nieder wrote:

> I see this has been seconded by
> 
>  Niko Tyni  (message #25)
> 
> and I imagine that Russ might be willing to second this, but that
> still leaves us one DD short[1].  Seconds?  Objections?
> Clarifications?

> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index b9f3277..b41342d 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -128,17 +128,27 @@
>
>   Module Path
>   
> -   Perl searches three different locations for modules, referred
> -   to in this document as core in which modules
> -   distributed with Perl are installed, vendor for
> -   packaged modules and site for modules installed by
> -   the local administrator.
> +   Perl searches four different locations for modules, referred to
> +   in this document as etc for system configuration
> +   modules, core in which modules distributed with Perl
> +   are installed, vendor for packaged modules,
> +   and site for modules installed by the local
> +   administrator.
>   
>   
> The module search path (@INC) in the Debian packages
> has been ordered to include these locations in the following
> order:
> 
> + etc
> + 
> +   
> + Configuration modules (see ).
> + 
> +/etc/perl
> + 
> +   
> + 
>   site (current)
>   
> 
> @@ -393,6 +403,17 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
> 
>   
>
> +
> +  
> + Configuration Modules
> + 
> +   Some Perl packages load system-wide configuration from a
> +   dedicated Perl module whose purpose is solely to contain
> +   configuration settings.  The module often contains only variable
> +   settings.  Such modules should be treated as configuration files
> +   and installed under /etc/perl.
> + 
> +  
>  
>  
>  


Seconded.


Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Tracy Chapman: Subcity


signature.asc
Description: Digital signature

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

[gregor herrmann]

On Mon, 04 Apr 2011 12:40:01 -0700, Russ Allbery wrote:

> I think this is an interesting conversation, but so far as I can tell it's
> not particularly relevant to Policy.  There are no such packages with
> those version numbers currently in Debian, so Policy can simply say that
> there will never be in the future either and be done with it.

There is (or better: was) cnews, in etch and lenny, with
cr.g7-40.{1,4}.

I noticed this because of
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 
699262 package 'cnews':
 error in Version string 'cr.g7-40.4': version number does not start with 
digit
each time I build a package (maybe I should just remove oldstable
from my sources.list at some point :))
 
(Just as a side note, and not relevant for policy.)


Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Tom Waits: Innocent When You Dream


signature.asc
Description: Digital signature

Bug#619275: Perl Policy change to document major version upgrade trigger

[gregor herrmann]

On Sat, 28 May 2011 21:53:52 +0200, Bill Allombert wrote:

> Is there progress on the implementation of this feature ?

It's in perl 5.12.3 since the upload to unstable:

http://lists.debian.org/debian-devel-announce/2011/05/msg6.html
 

Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Van Morrison: Ain't No Sunshine


signature.asc
Description: Digital signature

Bug#619275: Perl Policy change to document major version upgrade trigger

[gregor herrmann]

On Mon, 06 Jun 2011 19:50:20 +0200, Bill Allombert wrote:

> > > Is there progress on the implementation of this feature ?
> > It's in perl 5.12.3 since the upload to unstable:
> > http://lists.debian.org/debian-devel-announce/2011/05/msg6.html
> So are you seconding this policy amendment ?

If Niko and Dominic are happy with the implementation and the wording
(Niko seemed a bit hesitant in message #37 -- that's why I'm asking if
this is all settled in the meantime), I'm happy to second the
proposal.

Cheers,
gregor

-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Alanis Moristte: That I Would Be Good


signature.asc
Description: Digital signature

Bug#619275: Perl Policy change to document major version upgrade trigger

[gregor herrmann]

On Mon, 06 Jun 2011 21:13:06 +0100, Dominic Hargreaves wrote:

> >From 87c527dce3a9f8dcaca7cf43f830ce9ff178f4e6 Mon Sep 17 00:00:00 2001
> From: Dominic Hargreaves 
> Date: Tue, 22 Mar 2011 16:11:29 +
> Subject: [PATCH] Describe the Perl upgrade trigger
> 
> ---
>  perl-policy.sgml |   20 
>  1 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index b9f3277..70c5bfc 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -461,6 +461,26 @@ perl -MExtUtils::Embed -e ldopts
> package must depend upon it explicitly.
>   
>
> +
> +  
> +Perl Package Upgrades
> +
> +  Starting from perl 5.12.3-2, a dpkg trigger
> +  named perl-major-upgrade will be triggered by the
> +  postinst of the perl package during major
> +  upgrades. Some examples of things which constitute a major upgrade
> +  are an upgrade which would change the value of versioned
> +  directories in @INC, or one which changes 
> abiname.
> +  Any package may declare an interest in the trigger, especially
> +  packages including long-running daemons which would stop working
> +  until restart.
> +
> +
> +  It is suggested that such packages include an appropriate section
> +  in their postinst to handle the trigger by restarting relevant
> +  daemons or notifying users of further action.
> +
> +  
>  
>  
>  


Seconded.

(And thanks for your work, Dominic and Niko.)

Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Janis Joplin: Half Moon


signature.asc
Description: Digital signature

Bug#640737: [copyright-format] Format URL and installation on www.debian.org

[gregor herrmann]

On Mon, 21 Nov 2011 09:33:57 +0900, Charles Plessy wrote:

> Le Mon, Oct 31, 2011 at 04:58:37PM -0400, David Prévot a écrit :
> > Le 22/10/2011 10:57, Charles Plessy a écrit :
> > > Le Sat, Oct 08, 2011 at 06:27:15PM +0900, Charles Plessy a écrit :
> > >>
> > >> So I propose to do the following, in line with the other propositions.
> > >>
> > >>  a) Apply the attached patch to point at 
> > >> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ in the 
> > >> spec.
> > > 
> > > I overlooked README.org, which was missing from the patch.  Here is an 
> > > updated
> > > one.  Comments or seconds are welcome.
> > 
> > Seconded, thanks for working on that.
> 
> one more developer seconding the use of the above URL, that is, expressing not
> only his own approbation but also his feeling that it reflects a broad
> consensus, and we can close the issue.

[I'm still a bit confused by the need to second a URL, but FWIW:]

This proposal is fine with me, so: seconded.
 

Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - OpenPGP key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Sting: Roxanne


signature.asc
Description: Digital signature

Bug#641071: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken

[gregor herrmann]

On Sat, 10 Sep 2011 14:12:31 +0900, Charles Plessy wrote:

> I attached a patch that corrects or adds links to the SPDX Open Source License
> Registry.

Looks good to me, thanks.
 
Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - OpenPGP key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Beatles


signature.asc
Description: Digital signature

Bug#648387: [copyright-format] English proofreading.

[gregor herrmann]

On Mon, 14 Nov 2011 19:24:21 -0600, Jonathan Nieder wrote:

> For what it's worth, I find the text more readable after JBR's changes
> than before.

Same here.
 

On Sun, 13 Nov 2011 11:01:05 -0600, Jonathan Nieder wrote:

> DEP drivers: do these changes look reasonable to you?  Policy
> delegates: does this require formal seconds, or is it just an
> informative change?

I'm having the same question :) 

(In general I won't dive into the discussion about it's the right
time now to improve the wording or not ... But I hope to see progress
in the near future.)


Cheers,
gregor

-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - OpenPGP key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Joan Baez: Here's to you


signature.asc
Description: Digital signature

Bug#633797: copyright-format: "with exception" underspecified

[gregor herrmann]

On Wed, 16 Nov 2011 20:03:27 +0900, Charles Plessy wrote:

> > I have no objection to this for 1.0, provided we at the same time clarify
> > that if more than one exception is in use, you need to use a custom
> > shortname instead of an ORed or ANDed list of licenses.
> > 
> > Is there a consensus for this position?
> 
> Le Wed, Nov 16, 2011 at 10:49:46AM +0700, Jonas Smedegaard a écrit :
> > Above approach sounds reasonable to me.  Seconded.
> 
> Le Wed, Nov 16, 2011 at 11:38:29AM +0100, Jakub Wilk a écrit :
> > Seconded.

Same here.
 
>
> -Exceptions and clarifications are signaled in plain text, by 
> appending
> -with keywords
> +Exceptions or clarifications are signaled in plain text, by appending
> +with keyword
>  exception to the short name.  This document provides a 
> list of
> -keywords that refer to the most frequent exceptions.
> +keywords that refer to the most frequent exceptions.  In case a 
> license
> +is modified by multiple exceptions or clarifications, a single 
> arbitrary
> +short name must be used.
>

Seconded.


Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - OpenPGP key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Bruce Springsteen: I'm On Fire


signature.asc
Description: Digital signature

Bug#643690: perl policy unclear about the section for manpages

[gregor herrmann]

On Sat, 24 Dec 2011 11:06:31 -0800, Russ Allbery wrote:

> Yes, this tripped me up too.  Here's a proposed patch.  Seconds or further
> discussion?  I'll copy debian-perl as well for further review.


> >From f6938d47f9250f672586191cc00988e9e61cea06 Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Sat, 24 Dec 2011 11:03:49 -0800
> Subject: [PATCH] Clarify the Perl policy documentation rules
> 
> The first section about documentation and manual page extensions
> only applies to packages generated from the perl source package.
> Make that explicit and add a reference to the section discussing
> module packages.
> ---
>  perl-policy.sgml |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index 70c5bfc..626c514 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -197,8 +197,8 @@
> package.
>   
>   
> -   Manual pages distributed with Perl packages must be installed
> -   into the standard directories:
> +   Manual pages distributed with packages built from the perl
> +   source package must be installed into the standard directories:
> 
>   Programs
>   
> @@ -217,6 +217,8 @@
> 
>   
> 
> +   The extensions used for manual pages distributed with module
> +   packages are different.  See .
>   
>
>  

Looks good to me.
Seconded.

Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - OpenPGP key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Arlo Guthrie: Can't Help Falling in Love


signature.asc
Description: Digital signature

Bug#658209: DEP-5: Clarifying copyright/license requirements

[gregor herrmann]

On Wed, 01 Feb 2012 10:14:11 +0900, Charles Plessy wrote:

> would the follwing be sufficient in your opinion ?

Thank you!
 
> --- copyright-format.xml  (révision 252)
> +++ copyright-format.xml  (copie de travail)
> @@ -42,8 +42,11 @@
>automatically extract licensing information.
>  
>  
> -  This is not a proposal to change the policy in the short term.  In
> -  particular, nothing in this proposal supersedes or modifies any of the
> +  This specification is not part of the Debian Policy, and its use is
> +  optional.
> +
> +
> +  Nothing in this proposal supersedes or modifies any of the
>requirements specified in Debian Policy regarding the appropriate 
> detail
>or granularity to use when documenting copyright and license status in
>debian/copyright.

Fine with me.

> @@ -262,10 +265,15 @@
>
>  The declaration of copyright and license for files is done in one or
>  more paragraphs.  In the simplest case, a single paragraph can be 
> used
> -which applies to all files and lists all applicable copyrights and
> -licenses.
> +which applies to the whole package.
>
>
> +Only the license and copyright information required by the Debian
> +archive is required to be listed here.  While the syntax of the Files
> +paragraph allows more information to be provided if one desires, it
> +is totally optional.
> +  
> +  
>  The following fields may be present in a Files paragraph.
>

IMO the "totally optional" is not the best message to send, I think
we rather mean "optional but recommended".
But I think just leaving out the sentence (and merging the first one
with the paragraph before) would be enough:

|
|  The declaration of copyright and license for files is done in one or 
 
|  more paragraphs.  In the simplest case, a single paragraph can be 
used
|  which applies to the whole package.
|  Only the license and copyright information required by the Debian
|  archive is required to be listed here.  
|

Cheers,
gregor

 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: STS: Lass net los


signature.asc
Description: Digital signature

Re: Proposal to update NMU section 5.11.1

[gregor herrmann]

On Tue, 24 Apr 2012 12:34:00 -0400, Chris Knadle wrote:

> For instance, say a potential maintainer picks up an old package to do an NMU 
> on, and updates the version of debhelper from v5 to v8, switches from 1.0 
> format to 3.0 quilt format, and likewise has to make numerous other similar 
> tweaks both to the debian files and patching the upstream source.  Are any of 
> these possibly considered part of packaging style in terms of this section of 
> the Dev Ref?

IMO: yes, to all of these examples.

As I understand it, NMUs should only do the minimal necessary changes
needed to fix a bug (in order to make it easy for the maintainer to
incorporate the diff).

Changing patch systems, debhelper/cdbs/dh, source format etc. would
indeed be sometimes easier for the NMUer, but they are usually not
_necessary_ for solving a problem. This might lead to more work when
preparing an NMU but that's not the main priority.

(For totally outdated packages it might make more sense to think
about getting them orphaned by the MIA team or discussing their
removal.)

And this is only 1) my personal understanding of 2) the current
situation; I might be wrong, and the common interpretation might
change :)
 

In general, I agree that zack's wording _sounds_ more positive towards
NMUs than the language in DevRef at the moment, and I wouldn't mind
if you came up with improvements.

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital signature

Re: Proposal to update NMU section 5.11.1

[gregor herrmann]

On Wed, 25 Apr 2012 09:33:31 +0900, Charles Plessy wrote:

> Talking about improvements, if the following part about NMU acknowledgement is
> obsolete as I think, how about removing it, either as a separate bug, or as
> part of the general refresh of the section that is discussed here.
> 
>   To acknowledge an NMU, include its changes and changelog entry in your next
>   maintainer upload. If you do not acknowledge the NMU by including the NMU
>   changelog entry in your changelog, the bugs will remain closed in the BTS 
> but
>   will be listed as affecting your maintainer version of the package. 

Is this obsolete? In my understanding this is still how the BTS
works; but I might have missed any changes.

Cheers,
gregor, cc'ing owner@
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital signature

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

[gregor herrmann]

On Sat, 23 Jun 2012 00:39:31 -0700, Russ Allbery wrote:

> Policy 12.5 says:
> 
> In addition, the copyright file must say where the upstream sources
> (if any) were obtained, and should name the original authors.
> 
> The last part is not at all clear.  Prior to a recent conversation on
> debian-mentors, I had always assumed that this meant the legal authors,
[..] 
> Similarly, "original" is ambiguous.  I had always assumed that meant
> "upstream," as in the current upstream maintainer,

I agree that "original authors" is not clear, and I've also made the
same assumptions as you. - Getting the ambiguities fixed seems like a
good idea to me.

I'd be happy to either drop the "original author" part [copyright
information is in the first paragraph anyway] or to change it into
something like "optionally the upstream contact information can be
named".

Speaking about the first paragraph

  Every package must be accompanied by a verbatim copy of its
  copyright information and distribution license in the file
  /usr/share/doc/package/copyright.

IIRC the "verbatim copy" has also led to confusion, maybe we could
change it to "accurate" or "complete" or something along these lines.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital signature

Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

[gregor herrmann]

On Tue, 21 Aug 2012 14:34:50 +0200, Andreas Tille wrote:

>   http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 
> --- 8< -
> Files-Excluded
> --
> 
> Whitespace-separated list: list of patterns indicating files removed
> from upstream source.
> 
> # begin copy of Files field description

[..]

> # end copy of Files field description

Wouldn't it be easier to say "Same as ``Files'', except that it may
only occur once."?
 
> The field is optional and should be specified in connection with the
> Source field.
> --- >8 -

This probably belongs into the "Header paragraph (once)" section as
an additional bullet point "Files-Excluded: optional".


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Supertramp: Just Another Nervous Wreck


signature.asc
Description: Digital signature

Bug#685506: copyright-format: new Files-Excluded field

[gregor herrmann]

On Wed, 16 Jan 2013 14:23:17 +0100, Thibaut Paumard wrote:

> On Tue, Aug 21, 2012 at 04:54:13PM +0200, gregor herrmann wrote:
> > This probably belongs into the "Header paragraph (once)" section
> > as an additional bullet point "Files-Excluded: optional".
> I don't agree: I find it better to allow several such paragraphs, when
> the rationale behind removing several files differs, as in this
> real-life example:
> 
> Removed-Files: yorick/lbfgs*
> Rationale: Not DFSG

Ok; that would mean defining a new paragraph type for
Copyright-Format 1.x; adding a field to the Header paragraph can be
tried "for free" before changing the spec.
(Just saying, not that this means we can't do it.)

Currently CF1.0 also says for the Source Field in the Header
paragraph:
"If the upstream source has been modified to remove non-free parts,
that should be explained in this field."
so just using this seems easier.

I guess it boils down to how much detail we need (your "Rationale");
while I understand your point, so far I was quite happy with writing
one free-form line in a (Header) Comment field and be done with it.

Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bruce Springsteen: Atlantic City


signature.asc
Description: Digital signature

Bug#750017: perl-policy: All packages using Perl vendorarch directory need a perlapi-* dependency

[gregor herrmann]

On Sat, 31 May 2014 20:33:48 +0300, Niko Tyni wrote:

> ---
>  perl-policy.sgml | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index c23f7c3..e83c8c5 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -388,13 +388,14 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
>   
>  
>   
> -   Binary Modules
> +   Binary and Other Architecture Dependent Modules
> 
>   Binary modules must specify a dependency on either
>   perl or perl-base with
>   a minimum version of the perl package
> - used to build the module, and must additionally depend on
> - the expansion of
> + used to build the module. Additionally, all modules installed
> + into $Config{vendorarch} (binary or otherwise
> + architecture dependent) must depend on the expansion of
>   perlapi-$Config{debian_abi} using
>   the Config module. If $Config{debian_abi}
>   is empty or not set, $Config{version} must be used.

Seconded.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Ben Weaver: El camino blues


signature.asc
Description: Digital Signature

Bug#750017: perl-policy: All packages using Perl vendorarch directory need a perlapi-* dependency

[gregor herrmann]

On Sun, 01 Jun 2014 09:53:11 -0700, Russ Allbery wrote:

> Niko Tyni  writes:
> > I now realize that this wording unintentionally removes the perlapi
> > requirement for binary modules outside vendorarch (see for instance
> > the amanda-common package, which uses /usr/lib/amanda/perl/).
> 
> > Revised patch attached. The new wording feels a bit awkward but
> > I guess it will do. Improvements and eyeballs welcome, of course.
> 
> Ah, good catch.  The new wording seems fine to me.  Seconded.

Improved wording seconded as well.

Cheers,
gregor
 
> > From: Niko Tyni 
> > Date: Fri, 30 May 2014 14:10:22 +0300
> > Subject: [PATCH] All packages using Perl vendorarch directory need a 
> > perlapi-*
> >  dependency
> 
> > Having $Config{vendorarch} change between Perl major versions (for
> > multiarch or other reasons) implies that packages using it need a strict
> > dependency on those versions of perl-base that have a compatible search
> > path (@INC).
> 
> > The vast majority of these packages are binary ("XS") modules, where we
> > already require a dependency on the virtual package perlapi-*, provided
> > by perl-base. The name of this virtual package will change when the
> > interface between the Perl interpreter and the modules changes.
> 
> > If we consider @INC part of that interface, we can use the existing
> > mechanism also for the few nonbinary modules using $Config{vendorarch}.
> > This is a new requirement that currently affects six packages in
> > the archive.
> > ---
> >  perl-policy.sgml | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> > diff --git a/perl-policy.sgml b/perl-policy.sgml
> > index c23f7c3..12cd82c 100644
> > --- a/perl-policy.sgml
> > +++ b/perl-policy.sgml
> > @@ -388,14 +388,15 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
> > 
> >  
> > 
> > - Binary Modules
> > + Binary and Other Architecture Dependent Modules
> >   
> > Binary modules must specify a dependency on either
> > perl or perl-base with
> > a minimum version of the perl package
> > -   used to build the module, and must additionally depend on
> > -   the expansion of
> > -   perlapi-$Config{debian_abi} using
> > +   used to build the module. Additionally, all binary modules
> > +   (regardless of their installation directory) and any other modules
> > +   installed into $Config{vendorarch} must depend on the
> > +   expansion of perlapi-$Config{debian_abi} using
> > the Config module. If $Config{debian_abi}
> > is empty or not set, $Config{version} must be used.
> >   
> 

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Ludwig Hirsch: Der Turm


signature.asc
Description: Digital Signature

Re: Bug#679751: Lintian now detect package pointing to /home

[gregor herrmann]

On Thu, 06 Aug 2015 18:25:27 +0100, Colin Watson wrote:

> On Fri, Jul 31, 2015 at 11:34:20AM +0200, Bastien ROUCARIES wrote:
> > After a chat under #debian-qa it appear that canonical path for non
> > existant home dir is /nonexistant could be documented ?
> If we do (and I'm not expressing any opinion on that here), we should
> spell it correctly: "/nonexistent".

This also matches what I see on a Debian installation from 2003:

% ls -1d /nonex*
/nonexistent


Cheers,
gregpr

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: DKP: Die Internationale


signature.asc
Description: Digital Signature

Bug#798476: debian-policy: don't require Uploaders

[gregor herrmann]

On Wed, 09 Sep 2015 21:54:29 +0200, Bill Allombert wrote:

> On Wed, Sep 09, 2015 at 09:10:31PM +0200, Julien Cristau wrote:
> > for some time I've been uploading packages with Maintainer set to a
> > mailing list and no Uploaders field.
> Do you realize that upload of such package will count as an NMU ?

Not for lintian, if it doesn't have a NMU version and has "Team
upload." as the first changelog line.
(Since version 2.4.2 from 2010.)
 

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Featuring The Dubliners, The Fureys And Davey Arthur Etc.: Molly 
Malone, The Band Of ' Du


signature.asc
Description: Digital Signature

Bug#114920: [PROPOSAL] remove foolish consistency in perl module names

[gregor herrmann]

On Wed, 02 Jan 2008 00:58:12 -0200, Martín Ferrari wrote:

> On Jan 2, 2008 12:28 AM, Russ Allbery <[EMAIL PROTECTED]> wrote:
> > This is a Policy proposal that's sat in the Policy bug queue with wording
> > and seconds for quite some time.  I'd like to resurrect it and resolve it
> > one way or the other.
> I think the proposal is a good technical solution to the problem: I
> really want to still be able to apt-get install
> libbusiness-onlinepayment-bankofamerica-perl, I don't need to think
> twice to find it.

Count me in -- I appreciate the simple mapping of Foo::Bar to
libfoo-bar-perl, too.
 
> But, is this really a problem? I don't completely grasp the benefit of
> using reduced names for libraries. Also, there is the problem of
> assigning good names. 

Ack.

But I don't oppose to the policy change, as long as the "fancy" names
are optional and the "real" names are required to be in a Provides
field (and that's the way I read the proposal).

> Call me a consistency freak :)

Call me more conservative than I'd like to be :)

Cheers,
gregor 
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Dire Straits: Money For Nothing


signature.asc
Description: Digital signature

Re: packages with perl-modules, CPAN, Policy

[gregor herrmann]

On Thu, 05 Jun 2008 12:08:00 +0400, Dmitry E. Oboukhov wrote:

[cc-ing [EMAIL PROTECTED], please adjust address for replies as
appropriate]

> I dislike very much to watch how the admins I'm  acquainted  with
> install perl-modules with the help of the command perl -MCPAN  -e
> shell, however there's no other way out when the package  is  not
> included into deb-repositary.  Many of them simply can't build  a
> deb-package.

You could point them to dh-make-perl which will create usable
packages from CPAN modules in many cases.
 
> I think if in the system of controlling the packages there  would
> be  an  opportunity  of  univocal  (single-valued)  search  of  a
> deb-package according to the name of a perl-module [1],  then  it
> would give the following opportunity (and besides the simple ease
> of search of a package name (sometimes it is rather hard to  find
> a  deb-package  in  repository   according   to   the   name   of
> perl-module)):

I don't find it hard, `apt-file search' for Foo/Bar.pm is quite handy
(and can be scripted or used in a shell function or ...).
 
> So when refreshing the system the  modules  installed  from  cpan
> would be replaced by the modules from  deb-packages  (if  they've
> appeared).

This would have to take the versions into account too.
 
> I offer to include new fields into  debian/contol,  for  example:
> Export-Perl-Modules: WWW::Mechanize,  WWW::Mechanize::Image,  ...
> These fields may be filled in by hand or it is better to  entrust
> this function to dh_perl (or a new utility of such kind).

Manually adding the provided module names doesn't really scale IMO.
 

In general I'm not sure if all this work is worth the effort; but a
database that matches perl modules and debian packages would have
another use case: There has been interest from the CPAN QA guys to
get more information about the status of CPAN modules in Debian, and
one first obstacle we meet when discussing these nice ideas on
[EMAIL PROTECTED] was to find the match between the names.
Maybe it would work the other way round: To find a way to get the
"CPAN status in Perl" and make these data available for local admins
without having to mess with ~1400 lib.+-perl packages and bloating
debian/control.

Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: John Zorn & Masada: Halom


signature.asc
Description: Digital signature

Re: Goals of debian/copyright

[gregor herrmann]

On Tue, 24 Mar 2009 16:55:04 -0700, Russ Allbery wrote:

> 8) Provide information about the upstream maintainer and upstream
>location of the software for non-native software, including any
>necessary repackaging of upstream source for Debian's purposes.

Besides upstream maintainer and upstream location also 'upstream
name' would be nice to have; it would allow a bi-directional mapping
between package names and upstream project names. We've had requests
from the CPANTS (Perl CPAN QA project) guys about such lists.

(Of course this doesn't have to be in debian/copyright technically.)

Cheers,
gregor
 
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Queen: Stone Cold Crazy


signature.asc
Description: Digital signature

Re: debian/copyright and Files-Within-Files

[gregor herrmann]

On Tue, 30 Jun 2009 10:02:45 -0400, Jonathan Yu wrote:

> >> How would we represent such a case? Would we need to unpack that
> >> tarball and then reference the files appropriately?
> > Unpacking the tarballs would mean modifying the pristine upstream tar,
> > wouldn't it?  I don't think we want to do that.
> That's what we've had to do, 

Right, but only temporarily for getting the information.

> But that loses information there. And I don't think that's the way
> we're supposed to do things (in the pkg-perl packages we track each
> license separately).

Maybe we could use "sub-stanzas" like

Files: tarball1.tar.gz
Copyright: , main author
License: GPL-1 | Artistic
X-Comment: this tarball also contains
Files: foo.pl
Copyright: , some other guy
License: Apache-2.0
etc. Or whatever creative stuff we can imagine :)

> > And these tarballs contain files with differing copyright holders?  Congrats
> > on finding a strange corner case. :)

:)
 
Cheers,
gregor
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Aimee Mann: Guys Like Me


signature.asc
Description: Digital signature

Re: Bug#458385: New version of Artistic License

[gregor herrmann]

On Fri, 28 Aug 2009 19:43:21 -0700, Russ Allbery wrote:

> > I notice this has been discussed quite a bit previously (though
> > something like 18 months ago), and the general idea I have gathered from
> > reading is that the Artistic License, version 2.0 is not yet popular
> > enough to warrant inclusion in common-licenses.
> I think the general feeling was that by the time we have around 250
> packages in the archive or so that are using it, it probably warrants
> inclusion, since we know that its use is going to grow in the long run.
> Last time I checked, which was quite some time ago, there were *way* fewer
> than that, and the surge of packages predicted in the previous thread
> appears not to have happened.
> 
> Do you have a feel for how many there are now?

As a first approach I've grepped thruugh the lintian lab:

gre...@bellini:/org/lintian.debian.org/laboratory/source$ egrep "(Artistic 
License (Version )*2|Artistic-2)" */debfiles/copyright | cut -f1 -d/ | uniq | 
wc -l
19

I might have missed something but the number doesn't seem very high
in any case.
(Which is a pity, since I also feel that having Artistic-2 in
common-licenses would be nice. Maybe later :)) 

Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Supertramp: Child Of Vision


signature.asc
Description: Digital signature

Bug#543417: README.source patch system documentation requirements considered harmful

[gregor herrmann]

On Tue, 08 Sep 2009 10:31:34 -0700, Russ Allbery wrote:

> > If we had a generic set of packaging types that we could agree didn't
> > need to be documented in README.source (perhaps in devref, with pointers
> > to the actual documentation?), the README.source could be reserved for
> > things which actually were unusual, and would obviate most of the
> > concerns raised.
> Yeah, that's where I'm coming from as well.  After now having some
> experience with this policy, it's not feeling particularly useful to have
> people copy over some boilerplate if they're using quilt or dpatch in the
> normal and expected way.

Count me in; these boilerplate README.source copies are tiresome for
me, both for writi^Wcopying and reading (or ignoring).

I also share the concern that they actually devaluate the files that
contain real information (as opposed to pointing to well-known or
easy-to-find docs).

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-BOFH excuse #96:  Vendor no longer supports the product 


signature.asc
Description: Digital signature

Bug#548823: devref: please point to text file to get #debian-private password

[gregor herrmann]

tag 548823 + patch
thanks

On Fri, 16 Oct 2009 17:24:29 -0700, Ryan Niebur wrote:

> > > instead of wasting peoples time, making them read through
> > > debian-private list archives, trying 3 wrong passwords until they
> > > finally discover that they could have figured it out much, much easier
> > > if devref had not mislead them.
> > Sounds reasonable. I suggest providing a patch which makes this
> > change.
> btw, it's master.debian.org:/home/debian/misc/irc-password
> I might provide a patch, tho I'm assuming it wouldn't be very hard for
> the devref maintainers to just change it...

Let's try to make their lives easier with the attached patch :)

Cheers,
gregor 
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Peter Jones: Heart Labour
Index: resources.dbk
===
--- resources.dbk	(revision 6982)
+++ resources.dbk	(working copy)
@@ -152,10 +152,8 @@
 speak there of issues that are discussed in
 &email-debian-private;.  There's another channel for this
 purpose, it's called #debian-private and it's protected by
-a key.  This key is available in the archives of debian-private in
-master.debian.org:&file-debian-private-archive;,
-just zgrep for #debian-private in all
-the files.
+a key.  This key is available at
+master.debian.org:&file-debian-private-key;.
 
 
 There are other additional channels dedicated to specific subjects.
Index: common.ent
===
--- common.ent	(revision 6982)
+++ common.ent	(working copy)
@@ -152,6 +152,7 @@
 /usr/share/doc/ocaml/ocaml_packaging_policy.gz">
 /usr/share/doc/common-lisp-controller/README.packaging">
 
+
 /usr/share/doc/autotools-dev/README.Debian.gz">
 
 address" | mail request@&bugs-host;'>


signature.asc
Description: Digital signature

Re: use README.source to describe whether committing to VCS is desired

[gregor herrmann]

On Wed, 23 Dec 2009 16:09:22 +0100, Stefano Zacchiroli wrote:

> On Wed, Dec 23, 2009 at 11:41:07PM +0900, Charles Plessy wrote:
> > +   
> > + In addition, debian/README.source may also be
> I'd rather use "should" if, as it seems from the few early messages,
> there is consensus on this change.

To be honest, I'm a bit ambivalent: On the one hand I like the idea
of having the info in the package for NMUs, on the other hand having
to add a (line to) debian/README.source for ~1500 package in the perl
group saying "If you are a DD please work off and commit to $URI."
sounds a bit scary. -- But I have no better idea either at the
moment.
 
Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Mark Knopfler: Smooching


signature.asc
Description: Digital signature

Re: Bug#566220: [PATCH] Clarify "verbatim copy of its copyright and distribution license"

[gregor herrmann]

On Mon, 25 Jan 2010 09:39:14 +1100, Ben Finney wrote:

> I can't recall an ftpmaster *ever* giving their position on this in
> answer to the questions raised over on debian-devel, and I'd love to be
> shown where your certainty comes from.

As long as there is no other statement I consider it safe to assume
that the older statements are still valid:

http://ftp-master.debian.org/REJECT-FAQ.html and (linked from there)
http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html

Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Leonard Cohen: Everybody Knows


signature.asc
Description: Digital signature

Bug#566220: [PATCH] Clarify "verbatim copy of its copyright and distribution license"

[gregor herrmann]

On Mon, 08 Feb 2010 09:16:29 +1100, Ben Finney wrote:

> ... how this policy is compatible with the observed fact of
> a dearth of such all-copyright-notices duplication in the actual Debian
> packages.

I seems you are looking at other packages than me; I know quite a few
which follow the ftp-masters' interpration of policy.
 
> So the situation we end up with is that there are two contradictory
> “existing practices” to document in Debian policy: the actual practice
> embodied in Debian packages, and the actual policy expressed by
> ftpmasters.

Ehrm, just because we have incomplete debian/copyright files doesn't
mean there's a consensus or an accepted practice that they are
correct.

Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-BOFH excuse #315:  The recent proliferation of Nuclear Testing 


signature.asc
Description: Digital signature

Bug#566220: [PATCH v2] Clarify “copyright and distribution license”

[gregor herrmann]

On Sun, 07 Feb 2010 22:58:36 -0600, Jonathan Nieder wrote:

> From: Steve Langasek 
> 
> Claims that the policy never meant copyright notices were
> supposed to be included in debian/copyright in the first place
> only muddle the discussion.
> 
> This says “copyright information” instead of “copyright notices”
> because as long as the information is there, it doesn’t matter if
> it has exactly the same formatting.  For example, combining the
> dates from multiple copyright notices is a common practice.
> 
> Signed-off-by: Jonathan Nieder 
> ---

[..]
 
>  policy.sgml |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/policy.sgml b/policy.sgml
> index 76ac0d4..ea3ed35 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -569,8 +569,8 @@
>   Copyright considerations
>  
>   
> -   Every package must be accompanied by a verbatim copy of
> -   its copyright and distribution license in the file
> +   Every package must be accompanied by a verbatim copy of its
> +   copyright information and distribution license in the file
> /usr/share/doc/package/copyright
> (see  for further details).
>   
> @@ -1638,8 +1638,8 @@
>
>   Copyright: debian/copyright
>  
> -  Every package must be accompanied by a verbatim copy of
> -   its copyright and distribution license in the file
> +   Every package must be accompanied by a verbatim copy of its
> +   copyright information and distribution license in the file
> /usr/share/doc/package/copyright
> (see  for further details). Also see
>  for further considerations related
> @@ -9108,7 +9108,7 @@ END-INFO-DIR-ENTRY
>  
>   
> Every package must be accompanied by a verbatim copy of its
> -   copyright and distribution license in the file
> +   copyright information and distribution license in the file
> /usr/share/doc/package/copyright. This
> file must neither be compressed nor be a symbolic link.
>   

Seconded.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-


signature.asc
Description: Digital signature

Re: Removing the manpage requirement for GUI programs?

[gregor herrmann]

On Sat, 27 Feb 2010 20:06:37 +0100, Josselin Mouette wrote:

> GUI applications usually take only a few simple command-line options,
> and more importantly, when you use a modern development framework, these
> options will always be documented correctly with the --help switch.

Manpages can be used with/by debman, http://manpages.debian.net/,
apropos, and probably a dozen other tools which don't know about any
--help output.

> For extra points, we could agree on a way to generate manual pages
> automatically, either at installation time or on the fly, using
> help2man.

IMO these are not extra points but a necessary pre-requisite. And I
believe it should happen at build time.
 
Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-BOFH excuse #205:  Quantum dynamics are affecting the transistors 


signature.asc
Description: Digital signature

Re: Bug#579457: debian-policy: finer granularity for perlapi-*

[gregor herrmann]

On Fri, 07 May 2010 19:16:32 +0300, Niko Tyni wrote:

> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index 1d26df7..1ee5df5 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -89,8 +89,11 @@
>   
>   
> The perl-base package must provide
> -   perlapi-version for all released
> -   versions it is compatible with.
> +   perlapi-abiname for all released
> +   package versions it is compatible with. The choice of
> +   abiname is arbitrary, but if it differs from
> +   $Config{version}, it must be specified in
> +   $Config{debian_abi}.
>   
>
>  
> @@ -348,8 +351,9 @@ $(MAKE) install PREFIX=$(CURDIR)/debian//usr
>   a minimum version of the perl package
>   used to build the module, and must additionally depend on
>   the expansion of
> - perlapi-$Config{version} using
> - the Config module.
> + perlapi-$Config{debian_abi} using
> + the Config module. If $Config{debian_abi}
> + is empty or not set, $Config{version} must be used.
> 
>   

Seconded.

Cheers,
gregor  
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Paul McCartney: I Got Stung


signature.asc
Description: Digital signature

Bug#436105: suggestion to add GPL-1 as a common licence

[gregor herrmann]

On Thu, 10 Jun 2010 14:54:45 -0700, Russ Allbery wrote:

> Given that, while I'm very sympathetic to Santiago's argument, I also
> think that we should be able to represent in packages their upstream
> licensing statement and not be implicitly relicensing them under later
> versions of the GPL, 

Ack, pointing to the -GPL symlink (and relying (and therefore
relicensing) on the "or later" aspect) doesn't feel right to me; and
it also involves coming up with lintian patches every now and then
when the wording for "same as Perl" changes.

> I therefore propose adding GPL version 1 to the list of licenses said by
> Policy to be in common-licenses and asking Santiago to include a copy in
> base-files.  I'm not including a diff since it would just create merge
> conflicts with the BSD diff proposed earlier today and because it's fairly
> obvious, although I can if people would prefer.
> 
> Objections or seconds?

Seconded.
 
> Copying debian-perl on this message since that's the set of developers who
> are most affected by this.

Thanks!

(Although that means some changes on our part, in dh-make-perl and in
most of our packages :))

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: U2: With Or Without You


signature.asc
Description: Digital signature

Bug#458385: New version of Artistic License

[gregor herrmann]

On Thu, 10 Jun 2010 15:03:41 -0700, Russ Allbery wrote:

> Based on that search, there are still only 20 binary packages in the
> archive covered by the Artistic 2.0 license.

Thanks for your research!
 
> Given that, this license really isn't common in Debian, and hence doesn't
> warrant inclusion in common-licenses.  

Agreed.

> Certainly if the license becomes more broadly used in the
> future, it can be proposed for inclusion again at that time.

Some clear criterion might be helpful (and save you some time in the
future :))

Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: U2: With Or Without You


signature.asc
Description: Digital signature

Bug#284340: Please remove reference to UC in BSD license

[gregor herrmann]

On Thu, 10 Jun 2010 13:13:23 -0700, Russ Allbery wrote:

> Any further discussion?  

Sounds logcial to me.

> I'm also looking for seconds for the Policy patch
> below:
> 
> diff --git a/policy.sgml b/policy.sgml
> index 87b9795..02d6f8d 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -9227,14 +9227,13 @@ END-INFO-DIR-ENTRY
>   
>  
>   
> -   Packages distributed under the UCB BSD license, the Apache
> -   license (version 2.0), the Artistic license, the GNU GPL
> -   (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and the
> -   GNU FDL (versions 1.2 or 1.3) should refer to the corresponding
> -   files under /usr/share/common-licenses,
> +   Packages distributed under the Apache license (version 2.0), the
> +   Artistic license, the GNU GPL (version 2 or 3), the GNU LGPL
> +   (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3)
> +   should refer to the corresponding files
> +   under /usr/share/common-licenses,
>   
> In particular,
> -  /usr/share/common-licenses/BSD,
>/usr/share/common-licenses/Apache-2.0,
>/usr/share/common-licenses/Artistic,
>/usr/share/common-licenses/GPL-2,
> @@ -9244,7 +9243,14 @@ END-INFO-DIR-ENTRY
>/usr/share/common-licenses/LGPL-3,
>/usr/share/common-licenses/GFDL-1.2, and
>/usr/share/common-licenses/GFDL-1.3
> -  respectively.
> +   respectively.  The University of California BSD license is
> +   also included in base-files as
> +   /usr/share/common-licenses/BSD, but given the
> +   brevity of this license, its specificity to code whose
> +   copyright is held by the Regents of the Univesrity of
> +   California, and the frequency of minor wording changes, its
> +   text should be included in the copyright file rather than
> +   referencing this file.
>  
> rather than quoting them in the copyright
> file. 

Seconded.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Queen: You Don't Fool Me


signature.asc
Description: Digital signature

Bug#436105: suggestion to add GPL-1 as a common licence

[gregor herrmann]

On Sat, 12 Jun 2010 00:25:57 +1200, Andrew McMillan wrote:

> If the code is v1-or-later then a trivial fork (by the original
> developer) is able to relicense it as v2-or-later or v3-or-later.  If
> the original developer is unhappy with doing that, then they do have
> uncommon licensing desires.

Most perl modules are licensed "under the same terms as Perl itself",
and perl is licensed under "GPL-1 or later" or Artistic.

Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: George Harrison: If Not For You


signature.asc
Description: Digital signature

Bug#591857: debian-policy: please clarify which of DEB_{BUILD,HOST}_* is which

[gregor herrmann]

On Fri, 06 Aug 2010 00:28:51 +0200, Adam Borowski wrote:

> It is utterly non-obvious what the BUILD and HOST architectures mean.
[..]
> Browsing the relevant documentation (debian-policy, man dpkg, ...),
> I found no place that disambiguates those.  

Is `man dpkg-architecture' what you are looking for?

> Could you please reword section 4.9 to mention that BUILD is the one you
> host the build on, and HOST the one your build for?  The current version
> just says that HOST is the host machine, and BUILD is the build machine,
> which is just a waste of words.

Might be good to have it more clearly here too.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-BOFH excuse #244:  Your cat tried to eat the mouse. 


signature.asc
Description: Digital signature

Bug#593611: Clarify whose signature should go in debian/changelog (4.4)

[gregor herrmann]

On Wed, 22 Sep 2010 21:37:24 +1200, Andrew McMillan wrote:

> On Sat, 2010-09-18 at 21:10 -0700, Russ Allbery wrote:

> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -1688,11 +1688,14 @@
> >  
> > 
> >   The maintainer name and email address used in the changelog
> > - should be the details of the person uploading this
> > - version.  They are not necessarily those of the
> > - usual package maintainer.
> > -   If the developer uploading the package is not one of the usual
> > -   maintainers of the package (as listed in
> > + should be the details of the person who prepared this release of
> > + the package.  They are not necessarily those of the
> > + uploader or usual package maintainer.
> > +   In the case of a sponsored upload, the uploader signs the
> > +   files, but the changelog maintainer name and address are those
> > +   of the person who prepared this release.  If the preparer of
> > +   the release is not one of the usual maintainers of the package
> > +   (as listed in
> > the Maintainer
> > or Uploaders control
> > fields of the package), the first line of the changelog is
> 
> Seconded.

Seconded as well.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Tom Waits: The Piano Has Been Drinking


signature.asc
Description: Digital signature

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[gregor herrmann]

On Thu, 07 Sep 2023 21:28:15 +0100, Luca Boccassi wrote:

> Yes, that is fine by me, as explained in later replies my main
> intention is to fix the issue that some wording is being used to
> reintroduce things that should not be reintroduced

If I understand you correctly, "Reintroduc[ing] things that should not be
reintroduced" means not acting on bug reports where someone says
"Please change #!/usr/bin/sh back to #!/bin/sh".

If I'm understanding the technical question correctly, "#!/bin/sh"
works for both merged-/usr and split-/usr, while "#!/usr/bin/sh" works
only for merged-/usr and breaks for split-/usr.

Now, how to handle this situation? In my naïve point of view and a
bit late at night I see two options for maintainers. They can say …

1) "Well, right, *sigh*, ok, let's take the five minutes to change
   this back to "#!/bin/sh", and everyone's happy."

… or …

2) "No way, we are usr-merge, resistence is futile, go  yourself, "#!/usr/bin/sh" is the default, bad luck for
   you 111"


I'm a bit sad that many discussions in Debian (like this one) turn
into the "my way or the highway" lane, and I'd rather see a way of
cooperation which gives more leeway to others and take small extra
steps to accomodate minorities, when it doesn't have any actual cost.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1024367: In 4.9.1, the example uses not recommended install -s

[gregor herrmann]

On Sat, 09 Sep 2023 15:16:10 -0700, Russ Allbery wrote:

> I'm therefore going to propose fixing this bug with the following patch,
> which is more aggressive than you propose.
> 
> I think this is informative rather than normative and therefore
> technically doesn't require seconds, but I'll give this some time for
> other people to take a look and talk me out of deleting this section if
> they wish.

Looks good to me.

Cheers,
gregor 


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1064454: debian-policy: Restrict deb822 field names more

[gregor herrmann]

On Thu, 22 Feb 2024 14:08:38 +0100, Simon Josefsson wrote:

> Would it make sense to change this to use an inclusive list of permitted
> characters instead?  How about checking the field names that is in use
> today, and construct a regexp of permitted symbols out of that?
> Starting point: [A-Za-z][A-Za-z0-9-_]*

Right, also: defining this as a regexp would be helpful for
implementation in all parsers (and I suspect there are many of them
…).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1087820: debian-policy: allows README.source.md alternatively

[gregor herrmann]

On Tue, 19 Nov 2024 12:37:57 +0100, Bill Allombert wrote:

> On Tue, Nov 19, 2024 at 06:29:25PM +0800, Sean Whitton wrote:
> > On the other hand, is there much benefit?  People used to typing
> > 'less debian/README.source' would need to retrain their fingers.
> This is my concern too:
> the whole point of this policy is to specify the filename.
> Beside this file is only useful in limited circumstances which are less
> and less frequent due to improvement to dpkg and uupdate. It is unclear
> why anyone would need markdown for it.

I guess Otto was thinkig about Gitlab/salsa which renders markdown
automatically.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   BOFH excuse #337:  the butane lighter causes the pincushioning