Bug#1062983: Developers Reference in A4 instead of US Letter

[Paul Wise]

On Sun, 2024-02-04 at 19:25 +, Holger Levsen wrote:

> I think for English at least I'd prefer to offer both A4 and letter, for eg
> the German translation I think it's enough to only provide A4.

Looks like that info can be gotten from the locales on glibc systems:
   
   $ LANG=en_AU.utf8 locale -k LC_PAPER
   height=297
   width=210
   paper-codeset="UTF-8"

   $ LANG=en_US.utf8 locale -k LC_PAPER
   height=279
   width=216
   paper-codeset="UTF-8"

For languages with one translation instead of one per dialect,
you could produce documents in each of the unique sizes.

Seems like this is a GNU extension to POSIX though:

   
https://manpages.debian.org/bookworm/manpages/locale.5.en.html#Locale_category_sections
   https://manpages.debian.org/bookworm/manpages/locale.5.en.html#LC_PAPER
   https://manpages.debian.org/bookworm/manpages/locale.7.en.html#LC_PAPER

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Paul Wise]

On Thu, Sep 2, 2021 at 10:39 PM Phil Morrell wrote:

> Over this last year there seems to have been a noticeable divergence of
> maintainer opinion, on what has become known as vendoring

Embedded copies of code/etc have downsides ...

https://wiki.debian.org/EmbeddedCopies

> It is my reading of the situation that not only has this practice become
> more prevalent across multiple ecosystems since 2008

... but there are many many copies in Debian and they are not going
away upstream.

> [security-tracker]: 
> https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies

Side note: This file is very much outdated, new copies are introduced
all the time and old copies get removed. This has always been the case
and it always will be.

So we need to cope with the consequences of this change toward
embedding in the upstream FLOSS ecosystems.

Personally, my recommendations are that:

Debian package maintainers could investigate upstream tarballs for
embedded copies before each upload containing a new/changed upstream
tarball.

Debian package maintainers could talk to upstream about removing
embedded copies and replacing them with dependencies.

Debian package maintainers could talk to upstream about upstreaming
changes in modified embedded copies, removing the embedded copies and
replacing them with dependencies.

Debian package maintainers could use Files-Excluded or `rm -r` in
debian/rules to ensure that embedded copies are not used by the build.

Debian package maintainers could add hints to the source package about
which embedded copies are definitely used.

Debian security tracker could remove the perpetually outdated list of
embedded copies.

Debian security issue investigators could search the archive for
similar or duplicate code (using the tools listed on the above wiki
page), investigate the build logs for each package found and determine
which packages are affected. This is a lot of work, but given the
level of embedding we already have, it is already necessary.

Also, the issue of static linking is similar; it is here, it isn't
going away and so now we have to cope with it and the problems it
causes are similar to embedded copies.

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#662998: debian-policy: stripping static libraries

[Paul Wise]

On Mon, 21 Nov 2016 13:55:02 +0800 Paul Wise wrote:
> On Wed, 7 Mar 2012 23:03:59 +0100 Jakub Wilk wrote:
> 
> > Can we make stripping static libraries a Policy “should”?
> 
> I note that Fedora is going the opposite way. They are currently
> stripping static libraries and are moving towards not stripping:

Update:

Fedora dropped that approach, then considered a hybrid approach, where
they strip static libraries, but copy the unstripped static libraries
into their debuginfo packages. That stalled and was discarded.

The latest message suggests a more complicated but better option:

  Maybe we should look at a solution that uses GNU Debug Fission or
  DWARF5 split DWARF where most of of the non-relocationable DWARF
  structures are put in a separate .dwo file. Then you could keep
  the skeleton units in the (unstripped) static library. And
  package up the .dwo units into a .dwp file that goes into the
  debuginfo. Those skeleton units contain an ID of the .dwo units.
  We would then need to create some mapping that ties together the
  debuginfo package containing the skeleton units to the debuginfo
  package containing the .dwp file?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

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

[Paul Wise]

Package: developers-reference
Severity: wishlist
X-Debbugs-CC: Philiip Kern , debian-wb-t...@lists.debian.org

In the section about wanna-build, please document the new self-service
givebacks in the wanna-build section of devref:

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#wanna-build

Here is a copy of the announcement and blog post for your reference:

https://lists.debian.org/msgid-search/8b000c23ac2defbfeea7d5a0bc28ec2e3df55baa.ca...@debian.org

   Self-service buildd givebacks
   -

Philipp Kern has created[1] an *experimental* service that allows Debian
members to perform self-service retries of failed package builds (aka
give-backs). This service aims to reduce the time it takes for give-back
requests to be processed, which was done manually by the wanna-build
admins until now. The service is authenticated using the Debian Single
Signon[2] service. Debian members are still expected to act responsibly
when looking at build failures; do your due diligence and try reproducing
the issue on a porterbox first. Access to this service is logged and logs
will be audited by the admins.

 -- Paul Wise

[1] 
https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html
 [2] https://sso.debian.org/

https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html

Alpha: Self-service buildd givebacks

   Builds on Debian's build farm sometimes fail transiently. Sometimes
   those failures are legitimate flakes, for instance when an in-
   progress build happens to exhaust its resources because of other
   builds on the same machine. Until now, you always needed to mail the
   buildd, wanna-build admins or the Release Team directly in order to
   get the builds re-queued.

   As an alpha trial I implemented self-service givebacks as a web
   script. As SSO for Debian developers is now a thing, it is trivial
   to add authentication in a way that a role account can use to act on
   your behalf. While at work this would all be an RPC service, I
   figured that a little CGI script would do the job just as well. So
   lo and behold, accessing
   
https://buildd.debian.org/auth/giveback.cgi?pkg===
   with the right parameters set:

  You are authenticated as pkern. ✓
  Working on package fife, suite sid and architecture mipsel. ✓
  Package version 0.4.2-1 in state Build-Attempted, can be given back. ✓
  Successfully given back the package. ✓

   Note that you need to be a Debian developer with a valid SSO client
   certificate to access this service.

   So why do I say alpha? We still expect Debian developers to act
   responsibly when looking at build failures. A lot of times there is
   a legitimate bug in the package and the last thing we would like to
   see as a project is someone addressing flakiness by continuously
   retrying a build. Access to this service is logged. Most people
   coming to us today did their due diligence and tried reproducing the
   issue on a porterbox. We still expect these things to happen but
   this aims to cut on the round-trip time until an admin gets around
   to process your request, which have been longer than necessary
   recently. We will audit the logs and see if particular packages
   stand out.

   There can also still be bugs. Please file them against
   buildd.debian.org when you see them. Please include a copy of the
   output, which includes validation and important debugging
   information when requests are rejected. Also this all only works for
   packages in Build-Attempted. If the build has been marked as Failed
   (which is a manual process), you still need to mail us. And lastly
   the API can still change. Luckily the state change can only happen
   once, so it's not much of a problem for the GET request to be
   retried. But it should likely move to POST anyhow. In that case I
   will update this post to reflect the new behavior.

   Thanks to DSA for making sure that I run the service sensibly using
   a dedicated role account as well as WSGI and doing the work to set
   up the necessary bits.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#910783: Remove doc-base recommendation

[Paul Wise]

On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote:

> Instead, if there is indeed consensus, we should change it so that it
> no longer says that doc-base registration is recommended.

We need a cross-distro cross-desktop standard for an index of
docs before we can move on from doc-base like we did with menu.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#824495: Use of the Build-Conflicts field

[Paul Wise]

On Sat, Feb 16, 2019 at 12:00 PM Sean Whitton wrote:

> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases.  See #824495 for the discussion.

Personally, the main RC use-case I can think of for such a field is
where the recursive chain of Build-Depends reaches at some point a set
of alternative dependencies and one of them causes an FTBFS or other
breakage in the package and so you want to make apt choose the other
alternative.

Any other use-cases imply a non-minimal chroot, which isn't our
standard build environment so I don't think they should be RC.

Other folks have already mentioned the use-case of avoiding optional
dependencies being installed affecting the reproducibility of the
build artefacts.

Obviously it is a good idea to declare all of the conflicts (optional
deps, FTBFS) to avoid frustration during development though.

I think QA efforts like the buildd-from-hell idea could help
automatically find such issues, if that ever happens.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#904413: debian-policy: HTML: link from section numbers in upgrading checklist to policy sections

[Paul Wise]

Package: debian-policy
Version: 4.1.5.0
Severity: wishlist

In the HTML version of Policy it would be nice to have links from the
section numbers in the upgrading checklist to the corresponding
sections in the Policy document. This would help developers read the
full sections as well as the description of the change. Currently that
requires searching the single-page version (or the Table of Contents
for the multi-page version) to find the right section.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.7.6-1

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#904412: debian-policy: HTML: add secondary anchors for section numbers

[Paul Wise]

Package: debian-policy
Version: 4.1.5.0
Severity: wishlist

It would be nice to have secondary anchors for section numbers so that
I could just add #10.4 or #s10.1 (for example) to my browser URL to jump to the 
right section when someone references a particular Policy section on IRC or 
elsewhere. These could be like this:



-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.7.6-1

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#813471: Seeking seconds for patch to permit some network access to localhost

[Paul Wise]

On Mon, 2018-07-23 at 20:16 +0100, Ian Jackson wrote:

