Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

On Mon, Dec 27, 2021 at 01:20:14PM -0700, Sean Whitton wrote:
> In that case, returning to Mattia's patch, it is probably not correct to
> say that the source Description is relevant for all binary packages,
> because perhaps the substvar is used for some but not all of them?

Mh, we probably we'll need Guillem to confirm/deny this, but here I
really really was trying to not even mention on the substvar thing.
That to me feels like an implementation detail on how to fill a binary
package Description (that can already be accomplished in several other
way).
In my mind I was mostly focusing on being able to provide a
**description for the source package** (that is, then, relevant to
everything that source package builds); said description being picked up
by a substvar and used again later on is more like a nicety that comes
after describing the source first.

Should I perhaps express my intention differently?  For example:

|+When used in a source control file in the general paragraph (i.e., the first
|+one, for the source package), the text in this field is used to describe the
|+source package itself, and consequently all of the binary packages
|+built from itself.

?


(fwiw, Guillem: do you think the same text, once picked, should be
copied verbatim on deb-src-control(5)?)

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

On Tue, Dec 21, 2021 at 05:53:31PM -0700, Sean Whitton wrote:
> > |--- a/policy/ch-controlfields.rst
> > |+++ b/policy/ch-controlfields.rst
> > |@@ -652,9 +654,14 @@ orderings.  [#]_
> > | ~~~
> > |
> > | In a source or binary control file, the ``Description`` field contains a
> > |-description of the binary package, consisting of two parts, the synopsis
> > |-or the short description, and the long description. It is a multiline
> > |-field with the following format:
> > |+description of the package, consisting of two parts, the synopsis or the 
> > short
> > |+description, and the long description.
> > |+
> > |+When used in a source control file in the general paragraph (i.e., the 
> > first
> > |+one, for the source package), the text in this field is relevant for all 
> > binary
> > |+packages built by the given source package.
> 
> Is there really no name for the first paragraph other than "general
> paragraph"?  Maybe "the source package's stanza"?

You should tell me :D

As I said, I'm happy to change those 3 words, but first you should
probably decide and then make it uniform with §5.2 "Source package
control files – debian/control" (and I have no idea how it is referred
to in the rest of the document).

> Also, how about "the text in this field describes all binary packages
> which do not have their own Description: fields" ?

Where would you add this line?  The whole section is talking about
Description regardless of where it is used, so your suggestion doesn't
sounds any good there.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

On Sun, Dec 12, 2021 at 10:51:43PM +, Holger Levsen wrote:
> > |--- a/policy/ch-controlfields.rst
> > |+++ b/policy/ch-controlfields.rst
> > |@@ -652,9 +654,14 @@ orderings.  [#]_
> > | ~~~
> > | 
> > | In a source or binary control file, the ``Description`` field contains a
> > |-description of the binary package, consisting of two parts, the synopsis
> > |-or the short description, and the long description. It is a multiline
> > |-field with the following format:
> > |+description of the package, consisting of two parts, the synopsis or the 
> > short
> > |+description, and the long description.
> > |+
> > |+When used in a source control file in the general paragraph (i.e., the 
> > first
> 
> I believe the 2nd "in" in this line is too much.

Mh, not really?  However indeed it might be clearer this other way:

When used in the general paragraph of a source control file [...]

> > |+one, for the source package), the text in this field is relevant for all 
> > binary
> > |+packages built by the given source package.
> 
> and then I'd rewrite "the general paragraph (i.e., the first one, for 
> the source package)" into "the first paragraph" and the whole paragraph into
> 
> When used in a source control file the first paragraph is used as the first
> paragraph for all binary packages built by the given source package.

That's not proper: the place this text is placed (§5.6.13 "Description")
talks about the "Description" and it's linked to from the various places
this field is used (a source control file, a binary control file, a
changes control file); it's not describing the source control file (i.e.
d/control).  Furthermore, note that the wording "general paragraph"
comes from §5.2 "Source package control files – debian/control":

The first paragraph of the control file contains information about
the source package in general. [...]

The fields in the general paragraph (the first one, for the source
package) are: [...]


Of course I'm happy to use a different expression (like, "first
paragraph of a source control file") if I'm recommended to.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

On Sun, Oct 31, 2021 at 11:18:35AM +0100, Mattia Rizzolo wrote:
> If I get no pushbacks I'll also propose some text later on when I'm
> freer (unless somebody beats me to it!).

I'm hereby seeking seconds (or, well, suggestions for improvements) for
the following diff, which is based on
daa7d69fbffc1c438002993860f0df407e4aaeb1 (4.6.0.1):

