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

[Guillem Jover]

On Tue, 2017-08-22 at 17:26:32 -0700, Sean Whitton wrote:
> On Tue, Aug 22 2017, Guillem Jover wrote:
> > I guess there are two problems here, one is indeed completely losing
> > the multi-page rendering from the package. The other is the default
> > change in the web site. IMO the best solution, and what is customary,
> > is to present both (or more) rendering and let the user select:
> >
> >   [HTML one-page] [HTML multi-page] [PDF] [EPUB]
> 
> So you'd like https://www.debian.org/doc/debian-policy/ to be a menu?

No,  which already
contains such menu. I'd rather see no change to the default and just
see the multi-page one added as an additional "format", so that we do
not break links etc. It's very common, and it's been so for people to
post URLs to the multi-page URLs BTW. I think having to add lots of
redirects would be counter-producive.

Thanks,
Guillem

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

[Bastien ROUCARIÈS]

Package: debian-policy
Version: 4.0.1.0
Severity: normal

get-orig-source should include an example.

If you use uscan this is safe and policy compliant (maybe opening a bug against 
dpkg-dev to get this rule by default)
cd "$(subst ",\",$(dir $(lastword $(MAKEFILE_LIST/.." && uscan --destdir 
$(subst ",\",$(CURDIR)) #" 

We have a bug report for lintian asking for checking unsafe uscan, so I was 
creating a compliant version

A footnote is suffisant

signature.asc
Description: This is a digitally signed message part.

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

[Russ Allbery]

Osamu Aoki  writes:

> After all the discussion, Policy 4.1.0 goes as:

> | 4.11. Optional upstream source location: debian/watch¶
> | 
> | This is an optional, recommended configuration file for the uscan
> | utility which defines how to automatically scan ftp or http sites for
> | newly available updates of the package. This is also used by some Debian
> | QA tools to help with quality control and maintenance of the
> | distribution as a whole.
> | 
> | If the upstream maintainer of the software provides OpenPGP signatures
> | for new releases, including the information required for uscan to verify
> | signatures for new upstream releases is also recommended. To do this,
> | use the pgpsigurlmangle option in debian/watch to specify the location
> | of the upstream signature, and include the key or keys used to sign
> | upstream releases in the Debian source package as
> | debian/upstream/signing-key.asc.
> | 
> | For more information about uscan and these options, including how to
> | generate the file containing upstream signing keys, see uscan.

> Please note few things which I failed to share:

> The current uscan supports both 
>  debian/upstream/signing-key.asc
>  debian/upstream/signing-key.pgp

> Now, if debian/upstream/signing-key.asc is used, uscan converts it to
> /signing-key.gpg by gpg for use with gpgv to check signature.
> (I think the same goes with dpkg-source).  It looks extra CPU power
> waste but not a big deal. I do this conversion since no documentation
> mention keyring can be ascii armored for gpgv.

> The updated uscan will support debian/upstream/signing-key.asc only and
> internally convert it /signing-key.gpg.  I will make uscan to
> convert other formats to this policy compliant *.asc.  Also make noise
> to the maintainer to push them to policy 4.1.0

Note that this Policy language is carefully written to make it perfectly
fine for uscan to support all the things it currently supports, since it
only talks about what Policy recommends the maintainer does.  So don't
feel any obligation to change what uscan is doing on Policy's account
here.

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

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

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

[Osamu Aoki]

Hi,

After all the discussion, Policy 4.1.0 goes as:

| 4.11. Optional upstream source location: debian/watch¶
| 
| This is an optional, recommended configuration file for the uscan
| utility which defines how to automatically scan ftp or http sites for
| newly available updates of the package. This is also used by some Debian
| QA tools to help with quality control and maintenance of the
| distribution as a whole.
| 
| If the upstream maintainer of the software provides OpenPGP signatures
| for new releases, including the information required for uscan to verify
| signatures for new upstream releases is also recommended. To do this,
| use the pgpsigurlmangle option in debian/watch to specify the location
| of the upstream signature, and include the key or keys used to sign
| upstream releases in the Debian source package as
| debian/upstream/signing-key.asc.
| 
| For more information about uscan and these options, including how to
| generate the file containing upstream signing keys, see uscan.

Please note few things which I failed to share:

The current uscan supports both 
 debian/upstream/signing-key.asc
 debian/upstream/signing-key.pgp

Now, if debian/upstream/signing-key.asc is used, uscan converts it to
/signing-key.gpg by gpg for use with gpgv to check
signature.  (I think the same goes with dpkg-source).  It looks extra
CPU power waste but not a big deal. I do this conversion since no
documentation mention keyring can be ascii armored for gpgv.

The updated uscan will support debian/upstream/signing-key.asc only and
internally convert it /signing-key.gpg.  I will make uscan to
convert other formats to this policy compliant *.asc.  Also make noise
to the maintainer to push them to policy 4.1.0

Regards,

Osamu

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

[Russ Allbery]

Bastien ROUCARIÈS  writes:

> get-orig-source should include an example.

> If you use uscan this is safe and policy compliant (maybe opening a bug
> against dpkg-dev to get this rule by default)

> cd "$(subst ",\",$(dir $(lastword $(MAKEFILE_LIST/.." && uscan --destdir 
> $(subst ",\",$(CURDIR)) #" 

> We have a bug report for lintian asking for checking unsafe uscan, so I
> was creating a compliant version

> A footnote is suffisant

I'm reasonably fluent in shell and make, and I still have absolutely no
idea what that does.

Is there any way that we could help people out and have the correct thing
to do be much, much simpler?  Just a single command invocation?

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

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

[Russ Allbery]

roucaries bastien  writes:

> you call the rules with something (using shebang or directly) make -f
> somepath/package/debian/rules, uscan need to be excuted on
> somepath/package/.

Oh, I see the edge case this is trying to handle.

I'll be honest: I'm personally more inclined to just drop get-orig-source
entirely than to try to handle special cases like this.  I feel like the
target has outlived its usefulness and it would be better to just enhance
uscan to support repacking scripts.  (And people can still keep the target
if they want; I'm not saying people need to remove it.  I just question
whether it's useful for Policy to bless it and try to standardize it,
since I'm dubious it's an important part of the workflow to try to
standardize.)

But that said, I think your feeling that this should go into dpkg-dev's
makefile fragment is the right one, and then we can put something much
simpler in Policy that assumes the dpkg-dev interface.  That doesn't solve
the problem for packages older than that version of dpkg-dev, but we can
probably just note that.

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

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Russ Allbery]

Control: tags -1 patch

Scott Kitterman  writes:
> On January 8, 2016 12:26:24 PM EST, Russ Allbery  wrote:
>> Scott Kitterman  writes:

>>> As is currently being discussed on #debian-devel, the git:// protocol
>>> is insecure, but is what is normally used in Vcs-git fields in Debian
>>> packages.

>>> For git, it would be far better to used https://, but I don't think
>>> policy is completely clear that is OK since it says to use the
>>> "version control system's conventional syntax".  For git, that's
>>> arguably git:// even though it's a security risk.

>>> Please see the attached patch.  Although the diff is slightly noisy,
>>> the patch only adds one word.

>> I would rather add a new sentence saying that ideally the URL should
>> use a secure transport mechanism.  Right now, with this rephrasing, it
>> sort of implies that if there's no encrypted transport, you shouldn't
>> use this field.  It used to be that serving Git over HTTPS was a huge
>> pain and disabled a bunch of features, so some folks may just not have
>> bothered to ever set that up.

> Sounds good to me.  My proposal was an attempt at a minimal change.  I
> think what you're suggesting is better.

Here's a proposed diff for this.  I avoided using the ambiguous term
"secure" in favor of "confidentiality," which I think is the security
property we're aiming for here.  ("Integrity protection" is even more
desirable, but confuses matters since the Git protocol does arguably
provide that even over git:// and Git repositories can provide that other
ways, such as with signed tags.)