> LGTM.  It might be worth saying "the apt repository (both source and
> binaries)".  There are both packages which fetch .debs explicitly, and
> packages which fetch sources explicitly (yes, this is not very good,
> but consensus in a discussion of relevant people in ? Nicaragua I
> think was that there isn't a better way right now, and that making a
> better way would be a *lot* of work).

Sean and I discussed this at DebCamp and he mentioned that udeb
building packages have an exception from (most?) of policy, so we
probably do not need this particular apt repo network exception?

The only other reason I can think of to need access to the apt repo
from the build scripts is as an alternative workaround to the "cannot
build-dep on source packages" problem, which is usually worked around
via -source binary packages. The -source workaround is used by
toolchain packages, external Linux kernel drivers and some other
things. It seems to be working OK so I suggest that we deprecate all
access to the apt repo except for d-i and installing Build-Depends.

> If you access the archive to fetch .debs or .dscs, you almost
> certainly needed to put in a Built-Using.  Maybe we should mention
> that ?

Since Built-Using is *only* for license compliance (and folks strongly
discourage its use for other things such as static linking), that is
completely dependent on the license of the source/binary being fetched.
It is probably worth mentioning if we add the apt repo exception.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#813471: Seeking seconds for patch to permit some network access to localhost

[Paul Wise]

On Sun, 2018-07-22 at 10:41 +, Niels Thykier wrote:

> Basically I read "No required target may attempt network access via the
> loopback interface (except if/when ...).".  To me that implies /only/
> the loopback interface is restricted by that sentence (i.e. any other
> network interface is not restricted by this sentence).
> 
> If there is another saying that no other network interfaces may be used
> during the build, then the loopback restriction may be fine.  But the
> original sentence sounded like it was the only sentence restricting
> network access.

For clarity, how about we separate the two types of network access?

In addition, d-i relies on access to the apt repo for the system.
I can imagine other uses of that, so I added a carve-out for that.

   For packages in the main archive, no required targets may attempt
   network access on non-loopback interfaces, except to the apt
   repositoryused by the system.

   For packages in the main archive, no required targets may attempt
   network access on the loopback interface, except to services that
   were started by the build process. Services started by the build
   process must be shut down after use.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

[Paul Wise]

On Fri, Jul 6, 2018 at 2:16 PM, Andreas Tille wrote:

> I fully share your view that the optimal situation would be if uscan
> would be some kind of wrapper around whatever code would be needed to
> create the source tarball.  Since I share this view I once started to
> hack Files-Excluded into uscan and I'm very happy about the git mode.
> In other words: If we could get some kind of "ultra-flexible" uscan the
> sense of the get-orig-source replacement as discussed above would be
> completely fullfilled and that would be an optimal outcome of the
> situation I was not so happy about that get-orig-source was droped from
> policy.

If that happens, please ensure that the uscan --report-status and
--safe options continue to not run code from the source package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#892142: debian-policy: update example to use default-mta instead of exim

[Paul Wise]

On Mon, 2018-03-05 at 17:12 -0800, Jonathan Nieder wrote:

> How about this patch?

Looks good to me.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#892142: debian-policy: update example to use default-mta instead of exim

[Paul Wise]

Package: debian-policy
Version: 4.1.3.0
Severity: minor

In Policy 7.1. Syntax of relationship fields, there is an example:

   For example, a list of dependencies might appear as:

   Package: mutt
   Version: 1.3.17-1
   Depends: libc6 (>= 2.2.1), exim | mail-transport-agent

I would like to suggest that this be updated to replace exim with
default-mta, since exim is no longer in Debian as it has been replaced
with exim4 and many years ago we switched to using the default-mta
virtual package to make it easier to change the default MTA on Debian.

https://www.debian.org/doc/debian-policy/#syntax-of-relationship-fields

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.6.7-1

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

[developers-reference] branch master updated (ee6157d -> e586826)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository developers-reference.

  from  ee6157d   just update wordwrap
   new  e586826   Fix spelling, grammar, capitalisation and wording issues

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 best-pkging-practices.dbk | 18 +--
 beyond-pkging.dbk |  2 +-
 debian/changelog  | 76 +++
 new-maintainer.dbk|  2 +-
 pkgs.dbk  |  6 ++--
 5 files changed, 52 insertions(+), 52 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] 01/01: Fix spelling, grammar, capitalisation and wording issues

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a commit to branch master
in repository developers-reference.

commit e5868261174693a5a4f3f44282d292794d7d
Author: Paul Wise <p...@debian.org>
Date:   Sun Nov 5 09:35:26 2017 +0800

Fix spelling, grammar, capitalisation and wording issues

Suggested-by: codespell
Suggested-by: spellintian
---
 best-pkging-practices.dbk | 18 +--
 beyond-pkging.dbk |  2 +-
 debian/changelog  | 76 +++
 new-maintainer.dbk|  2 +-
 pkgs.dbk  |  6 ++--
 5 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 1651ddb..27b5eca 100644
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -110,7 +110,7 @@ but by the build rule of
 
 
 quilt is the recommended tool for this.
-It does all of the above, and also allows to manage patch series.
+It does all of the above, and also allows one to manage patch series.
 See the 
 quilt package for more information.
 
@@ -1050,7 +1050,7 @@ original.
 
 
 The short description should be able to stand on its own.  Some interfaces do
-not show the long description by default, or only if the user explicitely asks
+not show the long description by default, or only if the user explicitly asks
 for it or even do not show it at all.  Avoid things like What do you want to
 do?
 
@@ -1247,7 +1247,7 @@ __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), 
Chinese (zh), Czech (cs
 # This is the default choice. Translators may put their own language here
 # instead of the default.
 # WARNING : you MUST use the ENGLISH NAME of your language
-# For instance, the french translator will need to put French (fr) here.
+# For instance, the French translator will need to put French (fr) here.
 _Default: English[ translators, please see comment in PO files]
 _Description: Geneweb default language:
 
@@ -1360,8 +1360,8 @@ Some tools (e.g. po4a, poxml, or the translate-toolkit) are specialized in extracting
 the translatable material from different formats.  They produce PO files, a
-format quite common to translators, which permits to see what needs to be
-retranslated when the translated document is updated.
+format quite common to translators, which permits one to see what needs to be
+re-translated when the translated document is updated.
 
 
 
@@ -1441,7 +1441,7 @@ upstream.
 
 
 The manpages do not need to be written directly in the troff format.  Popular
-source formats are Docbook, POD and reST, which can be converted using
+source formats are DocBook, POD and reST, which can be converted using
 xsltproc, pod2man and
 rst2man respectively. To a lesser extent, the
 help2man program can also be used to write a stub.
@@ -1466,7 +1466,7 @@ role="package">libmldbm-perl (arch 
independent perl module).
 
 
 
-Python related packages have their python policy; see
+Python related packages have their Python policy; see
  in the python package.
 
@@ -1487,7 +1487,7 @@ policy.
 
 
 
-Ocaml related packages have their own policy, found in
+OCaml related packages have their own policy, found in
  from the ocaml package.  A good example is the camlzip source package.
@@ -1793,7 +1793,7 @@ this can aid in debugging many programs linked to a 
library.  In general, debug
 packages do not need to be added for all programs; doing so would bloat the
 archive.  But if a maintainer finds that users often need a debugging version
 of a program, it can be worthwhile to make a debug package for it.  Programs
-that are core infrastructure, such as apache and the X server are also good
+that are core infrastructure, such as Apache and the X server are also good
 candidates for debug packages.
 
 
diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
index 7963b49..5197573 100644
--- a/beyond-pkging.dbk
+++ b/beyond-pkging.dbk
@@ -119,7 +119,7 @@ Usertags: tag-name [ tag-name ... 
]
 description-of-bug ...
 
 
-Note that tags are seperated by spaces and cannot contain underscores. If you
+Note that tags are separated by spaces and cannot contain underscores. If you
 are filing bugs for a particular group or team it is recommended that you
 set the User to an appropriate mailing list after describing
 your intention there.
diff --git a/debian/changelog b/debian/changelog
index 451aa03..20b0760 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -30,8 +30,8 @@ developers-reference (3.4.18) unstable; urgency=medium
   * Also document List-Id header in package tracker mails.
 
   [ Lev Lamberov ]
-  * adding russian translation (Closes: #797603)
-  * changing Makefile to handle russian translation
+  * adding Russian translation (Closes: #797603)
+  * changing Makefile to handle Russian translation
 
   [ Anthony Fok ]
   * Change ftp-master-mirror to coccia.debian.org
@@ -99,7 +99,7 @@ developers-reference (3.4.15) unstable; urgency=medium
  

Re: Bug#877337: www.debian.org: Switch back to single page version of Policy Manual

[Paul Wise]

On Wed, Oct 4, 2017 at 11:41 AM, Sean Whitton wrote:

> - installing the policy.html/ dir as 
> https://www.debian.org/doc/debian-policy/;
> - copying policy-1.html into that dir; and
> - telling Apache to serve policy-1.html as the directory index?

Correct.

> I'm a little worried people could be very confused (why is
> debian-policy/index.html different from debian-policy/?!  is there some
> cache refresh needed somewhere?) but I don't object.

Hmm, I'm not sure what to do about that.

> I'm about to upload a fix for that, though, following your advice, the
>  tags will point to policy.html/, so they would break again if
> policy-1.html were copied within that directory.

You could use symlinks in the package instead to avoid that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: www.debian.org: Switch back to single page version of Policy Manual

[Paul Wise]

On Sat, 30 Sep 2017 09:33:52 -0700 Sean Whitton wrote:

> We (the active Policy Team members) think that the single page version
> is more suitable for Debian's web mirrors.  This is because it is more
> useful for newcomers: with the single page version, it is possible to
> use your browser's search function to search across the entire document.
> More experienced users, who want the multi-page version, probably have
> the debian-policy package installed locally.

I wonder if we could accommodate both categories of Debian Policy
readers instead of dropping support for more experienced readers?

I propose to do it by placing both versions of the document into the
same directory and then setting the DocumentIndex Apache configuration
option to prefer the single page document over the multi-page one.

The advantage of this is that we accommodate folks who prefer the
existing multi-page document and no existing URL will break but that by
default new users will get the single-page version.

The only problem with this is #877573 but that also affects offline
readers of Debian Policy anyway so it needs to be fixed anyway.

I have verified with diffoscope that the _static and _images
directories are identical between the two documents.

If there are no objections to this then I can do the changes needed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#877573: policy-1.html: invalid links to index.html genindex.html search.html

[Paul Wise]

Package: debian-policy
Version: 4.1.1.0
Severity: important
File: /usr/share/doc/debian-policy/policy-1.html
Usertags: offline

The policy-1.html file contains many invalid links to index.html and
single invalid links to genindex.html and search.html. This means that offline 
readers will get broken links for every item in the ToC and every link within 
the document.

For index.html they look like they should all just be intra-document
links with only an anchor and no filename. For genindex.html and
search.html, the files should either get symlinks to the policy.html/
directory or the HTML modified to point to that directory.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.6.4-1

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#873456: debian-policy: missing anchor: document-index

[Paul Wise]

Package: debian-policy
Version: 4.1.0.0
Severity: minor

There are several links that point to the document-index anchor, but it
is not available in the document. This is especially annoying for users
of text-based browsers because it means that there is no easy way to
get to the Table of Contents, which used to be at the top of index.html

$ grep -ri document-index /usr/share/doc/debian-policy/
/usr/share/doc/debian-policy/policy.html/index.html:Debian Policy Manual 
v4.1.0.0  
/usr/share/doc/debian-policy/policy.html/index.html:  Table Of Contents
/usr/share/doc/debian-policy/policy.html/index.html:Debian Policy Manual 
v4.1.0.0  

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.5.6-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Paul Wise]

On Fri, Aug 4, 2017 at 6:10 AM, Ansgar Burchardt wrote:

> So I have been wondering several times whether we should move the
> maintainer information elsewhere.  For example, tracker.d.o could be
> extended to record maintainer information.  It could also understand
> the concept of "teams" listing team members and whom to send mails
> about individual packages.

This has been planned by the distro-tracker folks for many years,
there is even a DEP about it:

http://dep.debian.net/deps/dep2/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature

[Paul Wise]

On Tue, 2017-06-27 at 19:49 -0700, Paul Hardy wrote:

> 1) Serving debian-policy pages on Debian servers as UTF-8 documents,
> as an interim measure.