|--- a/policy/ch-controlfields.rst
|+++ b/policy/ch-controlfields.rst
|@@ -131,6 +131,8 @@ package) are:
| 
| -  :ref:`Rules-Requires-Root `
| 
|+-  :ref:`Description `
|+
| The fields in the binary package paragraphs are:
| 
| -  :ref:`Package ` (mandatory)
|@@ -652,9 +654,14 @@ orderings.  [#]_
| ~~~
| 
| In a source or binary control file, the ``Description`` field contains a
|-description of the binary package, consisting of two parts, the synopsis
|-or the short description, and the long description. It is a multiline
|-field with the following format:
|+description of the package, consisting of two parts, the synopsis or the short
|+description, and the long description.
|+
|+When used in a source control file in the general paragraph (i.e., the first
|+one, for the source package), the text in this field is relevant for all 
binary
|+packages built by the given source package.
|+
|+It is a multiline field with the following format:
| 
| ::
| 

I also pushed my change here:
https://salsa.debian.org/mattia/policy/-/commit/807bd3ea551087df33c54c270e7f11151c8b0ae2

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

On Wed, Nov 03, 2021 at 11:40:02PM +0100, Bill Allombert wrote:
> Could you clarify what source packages that produce several binary
> packages should do ? Maybe give an example ?

Sure.

Here is how I would use it, for example.

--- a/debian/control
+++ b/debian/control
@@ -25,6 +25,13 @@ Rules-Requires-Root: no
 Homepage: http://xmlsoft.org
 Vcs-Git: https://salsa.debian.org/xml-sgml-team/libxml2.git
 Vcs-Browser: https://salsa.debian.org/xml-sgml-team/libxml2
+Description: GNOME XML library
+ XML is a metalanguage to let you design your own markup language.
+ A regular markup language defines a way to describe information in
+ a certain class of documents (eg HTML). XML lets you define your
+ own customized markup languages for many classes of document. It
+ can do this because it's written in SGML, the international standard
+ metalanguage for markup languages.

 Package: libxml2
 Architecture: any
@@ -36,13 +43,8 @@ Depends:
 Conflicts:
  w3c-dtd-xhtml,
 Multi-Arch: same
-Description: GNOME XML library
- XML is a metalanguage to let you design your own markup language.
- A regular markup language defines a way to describe information in
- a certain class of documents (eg HTML). XML lets you define your
- own customized markup languages for many classes of document. It
- can do this because it's written in SGML, the international standard
- metalanguage for markup languages.
+Description: ${source:Synopsis}
+ ${source:Extended-Description}
  .
  This package provides a library providing an extensive API to handle
  such XML data files.
@@ -54,13 +56,8 @@ Depends:
  ${misc:Depends},
  ${shlibs:Depends},
 Multi-Arch: foreign
-Description: XML utilities
- XML is a metalanguage to let you design your own markup language.
- A regular markup language defines a way to describe information in
- a certain class of documents (eg HTML). XML lets you define your
- own customized markup languages for many classes of document. It
- can do this because it's written in SGML, the international standard
- metalanguage for markup languages.
+Description: ${source:Synopsis} - utilities
+ ${source:Extended-Description}
  .
  This package provides xmllint, a tool for validating and reformatting
  XML documents, and xmlcatalog, a tool to parse and manipulate XML or
@@ -76,13 +73,8 @@ Depends:
 Suggests:
  pkg-config,
 Multi-Arch: same
-Description: Development files for the GNOME XML library
- XML is a metalanguage to let you design your own markup language.
- A regular markup language defines a way to describe information in
- a certain class of documents (eg HTML). XML lets you define your
- own customized markup languages for many classes of document. It
- can do this because it's written in SGML, the international standard
- metalanguage for markup languages.
+Description: ${source:Synopsis} - development files
+ ${source:Extended-Description}
  .
  Install this package if you wish to develop your own programs using
  the GNOME XML library.
@@ -95,13 +87,8 @@ Depends:
 Suggests:
  devhelp,
 Multi-Arch: foreign
-Description: Documentation for the GNOME XML library
- XML is a metalanguage to let you design your own markup language.
- A regular markup language defines a way to describe information in
- a certain class of documents (eg HTML). XML lets you define your
- own customized markup languages for many classes of document. It
- can do this because it's written in SGML, the international standard
- metalanguage for markup languages.
+Description: ${source:Synopsis} - documentation
+ ${source:Extended-Description}
  .
  This package contains general information about the GNOME XML library
  and more specific API references.
@@ -115,13 +102,8 @@ Depends:
  ${misc:Depends},
  ${python3:Depends},
  ${shlibs:Depends},
-Description: Python3 bindings for the GNOME XML library
- XML is a metalanguage to let you design your own markup language.
- A regular markup language defines a way to describe information in
- a certain class of documents (eg HTML). XML lets you define your
- own customized markup languages for many classes of document. It
- can do this because it's written in SGML, the international standard
- metalanguage for markup languages.
+Description: ${source:Synopsis} - Python3 bindings
+ ${source:Extended-Description}
  .
  This package contains the files needed to use the GNOME XML library
  in Python3 programs.


-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

On Mon, Nov 01, 2021 at 05:32:19PM -0700, Sean Whitton wrote:
> > The main "bad" consequence would be that Description would be exported
> > in the .dsc and as such end up in the Sources index.  This is probably
> > what we want anyway, but with all the people complaining about how big
> > the index is getting it's something to consider.  However it's also true
> > that realistically very few packages are going to make use of this
> > facility in the near future so it shouldn't really matter IMHO.
> 
> Hrm.  Could dak be modified to filter this out of the Sources file?


I'm sure it could, but I don't think we would want that?  As I wrote,
it's likely what we would like to have regardless, so that, say
`apt-cache showsrc` can bring some more information.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

Package: debian-policy
Version 4.6.0.0

Hi!

dpkg 1.19.0 introduced, following the request in #555743, a bunch of new
substvars.  Notably, it now handles ${source:Synopsis} and
${source:Extended-Description} that are described as follow:

   source:Synopsis
   The source package synopsis, extracted from the source stanza
   Description field, if it exists

   source:Extended-Description
   The source package extended description, extracted from the
   source stanza Description field, if it exists


Currently Policy §5.2 lists the allowed known fields, and Description is
accepted only in the "binary package paragraphs", not in the one for the
source package.


As documented in the bug report mentioned above, these are the main
benefits of having a Description in the source paragraph:
 * helps de-duplicate the description in the binary paragraphs (mostly
   relevant for libraries and other packages that build many binaries
   and share a common description).  Note that this would only
   de-duplicate d/control, the binary DEBIAN/control of each binary
   package would still keep the generated long description.
 * ship a generic source-level descrption of the package, which just
   make sense if one thinks about it
 * as a consequence of the above, a bunch of tools (DDPO, PTS, etc)
   would be able to drop the weird and unnatural logic that they use to
   pick a description for the source package
The main "bad" consequence would be that Description would be exported
in the .dsc and as such end up in the Sources index.  This is probably
what we want anyway, but with all the people complaining about how big
the index is getting it's something to consider.  However it's also true
that realistically very few packages are going to make use of this
facility in the near future so it shouldn't really matter IMHO.



If I get no pushbacks I'll also propose some text later on when I'm
freer (unless somebody beats me to it!).

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

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

[Mattia Rizzolo]

On Fri, Sep 17, 2021 at 03:58:55PM -0700, Sean Whitton wrote:
> On Fri 17 Sep 2021 at 06:24PM -04, Nicholas D Steeves wrote:
> > Sean Whitton  writes:
> >> On Sun 25 Oct 2020 at 09:40PM -04, Joe Nahmias wrote:
> >>> Is this truly the case that all that's needed is a new patch? Can we get
> >>> an official ACK from one of the policy editors? I'd be happy to re-write
> >>> the original patch to apply against HEAD if that's all that is required.
> >>
> >> Well, it would need seconding, but otherwise, ACK.
> >>
> >> Thank you for your interest.
> >>
> >
> > Gentle ping to Policy editors for that seconding :-)  It would be really
> > nice to move this info from tribal knowledge to documentation.
> 
> There's no patch to be seconded ...?

I'm interested in seconding such patch.

For whoever is going to write it, remember to talk about:
 * Files-Excluded-$component
 * Files-Included
which are even less-known bits of the "specification" (Files-Included is
also *very* new, in Debian times).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#682347: resurrect editor virtual package name

[Mattia Rizzolo]

led in ``/usr/share/man/man6``.
> portion is handled internally by the package system based on the os
> and cpu.
>  
> -.. [#]
> -   The Debian base system already provides an editor and a pager
> -   program.
> -

Can't this note be attached to "Programs may assume that
``/usr/bin/pager`` is available" above, to make clear that the base
already has a `pager`?  (which is… `more`, right?  what can we do to
change that again? :P)

>  .. [#]
> If it is not possible to establish both locks, the system shouldn't
> wait for the second lock to be established, but remove the first
> diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
> index 2a9857a..6c0b59e 100644
> --- a/virtual-package-names-list.yaml
> +++ b/virtual-package-names-list.yaml
> @@ -100,6 +100,14 @@ virtualPackages:
>  
>  # System
>  
> + - name: default-editor
> +   description: default base system /usr/bin/editor
> +   alternatives:
> + - /usr/bin/editor
> + - name: editor
> +   description: suitable /usr/bin/editor
> +   alternatives:
> + - /usr/bin/editor
>   - name: flexmem
> description: anything that can access flexible memory via the OBEX 
> Protocol
>   - name: foomatic-data
> @@ -457,3 +465,7 @@ virtualPackages:
>  #   Added default-dbus-session-bus
>  #   15 Feb 2019 Added logind
>  #   Added default-logind
> +#
> +# Russ Allbery:
> +#   01 Apr 2021 Added editor
> +#   Added default-editor


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#875531: "editor +42 filename" -- accept or reject?

[Mattia Rizzolo]

On Tue, May 18, 2021 at 12:11:08PM -0700, Sean Whitton wrote:
> On Tue 18 May 2021 at 01:42PM +02, Mattia Rizzolo wrote:
> 
> > Seconded.
> 
> Thanks.  I looked at applying this patch but the version we have in git
> doesn't apply to 'next' without first applying the patch in #682347.
> Mattia, would you be interested in reviewing and seconding that one too,
> so I can apply both?

I commented on it, as I think I need a few more details before seconding
it.

Honestly, I think it would be better if you just applied this, much
smaller, change to "next", and rebase #682347 on top of it :)

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#875531: "editor +42 filename" -- accept or reject?

[Mattia Rizzolo]

Inline an editorial bit that I suggest for what I consider better flow.

On Tue, May 18, 2021 at 12:27:27AM -0700, Sean Whitton wrote:
> On Fri 02 Apr 2021 at 10:46AM -07, Russ Allbery wrote:
> 
> > diff --git a/policy/ch-customized-programs.rst 
> > b/policy/ch-customized-programs.rst
> > index 27abebd..d58e297 100644
> > --- a/policy/ch-customized-programs.rst
> > +++ b/policy/ch-customized-programs.rst
> > @@ -93,6 +93,14 @@ alternative should have a slave alternative for
> >  ``/usr/share/man/man1/pager.1.gz`` pointing to the corresponding manual
> >  page.
> >
> > +Packages that register as an alternative for ``/usr/bin/editor`` must
---^--
themselves

> > +support the following features:
> > +
> > +- When invoked as ``editor ``, they open  for
> > +  editing.
> > +- When invoked as ``editor +N ``, they open  for
> > +  editing and position the cursor or equivalent at line ``N`` of the file.
> > +
> >  Packages that register as an alternative for ``/usr/bin/editor`` should
> >  also provide the virtual package ``editor`` by including it in the
> >  ``Provides`` control field. The package providing the current default


Seconded.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Mattia Rizzolo]

On Thu, Apr 01, 2021 at 01:40:06PM -0700, Russ Allbery wrote:
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index a21a510..2a2e364 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -972,11 +972,33 @@ repository where the Debian source package is developed.
>  - Mtn (Monotone)
>  - Svn (Subversion)
>  
> -In the case of Git and Mercurial, the value consists of a URL,
> -optionally followed by the word ``-b`` and the name of a branch in
> -the indicated repository, following the syntax of the ``git clone``
> -or ``hg clone`` command. If no branch is specified, the packaging
> -should be on the default branch.
> +In the case of Git, the value must have the following syntax::
> +
> + [ " -b "  ] [ " ["  "]" ]
> +
> +where the portions enclosed in brackets are optional and the portions
> +enclosed in double quotes are literal strings.   indicates
> +the repository.  If the  stanza is present, it names a
> +branch in the indicated repository.  If no branch is specified, the
> +packaging should be on the default branch.  If the  stanza
> +is present, it specifies the relative path to the top of the packaging
> +tree (the parent directory of the ``debian`` directory).  If no path
> +is specified, it defaults to ``.`` (the top level of the indicated
> +repository and branch).
> +
> +For example::
> +
> +Vcs-Git: https://example.org/repo -b debian [p/package]
> +
> +indicates a subdirectory named ``p/package`` in the ``debian`` branch
> +of the repository at ``https://example.org/repo``.
> +
> +In the case of Mercurial, the value must have the following syntax::
> +
> + [ " -b "  ]
> +
> +This is interpreted the same way as the Git syntax except a path
> +within the repository is not supported.
>  
>  A package control file must not have more than one ``Vcs-``
>  field.  If the package is maintained in multiple version control


Seconded.

Thank you for formalizing this syntax.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#971023: Version field (5.6.12) and colons

[Mattia Rizzolo]

On Sat, Nov 07, 2020 at 01:01:28PM -0700, Sean Whitton wrote:
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 0d7a3e9..a21a510 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -552,8 +552,7 @@ The three components here are:
> 
>  ``epoch``
>  This is a single (generally small) unsigned integer. It may be
> -omitted, in which case zero is assumed. If it is omitted then the
> -``upstream_version`` may not contain any colons.
> +omitted, in which case zero is assumed.
> 
>  Epochs can help when the upstream version numbering scheme
>  changes, but they must be used with care.  You should not change

I don't consider this a normative change tbh (after the previous change
already forbidding multiple colons).
If it's really needed, consider it seconded by me.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Bug#971023: Version field (5.6.12) and colons