Seconds?

--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -962,6 +962,10 @@ repository where the Debian source package is developed.
 
 More than one different VCS may be specified for the same package.
 
+For both fields, any URLs given should use a scheme that provides
+confidentiality (``https``, for example, rather than ``http`` or ``git``)
+if the VCS repository supports it.
+
 .. _s-f-Package-List:
 
 ``Package-List``

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

Processed: Re: Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #810381 [debian-policy] Update wording of 5.6.26 VCS-* fields to recommend 
encryption
Added tag(s) patch.

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

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 661928 ...

[Debian Bug Tracking System]

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

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

> usertags 661928 = informative
Usertags were: informative proposal.
Usertags are now: informative.
> tags 661928 + pending
Bug #661928 [debian-policy] debian-policy: recipe for determining shlib package 
name
Added tag(s) pending.
> thanks
Stopping processing here.

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

Bug#871534: debian-policy: Clarify whether mailing lists in Maintainers/Uploaders may be moderated

[Russ Allbery]

Per the message below, I propose to close this bug because I think this is
already addressed reasonably well.  (There's probably some room to offer
advice to maintainers on how to run the mailing list, but that feels more
like devref material than Policy material.)

Chris, any objections?  Am I missing some aspect of your original bug
report?

Russ Allbery  writes:

> My personal feeling is that the current vagueness is a feature rather
> than a bug.  I think a moderated mailing list is fine *if* the
> moderation queue is very promptly processed, but not okay if the
> moderation queue is just a place for messages to go to die.

> I feel like Policy already strikes a fairly good balance here:

> The maintainer must be specified in the Maintainer control field
> with their correct name and a working email address. The email
> address given in the Maintainer control field must accept mail from
> those role accounts in Debian used to send automated mails regarding
> the package. This includes non-spam mail from the bug-tracking
> system, all mail from the Debian archive maintenance software, and
> other role accounts or automated processes that are commonly agreed
> on by the project.

> and also note the footnote, which directly addresses moderated mailing
> lists:

> A sample implementation of such a whitelist written for the Mailman
> mailing list management software is used for mailing lists hosted by
> alioth.debian.org.

> This language dates from an earlier bug about moderated mailing lists
> from ftp-master, and was the result of that bug discussion.

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

Bug#661928: debian-policy: recipe for determining shlib package name

[Russ Allbery]

Russ Allbery  writes:
> Jakub Wilk  writes:

>> The actualy lintian code is:

>> foreach my $expected_name (@sonames) {
>> $expected_name =~ s/([0-9])\.so\./$1-/;
>> $expected_name =~ s/\.so(?:\.|\z)//;
>> $expected_name =~ s/_/-/g;
>> if ((lc($expected_name) eq $pkg)
>> || (lc($expected_name) eq $base_pkg)) {
>> $match_found = 1;
>> last;
>> }
>> }

>> This can be translated to the following sed command:

>> LC_ALL=C sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/\L&/'

> And presumably also needs the:

> objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n 
> -e's/^[[:space:]]*SONAME[[:space:]]*//p'

> part to extract the SONAME in the first place.

Sean and I talked about this at DebConf and agreed that it made sense to
add this footnote now, although it would still be great if there were some
implementation of this elsewhere we could just point to.

I've applied the following, which also fixes some formatting issues (we'd
lost the italics on soversion).

diff --git a/policy/ch-sharedlibs.rst b/policy/ch-sharedlibs.rst
index 15bba3b..2acb909 100644
--- a/policy/ch-sharedlibs.rst
+++ b/policy/ch-sharedlibs.rst
@@ -59,19 +59,19 @@ the shared library packages.
 Run-time shared libraries
 -
 