I think we would want to do this for all *.txt documents that are UTF-8 
and available on the website. First we need the list of UTF-8 encoded
text files and then we need an appropriate Apache configuration snippet
to be added to the template.

https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/roles/templates/apache-www.debian.org.erb

I've run these commands on one of the static mirrors, results attached.

find . -iname *.txt -print0 | xargs -0 isutf8 --list --invert | sort > 
~/isutf8.txt
find . -iname *.txt -print0 | xargs -0 isutf8 --list | sort > ~/isnotutf8.txt
find . -iname *.txt -print0 | xargs -0 file --mime-encoding | sort > 
~/mime-encoding.txt

Could someone come up with an appropriate Apache configuration snippet?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


isnotutf8.txt.gz
Description: application/gzip


isutf8.txt.gz
Description: application/gzip


mime-encoding.txt.gz
Description: application/gzip


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

Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature

[Paul Wise]

On Sun, 2017-06-25 at 16:07 -0700, Paul Hardy wrote:

> Earlier today, I sent the GNU less maintainer a two-line patch to the
> "charset.c" file after my original email to him.

I'm no expert on the less source code, but it seems to me that it will
also hide U+FEFF characters after the first one. I would suggest
updating it so that  is only hidden when it is the first UTF-8
character in the file.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#865713: Declaring a charset of UTF-8 for policy files

[Paul Wise]

On Sat, 2017-06-24 at 20:48 -0700, Russ Allbery wrote:

> Can't we just set the character set for the text files that come from
> Debian Policy?  At least with Apache you can set character sets with
> whatever granularity you want.

Doesn't look like there are any files within the Debian Policy
directory that are non-UTF-8, so that should be doable.

pabs@mirror-anu:/srv/static.debian.org/mirrors/www.debian.org/cur$ find -iname 
'*.txt' -print0 | xargs -0 isutf8 | grep policy
./doc/manuals/ddp-policy/ddp-policy.en.txt: line 1476, char 1, byte offset 22: 
invalid UTF-8 code

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#865713: Declaring a charset of UTF-8 for policy files

[Paul Wise]

On Sat, 2017-06-24 at 20:07 -0700, Paul Hardy wrote:

> Three possibilities seem to exist, and I am fine with any one being chosen:
> 
> 1) Use the UTF-8 signature in UTF-8 text files

If this triggers browsers to use the right encoding, it seems
reasonable to add it in the situation where the files could be served
by any web server on the Internet. Right now all the mirrors of
www.debian.org are on Debian-controlled servers though, but there are
many non-UTF-8 text files so using the UTF-8 signature seems better.

> 2) Set the HTTP headers for charset="UTF-8"

FYI, there are 1018 non-UTF-8 out of 2605 total *.txt files on the
Debian website and 9 non-UTF-8 out of 1102 total *.txt files in the
Debian archive mirrors. It seems feasible to convert the files in the
Debian archive to UTF-8 but it doesn't seem to be feasible to do that
for www.debian.org.

pabs@mirror-anu:/srv/static.debian.org/mirrors/www.debian.org/cur$ find -iname 
'*.txt' | wc -l
2605
pabs@mirror-anu:/srv/static.debian.org/mirrors/www.debian.org/cur$ find -iname 
*.txt -print0 | xargs -0 isutf8  | wc -l
1018
pabs@mirror-anu:/srv/mirrors/debian$ find -iname '*.txt' | wc -l
1102
pabs@mirror-anu:/srv/mirrors/debian$ find -iname '*.txt' -print0 | xargs -0 
isutf8  | wc -l
9

> 3) Convert UTF-8 text files to HTML documents for web display

Sounds like this is already done.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#865713: Declaring a charset of UTF-8 for policy files

[Paul Wise]

On Sun, Jun 25, 2017 at 8:54 AM, Simon McVittie wrote:

> For what it's worth, I agree that declaring the correct charset in HTTP
> metadata is a better solution than prepending U+FEFF ZERO WIDTH NO-BREAK SPACE
> (aka the "byte-order mark") in the file content.

Forcing every text file to UTF-8 isn't the correct solution either,
since it breaks text files that are not encoded in UTF-8 (such as old
dedication texts) and does not work on Debian mirrors that are not
controlled by us.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[developers-reference] branch master updated (0dc5821 -> 87211e0)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository developers-reference.

  from  0dc5821   clarify that the release team wants a source debdiff
   new  87211e0   Use mkdir -p instead of ignoring mkdir exit codes

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] 01/01: Use mkdir -p instead of ignoring mkdir exit codes

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a commit to branch master
in repository developers-reference.

commit 87211e037bcc4a068bc4640521b1718cfce29049
Author: Paul Wise <p...@debian.org>
Date:   Mon Jan 2 12:06:14 2017 +0800

Use mkdir -p instead of ignoring mkdir exit codes

Properly errors out when the directory cannot be created.
Properly does not give an error when the directory exists.

Fixes: ec242bbcad6b2c6b8b557a67b3146929870ecdf7
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 4903f79..5ca63b9 100644
--- a/Makefile
+++ b/Makefile
@@ -53,7 +53,7 @@ validate: $(SOURCES)
 
 .PHONY: css
 css:
-   -mkdir $(CURDIR)/images
+   mkdir -p $(CURDIR)/images
cd $(DIMG) && cp caution.png important.png note.png tip.png up.gif 
warning.png $(CURDIR)/images
cd $(CURDIR)/pngfile && cp *.png $(CURDIR)/images
 

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

Bug#662998: debian-policy: stripping static libraries

[Paul Wise]

On Wed, 7 Mar 2012 23:03:59 +0100 Jakub Wilk wrote:

> Can we make stripping static libraries a Policy “should”?

I note that Fedora is going the opposite way. They are currently
stripping static libraries and are moving towards not stripping:

https://fedoraproject.org/wiki/Changes/StaticLibraryDebuginfo
https://bugzilla.redhat.com/show_bug.cgi?id=1395280
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/OFNQT4QPQB4TRHAD4FQTOHXBMORXJWQV/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#839885: developers-reference: reintroducing packages: update security issue metadata

[Paul Wise]

Package: developers-reference
Severity: wishlist
X-Debbugs-CC: secur...@debian.org

I would like to add a paragraph to the section about reintroducing
packages so that people reintroducing packages check the security
tracker metadata for the old package and update the metadata once it
gets reintroduced to Debian.

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

I propose the following text, please wait for an ack from the security
team before adding it to devref.