[Mattia Rizzolo]

On Wed, Sep 30, 2020 at 11:23:43AM +0200, Christian Kastner wrote:
> To be honest, as a reader, I found that to be the opposite. The "If
> [epoch] is omitted" makes it sound as if there were an alternative
> handling if it's not omitted.
> 
> So the text
> 
>  If it is omitted then the upstream_version may not contain any colons
> 
> actually means
> 
>  The upstream_version may not contain any colons

If my memory serves correctly¹, this is just a historic remnant, as
colons used to be allowed if the epoch was present (i.e., a version
string "1:2.3:abc" used to be valid).


¹ and I think it does: 
https://salsa.debian.org/dbnpolicy/policy/-/commit/918cac858424739a5af269d993e4cadfab285b29


So, yes.  I think it would be good to make the wording just clearer,
instead of carrying over some previous syntax from when the rules were
different.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#940144: developers-reference: document self-service givebacks in wanna-build section

[Mattia Rizzolo]

On Tue, Jan 21, 2020 at 09:20:54PM +0100, Philipp Kern wrote:
> That being said, tracker, nm and contributors already moved to request
> client certificates on the main host.

In their case it didn't really change anything, since they had the
client certificate bit in their  section.

> And yes, the correct approach would be something like OAuth2. Or use
> client certificates with some sort of CLI. :/

Then get the sso.d.o team to do that, in a sane way.  We are still
waiting for an interface to register guest accounts, that has been ready
for more than a year now but apparently has trouble being deployed.



-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#941475: debian-policy: please document the /run/reboot-required thingy in the upgrade changelog

[Mattia Rizzolo]

On Wed, Oct 02, 2019 at 08:03:15AM -0700, Sean Whitton wrote:
> > Like you document in the checklist addition to the virtual packages:
> > also those don't require any change to existing packages, it's just
> > there for everybody to know that starting from that version they can
> > make use of that new thing.
> 
> From your point of view, if we started to add a summary of d/changelog
> entries which are /not/ accounted for by the upgrading checklist to the
> d-d-a e-mail, would that be sufficient?  Or do you think this stuff has
> to be in the upgrading checklist?

I only read the title of the d-d-a mail, but I read the upgrade
checklist many times over the course of the years.  Hope that answers
your question :)

I think this would be the case where a 3rd party thought would be
welcome :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#941475: debian-policy: please document the /run/reboot-required thingy in the upgrade changelog

[Mattia Rizzolo]

On Tue, Oct 01, 2019 at 07:14:08AM -0700, Sean Whitton wrote:
> Hmm, this was deliberate because the additional documentation doesn't
> require anyone to make changes to their packages.
> 
> Could you explain why you want it in the upgrading checklist?

because it's a new thing, and it helps those people that don't follow
closely enough to know that there is a new thing.  So if at some point
any given package start to need some "reboot required" information,
everybody who read once the checklist know that there already is a
policy/standard for that.

Like you document in the checklist addition to the virtual packages:
also those don't require any change to existing packages, it's just
there for everybody to know that starting from that version they can
make use of that new thing.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#941475: debian-policy: please document the /run/reboot-required thingy in the upgrade changelog

[Mattia Rizzolo]

Package: debian-policy
Version: 4.4.1.0

SSIA.