-The run-time shared library must be placed in a package whose name
-changes whenever the ``SONAME`` of the shared library changes. This
-allows several versions of the shared library to be installed at the
-same time, allowing installation of the new version of the shared
-library without immediately breaking binaries that depend on the old
-version. Normally, the run-time shared library and its ``SONAME``
-symlink should be placed in a package named librarynamesoversion, where
-soversion is the version number in the ``SONAME`` of the shared library.
-Alternatively, if it would be confusing to directly append soversion to
-libraryname (if, for example, libraryname itself ends in a number), you
-should use libraryname-soversion instead.
-
-To determine the soversion, look at the ``SONAME`` of the library,
+The run-time shared library must be placed in a package whose name changes
+whenever the ``SONAME`` of the shared library changes. This allows several
+versions of the shared library to be installed at the same time, allowing
+installation of the new version of the shared library without immediately
+breaking binaries that depend on the old version. Normally, the run-time
+shared library and its ``SONAME`` symlink should be placed in a package
+named libraryname\ *soversion*, where *soversion* is the version number in
+the ``SONAME`` of the shared library.  Alternatively, if it would be
+confusing to directly append *soversion* to libraryname (if, for example,
+libraryname itself ends in a number), you should use
+libraryname-\ *soversion* instead. [#]_
+
+To determine the *soversion*, look at the ``SONAME`` of the library,
 stored in the ELF ``SONAME`` attribute. It is usually of the form
 ``name.so.major-version`` (for example, ``libz.so.1``). The version part
 is the part which comes after ``.so.``, so in that example it is ``1``.
@@ -126,6 +126,14 @@ that the dynamic linker (for example ``ld.so`` or 
``ld-linux.so.*``) can
 find the library between the time that ``dpkg`` installs it and the time
 that ``ldconfig`` is run in the ``postinst`` script.  [#]_
 
+.. [#] The following command, when run on a shared library, will output
+   the name to be used for the Debian package containing that shared
+   library::
+
+   objdump -p /path/to/libfoo-bar.so.1.2.3 \
+   | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' \
+   | LC_ALL=C sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; 
y/_/-/; s/(.*)/\L&/'
+
 .. [#] The package management system requires the library to be placed
before the symbolic link pointing to it in the ``.deb`` file. This
is so that when ``dpkg`` comes to install the symlink (overwriting

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

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

[roucaries bastien]

On Wed, Aug 23, 2017 at 6:29 PM, Russ Allbery  wrote:
> Bastien ROUCARIÈS  writes:
>
>> get-orig-source should include an example.
>
>> If you use uscan this is safe and policy compliant (maybe opening a bug
>> against dpkg-dev to get this rule by default)
>
>> cd "$(subst ",\",$(dir $(lastword $(MAKEFILE_LIST/.." && uscan --destdir 
>> $(subst ",\",$(CURDIR)) #"
>
>> We have a bug report for lintian asking for checking unsafe uscan, so I
>> was creating a compliant version
>
>> A footnote is suffisant
>
> I'm reasonably fluent in shell and make, and I still have absolutely no
> idea what that does.

you call the rules with something (using shebang or directly) make -f
somepath/package/debian/rules, uscan need to be excuted on
somepath/package/.

So you need to get the f parameter. Make get it in last entry of
$MAKEFILE_LIST, so, $(lastword $(MAKEFILE_LIST)) that return
somepath/package/debian/rules,

now we get the dir using $(dir ) and get one level up by ..
$(dir $(lastword $(MAKEFILE_LIST)))/..

Unfortunatly we need to escape, some char so use ' to quote and escape
it using $(subst  ',\', $(dir $(lastword $(MAKEFILE_LIST)))/..)

now i can cd:
$(subst  ',\', $(dir $(lastword $(MAKEFILE_LIST)))/..)

and do a uscan with DESTDIR (here the local dir) escaped:

Finnally:
cd $(subst  ',\', $(dir $(lastword $(MAKEFILE_LIST)))/..) && uscan
--destdir $(subst ",\",$(CURDIR)) #'

the #' at end if for emacs syntax highlight

Bastien


>
> Is there any way that we could help people out and have the correct thing
> to do be much, much simpler?  Just a single command invocation?
>
> --
> Russ Allbery (r...@debian.org)   

* do not expect something with name that include space