Package removals from unstable also trigger marking the package as
removed in the security tracker. Debian members should [mark removed
issues as unfixed][1] in the security tracker repository and all others
should contact[2] the security team to report reintroduced packages.

1. https://security-team.debian.org/security_tracker.html#removed-packages
2. https://security-tracker.debian.org/tracker/data/report

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

[developers-reference] branch master updated (e63c32e -> b3a3512)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository developers-reference.

  from  e63c32e   Add some missing words
   new  b3a3512   Fix missing spaces

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 po4a/po/developers-reference.pot | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] 01/01: Fix missing spaces

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a commit to branch master
in repository developers-reference.

commit b3a351237470ae725673dae482928dee674613c9
Author: Paul Wise <p...@debian.org>
Date:   Thu Mar 3 14:28:24 2016 +0800

Fix missing spaces
---
 po4a/po/developers-reference.pot | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/po4a/po/developers-reference.pot b/po4a/po/developers-reference.pot
index 487b0b0..3a55914 100644
--- a/po4a/po/developers-reference.pot
+++ b/po4a/po/developers-reference.pot
@@ -5004,9 +5004,9 @@ msgstr ""
 #. type: Content of: 
 #: pkgs.dbk:306
 msgid ""
-"Uploading to stable means that the package will be"
+"Uploading to stable means that the package will be "
 "transferred to the proposed-updates-new queue for review "
-"by the stable release managers, and if approved will be installed in the"
+"by the stable release managers, and if approved will be installed in the "
 "stable-proposed-updates directory of the Debian "
 "archive.  From there, it will be included in stable with "
 "the next point release."

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] 01/01: Add some missing words

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a commit to branch master
in repository developers-reference.

commit e63c32e14535d1925e7498a0d2af885f8d4a3cdd
Author: Sander Bos <>
Date:   Thu Mar 3 13:23:58 2016 +0800

Add some missing words

Signed-off-by: Paul Wise <p...@debian.org>
---
 pkgs.dbk | 4 ++--
 po4a/po/de.po| 4 ++--
 po4a/po/developers-reference.pot | 4 ++--
 po4a/po/fr.po| 4 ++--
 po4a/po/ja.po| 4 ++--
 po4a/po/ru.po| 4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/pkgs.dbk b/pkgs.dbk
index 4be1d5e..ccf45d5 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -302,9 +302,9 @@ time.
 Special case: uploads to the stable and
 oldstable distributions
 
-Uploading to stable means that the package will transferred
+Uploading to stable means that the package will be 
transferred
 to the proposed-updates-new queue for review by the stable
-release managers, and if approved will be installed in
+release managers, and if approved will be installed in the
 stable-proposed-updates directory of the Debian archive.
 From there, it will be included in stable with the next
 point release.
diff --git a/po4a/po/de.po b/po4a/po/de.po
index ed3cb0b..a627e04 100644
--- a/po4a/po/de.po
+++ b/po4a/po/de.po
@@ -7166,9 +7166,9 @@ msgstr ""
 #. type: Content of: 
 #: pkgs.dbk:306
 msgid ""
-"Uploading to stable means that the package will "
+"Uploading to stable means that the package will be "
 "transferred to the proposed-updates-new queue for review "
-"by the stable release managers, and if approved will be installed in "
+"by the stable release managers, and if approved will be installed in the "
 "stable-proposed-updates directory of the Debian "
 "archive.  From there, it will be included in stable with "
 "the next point release."
diff --git a/po4a/po/developers-reference.pot b/po4a/po/developers-reference.pot
index f1b4008..487b0b0 100644
--- a/po4a/po/developers-reference.pot
+++ b/po4a/po/developers-reference.pot
@@ -5004,9 +5004,9 @@ msgstr ""
 #. type: Content of: 
 #: pkgs.dbk:306
 msgid ""
-"Uploading to stable means that the package will "
+"Uploading to stable means that the package will be"
 "transferred to the proposed-updates-new queue for review "
-"by the stable release managers, and if approved will be installed in "
+"by the stable release managers, and if approved will be installed in the"
 "stable-proposed-updates directory of the Debian "
 "archive.  From there, it will be included in stable with "
 "the next point release."
diff --git a/po4a/po/fr.po b/po4a/po/fr.po
index a27180a..d3ea3d3 100644
--- a/po4a/po/fr.po
+++ b/po4a/po/fr.po
@@ -7182,9 +7182,9 @@ msgstr ""
 #. type: Content of: 
 #: pkgs.dbk:306
 msgid ""
-"Uploading to stable means that the package will "
+"Uploading to stable means that the package will be "
 "transferred to the proposed-updates-new queue for review "
-"by the stable release managers, and if approved will be installed in "
+"by the stable release managers, and if approved will be installed in the "
 "stable-proposed-updates directory of the Debian "
 "archive.  From there, it will be included in stable with "
 "the next point release."
diff --git a/po4a/po/ja.po b/po4a/po/ja.po
index 39b2998..879f617 100644
--- a/po4a/po/ja.po
+++ b/po4a/po/ja.po
@@ -6856,9 +6856,9 @@ msgstr ""
 #. type: Content of: 
 #: pkgs.dbk:306
 msgid ""
-"Uploading to stable means that the package will "
+"Uploading to stable means that the package will be "
 "transferred to the proposed-updates-new queue for review "
-"by the stable release managers, and if approved will be installed in "
+"by the stable release managers, and if approved will be installed in the "
 "stable-proposed-updates directory of the Debian "
 "archive.  From there, it will be included in stable with "
 "the next point release."
diff --git a/po4a/po/ru.po b/po4a/po/ru.po
index 37dd2f5..525a161 100644
--- a/po4a/po/ru.po
+++ b/po4a/po/ru.po
@@ -7150,9 +7150,9 @@ msgstr ""
 #. type: Content of: 
 #: pkgs.dbk:305
 msgid ""
-"Uploading to stable means that the package will "
+"Uploading to stable means that the package will be "
 "transferred to the proposed-updates-new queue for review "
-"by the stable release managers, and if approved will be installed in "
+"by the stable release managers, and if approved will be installed in the "
 "stable-proposed-updates directory of the Debian "
 "archive.  From there, it will be included in stable with "
 "the next point release."

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] branch master updated (7447369 -> e63c32e)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository developers-reference.

  from  7447369   Add bug closer for #806993, ftp-master mirror on 
mirror.ftp-master.debian.org
   new  e63c32e   Add some missing words

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 pkgs.dbk | 4 ++--
 po4a/po/de.po| 4 ++--
 po4a/po/developers-reference.pot | 4 ++--
 po4a/po/fr.po| 4 ++--
 po4a/po/ja.po| 4 ++--
 po4a/po/ru.po| 4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

Re: [developers-reference] [PATCH] Make it easier to update devref for a new Debian release.

[Paul Wise]

On Thu, 2015-10-15 at 23:39 +0800, Paul Wise wrote:

> Make it easier to update devref for a new Debian release.

FYI, I have fixed the build errors, compared the binary packages
before/after the patch using diffoscope and pushed the patch to git.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

[developers-reference] 01/01: Make it easier to update devref for a new Debian release.

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a commit to branch master
in repository developers-reference.

commit fc56ee5bbbfe406dc00bf6bf7572b77889bf8056
Author: Paul Wise <p...@debian.org>
Date:   Thu Oct 15 23:33:52 2015 +0800

Make it easier to update devref for a new Debian release.

Move information about codenames/versions into the entities.

Refer readers to the website for a list of obsolete releases.
---
 common.ent| 13 +
 pkgs.dbk  | 17 -
 resources.dbk | 19 ---
 3 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/common.ent b/common.ent
index ca802a4..a1ec2b0 100644
--- a/common.ent
+++ b/common.ent
@@ -15,6 +15,18 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
 
 
@@ -67,6 +79,7 @@
 https://db.debian.org/machines.cgi;>
 https://buildd.debian.org/;>
 https://release.debian.org/wanna-build.txt;>
+https:///releases/;>
 https://lists.debian.org/debian-project/2009/03/msg00096.html;>
 https://lintian.debian.org/;>
 https://qa.debian.org/;>
diff --git a/pkgs.dbk b/pkgs.dbk
index 126eaac..d4acfad 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1,5 +1,4 @@
-
- http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [
%commondata;
 ]>
@@ -1124,7 +1123,7 @@ Be sure to verify the following items:
 Target the right distribution
 in your debian/changelog:
 codename-security
-(e.g. jessie-security).
+(e.g. -security).
 Do not target 
distribution-proposed-updates or
 stable!
 
@@ -1155,7 +1154,7 @@ you have already used for a previous upload, or one that 
conflicts with a
 binNMU. The convention is to append
 +debXu1 (where
 X is the major release number), e.g.
-1:2.4.3-4+deb8u1, of course increasing 1 for any subsequent
+1:2.4.3-4+debu1, of course increasing 1 for 
any subsequent
 uploads.
 
 
@@ -2157,10 +2156,10 @@ this, a version of the form
 
+debXuY
 should be used, where X is the major release number,
 and Y is a counter starting at 1.
-For example, while Wheezy (Debian 7) is stable, a security NMU to stable for
+For example, while  (Debian ) is stable, a 
security NMU to stable for
 a package at version 1.5-3 would have version
-1.5-3+deb7u1, whereas a security upload to Jessie would get
-version 1.5-3+deb8u1.
+1.5-3+debu1, whereas a security upload to 
 would get