(incidentally, due to this the change also didn't make it to d-d-a…)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Mattia Rizzolo]

Hello, I have some comments on the already applied patch:

> -2. Send an gpg-signed email announcing your retirement to
> -   ``debian-priv...@lists.debian.org``.
> +-  Use the link https://nm.debian.org/process/emeritus to log in to
> +   nm.debian.org [2]_, request emeritus status and write a goodby
typo: goodbye
> +   message that will be automatically posted on debian-private.

While the above it's true, sending a signed retirement email to
debian-private@ is still very much supported, and a very good way to
proceed for all the myriad reasons there could be for SSO to fail (or to
be a pain to set up for inactive people that just want to get out of the
way).
Can I recommend we keep the alternative available (with a somewhat lower
precedence, as retirment through nm.d.o are a tad easier to process for
everybody involved).


> -4. If you received mails via a @debian.org e-mail alias (e.g.
> -   pr...@debian.org) and would like to get removed, open a RT ticket for
> -   the Debian System Administrators. Just send an e-mail to
> -   ``ad...@rt.debian.org`` with "Debian RT" somewhere in the subject
> -   stating from which aliases you'd like to get removed.

This is still true.  Nobody is actually checking the aliases to see if
any need updating in the retirement/removal process, so really if
somebody is receiving mails from an alias it needs to be updated
manually.

> +   This also automatically notifies the MIA team, so that they can
> +   check if some of your packages still need orphaning.

Why mentioning the MIA team here?

> --  Contact ``da-mana...@debian.org``.
> +-  Use the link https://nm.debian.org/wizard/process/return to log in to
> +   nm.debian.org [2]_ and request to return from emeritus status.

Here I would also mention that doing so requires being able to actually
authenticate.  That's usually hard for retired DDs because they can't
get a @d.o certificate, and they most likely long lost access to their
@user.alioth.d.o account.  Maybe just mention in passing that for auth
(or, most likely, all kind of) issues they can write to nm@d.o?
And if they are registering a new SSO account (don't ask me why, it
happens…), it probably needs to be linked to their previous nm.d.o
account, which requires manual intervention from the people behind
nm@d.o, so please do write that address as the contact point.

> +.. [2]
> +   Login on nm.debian.org requires an SSO browser certificate.
> +   (you can generate them on https://sso.debian.org)
> +   If you cannot access SSO, the recommended way of action is to
> +   mail NM frontdesk using ``n...@debian.org``.

Mh, not really.  For SSO issues, the point of contact is the SSO team.
The NM team grew a some know-how due to providing support in the past,
but I really don't want it to be advertised as the SSO support team.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Mattia Rizzolo]

On Sun, Sep 22, 2019 at 08:37:13PM +0700, Judit Foglszinger wrote:
> Wouldn't it be more advisable to write something like
> "in case you fail to authenticate to the NM site or have other issues
> to open the retirement/return process yourself, contact front desk"
> instead of keeping the former more cumbersome way of retirement alife?

Yes, I think that would do (even if it would require a round trip for
people wanting to retire).

> Also, what about the gpg  key?
> Are people asked to prove they still control their key?
> If so, in which way?

Good questions indeed…  In the very few cases of returnees I saw during
my little time I have in FD, I noticed two cases:
 * people whom their old key was still perfectly valid → just accept it
 * people whom their old key was not trustable anymore → require another
   DD to vouch for it (i.e. "yes, this gpg key really belongs to the
   same person that used to be behind this Debian uid")

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Mattia Rizzolo]

On Sun, Jul 21, 2019 at 08:29:16PM -0700, Russ Allbery wrote:
> Sure, an extensible syntax sounds great.  The problem is that we kind of
> had one (Vcs-Git was a subset of a git checkout command line, which
> allowed support of the -b option), but this (if I understand it correctly)
> is a whole new type of thing that I don't think corresponds to any git
> command-line flags.
> 
> It's kind of hard to design an extensible format with any well-defined
> meaning if we don't know what sorts of things people will want to add via
> extensions
> 
> What we would ideally have is a git URL that allows representing the
> branch and path within the repository, along with the transport.  Surely
> there must be prior work out there -- has anyone defined such a thing
> already?

I don't remember where this was discussed (quite in length actually),
probably debina-qa@ or debian-devel@.  It was then implemented in
vcswatch (https://qa.debian.org/cgi-bin/vcswatch) and elsewhere.
I'm positive a result of that discussion made clear there was no such
URI format available already.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#918438: orig tarball components with uppercase letters

[Mattia Rizzolo]

On Sun, Jan 06, 2019 at 01:05:34PM +, Ian Jackson wrote:
> People should be able to convey Debian packages (including source
> packages) across such computers.  There are all sorts of situations
> where a user may for whatever reason have to do so.
> 
> Note that even Debian systems sometimes mishandle this: ISO9660
> (without Rock Ridge) and VFAT filesystems, both of which we commonly
> use for distributing our own software, are case-insensitive.
> 
> Yes, this could be avoided by never using those filesystems and only
> ever providing our softare as ext2 (say) instead of VFAT, or whatever.
> Hopefully you can see why we don't do that...

We have packages (src:debhelper did for a long time) containing files
with the same name and only case differences in them (in the case of
debhelper, it was shipping a 'debian' and a 'Debian' directory).
Are you say that you really want to go ahead and chase after all such
things.

Yes, there are case-insensitive file systems and the like, but really
that's their problem or of the transmission mechanism, and further
limiting our possibilities is just like that, limiting our possibilities
for the sake of more limited software.

I really wish we could stop banning things just because third parties
can't deal with our stuff.
Your dgit case is like this: you had a bug in a software that couldn't
properly handle such files, you fixed it, end of story, no need to block
the usage of features because of a bug.

And don't use case insensitive file systems to do UNIX development.  :)

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#850171: Recommend that manpages contain an EXAMPLES section

[Mattia Rizzolo]

On Sat, Nov 03, 2018 at 02:00:51PM -0700, Sean Whitton wrote:
> +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.

I'm wary of one thing: I don't really want to be bothered by this.
Going around patching upstream's manpages to add an EXAMPLE section is
totally busywork, not mention possibly even hard to do for all the
autogenerated manpages.
What I mean is: if there is really enough people wanting this change by
all means do it, but 1. make the wording clear that is really optional
(in this view, I see "recommended" as too strong a word) and 2. I really
hope lintian won't start bothering for this.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#845715: Required targets must not write outside of the source package tree

[Mattia Rizzolo]

Hi,

On Sat, Nov 03, 2018 at 12:38:55PM -0700, Sean Whitton wrote:
> Given that whole archive rebuilds with use sbuild and already catch
> packages that violate this requirement, making this change would not
> declare any packages buggy that would not already be considered buggy,
> so we can make it right away.

That's not entirely true, I can very easily imagine stuff trying to
write to $HOME but, if failing, trying elsewhere…



Anyway, seconded the below, with or without Russ' amend in
<87woptdiwa@hope.eyrie.org>.
Thank you!

> diff --git a/debian/changelog b/debian/changelog
> index 956f367..b90ea92 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -10,6 +10,11 @@ debian-policy (4.2.2.0) UNRELEASED; urgency=medium
>  Seconded: Holger Levsen 
>  Seconded: Russ Allbery 
>  Closes: #912581
> +  * Policy: Required targets must not write outside of the source package 
> tree
> +Wording: Johannes Schauer 
> +Seconded: Sean Whitton 
> +Seconded: ...
> +Closes: #845715
>* In a preexisting footnote, recommend passing -D to strip(1) when
>  stripping static libraries.
>  Thanks to Niels Thykier for the suggestion.
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index dc80243..c486e7c 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -291,6 +291,16 @@ For packages in the main archive, no required targets 
> may attempt
>  network access, except, via the loopback interface, to services on the
>  build host that have been started by the build.
> 
> +Required targets must not attempt to write outside of the unpacked
> +source package tree. An exception to this rule is the use of
> +``TMPDIR`` (or ``/tmp`` if that is not set) which is permitted as long
> +as temporary files are deleted by the end of the target, and not
> +reused by subsequent execution of the target.  This restriction is
> +intended to prevent source package builds creating and depending on
> +state outside of themselves, thus affecting multiple independent
> +rebuilds.  In particular, the required targets must not attempt to
> +write into ``HOME``.
> +
>  The targets are as follows:
> 
>  ``build`` (required)
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index 899f7e8..70b31bd 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -52,6 +52,10 @@ Unreleased.
>  copyright file, but it need not be if creating and maintaining a
>  copy of that information involves significant time and effort
> 
> +4.9
> +Required targets must not write outside of the unpacked source
> +package tree, except for TMPDIR (or /tmp if that is not set).
> +
>  10.1
>  Binaries should be stripped using
>  ``strip --strip-unneeded --remove-section=.comment 
> --remove-section=.note``

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

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

[Mattia Rizzolo]

On Sat, Oct 20, 2018 at 10:09:17AM -0700, Sean Whitton wrote:
> On Wed 17 Oct 2018 at 01:47AM -0700, Josh Triplett wrote:
> > Which is a good argument for them not being in /etc.
> Do we need to block this Policy change on moving these files out of
> /etc?  Whether or not we need to block the Policy change on that seems
> to be the main point of disagreement right now, though some are opposed
> on principle.

I haven't counted them, but to me it feels like there is no consensus at
all.  Even one of the proposed (smvc) said that he is happier to see
pbuilder fix /etc/hosts than having netbase.  And with the presence of
people being actively against netbase in build essential then I'd say
this policy change can't go on at all…

-- 
regards,
            Mattia Rizzolo

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


signature.asc
Description: PGP signature

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

[Mattia Rizzolo]

Hi,

On Mon, Aug 06, 2018 at 07:06:45PM +0800, Sean Whitton wrote:
> Here is the complete patch, for which I am seeking seconds:
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 9e7d79c..011893c 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -40,9 +40,25 @@ example, if building a package requires a certain 
> compiler, then the
>  compiler should be specified as a build-time dependency.
> 
>  It is not necessary to explicitly specify build-time relationships on a
> -minimal set of packages that are always needed to compile, link and put
> -in a Debian package a standard "Hello World!" program written in C or
> -C++. The required packages are called *build-essential*, and an
> +minimal set of packages that are always needed
> +
> +- to compile, link and put in a Debian package a standard "Hello
> +  World!"  program written in C or C++;
> +
> +- for the package build to resolve the system hostname to a
> +  fully-qualified domain name using the C standard library; and
> +
> +- for the package build to look up longstanding and conventionally
> +  available service and protocol names and numbers, either by directly
> +  reading /etc/services and /etc/protocols, or by using the
> +  corresponding functions from the C standard library. [#]_
> +
> +  (If the package needs to look up a more recent service or protocol,
> +  and certainly if the service or protocol was not listed in these
> +  files in the package's targeted Debian releases, an appropriate
> +  versioned build-dependency is needed.)
> +
> +The required packages are called *build-essential*, and an
>  informational list can be found in
>  ``/usr/share/doc/build-essential/list`` (which is contained in the
>  ``build-essential`` package).  [#]_
> @@ -757,6 +773,10 @@ according to this convention, the C source code of an 
> executable
>  ``debian/missing-sources/checksum/util.c``.
> 
>  .. [#]
> +   The functionality described in these last two list items is
> +   provided by the "netbase" package at the time of writing.
> +
> +.. [#]
> Rationale:
> 
> -  This allows maintaining the list separately from the policy
> 

I hereby disagree with this approach.
I think that if we were going this way, build-essential should just
start depending on netbase instead.

Changing the Policy wording to say that build-essential should also
provide networking base stuff it's probably fine though.

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.


Talking about the proposed wording: the text within parenthesis mentions
"versioned build-dependency", but the package it's talking about
(netbase, I suspect) it's only mentioned in the footnote, which is an
issue in my book.


On the note of /etc/hosts, I'm fixing the original bug rised by Simon
McVittie (that was triggered by tests.reproducible-builds.org not
resolving localhost) within pbuilder (#905307) btw.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Current plan for translating Policy

[Mattia Rizzolo]

On Mon, Jul 30, 2018 at 04:44:53PM +0800, Sean Whitton wrote:
> 6. When we have a translation of a substantial portion of Policy into
>language xx, add a new binary package debian-policy-xx that installs
>that translation to /usr/share/doc/debian-policy-xx

Please consider using /usr/share/doc/debian-policy/xx instead — also
considering Policy §12.3 (the relevant change made with v3.9.7).

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#795402: base-files: Please add Creative Commons license texts

[Mattia Rizzolo]

On Tue, Jul 10, 2018 at 03:36:25PM +0100, Jonathan Dowland wrote:
> Sure: https://salsa.debian.org/jmtd/policy/merge_requests/1
> 
> (MR #1? Wow)

You did the MR against your own fork instead of the original project ;)
(and the salsa project is not configured to accept MRs, so I suppose
Sean means a "regular patch" in the bug).

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump

[Mattia Rizzolo]

On Thu, Jun 28, 2018 at 12:58:28PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: Bug#891216: seconded 891216: Requre d-devel 
> consultation for epoch bump"):
> > Incorrect epochs are a nuisance at best.
> 
> The problem is that they are a permanent nuisance.  This discussion
> was prompted when someone caused significant trouble by *only* bumping
> the epoch.  (We have other text saying not to do that but I don't
> think that text would have prevented the error.)

They cause real issues, not just nuisances.  Check out the whole mariadb
situation, where a totally wrong epoch bump caused both maintainer to
not maintain anything anymore and now the debian packages are
incompatible with the rest of the world (not to mention the many
silently broken dependencies that who know when somebody will notice
them, but there must be some).


(I believe the trouble Ian is referring to is much minor, and it's the
case where an useless epoch bump in debian caused the ubuntu autosync
to fail due to reuse of filename - which has been "fixed" differently in
policy by forbidding epoch-free-version reuse)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#900679: nmu: Migrating developers-reference to Salsa and minor updates

[Mattia Rizzolo]

On Sun, Jun 03, 2018 at 07:13:47PM +0200, Aurélien COUDERC wrote:
> Sounds good to me.
> I've made you co-owner of the def ref editors group so please go ahead with 
> moving it to the Debian group.
> 
> I'm DM so I'd be interested in you giving me commit rights on the repo after 
> the move.

Done => https://salsa.debian.org/debian/developers-reference
And added you to the project.

-- 
regards,
            Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#900679: nmu: Migrating developers-reference to Salsa and minor updates

[Mattia Rizzolo]

On Sun, Jun 03, 2018 at 04:55:01PM +0100, Sean Whitton wrote:
> > I even dare to say there is no "devref maintainers" team at all, and
> > that if you actually wish to work on it you should go ahead, add
> > yourself to uploaders and do stuff.
> 
> And he is not inactive in Debian.

Yes, it was even me who filed the "please update the uploaders field"
bug for removing he, but the current maintainers didn't act on that bug.

> There was an upload by the current maintainer less than six months ago.
> It would surely be a hijack to add to
> uploaders without his explicit agreement.

You are talking about Hideki, whom "added himself" without much talking
on this list, if my memory serves correctly.
Anyway, CCing him here to see whether he would be fine with having a new
comaintainer (tbh, I'm not sure he is receiving the bug mails in any
way).  Also CCing lucas…

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#900679: nmu: Migrating developers-reference to Salsa and minor updates

[Mattia Rizzolo]

On Sun, Jun 03, 2018 at 12:01:44PM +0200, Aurélien COUDERC wrote:
> The repository is already up on Salsa at [0].
> I’ve left the master branch untouched as was on Alioth and created an
> nmu-3.4.19 branch with the changes above.
> The complete diff is at [1].
> 
> 
> [0] https://salsa.debian.org/dev-ref-team/developers-reference/
> [1] https://salsa.debian.org/dev-ref-team/developers-
> reference/compare/debian%2F3.4.19...nmu-3.4.19

tbh, I'd put the repo on the debian group.
devref has been quite poorly maintained in the last years, and most of
the changes effectively happened because a random DD with an interest
in updating a specific section just committed stuff and added
themselves to the uploaders list.

> Feel free to say if you think this is not a good idea or would better be done
> differently.

I even dare to say there is no "devref maintainers" team at all, and
that if you actually wish to work on it you should go ahead, add
yourself to uploaders and do stuff.


Incidentally, what's your interest for working on devref?  Surely you
have some other goal other than those very very minor changes…

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#891216: Requre d-devel consultation for epoch bump

[Mattia Rizzolo]

On Fri, Feb 23, 2018 at 01:26:01PM +, Ian Jackson wrote:
> Concretely,
> 
> epoch
> 
>   This is a single (generally small) unsigned integer. It may be
>   omitted, in which case zero is assumed. If it is omitted then the
>   upstream_version may not contain any colons.
>   -
>   - It is provided to allow mistakes in the version numbers of older
>   - versions of a package, and also a s previous version numbering
>   - schemes, to be left behind.
>   - package
>   +
>   + Epochs can help when the upstream version numbering scheme
>   + changes, but they must be used with care.  In Debian, please
>   + consult debian-devel when changing the epoch.
> 
>   ...
> 
> Note that the purpose of epochs is
>   - to allow us to leave behind mistakes in version numbering, and
> to cope with situations where the
>   + upstream
> version numbering scheme changes
>   + and to allow us to leave behind serious mistakes
> .
>   +
>   + Epochs should not usually be used when
>   + a package needs to be rolled back (use the +really convention)
>   + or to

This needs to be reworded.  "the +really convention" is probably not
really policy material (feels more like devref's) and therfore probably
not mentioned here.

> cope with
>   - It is not intended to
> version numbers containing strings of letters which the package
> management system cannot interpret (such as ALPHA or pre-), or with
> silly orderings.
>   +
>   + If you think that increasing the epoch is the right situation,
>   + please consult debian-devel before doing so
>   + (even in experimental).

And with this the mention of d-devel happened twice in your patch.



I'm very happy to second this idea, but I believe the actual text needs
to be improved.  I'll leave that to policy editors though, as it's
really not my field of competence :)
BTW, I believe that when you propose a patch like this, pretty much
everybody would like to see the filename and the hook delimiters (i.e.
everything git diff gives you).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#887771: debian-policy: No paragraph numbers in 4.1.3 policy.txt

[Mattia Rizzolo]

Control: reassign -1 python3-sphinx
Control: forcemerge 872868 -1

On Fri, Jan 19, 2018 at 03:08:15PM -0500, Scott Kitterman wrote:
> There are no pargraph numbers in policy.txt either on the web site and in the
> package.  This is a major issue for the text version of the policy since we
> use the paragraph numbers to reference specific parts of the policy in many
> places in the project.  It's required by reportbug for reporting serious bugs.
> I noticed the issue when looking up an issue while doing a New review for the
> FTP Team (in an environment where the other formats are not very usable).

Right, that's a long known issue due to a sphinx bug (that has very
recently been fixed upstream).

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Bug#886219: lintian should be less pedantic about latest policy version

[Mattia Rizzolo]

Control: forecemerge -1 886210
Control: tag -1 pending

the previous merge from Holger failed due to mismatching severities.

On Wed, Jan 03, 2018 at 02:24:46PM +, Sean Whitton wrote:
> Mattia and I are in significant disagreement over this and both feel
> quite strongly about the topic (hence the severity bump -- I think this
> moderately important for Debian).  In this e-mail I want to lay out in
> full detail why I would like to see this change in Lintian.

Whilst that might be true, I don't think it's actually worth discussing,
we can get along pretty fine anyway :)
But let me answer some of your points.

> Let me first say exactly what change I'd recommend:
> 
> - out-of-date-standards-version should be I: or P: instead of W:

This happened:
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=97912d84cf49d35188ac91ed3a50357095400386
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=098ceec8af75aae4d228c634fc1b19224b0e9273
It will be in the next Lintian release.

So please let's not lose our heads in discussing this to death.

> > remember 3.9.{6,7,8} changes by heart, I can't with the latest…).  But
> > it doesn't mean that I as a maintainer should make an effort to keep
here I forgot a negation  ↑
It should read "it doesn't mean that I shouldn't make an effort".

> > up and check for Policy compliance at each package update.
> 
> You argue that
> - whenever a maintainer uploads a package and S-V is out-of-date, they
>   should work through the relevant entries in the Policy Manual's
>   Upgrading Checklist

Yes.

> - Policy Manual releases should be infrequent to avoid maintainers
>   having to do this too often

That would be nice, but I'm don't have a strong opinion on it.

> On the contrary, I argue that
> - the only thing that should be /required/ when uploading a package is
>   making the package non-trivially better than the current version in
>   unstable
> - updating S-V should never block uploading other improvements

I agree with all of this.  I say that a maintainer *should* do that
work.  If he doesn't because he believe his other changes are more
important and he wants to upload nonetheless, by all means, please do!
But then, be prepared for people and tools who look at your package to
notice that nobody checked whether it complies with the latest Policy.
That's all about it.  You haven't done something that you should do,
that's reflected.
For example, I often deferred bumping std-ver on packages which lagged a
lot behind and it would have take me too much time to through several
screenful of upgrading checklist, because I believed delivering other
fixes were more important at that time.

I personally am not too attached to lintian severities.  I keep all
pedantic and wishlist tags on, and always go through all of them
whenever I upload anything.

> - there are good reasons to release the Policy Manual frequently, and
>   this should not be blocked by the expectation that everyone respond to
>   those new versions in their very next uploads.

Sure.

> ISTM that requiring maintainers to check packages against the upgrading
> checklist before they can upload other improvements is an example of
> requiring prerequisite work of volunteers that is not needed for
> co-ordinating with other volunteers.  So we should not require it.

Agree, we should not require it.  But I believe we should definitely
(more or less strongly) recommend it.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

[Mattia Rizzolo]

Package: debian-policy

Nowadays it's common to see stand alone license paragraphs like these:

|License: GPL-2+
| On Debian systems the full text of the GPL-2 can be found in
| /usr/share/common-licenses/GPL-2

or

|License: GPL-2+
| This program is free software; you can redistribute it and/or modify
| it under the terms of the GNU General Public License as published by
| the Free Software Foundation; either version 2 of the License, or
| (at your option) any later version.
| .
| This program is distributed in the hope that it will be useful,
| but WITHOUT ANY WARRANTY; without even the implied warranty of
| MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
| GNU General Public License for more details.
| .
| You should have received a copy of the GNU General Public License along
| with this program; if not, write to the Free Software Foundation, Inc.,
| 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
| .
| On Debian systems, the complete text of the GNU General Public
| License version 2 can be found in `/usr/share/common-licenses/GPL-2'.


First of all, I'd like policy to stop being unclear on this matter, or
state whether the correct form is the former or the latter.

Secondly (which would overcome the first matter as well), I'd like to
propose to just stop wasting time/bytes in dumping such useless
boilerplte in our `debian/copyright`s when a license is available in
/usr/share/common-licenses.
I'm proposing either a new License-File field to be used in stand-alone
license paragraphs, or just whitelist some license identifiers as
"well known" and allow them to not need stand alone license paragraphs
at all (i.e. a file paragraph with 'License: GPL-2+' would be fine
without any extended license specification).

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#859649: debian-policy: Please add CC0-1.0 to common-licenses

[Mattia Rizzolo]

Hi,

> > diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst index
> > dc02bc6..1de221f 100644 --- a/policy/ch-docs.rst +++
> > b/policy/ch-docs.rst @@ -208,11 +208,12 @@ important because
> > ``copyright`` files must be extractable by mechanical
> >  means.
> >
> >  Packages distributed under the Apache license (version 2.0), the
> > -Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
> > -(versions 2, 2.1, or 3), the GNU FDL (versions 1.2 or 1.3), and the
> > -Mozilla Public License (version 1.1 or 2.0) should refer to the
> > -corresponding files under ``/usr/share/common-licenses``, [#]_ rather
> > -than quoting them in the copyright file.  +Artistic license, the
> > Creative Commons CC0-1.0 license, the GNU GPL +(versions 1, 2, or 3),
> > the GNU LGPL (versions 2, 2.1, or 3), the GNU FDL +(versions 1.2 or
> > 1.3), and the Mozilla Public License (version 1.1 or +2.0) should
> > refer to the corresponding files under
> > +``/usr/share/common-licenses``, [#]_ rather than quoting them in the
> > +copyright file.
> >
> >  You should not use the copyright file as a general ``README``
> >  file. If your package has such a file it should be installed in
> > @@ -341,6 +342,7 @@ please see :ref:`s-dpkgchangelog`.
> >  .. [#]
> > In particular, ``/usr/share/common-licenses/Apache-2.0``,
> > ``/usr/share/common-licenses/Artistic``,
> > + ``/usr/share/common-licenses/CC0-1.0``,
> > ``/usr/share/common-licenses/GPL-1``,
> > ``/usr/share/common-licenses/GPL-2``,
> > ``/usr/share/common-licenses/GPL-3``,

Seconded.

(just know that I'd love to see as many long text licenses there
as possible :))

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#881431: debian-policy: Clarify a version number is unique field

[Mattia Rizzolo]

On Sat, Nov 11, 2017 at 07:07:48PM +0100, Christoph Biedl wrote:
> Version number re-usage happens, probably always by accident. In the
> past, before the advent of slugs to mark security uploads and the like,
> this was more likely to happen, and a long time ago my src:file package
> was affected by that as well[1]. Unfortunately, there was such an event
> even in 2017, see #876633.

There is another reuse that you haven't considered here: reusing a
version (or even, a lower version) after a package has been removed
from the archive (and here I mean, remove from all of oldoldstable,
oldstable, stable, testing, unstable, experimental releases).  At that
point dak doesn't know of it anymore and allows everything.

TTBOMK that happened in the past several times.

Do you want to forbid such "reuse" as well?

> So I'd like to suggest an addition to "3.2. The version of a package",
> for clarification, wording in the simplest form:
> 
> | For any package, a version number must never be re-used.
> 
> What I'd like to express but I guess is a bit too long:
> 
> | Unless bitwise identical, no two files that share the base name and
> | have a version number in it may exist anywhere in the archives, ever.

That's all good and nice, but it requires some techinical block on the
archive software for it not to happen.

> Also I feel a temptation to implement an according check in the
> auto-reject machinery at ftp-master. But that's for another day.

Personally I believe that should come *before* having it in policy.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#881432: debian-policy: Please clarify postinst invocation upon first installation

[Mattia Rizzolo]

On Sat, Nov 11, 2017 at 07:08:41PM +0100, Christoph Biedl wrote:
> 6.5. Summary of ways maintainer scripts are called
> 
> in the paragraph after
> 
> "postinst configure most-recently-configured-version"
> 
> Suggested wording:
> 
> | If this package was prevously uninstalled, the
> | "most-recently-configured-version" string is empty.

Seconded.

> Reading src/configure.c in dpkg, this should be technically correct.

Isn't there some dpkg manpage or document also nicely documenting this
somewhere?  I know guillem went to great effort of documenting how dpkg
behaves.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#846970: Patch to document Build-Indep-Architecture field

[Mattia Rizzolo]

On Sat, Oct 14, 2017 at 11:15:10AM -0700, Sean Whitton wrote:
> I am seeking seconds for the following patch.

Thank you for working on this!

> - I've included the ability to specify the architectures on which the
>   package is known /not/ to build.  This seems useful because in many
>   cases the architectures that don't work is precisely what the
>   maintainer knows, and wants to document in machine-readable form.  I
>   don't buy the argument that it creates any additional uncertainty

Whilst you did this, I think the proper syntax is not clear by your
wording.  For example, I take that
Build-Indep-Architecture: !amd64
means "this thing builds everywhere except amd64".  But then, how can I
specify "it builds on all 32-bit architectures except i386", for
example?
See the following inline comments:

> +Debian machine architectures.  If specified, it should be either
> +
> +-  A unique single word identifying a Debian machine architecture as
^^
> +   described in :ref:`s-arch-spec`.
> +
> +-  An architecture wildcard identifying a set of Debian machine
> +   architectures, see :ref:`s-arch-wildcard-spec`.

This also implies a single word.

But…

> +maintainer's control.  The specification should entail that the
> +architecture-independent packages are buildable on at least two
> +architectures.

this is not compatible with the above: both cases say that you have to
provide at most one word, but how can you provide at least two
architectures if you have only one word and can't use a wildcard?
And if you can provide multiple words, you need to specify a separator
(whitespace vs comma, I suppose).

Also, I dislike the sentence in itself, I believe it should be more
straightforward in conveying its meaning of "pretty please at least two
arch".

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified

[Mattia Rizzolo]

On Sat, Oct 14, 2017 at 11:36:55AM -0700, Sean Whitton wrote:
> diff --git a/policy.sgml b/policy.sgml
> index b8db0ab..d0baa1b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -7697,8 +7697,9 @@ strip --strip-unneeded your-lib
> Shared object files (often .so files) that are not
> public libraries, that is, they are not meant to be linked
> to by third party executables (binaries of other packages),
> -   should be installed in subdirectories of the
> -   /usr/lib directory.  Such files are exempt from the
> +   should be installed in subdirectories of the /usr/lib
> +   or /usr/lib/triplet directories (see
> +for a definition).  Such files are exempt from the
> rules that govern ordinary shared libraries, except that
> they must not be installed executable and should be
> stripped.

Seconded.


Triviality: could you please (in the changelog, upgrading checklist,
etc) word this change to mean "allow private libraries to be placed in a
multiarch location" rather than "disallow private libraries to be places
directly under /usr/lib/" which very weirdly seemed to be what
most of the mails in this bug are about?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#877697: debian-policy: discourage using all 4 digits numbers in Standards-Version

[Mattia Rizzolo]

On Wed, Oct 04, 2017 at 03:38:30PM +0200, Bill Allombert wrote:
> what are the practical negative effect of
> putting the 4th digit in the Standards-Version field ?

I can't really think of any, except consistency across packages, and
perhaps being a tad less confusing to see a 4th digit when you are
always used to see 3.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#877697: debian-policy: discourage using all 4 digits numbers in Standards-Version

[Mattia Rizzolo]

Package: debian-policy
Version: 4.1.1.0

Policy § 5.6.11, after describing the meaning of the digits in the
policy version, reads:

| Thus only the first three components of the policy version are
| significant in the Standards-Version control field, and so either
| these three components or all four components may be specified. [5]


Now, I've only got the impressions that packages should avoid using the
4th digit in their Standards-Version field, as that number has no
meaning when it comes to normative stuff.  I've seen on IRC/MLs all kind
of comments saying that the 4th digit should be avoided, and most
packages avoid it indeed, but this wording in the policy makes me feel
like it's pretty much the same.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#874206: debian-policy: allow a trailing comma in package relationship fields

[Mattia Rizzolo]

On Tue, Sep 05, 2017 at 10:28:37AM -0700, Josh Triplett wrote:
> I didn't even know this syntax was allowed, and now that I do I'd love
> to use it.

Happy to have confirmation that some clarity is needed :)

> Do you know how long this has worked, in apt and dpkg?

No idea about apt, but dpkg's maintainer told me (shortly after having
filed this bug) that dpkg supported it basically since ever; quoting
him:

 mapreri: the trailing comma syntax *must* be supported,
  otherwise things like «foo, ${substvar}» with an empty
  substvar would break havoc
 mapreri: well dpkg does not accept it but the perl code does
  and remove it before generating the DEBIAN/control files so
  it's all good
 mapreri: I'll clarify the deb-src-control man page

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#874206: debian-policy: allow a trailing comma in package relationship fields

[Mattia Rizzolo]

Package: debian-policy
Version: 3.9.8

I use the `wrap-and-sort` tool to keep my list of dependencies neatly
sorted and wrapped.  In particular, I use the `-t` flag to have a
trailing comma at the end of the list.  For example

Build-Depends:
 foo,
 bar,
Homepage: …

There, notice how there is a comma after "bar", the last item of the
list.

I've heard several people in several forums assert that such syntax is
totally undocumented, despite being accepted by all tools I know of.
Indeed, policy doesn't explicitly allow (but AFAIK neither disallow)
such syntax.  Nonetheless, I'd prefer if some tweaks could be done to
the policy to stop these annoying comments :)

I think such stuff belongs to § 7.1 "Syntax of relationship fields", but
I can't really image what to write and where.



FTR, this bug was triggered by <https://bugs.debian.org/760021#20>.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

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

[Mattia Rizzolo]

On Wed, Aug 30, 2017 at 12:56:30PM +0200, Ondrej Novy wrote:
> 2017-08-26 21:49 GMT+02:00 Sean Whitton <spwhit...@spwhitton.name>:
> > Actually, this depends on which autodep8 module you want to use.  I know
> > that my elpa module runs the tests even if the Testsuite: field is
> > missing, for example.
> 
> i think this is true for local build environment only, but not for
> ci.debian.net. If you want your autodep8 tests to run on Debian CI, you
> need to explicitly enable them.

Indeed.  Alternatively, you need to reach out to the ci.d.n admins: they
maintain a manual list of packages for which to run a specific autodep8
thing (which is what has been done for all the things currently in
autodep8 to have them enabled right away for all packages).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: [policy] 01/03: correct description of Testsuite:

[Mattia Rizzolo]

Wait a second...

On Tue, 29 Aug 2017, 12:01 a.m. Sean Whitton 
wrote:

> commit 18c8f975c6351c0c720804b7c4a9801561c94398
> Author: Sean Whitton 
> Date:   Sat Aug 26 12:44:44 2017 -0700
>
> correct description of Testsuite:
>
> - dpkg adds to binary control files
>

Not "binary"... It's added to the .dsc, therefore is the *source* control
file!

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
> +This field is automatically added to Debian binary control files by
>

Also here.

+``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.
>

Besides, I'm confused as to whether this "source package control file"
refers to the .dsc or debian/control (it's probably explained on other
parts of the chapter that I haven't taken the time to read now though)


(Unsigned as I'm writing it from my mobile, but I didn't want to let this
through and forget..)

Bug#873346: Updating the developers-reference Uploaders list

[Mattia Rizzolo]

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

Marc 'HE' Brockschmidt <h...@debian.org> has not been working on
the developers-reference package for quite some time.

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

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

Thanks.

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#872895: debian-policy: Split html for policy lost

[Mattia Rizzolo]

On Tue, Aug 22, 2017 at 12:10:36PM -0700, Sean Whitton wrote:
> - it would be nice to include the multi-page rendering in the package

More than nice, please.  I don't really deal with huge single-page
documents.  Besides you wrote:
> The single page output is much more useful to casual readers wanting
> to look something up
I deem this completely subjective, please don't assume such assertion as
facts.  Also, I don't consider myself a "causual reader" and when I want
to read something up I know what's the name of the paragrah, pick it
from the index and then head to the relevant, single page.

> - since we're publishing only the single-page version on www.debian.org,
>   we need to rewrite the links

Please do publish both.

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7

[Mattia Rizzolo]

On Mon, Aug 21, 2017 at 05:22:12PM -0700, Sean Whitton wrote:
> Commenting on Charles' patch, I think that it would be clearer to have
> the 'should' and 'must' requirements in separate sentences.

Good idea.

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index f706a13..89b355a 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -99,10 +99,11 @@ later reconfigure the package without losing the changes 
> you made.
>  Debian changelog: ``debian/changelog``
>  --
>  
> -Changes in the Debian version of the package should be briefly explained
> -in the Debian changelog file ``debian/changelog``.  [#]_ This includes
> -modifications made in the Debian package compared to the upstream one as
> -well as other changes and updates to the package.  [#]_
> +Every source package must include the Debian changelog file,
> +``debian/changelog``.  Changes in the Debian version of the package
> +should be briefly explained in this file.  [#]_ This includes
> +modifications made in the Debian package compared to the upstream one
> +as well as other changes and updates to the package.  [#]_
>  
>  The format of the ``debian/changelog`` allows the package building tools
>  to discover which version of the package is being built and find out

LGTM, seconded.


That said, I'd expect the upgrade-checklist to say that this change is
about clarifying that debian/copyright must exist (where before it was
"fine" not existing).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: Upstream Tarball Signature Files

[Mattia Rizzolo]

On Fri, Aug 18, 2017 at 07:48:24AM -0400, Daniel Kahn Gillmor wrote:
> I confess that i've been taking the boring/silly/cheating way out and if
> upstream ships a detached binary signature as foo-1.2.3.tar.gz.sig, i've
> just been manually renaming it to foo_1.2.3.orig.tar.gz.asc (without
> even converting its contents to ASCII-armored form) and the rest of the
> toolchain seems to just happily accept it -- it'd be even nicer if dpkg
> and/or uscan was to normalize the contents to match the file extension.

That's because TTBOMK there is *nothing* atm actually validating that
file, and AFAIK (please correct me if I'm wrong) dpkg-source just picks
up whatever file, no matter the contents.

> Lastly, it's conceivable that we might want to take an already-armored
> .asc, and "launder" the armor, to stabilize it (e.g. stripping
> non-cryptographically-relevant comments, other weird OpenPGP packets,
> etc, which could all be stuffed into the detached signature).

I'd love if something did this for me, pretty much like I'd love
something like that does a pretty output to debian/upstream/signing-key
like
https://sources.debian.net/src/inkscape/0.92.2-1/debian/upstream/signing-key.asc/
(that's
https://anonscm.debian.org/git/reproducible/misc.git/tree/dump-gpg-keys.sh)

IOW: Guillem: I second merging that sig→asc converter into dpkg-source!
:)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#844431: Revised patch: seeking seconds

[Mattia Rizzolo]

On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk  wrote:

> Tracker:
> https://tracker.debian.org/pkg/hsqldb1.8.0
> "Does not build reproducibly during testing"
>

And indeed it's not reproducible according to policy: it's storing the
build user at the very least.

>
> Let's look at the mdds package, that has red unreproducible entries in
> the maintainer dashboard:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mdds.html
>
> mdds is unreproducible only in sid since more things (including the
> build path) are varied there. The information behind "differences"
> confirms that the build path is the only issue.
>
> According to policy, mdds is reproducible.
>

And indeed its unreproducibility is not reported in tracker and ddpo (DMD
does because it's using a source data that includes everything, not just
the state we want to push.  But then, DMD has a tendency to show *lots* of
things, if you disagree with it, please take it to the DMD maintainer, not
us).

Unless policy is supposed to be completely detached from reality,
> the criteria for claiming in various places that a package is
> unreproducible have to match the policy definition of reproducibility.
>

IMHO, you are arguing about a non existent issue.  I believe we are always
being reasonable, otherwise I'd like to ask you to point us to actual
situation where we could have acted better.  Yes, I'm aware of the
src:libreoffice case.

Bug#870899: devref: priority:extra is deprecated, please stops uggesting it

[Mattia Rizzolo]

Package: developers-reference

Starting with Policy 4.0.1 the Priority:extra is deprecated.
https://browse.dgit.debian.org/debian-policy.git/commit/?id=4b3e61ac3fa06d8b82433e09a76f42a4f8859306

Therefore, please stop recommending/suggesting it in devref §6.7.7 (best
practices for transitional packages) and §6.7.9 (best practices for
debug packages).

I suggest instead to recommend priority:optional.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#863729: debian-policy: please use the cgit link in Vcs-Browser

[Mattia Rizzolo]

On Tue, May 30, 2017 at 04:22:06PM +0200, Ferenc Wágner wrote:
> Your control file specifies
> https://anonscm.debian.org/git/dbnpolicy/policy.git
> as Vcs-Browser, but the gitweb interface gives "Bad object id:" messages
> when clicking into the shortlog section.

How is gitweb involved in any way here and where do you see any
"shortlog" section in
https://anonscm.debian.org/git/dbnpolicy/policy.git ?

Which link are you clicking on?

-- 
regards,
    Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#850729: debian-policy: Documenting special version number suffixes

[Mattia Rizzolo]

On Mon, Jan 09, 2017 at 07:15:57PM +0100, Christoph Biedl wrote:
> ~deb+
>   Backport to the given (num1) distribution.

~deb+ is used for "backports" of something to stable through
point release or security, where that's more convenient than cherry
picking a patch and upload a +deb+.

Backports use ~bpo+ instead.

> Also, I wouldn't mind to document some suffixes used downstream,
> especially Ubuntu who have sometime "-u"-ish. But I'm not aware
> of their schema in the details.

'ubuntu' is the schema, to be appended to whatever debian version
that's based on (-0 is used as a revision if it's not coming from debian
but it's ubuntu only).   might be more convoluted than just an
unsigned integer for "stable uploads" and backports, for sorting and
clearity reasons (e.g. ubuntu16.04.2, that's the second (or third, if
you start counting from 0, afaik there is no rule here) revision of that
version uploaded directly to 16.04)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

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

[Mattia Rizzolo]

On Sun, Jan 08, 2017 at 12:02:38PM -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 john@example.com
>  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#850646: [copyright-format] Allow https version of Format URI

[Mattia Rizzolo]

On Sun, Jan 08, 2017 at 11:42:31AM -0800, Russ Allbery wrote:
> We probably should just make a 1.1 standard with various other proposed
> fixes

Yes.

> but in the meantime, I propose the attached patch as a stopgap
> for the next release.  This just documents that either URI is valid and
> both refer to the same format.
> 
> It's not strictly correct to do this as a revision of the 1.0 standard,
> but since it's backwards-compatible, I don't think it should pose any
> practical problems.

Please do it, I second this.

> +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 due to Debian's general move towards using
> +https for all project URLs.

I'd not say "Debian's general move towards using https for all projet
URLs", because it's hardly a Debian thing that plain text http is bad,
and I don't think a specification format is the place to explain it.
IMHO just drop that whole sentece; saying that both values are allowed
is already enough, no need to explain further.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#833177: 9.3.3.2: Remove /etc/init.d/

[Mattia Rizzolo]

On Mon, Aug 01, 2016 at 08:22:19PM +0200, Ondřej Nový wrote:
> 9.3.3.2 Running initscripts
> ---
> 
> Please remove usage of "/etc/init.d/package " as alternative for
> invoke-rc.d
> 
> invoke-rc.d is essential

right.

> diff --git a/policy.sgml b/policy.sgml
> index 9cd182b..6395dbb 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -7773,13 +7773,8 @@ test -f program-executed-later-in-script || 
> exit 0
> /etc/init.d/package
> action in their postinst
> and prerm scripts to:
> -   
> - if which invoke-rc.d >/dev/null 2>&1; then
> - invoke-rc.d package action
> - else
> - /etc/init.d/package action
> - fi
> -   
> +   invoke-rc.d package
> +       action
>   
>  
>   


Seconded.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

[Mattia Rizzolo]

On Sun, Jan 01, 2017 at 11:15:36PM -0800, Russ Allbery wrote:
> I massaged the wording a bit.  Here's what I committed for the next
> release:
> + Each binary package built from this source package has a
> + corresponding paragraph, except for any automatically-generated
> + debug packages that do not require one.

I now wonder, debhelper is adding this field to the binary control of
those automatically generated packages:
-DAuto-Built-Package=debug-symbols
Should this be documented too?  (Also dak accepts such packages not
listed in control only if they have such field, see
https://anonscm.debian.org/git/mirror/dak.git/tree/daklib/checks.py#n288
https://anonscm.debian.org/git/mirror/dak.git/tree/daklib/utils.py#n1372

-- 
regards,
        Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#780725: Bug#780729: Bug#780725: PATH used for building is not specified

[Mattia Rizzolo]

Control: severity 780729 wishlist
Control: block 780729 by 780725

On Samstag, 28. März 2015, gregor herrmann wrote:
 Additionally I'd like to mention that pbuilder doesn't set (as in
 hard-code) $PATH somewhere; it recommends a default in
 /etc/pbuilderrc which can be changed there or set in ~/.pbuilderrc.

Apart from that i find pbuilder default very sane and sbuild default very bad
(no, /usr/local on buildds is ugly, imho)
/usr/games is really too weird to be required during a build.  unluckily we
already changed pbuilder config in jenkins.d.n and so i don't know whether
there are other packages requiring it.


I'll be happy to change align to the policy once it's clear, because i also
don't believe that definition of PATH is right for buildds.
Until them, i'll stick this as a blocked wishlist bug.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: Digital signature