+version 1.5-3+debu1.
 
 
 
@@ -2745,7 +2744,7 @@ Version numbers are usually selected by appending
 +debXuY,
 where X is the major release number of Debian and
 Y is a counter starting at 1.
-e.g. 1:2.4.3-4+deb8u1.
+e.g. 1:2.4.3-4+debu1.
 
 
 Please make sure you didn't miss any of these items in your upload:
@@ -2771,7 +2770,7 @@ Make sure that you included an appropriate explanation in 
the changelog;
 
 
 Make sure that you've written the testing
-code name (e.g. jessie)
+code name (e.g. 
)
 into your target distribution;
 
 
diff --git a/resources.dbk b/resources.dbk
index 4b939e6..5bbcfcd 100644
--- a/resources.dbk
+++ b/resources.dbk
@@ -765,16 +765,12 @@ space on people.debian.org.
 
 Release code names
 
-Every released Debian distribution has a code name: Debian
-1.1 is called buzz; Debian 1.2, rex;
-Debian 1.3, bo; Debian 2.0, hamm;
-Debian 2.1, slink; Debian 2.2, potato;
-Debian 3.0, woody; Debian 3.1, sarge;
-Debian 4.0, etch; Debian 5.0, lenny;
-Debian 6.0, squeeze; Debian 7, wheezy;
-Debian 8, jessie;
-the next release Debian 9 will be called stretch
-and Debian 10 will be called buster.
+Every released Debian distribution has a code name:
+Debian  is called 
;
+Debian , ;
+Debian , ;
+the next release Debian  will be called 

+and Debian  will be called 
.
 There is also a ``pseudo-distribution'', called
 sid, which is the current unstable
 distribution; since packages are moved from unstable to
@@ -784,6 +780,7 @@ distribution, sid contains packages for 
architectures which
 are not yet officially supported or released by Debian.  These architectures
 are planned to be integrated into the mainstream distribution at some future
 date.
+The codenames and versions for older releases are listed on the website.
 
 
 Since Debian has an open development model (i.e., everyone can participate and
@@ -805,7 +802,7 @@ was 1.1, and not 1.0.)
 
 
 Thus, the names of the distribution directories in the archive are determined
-by their code names and not their release status (e.g., `squeeze'). These names
+by their code names and not their release status (e.g., `'). 
These names
 stay the same during the development period and after the release; symbolic
 links, which can be changed easily, indicate the currently released stable
 distribution.  That's why the real distribution directories use the

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] branch master updated (e7121c8 -> fc56ee5)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository developers-reference.

  from  e7121c8   Rebuild to fix issues with texlive fonts caused by 
#796120. Closes: #792009, #789391
   new  fc56ee5   Make it easier to update devref for a new Debian release.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 common.ent| 13 +
 pkgs.dbk  | 17 -
 resources.dbk | 19 ---
 3 files changed, 29 insertions(+), 20 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git

[developers-reference] [PATCH] Make it easier to update devref for a new Debian release.

[Paul Wise]

Move information about codenames/versions into the entities.

Refer readers to the website for a list of obsolete releases.
---
 common.ent| 13 +
 pkgs.dbk  | 13 ++---
 resources.dbk | 19 ---
 3 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/common.ent b/common.ent
index ca802a4..a1ec2b0 100644
--- a/common.ent
+++ b/common.ent
@@ -15,6 +15,18 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
 
 
@@ -67,6 +79,7 @@
 https://db.debian.org/machines.cgi;>
 https://buildd.debian.org/;>
 https://release.debian.org/wanna-build.txt;>
+https:///releases/;>
 https://lists.debian.org/debian-project/2009/03/msg00096.html;>
 https://lintian.debian.org/;>
 https://qa.debian.org/;>
diff --git a/pkgs.dbk b/pkgs.dbk
index 126eaac..5bbd53d 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1,5 +1,4 @@
-
- http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [
%commondata;
 ]>
@@ -1124,7 +1123,7 @@ Be sure to verify the following items:
 Target the right distribution
 in your debian/changelog:
 codename-security
-(e.g. jessie-security).
+(e.g. -security).
 Do not target 
distribution-proposed-updates or
 stable!
 
@@ -2157,10 +2156,10 @@ this, a version of the form
 
+debXuY
 should be used, where X is the major release number,
 and Y is a counter starting at 1.
-For example, while Wheezy (Debian 7) is stable, a security NMU to stable for
+For example, while  (Debian ) is stable, a 
security NMU to stable for
 a package at version 1.5-3 would have version
-1.5-3+deb7u1, whereas a security upload to Jessie would get
-version 1.5-3+deb8u1.
+1.5-3+debu1, whereas a security upload to 
 would get
+version 1.5-3+debu1.
 
 
 
@@ -2771,7 +2770,7 @@ Make sure that you included an appropriate explanation in 
the changelog;
 
 
 Make sure that you've written the testing
-code name (e.g. jessie)
+code name (e.g. 
)
 into your target distribution;
 
 
diff --git a/resources.dbk b/resources.dbk
index 4b939e6..68116a8 100644
--- a/resources.dbk
+++ b/resources.dbk
@@ -765,16 +765,12 @@ space on people.debian.org.
 
 Release code names
 
-Every released Debian distribution has a code name: Debian
-1.1 is called buzz; Debian 1.2, rex;
-Debian 1.3, bo; Debian 2.0, hamm;
-Debian 2.1, slink; Debian 2.2, potato;
-Debian 3.0, woody; Debian 3.1, sarge;
-Debian 4.0, etch; Debian 5.0, lenny;
-Debian 6.0, squeeze; Debian 7, wheezy;
-Debian 8, jessie;
-the next release Debian 9 will be called stretch
-and Debian 10 will be called buster.
+Every released Debian distribution has a code name:
+Debian  is called 
;
+Debian , ;
+Debian , ;
+the next release Debian  will be called 

+and Debian  will be called 
.
 There is also a ``pseudo-distribution'', called
 sid, which is the current unstable
 distribution; since packages are moved from unstable to
@@ -784,6 +780,7 @@ distribution, sid contains packages for 
architectures which
 are not yet officially supported or released by Debian.  These architectures
 are planned to be integrated into the mainstream distribution at some future
 date.
+The codenames and versions for older releases are listed on the website.
 
 
 Since Debian has an open development model (i.e., everyone can participate and
@@ -805,7 +802,7 @@ was 1.1, and not 1.0.)
 
 
 Thus, the names of the distribution directories in the archive are determined
-by their code names and not their release status (e.g., `squeeze'). These names
+by their code names and not their release status (e.g., `'). 
These names
 stay the same during the development period and after the release; symbolic
 links, which can be changed easily, indicate the currently released stable
 distribution.  That's why the real distribution directories use the
-- 
2.6.1

[policy] [PATCH] Fix one call to gzip that was missing -n

[Paul Wise]

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 2a3a76e..59b5679 100755
--- a/debian/rules
+++ b/debian/rules
@@ -174,7 +174,7 @@ stamp-binary: stamp-build
 #
 # Compress files and build MD5 checksums.
 #
-   gzip -f9 $(DOCDIR)/*.sgml $(DOCDIR)/changelog
+   gzip -f9 -n $(DOCDIR)/*.sgml $(DOCDIR)/changelog
gzip -f9 -n $(DOCDIR)/*.txt
@set -ex; cd debian/tmp; \
find . -path './DEBIAN' -prune -o -type f -printf '%P\0' \
-- 
2.6.1

Re: [policy] [PATCH] Fix one call to gzip that was missing -n

[Paul Wise]

On Thu, 2015-10-15 at 18:58 +0200, Bill Allombert wrote:

> This is not needed, these files are not generated at build time, they are
> simply copied to the build directory using 'install -p', which preserve
> the timestamp, so the embedded timestamp inside the gzip file is the timestamp
> of the original files, which is consistent across builds.

Thanks for pointing that out and sorry for the noise.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Re: [policy] [PATCH] Fix one call to gzip that was missing -n

[Paul Wise]

On Thu, 2015-10-15 at 19:29 +0200, Bill Allombert wrote:

> Sorry if I sounded a bit harsh, I have been trying to explain that to the
> lintian maintainers three time in a row without any success, so I started
> to feel like a broken clock.

No worries.

> If you do not mind, please try to include some kind of motivation for your
> patches next time instead of a summary of what it does.
> It is rather obvious that your patch "Fix one call to gzip that was missing 
> -n"
> but why you want to do that is to me to guess (and sometime I will guess wrong
> and draw bad inference).

I was reviewing changes since the last time I pulled git and noticed
your gzip -n changes but wondered why you applied gzip -n to some files
but not others, so I incorrectly assumed it was an oversight, oops.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

[developers-reference] branch master updated (16c13ad - de9303f)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository developers-reference.

  from  16c13ad   Update POT and PO files
   new  de9303f   Update links from http to https where possible

The 1 revisions listed above as new are entirely new to this
repository and will be described in separate emails.  The revisions
listed as adds were already present in the repository and have only
been added to this reference.


Summary of changes:
 README-contrib   |   6 +-
 best-pkging-practices.dbk|   2 +-
 beyond-pkging.dbk|   8 +-
 common.ent   | 112 +--
 debian/TODO  |   8 +-
 debian/changelog |   6 ++
 debian/control   |   2 +-
 debian/copyright |   2 +-
 new-maintainer.dbk   |   2 +-
 pkgs.dbk |  26 +++
 po4a/po/de.po| 160 +++
 po4a/po/developers-reference.pot |  62 +++
 po4a/po/fr.po| 136 -
 po4a/po/ja.po| 136 -
 resources.dbk|  24 +++---
 15 files changed, 349 insertions(+), 343 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/collab-maint/developers-reference.git


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140821014859.25649.22...@moszumanska.debian.org

Bug#750993: developers-reference: Please mention more lint-style tools

[Paul Wise]

On Mon, Jun 09, 2014 at 12:26:07PM +0200, Guillem Jover wrote:

 There are several very useful lint-style tools that would be nice to
 mention so that people are aware of them. Here's a non-exhaustive list
 that would be nice to add:

Here is a more exhaustive but still non-exhaustive list:

https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

I'm working making a package to make it easier for people to run them:

http://anonscm.debian.org/gitweb/?p=collab-maint/check-all-the-things.git
http://anonscm.debian.org/gitweb/?p=collab-maint/check-all-the-things-old.git

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#736381: developers-reference: add Steam subscriptions to the list of goodies offered to Debian Developers

[Paul Wise]

Please remember to CC bug submitters when relevant since they are
usually not subscribed and I am definitely not.

I can see both sides of this but I don't really mind which patch gets
into devref, so, please choose a patch, add Debian Maintainers to it
(since they were added after the announcement) and apply it.

PS: this section of devref appears under-maintained, #586186 and #581603
need fixing too.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.

[Paul Wise]

On Wed, Feb 26, 2014 at 6:40 AM, Bill Allombert ballo...@debian.org wrote:

 Debian menu is supported by much more window managers than the XDG menu draft.

This issue is addressed by the xdg-menu system from Arch Linux.

https://wiki.archlinux.org/index.php/Xdg-menu

For the awesome window manager there is also a specific addon.

https://github.com/terceiro/awesome-freedesktop

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6e3ru1zxhohu9pk7w79hrljexapsk7xdq+5itvof6k...@mail.gmail.com

Bug#726998: [debian-policy] any news ? Lintian implement some check now

[Paul Wise]

On Mon, 2014-02-10 at 13:48 +0100, Bill Allombert wrote:

 But practically, how is it possible to replace them by local resources ?

Since most of the remote resources for social networks are non-free the
options are to re-implement them or to just use text and links instead
of JavaScript, CSS and images. Personally I prefer the second option
even when the remote resources are free.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#726998: [debian-policy] any news ? Lintian implement some check now

[Paul Wise]

On Sun, 2014-02-09 at 23:11 +0100, Bill Allombert wrote:

 I am not quite sure I understand your point about Promotion of upstream 
 projects.
 What example do you have in mind ?

Some of the issues are to do with social networks - Twitter, Facebook,
Google+, which are mostly used for promotion in the FOSS world.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#726998: [debian-policy] any news ? Lintian implement some check now

[Paul Wise]

On Wed, Dec 18, 2013 at 03:25:45PM +0100, Bill Allombert wrote:

 Policy could include a word of warning about hypertext documentation.

I reported #738176 against lintian because I noticed Debian contributors
taking incorrect actions (for eg #738101) based on the lintian tag
descriptions. Bastian asked me to come up with some wording for this
section of policy, here is a combination of what I have recommended in
the lintian bug plus some rationale on privacy and the Social Contract:

Local HTML files that use resources (scripts, images, audio, video etc)
that are located on remote servers are a privacy breach for users who
view them in web browsers. On the other hand many of these remote
resources are used for promotion of the upstream projects that Debian
contains. Promotion of upstream projects is essential for their
continued use and development and is good for Free Software as a whole.
The Debian Social Contract suggests we should balance the interests of
our users (privacy) with the needs of upstream projects (new users and
continued development). The best way to do that is to use local
resources instead of remote resources. Please replace any scripts,
images or other remote resources used by HTML files in Debian packages
with non-remote resources. It is preferable to replace them with text
and links but local copies of the remote resources are also acceptable
as long as they don't also make calls to remote services or resources.
Please ensure that the remote resources are suitable for Debian main
before making local copies of them.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#736381: developers-reference: add Steam subscriptions to the list of goodies offered to Debian Developers

[Paul Wise]

Package: developers-reference
Severity: wishlist
Tags: patch
X-Debbugs-CC: jo.shie...@collabora.co.uk, neil.mcgov...@collabora.com

Please add Steam subscriptions to the list of goodies offered to Debian
Developers, Valve/Collabora recently announced[1] this. Patch attached.

 1. http://lists.debian.org/20140122182721.gf8...@halon.org.uk

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Index: resources.dbk
===
--- resources.dbk	(revision 10361)
+++ resources.dbk	(working copy)
@@ -1588,6 +1588,14 @@
 ulink url=http://lists-host;/debian-devel-announce/2008/11/msg4.html;/ulink.
 /para
 /section
+section id=steam
+titleValve games on Steam/title
+para
+Since January 2014, Valve has sponsored free subscribtions to all past and present
+Valve games on the Steam game distribution service for all interested Debian Developers.
+See ulink url=http://lists-host;/debian-devel-announce/2014/01/msg6.html;/ulink.
+/para
+/section
 
 /section
 


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

Bug#736381: developers-reference: add Steam subscriptions to the list of goodies offered to Debian Developers

[Paul Wise]

On Wed, 2014-01-22 at 19:31 -0400, David Prévot wrote:

 it may not be such a good idea to incite DD to install and use
 non-free tools (as potential security issue)

I have updated the patch to encourage Debian members to not install
Steam on their Debian development machines. I think it is reasonable for
Debian members to install proprietary games on machines they don't use
for Debian development though. That said, I'm sure many of us already
have non-free software on our systems; pretty much anyone who uses amd64
for example has fairly untrustworthy firmware somewhere on their system.

 spending time on such games may not be the most productive use of
 their time for the project.

I find this to be a fairly silly argument. The way Debian members use
their time is completely their own choice. We don't expect them to work
on Debian instead of playing board games, going to the movies, going to
the beach, spending time with friends/family and so on. Computer gaming
should be no different. I expect gaming is also an important stress
relief for some, especially after reading some Debian mailing lists. I
think it is important for Debian members and users to have some fun in
their lives and games (Free or not) are one such source of fun, which is
why I work in and support the Debian games team. Happily XKCD 306 is not
the reality of being a Debian member today and I hope it never will be.

https://xkcd.com/306/
http://packages.debian.org/sid/games/
https://wiki.debian.org/Games/Team

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Index: resources.dbk
===
--- resources.dbk	(revision 10361)
+++ resources.dbk	(working copy)
@@ -1588,6 +1588,16 @@
 ulink url=http://lists-host;/debian-devel-announce/2008/11/msg4.html;/ulink.
 /para
 /section
+section id=steam
+titleValve games on Steam/title
+para
+Since January 2014, Valve has sponsored free subscribtions to all past and present
+Valve games on the Steam game distribution service for all interested Debian Developers.
+Since Steam and Valve games are not Free Software, please avoid using your Debian
+development machines for using Steam and playing games from Steam.
+See ulink url=http://lists-host;/debian-devel-announce/2014/01/msg6.html;/ulink.
+/para
+/section
 
 /section
 


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

Re: obsolete conffiles: s/may/should/

[Paul Wise]

On Mon, 2013-05-06 at 15:18 +0800, Paul Wise wrote:

 In policy section 10.7.3 Behavior, there is this sentence:
 
 Obsolete configuration files without local changes may be
 removed by the package during upgrade.
 
 I would like to suggest that may be replaced with should.

Ping, what is the status of this?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

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

[Paul Wise]

On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote:

 do you think that the attached patch would solve the problem ?

There are more reasons for using Built-Using than licenses, for example:

Rebuilding against updated versions of static libraries.
Rebuilding the debian-installer-*-netboot-* packages.

I don't think we should restrict usage of Built-Using to only
license-related reasons, there are also other reasons.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6ESSNyFz=pcwkibsvobh_unhqbnhr2y5o822zu93m5...@mail.gmail.com

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

[Paul Wise]

On Mon, Sep 23, 2013 at 11:04 AM, Charles Plessy wrote:

 I paste below the current wording in the Policy 3.9.4.  If you have an
 improvement to propose, that would be much appreciated !

The wording doesn't appear confusing to me so I'm not the best person
to propose wording changes.

 The problem to solve here is to find a clear and concise way to describe how
 this field is used.  The current description in the Policy has confused some
 people and made them think or worry that they were asked unreasonable work.

I would suggest leaving the current wording, monitoring usage of the
field and filing bugs on any packages that use the field in an
improper way.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gza-6fcuddyz1sb0-gx-oh_yoqaivnzf7rwwu6k4y...@mail.gmail.com

obsolete conffiles: s/may/should/

[Paul Wise]

In policy section 10.7.3 Behavior, there is this sentence:

Obsolete configuration files without local changes may be
removed by the package during upgrade.

I would like to suggest that may be replaced with should.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: obsolete conffiles: s/may/should/

[Paul Wise]

On Mon, 2013-05-06 at 17:12 +0900, Charles Plessy wrote:

 do we have an estimate (via piuparts ?) on how many packages are
 failing to do that?

piuparts does test for this, some stats:

sid2experimental 23
testing2sid 12
squeeze2wheezy 209
squeeze2bpo2wheezy 36
lenny2squeeze 47

http://anonscm.debian.org/gitweb/?p=piuparts/piuparts.git;a=blob;f=known_problems/obsolete_conffiles_error.conf;hb=HEAD

Since the program 'adequate' appeared and supports checking for obsolete
conffiles we have been userttagging bugs and found a few of them:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=obsolete-conffile;archive=both

On my relatively recently installed machine there are 8 obsolete conffiles:

$ dpkg-query -W -f='${Conffiles}\n' | grep obsolete | wc -l
8

On a machine that has been running for a few years with apt pinned to
experimental (then sid, testing), there are 59:

$ dpkg-query -W -f='${Conffiles}\n' | grep obsolete | wc -l
59

On master.debian.org there is only one:

pabs@master:~$ dpkg-query -W -f='${Conffiles}\n' | grep obsolete | wc -l
1

So the vast majority of packages obey this suggestion.

 It looks to me that the removal would happen only if the packages are
 following the advices of http://wiki.debian.org/DpkgConffileHandling
 (which now looks as simple as using dpkg-maintscript-helper via
 dh_installdeb).

Correct.

 Maybe a few rounds of advocacy for the tools above could be done
 before making the recommendation a SHOULD statement ?

While advocacy for removing obsolete conffiles, adequate, puiparts,
lintian and other QA tools is definitely a good idea, I don't think we
need to do that before changing policy. Raphaël Hertzog has done some
advocacy about removing obsolete conffiles in the past:

http://raphaelhertzog.com/2010/10/07/the-right-way-to-remove-an-obsolete-conffile-in-a-debian-package/
http://raphaelhertzog.com/2011/01/31/debian-cleanup-tip-1-get-rid-of-useless-configuration-files/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#685039: developers-reference: please document what is needed to reintroduce a package

[Paul Wise]

On Fri, 2012-08-17 at 11:43 +0800, Paul Wise wrote:

 I changed the sentence to make it clear that this is only triggered by
 removals from unstable. Updated patch attached.

My patch does not seem to have been committed to the SVN repository,
could someone do that please?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#685039: developers-reference: please document what is needed to reintroduce a package

[Paul Wise]

On Sun, 2012-09-16 at 19:53 +0800, Paul Wise wrote:

 My patch does not seem to have been committed to the SVN repository,
 could someone do that please?

Apparently I need an ack on my patch to devref about the procedures
needed when re-introducing packages. I would appreciate it if someone
from the debian-qa list (CCed) could take a look at the patch and
suggest if the patch needs to be changed or is suitable for committing.

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=reintroducing-packages.patch;att=1;bug=685039

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#685039: developers-reference: please document what is needed to reintroduce a package

[Paul Wise]

On Sun, 2012-09-16 at 13:28 +, Bart Martens wrote:

 I'm looking at this now.  I agree with most of your patch.  I'm having doubts
 on this paragraph :
...
 I suggest to replace the paragraph quoted above by these two paragraphs :

Done in the attached patch, thanks.

Based on feedback from IRC I also changed the ftp-master removals link
to http://ftp-master.debian.org/#removed since the page I was linking to
was about pending removals instead of completed ones.

 Other than that, I read good info in your patch, so I think it's a good
 addition.

Thanks for the ack!

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Index: common.ent
===
--- common.ent	(revision 9361)
+++ common.ent	(working copy)
@@ -28,6 +28,7 @@
 !ENTITY www-debian-org www.debian.org
 !ENTITY ftp-debian-org ftp.debian.org
 !ENTITY release-debian-org release.debian.org
+!ENTITY snap-debian-org snapshot.debian.org
 !ENTITY lists-host lists.debian.org
 !ENTITY archive-host archive.debian.org
 !ENTITY keyserver-host keyring.debian.org
Index: pkgs.dbk
===
--- pkgs.dbk	(revision 9361)
+++ pkgs.dbk	(working copy)
@@ -1238,7 +1238,7 @@
 /section
 
 section id=archive-manip
-titleMoving, removing, renaming, adopting, and orphaning packages/title
+titleMoving, removing, reintroducing, renaming, adopting, and orphaning packages/title
 para
 Some archive manipulation operations are not automated in the Debian upload
 process.  These procedures should be manually followed by maintainers.  This
@@ -1385,6 +1385,51 @@
 
 /section
 
+section id=reintroducing-pkgs
+titleReintroducing packages/title
+para
+Packages are often removed due to release-critical bugs, absent maintainers,
+too few users or poor quality in general. There are some things you should be
+aware of when reintroducing removed packages.
+/para
+para
+You should check why the package was removed in the first place. This
+information can be found in the removal item in the news section of the PTS
+page for the package or by browsing the log of
+ulink url=http://ftp-master-host;/#removed;removals/ulink.
+The removal bug will tell you why the package was removed and will give some
+indication of what you will need to work on in order to reintroduce the package.
+It may indicate that the best way forward is to switch to some other piece of
+software instead of reintroducing the package.
+/para
+para
+It may be appropriate to contact the former maintainers to find out if
+they are working on reintroducing the package, interested in co-maintaining
+the package or interested in sponsoring the package if needed.
+You should do all the things required before introducing new packages
+(xref linkend=newpackage/).
+/para
+para
+You should base your work on the latest packaging available that is suitable.
+That might be the latest version from literalunstable/literal, which will
+still be present in the ulink url=snap-debian-org;snapshot archive/ulink.
+/para
+para
+The version control system used by the previous maintainer might contain useful
+changes, so it might be a good idea to have a look there.  Check if the control
+file of the previous package contained any headers linking to the version
+control system for the package and if it still exists.
+/para
+para
+Package removals from unstable (not testing, stable or oldstable) trigger the
+closing of all bugs related to the package. You should look through all the
+closed bugs (including archived bugs) and unarchive and reopen any that were
+closed in a version ending in literal+rm/literal and still apply. Any that
+no longer apply should be marked as fixed in the correct version if that is
+known.
+/para
+/section
+
 section id=s5.9.3
 titleReplacing or renaming packages/title
 para


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

Bug#685039: developers-reference: please document what is needed to reintroduce a package

[Paul Wise]

On Thu, 2012-08-16 at 18:35 +0300, Antti-Juhani Kaijanaho wrote:

 Perhaps there should be a note making clear that only removal from unstable
 (and experimental) is what is meant here; removals from testing do not give
 cause to use this procedure.

I changed the sentence to make it clear that this is only triggered by
removals from unstable. Updated patch attached.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Index: pkgs.dbk
===
--- pkgs.dbk	(revision 9307)
+++ pkgs.dbk	(working copy)
@@ -1238,7 +1238,7 @@
 /section
 
 section id=archive-manip
-titleMoving, removing, renaming, adopting, and orphaning packages/title
+titleMoving, removing, reintroducing, renaming, adopting, and orphaning packages/title
 para
 Some archive manipulation operations are not automated in the Debian upload
 process.  These procedures should be manually followed by maintainers.  This
@@ -1385,6 +1385,49 @@
 
 /section
 
+section id=reintroducing-pkgs
+titleReintroducing packages/title
+para
+Packages are often removed due to release-critical bugs, absent maintainers,
+too few users or poor quality in general. There are some things you should be
+aware of when reintroducing removed packages.
+/para
+para
+You should check why the package was removed in the first place. This
+information can be found in the removal item in the news section of the PTS
+page for the package or by browsing the log of
+ulink url=http://ftp-master-host;/removals.html;removals/ulink.
+The removal bug will tell you why the package was removed and will give some
+indication of what you will need to work on in order to reintroduce the package.
+It may indicate that the best way forward is to switch to some other piece of
+software instead of reintroducing the package.
+/para
+para
+It may be appropriate to contact the former maintainers to find out if
+they are working on reintroducing the package, interested in co-maintaining
+the package or interested in sponsoring the package if needed.
+You should do all the things required before introducing new packages
+(xref linkend=newpackage/).
+/para
+para
+You should base your work on the latest packaging available that is suitable.
+That might be the latest version from literalunstable/literal, which will
+still be present in the ulink url=snap-debian-org;snapshot archive/ulink.
+Or the version control system used by the previous maintainer might contain
+newer packaging. Check if the control file of the previous package contained
+any headers linking to the version control system for the package and if it
+still exists.
+/para
+para
+Package removals from unstable (not testing, stable or oldstable) trigger the
+closing of all bugs related to the package. You should look through all the
+closed bugs (including archived bugs) and unarchive and reopen any that were
+closed in a version ending in literal+rm/literal and still apply. Any that
+no longer apply should be marked as fixed in the correct version if that is
+known.
+/para
+/section
+
 section id=s5.9.3
 titleReplacing or renaming packages/title
 para
Index: common.ent
===
--- common.ent	(revision 9307)
+++ common.ent	(working copy)
@@ -28,6 +28,7 @@
 !ENTITY www-debian-org www.debian.org
 !ENTITY ftp-debian-org ftp.debian.org
 !ENTITY release-debian-org release.debian.org
+!ENTITY snap-debian-org snapshot.debian.org
 !ENTITY lists-host lists.debian.org
 !ENTITY archive-host archive.debian.org
 !ENTITY keyserver-host keyring.debian.org


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

Bug#685039: developers-reference: please document what is needed to reintroduce a package

[Paul Wise]

Package: developers-reference
Severity: wishlist
Tags: patch

How to reintroduce packages isn't fully obvious to everybody and there
some details that rely on services or information some folks don't know
about. I have written a section for devref with the information I know
about. Please apply the attached rough patch to document this process.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Index: common.ent
===
--- common.ent	(revision 9307)
+++ common.ent	(working copy)
@@ -28,6 +28,7 @@
 !ENTITY www-debian-org www.debian.org
 !ENTITY ftp-debian-org ftp.debian.org
 !ENTITY release-debian-org release.debian.org
+!ENTITY snap-debian-org snapshot.debian.org
 !ENTITY lists-host lists.debian.org
 !ENTITY archive-host archive.debian.org
 !ENTITY keyserver-host keyring.debian.org
Index: pkgs.dbk
===
--- pkgs.dbk	(revision 9307)
+++ pkgs.dbk	(working copy)
@@ -1238,7 +1238,7 @@
 /section
 
 section id=archive-manip
-titleMoving, removing, renaming, adopting, and orphaning packages/title
+titleMoving, removing, reintroducing, renaming, adopting, and orphaning packages/title
 para
 Some archive manipulation operations are not automated in the Debian upload
 process.  These procedures should be manually followed by maintainers.  This
@@ -1385,6 +1385,48 @@
 
 /section
 
+section id=reintroducing-pkgs
+titleReintroducing packages/title
+para
+Packages are often removed due to release-critical bugs, absent maintainers,
+too few users or poor quality in general. There are some things you should be
+aware of when reintroducing removed packages.
+/para
+para
+You should check why the package was removed in the first place. This
+information can be found in the removal item in the news section of the PTS
+page for the package or by browsing the log of
+ulink url=http://ftp-master-host;/removals.html;removals/ulink.
+The removal bug will tell you why the package was removed and will give some
+indication of what you will need to work on in order to reintroduce the package.
+It may indicate that the best way forward is to switch to some other piece of
+software instead of reintroducing the package.
+/para
+para
+It may be appropriate to contact the former maintainers to find out if
+they are working on reintroducing the package, interested in co-maintaining
+the package or interested in sponsoring the package if needed.
+You should do all the things required before introducing new packages
+(xref linkend=newpackage/).
+/para
+para
+You should base your work on the latest packaging available that is suitable.
+That might be the latest version from literalunstable/literal, which will
+still be present in the ulink url=snap-debian-org;snapshot archive/ulink.
+Or the version control system used by the previous maintainer might contain
+newer packaging. Check if the control file of the previous package contained
+any headers linking to the version control system for the package and if it
+still exists.
+/para
+para
+Package removals usually trigger the closing of all bugs related to the package.
+You should look through all the closed bugs (including archived bugs) and
+unarchive and reopen any that were closed in a version ending in
+literal+rm/literal and still apply. Any that no longer apply should be
+marked as fixed in the correct version if that is known.
+/para
+/section
+
 section id=s5.9.3
 titleReplacing or renaming packages/title
 para


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

Bug#671503: general: APT repository format is not documented

[Paul Wise]

On Sat, May 5, 2012 at 5:13 AM, Russ Allbery wrote:

 I think debian-policy is the right repository for this.  I think it would
 make the most sense to maintain this via a looser update method than the
 normal Policy process and to instead just apply any update that ftp-master
 says is in place, since the decision-making is already handled through
 ftp-master and other discussions and there's not much to be gained by an
 additional decision process.

As someone who has been working on validating the apt repository
metadata from our derivatives, I would greatly appreciate it if
debian-policy documented that metadata, especially the Release files.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6f7nzndsjrwuoq2qwo2rcxtn60hkqlg_fuz2_unha3...@mail.gmail.com

Re: alternative dependency ordering - with respect of packages in main

[Paul Wise]

On Tue, Sep 20, 2011 at 7:12 PM, Gerfried Fuchs wrote:

  tl;dr - what do you think, is a Depends: foo-contrib | foo acceptable
 for packages in main or should it be Depends: foo | foo-contrib
 instead?

I vote:

Package: bar
Depends: foo

Package: foo-contrib
Provides: foo

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gmiezzzyb3t0zbp-mtf1xyrdvglmarb2pmkcyncix...@mail.gmail.com

Re: alternative dependency ordering - with respect of packages in main

[Paul Wise]

On Tue, Sep 20, 2011 at 8:04 PM, Ben Armstrong wrote:

 While that neatly sidesteps the issue, 7.5 says:

     To specify which of a set of real packages should be the default to
     satisfy a particular dependency on a virtual package, list the real
     package as an alternative before the virtual one.

 But that doesn't specify a 'must' (or even 'should').

Well, obviously there would be a package foo in main too so this would
not be violated. I should have included such a package in my example.

 What I'm concerned
 about is if someone has already added contrib or non-free to their apt
 sources for the purpose of providing some software essential to their
 needs, by not specifying which dependency is preferable here, the user
 will arbitrarily end up with a free or non-free 'foo' which may or may
 not be what they want. Though arguably, if they wanted only the
 essential stuff from contrib/non-free, they could use pinning to
 ensure that's all they take.

In my intended case I believe they always end up with foo from main,
only if they choose foo-contrib will they get it, which is how I think
it should be. main should not reference packages from contrib/non-free
in any way.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6HCX=2g5vm9kc5qptsxot_fmi81eey2bj+moduhycp...@mail.gmail.com

Bug#586186: developers-reference: mention DD certificates in Goodies for Developers section

[Paul Wise]

Package: developers-reference
X-Debbugs-CC: lea...@debian.org

Please mention that DDs can get official certification of their Debian
project membership from the DPL. Some details are available here:

http://wiki.debian.org/DDCertificate
http://lists.debian.org/20100401011741.gp10...@einval.com

I'm sure the DPL will be willing to provide any more needed details.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#581603: developers-reference: please mention that DMs can now get HP-sponsored LWN subscriptions

[Paul Wise]

Package: developers-reference
Severity: wishlist

DMs are now able to get HP-sponsored LWN subscriptions:

http://www.gag.com/bdale/blog/posts/Debian_and_LWN.html

It would be good if this could be mentioned in devref 4.13.1.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Removing the manpage requirement for GUI programs?

[Paul Wise]

2010/2/28 Josselin Mouette j...@debian.org:

 currently policy §12.1 mandates that “each program, utility, and
 function should have an associated manual page”. However, the more I
 stomp on bug reports about manual pages, the less I am convinced of
 their usefulness for GUI programs.

How about replacing an associated manual page with associated
documentation? Also add a sentence or two saying that said
documentation may be in any format(s) (manual pages suggested)
viewable in Debian and should be well maintained.

help2man-generated manual pages are no substitute for good,
well-maintained manual pages or other documentation.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e13a36b31003050009x6983ddear22dc78643d61b...@mail.gmail.com

Re: Flag images

[Paul Wise]

On Mon, Feb 15, 2010 at 10:18 PM, Dmitry E. Oboukhov un...@debian.org wrote:

 I'm going to add into debian a few new (my) projects which need flag
 images and so I want to add a package which contains flag set.

Are you sure they need flags? Which package and what exactly will the
flags represent?

I would personally suggest to avoid adding flags to Debian where possible.

Some background to my opinion:

http://lwn.net/Articles/333623/
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
http://lists.fedoraproject.org/pipermail/legal/2009-January/thread.html#501
http://lwn.net/Articles/334519/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e13a36b31002150813g7a6886b0le736c15a557a6...@mail.gmail.com

Bug#564068: developers-reference: alioth section mentions GForge instead of FusionForge

[Paul Wise]

Package: developers-reference
Version: 3.4.3
Severity: minor
X-Debbugs-CC: ad...@alioth.debian.org

The alioth section[1] of the devref says that alioth runs GForge, which
is no longer the case. I'd suggest that it be amended to remove mention
of the software run on alioth altogether to avoid needing to change it
when/if alioth switches to another forge system or adds another version
control system. CCing the alioth admins in case they want to offer new
wording for the section.

 1. 
http://www.debian.org/doc/manuals/developers-reference/resources.html#alioth

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: does /var/games have to be deleted on purge? (if it's empty..)

[Paul Wise]

On Wed, Apr 8, 2009 at 7:51 PM, Holger Levsen hol...@layer-acht.org wrote:

 On Mittwoch, 8. April 2009, Bill Allombert wrote:
 Unless policy is changed to make clear that /var/games can be removed
 at any time, and thus that package cannot just ship /var/games in the
 deb and expect it to be available when running the postinst, or at any
 latter time, I have to object with this bug reports because this
 introduces a race condition.

 I dont understand, can you please explain what race condition you mean?

How about this:

Game a gets installed and ships /var/games
Game b gets installed and ships /var/games
Game a gets purged and removes /var/games
User starts game b and gets a high score
Game b tries to save the high score but fails because /var/games doesn't exist

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
http://synfig.org/User:PaulWise
http://bonedaddy.net/pabs3/


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: does /var/games have to be deleted on purge? (if it's empty..)

[Paul Wise]

On Tue, Apr 7, 2009 at 2:33 AM, Russ Allbery r...@debian.org wrote:

 I don't see much real benefit in going out of our way to remove /var/games
 and it looks like it would be a bit annoying (at the least, require adding
 purge code to all games that put files in /var/games that would usually
 never be triggered).  My inclination would be to say that this behavior is
 fine and perhaps we should officially bless it somewhere.

A single rmdir in every game using /var/games isn't that hard,
especially since they have to remove the files from there.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org