Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

[Gunnar Wolf]

Package: debian-policy
Version: 4.6.2.0
Severity: normal
Tags: patch

It has been four months since the General Resolution 2022/vote_003 was
voted¹, but it has not yet been completely adopted. The archive area
was created and at least a package was uploaded to it in October, but
it has not seen further movement. Two days ago, a call to action for
moving packages was sent by Cyril Brulebois², and I just sent a mail
checking for other places where it should be included³.

¹ https://www.debian.org/vote/2022/vote_003
² https://lists.debian.org/debian-boot/2023/01/msg00150.html
³ https://lists.debian.org/debian-project/2023/01/msg00018.html

To my surprise, the non-free-firmware archive area has not yet been
discussed for inclusion in the Policy.

I am (now!) aware there is a clear process to get changes included in
the Policy, but this is the first time I do this, so please excuse me
for jumping all the way to "State D: Wording proposed" (of course, my
words can be checked and improved, particularly given I'm not a native
English speaker).

⁴ https://www.debian.org/doc/debian-policy/ap-process.html

I am suggesting the following patch, which I'm attaching to this bug
report, and also uploaded them to my fork of debian-policy in Salsa:


https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0

Thank you very much for considering this!

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  5.3.0-3

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

-- no debconf information
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index ab04261..15b9343 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -24,11 +24,11 @@ The aims of this are:
 
 The *main* archive area forms the *Debian distribution*.
 
-Packages in the other archive areas (``contrib``, ``non-free``) are not
-considered to be part of the Debian distribution, although we support
-their use and provide infrastructure for them (such as our bug-tracking
-system and mailing lists). This Debian Policy Manual applies to these
-packages as well.
+Packages in the other archive areas (``non-free-firmware``,
+``contrib``, ``non-free``) are not considered to be part of the Debian
+distribution, although we support their use and provide infrastructure
+for them (such as our bug-tracking system and mailing lists). This
+Debian Policy Manual applies to these packages as well.
 
 .. _s-dfsg:
 
@@ -130,6 +130,27 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+.. _s-non-free-firmware:
+
+The non-free-firmware archive area
+~~
+
+The *non-free-firmware* archive area contains packages providing
+firmware needed to initialize, use or keep updated hardware required
+by our users, typically necessary for important functions to be
+available (i.e. wireless network connectivity) or for fixing security
+defects in hardware (i.e. CPU microcode updates). Packages in this
+archive may not comply with all of the policy requirements in this
+manual due to lack of source code availability, restrictions on
+modification or other limitations.
+
+Packages in *non-free-firmware*
+
+- must not be so buggy that we refuse to support them, and
+
+  - must meet all policy requiremens presented in this manual that it
+is possible for them to meet.
+
 .. _s-contrib:
 
 The contrib archive area
@@ -261,8 +282,8 @@ prohibited" and "distribution restricted".
 Sections
 
 
-The packages in the archive areas *main*, *contrib* and *non-free* are
-grouped further into *sections* to simplify handling.
+The packages in the archive areas *main*, *non-free-firmware*, *contrib*
+and *non-free* are grouped further into *sections* to simplify handling.
 
 The archive area and section for each package should be specified in the
 package's ``Section`` control record (see
@@ -272,8 +293,8 @@ the Debian distribution. The ``Section`` field should be of 
the form:
 
 -  *section* if the package is in the *main* archive area,
 
--  *area/section* if the package is in the *contrib* or *non-free*
-   archive areas.
+-  *area/section* if the package is in the *non-free-firmware*, *contrib*
+   or *non-free* archive areas.
 
 The Debian archive maintainers provide the authoritative list of
 sections. At present, they are: admin, cli-mono, comm, database, debug,

Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jun 21, 2019 at 02:36:05PM +0100]:
> My reading of the conclusion to #904558 is that the recommendation to
> form a working group is a recommendation that can be directed only to
> the developer body as a whole, not to the Policy process.  That's
> because actually implementing in the archive some new mechanism for
> maintscripts is a prerequisite to any Policy change requiring packages
> to use that new mechanism.  In other words, what the working group would
> be tasked with doing is beyond the scope of the Policy process.  We do
> design work as part of the Policy process, but we don't write code.
> 
> Assuming that the T.C.'s recommendation is the right way to proceed
> here, and someone doesn't come up with any other way to unblock things,
> the wontfix+stalled status will remain until and unless the working
> group actually forms, designs and implements something, and starts using
> it in the archive.  There is no role for the Policy process (and thus no
> role for the Policy Editors qua Policy Editors) until that occurs.
> 
> So, by all means insist on the recommendation, but so far as I can tell
> that's something which does not involve either the Policy process or the
> T.C., but simply the body of Debian contributors qua contributors.

I completely agree with you - My idea to kickstart this at DC19 is not
for TC and Policy Editors leading a session, but rather us (as
individuals) expressing the issue at a BoF trying to get more eyeballs
(and, more important, more brains) on it.

> Stepping back a bit, tagging this bug wontfix+stalled is part of the
> broader attempts, in which the Policy Editors are engaged, to more
> sharply delineate the boundaries of the Policy process.  We want to get
> to the point where the only bugs that we have listed are either
> highly actionable, or tagged wontfix.  For a bug to be highly actionable
> is for it to be the case that someone with enough time and background
> knowledge can sit down, think through the problem, and come up with at
> least a first version of a change proposal.
> 
> I think that a large number of very-difficult-to-action bugs strongly
> discourages people from getting involved.  It makes Policy seem like a
> sprawling, unmanageable morass of difficult problems.  That isn't how
> things are, because while there are indeed a lot of hard problems, they
> are largely independent of each other, and tackling individual
> debian-policy bugs really does improve Debian.  However, it is much
> harder to see that when half of the open bugs are more than five years
> old yet not tagged wontfix.

Right. This is a bug where I was quite happy that the TC decided to
declare it outside of its functions - And it is just fitting that it's
outside the Policy as well. We don't have a commonly implemented
practice to document / show / follow. This should go to the developer
body at large.


signature.asc
Description: PGP signature

Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"

[Gunnar Wolf]

Hello Sean,

> In #904558 I asked the T.C. for advice about how to move #802501
> forward.  Their ultimate response was to recommend that a working group
> of developers come up with some method, other than exiting nonzero, for
> a maintscript to indicate that it failed to restart services.  Let me
> take this opportunity to thank all those who were involved in #904558.
> 
> In this message, I seek to explain my understanding of what the closing
> of T.C. bug #904558 means for debian-policy bug #802501, and those
> merged with it.  Apologies for the length.  I wanted this general sort
> of reasoning to be recorded somewhere for reference in future
> discussions.

Thank you for providing this framing and for helping us (me, at
least!) better understand the circumstances of your bug filing. Quite
probably, I should have probably read #802501 during the #904558
discussion (and it's a very short bug FWIW), but didn't. Understanding
the bug follow-up policy of the Policy Editors makes me more at ease
with what we (TC) decided — We were not the first ones to fail to find
an always-good solution :-|

Now, I would more than welcome this bugs to be pushed to the right
areas: To d-devel, or to a new, specialized working group tackling the
issue. Both in the bugs and in our discussions, it is often repeated
(quoting here Sam, from #802501) «as a distribution, I think we should
explicitly encourage people to consider the consequences on
dist-upgrade and other operations». Inconsistently failing is *not*
OK, and nobody implied it that way...

So,

> The 'obsolete', 'ctte' and 'stalled' usertags are meant to be used in
> addition to the 'wontfix' tag.
> 
> ~ ~ ~
> 
> In #904558, I did not ask the T.C. to rule on what maintscripts should
> do when they fail to restart a service.  Rather, I asked them to weigh
> in on the decision between the options described above, given that the
> Policy Changes Process had failed to achieve consensus.  However, in the
> message closing #904558, the T.C. indicated that they declined to issue
> a ruling about what maintscripts should do when they fail to restart a
> service.  So the second option described above, corresponding to the
> 'ctte' usertag, has been taken off the table.
> 
> That leaves us with the question of whether to leave #802501 open, in
> the absence of the possibility of closing it by having the T.C. make a
> call.  Given that this bug has already been filed (at least) twice, I
> think it would be best for us to leave it open.  So I'm tagging
> wontfix+stalled.

I want to interpret this wontfix+stalled, and the TC answer ("The
Technical Committee does not engage in design of new proposals and
policies") don't mean this problem will just lay dormant and unsolved
forever. As Marga said in her mail closing this bug, «While we
recognize that this is a problem worth fixing, this is not something
that we can fix as a body and need the help of the Developers to do
it.»

I want to insist on our recommendation to create a work group of
developers to tackle this issue. Maybe we can start it off as a BoF
session in DC19?


signature.asc
Description: PGP signature

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jun 15, 2018 at 01:06:43PM +0100]:
> Thank you for this.
> 
> Let's use POSIX.1-2017 rather than relying on the download filenames.
> 
> Please find a revised patch below; hopefully Gunnar will renew his
> second, and perhaps you'll second too, Simon.  Again, all that the patch
> does is:

Sorry for the delay!

Of course, I second the following text.

> - replace the string "SUSv3" with "POSIX.1-2017" wherever it appears
> - update the footnote which gives the download URI for the standard
> 
> > or perhaps replacing SUSv3 with POSIX and clarifying that we use POSIX
> > to refer to the latest version of the POSIX.1 standard.
> 
> This is an interesting suggestion.  So far as I can see the only
> advantage to this is that we don't need Policy bugs to bump the version
> of the standard we target.  That does not strike me as a large enough
> advantage to justify giving up explicit control over the version of the
> standard that applies to Debian -- do you see other advantages?
> 
> Patch:
> 
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index 90ae58a..f31a3b4 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -203,9 +203,9 @@ may instead be easier to check the exit status of 
> > commands directly. See
> >  Every script should use ``set -e`` or check the exit status of *every*
> >  command.
> >  
> > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> > +Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell 
> > Command
> >  Language  [#]_ plus the following additional features not mandated by
> > -SUSv3.. [#]_
> > +POSIX.1-2017.. [#]_
> >  
> >  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> > newline.
> > @@ -238,13 +238,13 @@ SUSv3.. [#]_
> > which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> > allowed.
> >  
> > -If a shell script requires non-SUSv3 features from the shell interpreter
> > +If a shell script requires non-POSIX.1-2017 features from the shell 
> > interpreter
> >  other than those listed above, the appropriate shell must be specified
> >  in the first line of the script (e.g., ``#!/bin/bash``) and the package
> >  must depend on the package providing the shell (unless the shell package
> >  is marked "Essential", as in the case of ``bash``).
> >  
> > -You may wish to restrict your script to SUSv3 features plus the above
> > +You may wish to restrict your script to POSIX.1-2017 features plus the 
> > above
> >  set when possible so that it may use ``/bin/sh`` as its interpreter.
> >  Checking your script with ``checkbashisms`` from the devscripts package
> >  or running your script with an alternate shell such as ``posh`` may help
> > @@ -762,10 +762,10 @@ restricted to ASCII when it is possible to do so.
> > complicated and difficult to manage.
> >  
> >  .. [#]
> > -   Single UNIX Specification, version 3, which is also IEEE 1003.1-2004
> > -   (POSIX), and is available on the World Wide Web from `The Open
> > -   Group `_ after free
> > -   registration.
> > +   The Open Group Base Specifications Issue 7, 2018 Edition, which is
> > +   also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
> > +   available on the World Wide Web from `The Open Group
> > +   `_.
> >  
> >  .. [#]
> > These features are in widespread use in the Linux community and are
> > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> > index 7d85c00..32619e8 100644
> > --- a/policy/ch-opersys.rst
> > +++ b/policy/ch-opersys.rst
> > @@ -479,7 +479,7 @@ configurable values should not be placed directly in 
> > the script.
> >  Instead, they should be placed in a file in ``/etc/default``, which
> >  typically will have the same base name as the ``init.d`` script. This
> >  extra file should be sourced by the script when the script runs. It must
> > -contain only variable settings and comments in SUSv3 ``sh`` format. It
> > +contain only variable settings and comments in POSIX.1-2017 ``sh`` format. 
> > It
> >  may either be a ``conffile`` or a configuration file maintained by the
> >  package maintainer scripts. See :ref:`s-config-files` for
> >  more details.


signature.asc
Description: PGP signature

Bug#682347: mark 'editor' virtual package name as obsolete

[Gunnar Wolf]

Russ Allbery dijo [Mon, Dec 25, 2017 at 05:02:01PM -0800]:
> (...)
> I think there are three options, and I'd love to get feedback on which of
> those three options we should take.
> 
> 1. Status quo: there is an undocumented editor virtual package, Policy
>says that nothing has to provide or depend on it, and some random
>collection of editors provide it.  I think this is a bad place to be,
>so I would hope we can rule out sticking with that status quo.
> 
> 2. Document editor and recommend everyone implement it properly.  Since
>we're going to allow packages to depend on editor, I think providing it
>would need to be a should, so that's going to be a lot of buggy (but
>not RC-buggy) editor packages.  But it would get us to a clean
>dependency system.  (I will leave it to someone else to tackle this for
>pager if someone really wants to.)
> 
> 3. Mark editor obsolete, leaving only the alternative, and have people
>just use that directly and assume it exists.  (My previous patch.)
> (...)
> I have a previous proposed patch in this thread for option 3.  For the
> sake of completeness, here's a proposed patch for option 2.
> 
> I'd love to have people weigh in on this.  I know it's currently the
> holiday season, so I'll probably need to ping this bug again in a week or
> two to get more opinions.

I lean towards version 2. Yes, several packages will be buggy - but,
as you mention, not RC-buggy. It's not *that* many packages. And it's
the correct solution.

Of course, I was not familiar with this bug, and am replying just
after skimming it (trying to follow the most salient details), so this
should just be read as a "leaning towards" and not as an "endorsement"
for the patch in question.

Bug#742364: Patch to document debian/missing-sources

[Gunnar Wolf]

Sean Whitton dijo [Sat, Dec 09, 2017 at 12:16:35PM -0700]:
> I am seeking seconds for the following patch:

You just found one. Seconded!

> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index 37c4442..f8f768f 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -686,6 +686,26 @@ even if most environment variables and build paths are 
> > varied.  It is
> >  intended for this stricter standard to replace the above when it is
> >  easier for packages to meet it.
> >  
> > +Missing sources: ``debian/missing-sources``
> > +---
> > +
> > +Sometimes upstream does not include the source code for some files in
> > +the upstream tarball.  In order to satisfy the DFSG for packages in
> > +``main`` or ``contrib``, you should either:
> > +
> > +1. repack the upstream tarball to include those sources; or
> > +2. include a copy of the sources in the ``debian/missing-sources``
> > +   directory.
> > +
> > +There is an optional convention to organise the contents of
> > +``debian/missing-sources`` in the following way.  For a sourceless
> > +file ``foo`` in the subdirectory ``bar`` of the upstream tarball,
> > +where the source of ``foo`` has extension ``baz``, the source is to be
> > +located at ``debian/missing-sources/bar/foo.baz``.  For example,
> > +according to this convention, the C source code of an executable
> > +``checksum/util`` is to be located at
> > +``debian/missing-sources/checksum/util.c``.
> > +
> >  .. [#]
> > See the file ``upgrading-checklist`` for information about policy
> > which has changed between different versions of this document.




signature.asc
Description: PGP signature

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Gunnar Wolf]

Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:
> I am seeking seconds for the following patch to close this bug, which I
> think is uncontroversial at this point.
> 
> > @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> > scripts inside the
> >  package and used by ``dpkg``, should have a ``#!`` line naming the shell
> >  to be used to interpret them.
> >
> > -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> > +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> >
> >  When scripts are installed into a directory in the system PATH, the
> >  script name should not include an extension such as ``.sh`` or ``.pl``

Seconded.




signature.asc
Description: PGP signature

Bug#882445: Proposed change of offensive packages to -offensive

[Gunnar Wolf]

Sean Whitton dijo [Thu, Nov 23, 2017 at 02:40:54PM -0700]:
> Hello David,
> > On Wed, Nov 22, 2017 at 05:18:37PM -0700, Sean Whitton wrote:
> >> >   "cowsay-offensive".  In this situation the "-offensive" package can
> >> >   be Suggested by the core package(s), but should not be Recommended
> >> >   or Depended on, so that it is not installed by default.
> >   ^^
> > While it seems to be a reasonable explanation for why it should be at most
> > a suggests, this half-sentence is hardcoding behaviour of a specific
> > package manager in its current default configuration into policy.
> >(...)
> 
> Thank you for your feedback.  I see what you mean.
> 
> I second the patch revised to exclude this half-sentence.

Makes sense. Sean, please note that, having seconded Ian's original
wording, I also second this modification.


signature.asc
Description: PGP signature

Bug#882445: Proposed change of offensive packages to -offensive

[Gunnar Wolf]

Sean Whitton dijo [Wed, Nov 22, 2017 at 05:18:37PM -0700]:
> > So to be concrete, how about this:
> >
> >   N. Packages with potentially offensive content
> >
> >   As a maintainer you should make a judgement about whether the
> >   contents of a package is appropriate to include, whether it needs
> >   any kind of content warning, and whether some parts should be split
> >   out into a separate package (so that users who want to avoid certain
> >   parts can do so).  In making these decisions you should take into
> >   account the project's views as expressed in our Diversity Statement.
> >
> >   If you split out (potentially) offensive or disturbing material into
> >   a separate package, you should usually mark this in the package name
> >   by adding "-offensive".  For example, "cowsay" vs
> >   "cowsay-offensive".  In this situation the "-offensive" package can
> >   be Suggested by the core package(s), but should not be Recommended
> >   or Depended on, so that it is not installed by default.
> 
> I second this patch.  I suggest we add it as section 3.1.1, i.e., as a
> subsection to 3.1 "The package name".
> 
> Iain, Gunnar and Steve: could you repeat your seconding of this patch to
> this debian-policy bug, please?  Kindly quote the above text that you
> are seconding.
> 
> For posterity, the rest of the discussion outside of this bug may be
> found here: https://lists.debian.org/debian-devel/2017/11/msg00209.html

Right. I second this patch. Thanks, Sean, for doing the administrative
steps!


signature.asc
Description: PGP signature

Bug#813471: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Jérémy Lal dijo [Tue, Oct 03, 2017 at 07:46:43PM +0200]:
> It might be a good idea to make policy more explicit about downloads during
> build.

I completely agree. This led me to look at #813471 ("network access to
the loopback device should be allowed"), and... Well, it seems to set
the stage to the issue we are tackling now: #813471 is opened as a
reaction against #770016 ("Clarify network access for building
packages in main").

I fully agree with Guillem's suggestions, although Pabs has a point in
cuffing the build process more strongly.

But anyway, #770016 worries me as it seems to deal with main only;
however, the precise issue we are discussing was mentioned then as
well by Henrique:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#48
  And it is is not just for main, I don't think contrib is supposed to
  hit the network during *build*, either.

Bill explicitly mentioned he was not targeting contrib on this bug's
proposed (and accepted) changes:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#58
  I have no idea abut contrib.



signature.asc
Description: PGP signature

Re: common, FHS-compliant, default document root for the various web servers

[Gunnar Wolf]

Stefano Zacchiroli dijo [Wed, Nov 04, 2009 at 05:50:01PM +0100]:
  Uhm, why postpone this so long? I'd hope we could find a consensus quite 
  soon. 
  Then, we might not be able to fix _all_ web apps until squeeze, but at 
  least 
  tthose few with dir-or-file-in-var-www :-)
 
 I see it a tad more complicate than you, let's hope its me
 overestimating the task :-)
 
 - the agreement actually should not come among web app maintainers, but
   rather among web *server* maintainers: they should agree over a
   specific dir and change the default configuration of the web server so
   that that dir is the document root (for the default vhost, for web
   servers supporting vhosts)
 
   * possibly, migrating to that would require offering migration paths
 to package users

That's easy, as there is fewer of us than web app maintainers. And it
is a first step. We might even have a transitional symlink making
/var/www point to /var/lib/www or whatnot?

 - then you might start migrating web apps packages so that they install
   (static) stuff under that dir, preserving the per-package path as
   detailed in the webapps-common policy
 
 - then, the rule should go into policy (possibly under §9.1.1, has an
   exception to FHS, not sure about the section though) and that can't
   happen before due to the usual practice-should-predate-policy
 
 If it were me to try to achieve this, I would go for a DEP to keep track
 of consensus, ... but no, I'm not willing to drive this, at least not
 now :-)

It is a bit ambitious to have it _completely_ done by Squeeze. But we
can start pushing the right way. And anyway, I do not feel it is
asking too much. Yes, we cannot just go from using /var/www to
having its existence violate policy and making insta-RC, but as soon
as the (major at least) webserves change their defaults, we can start
filing wishlist bugs, pointing maintainers to this being a work in
progress and expecting it to be strictly enforced by policy for
squeeze+1. 

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Automatic Debug Packages

[Gunnar Wolf]

Russ Allbery dijo [Sat, Aug 08, 2009 at 05:51:33PM -0700]:
  You can build a .ddeb manually, yes. However for some cases
  (e.g. packages using debhelper and building ELF binaries) a .ddeb will
  be automatically created (if none is created manually) and detached
  debugging symbols will be put there. I'll try to automatize other
  languages too, so that having full archive coverage is as simpler as
  possible.
 
 Could you explain a bit more about what merits you see in creating
 something that we call a different type of package rather than just
 listing debug packages in debian/control and building them as we do now
 and handling section debug specially in the archive software?  Is it just
 the avoiding of the need to add a bunch of debian/control entries?

I would add:

• .ddebs could be autobuilt — I am not familiar with the procedure,
  but I suppose a debian/control field would indicate whether this
  package allows being built as a .ddeb (as there would be no way
  i.e. to build a Perl module as a ddeb)

• Less namespace explosion. We would get rid of all the -debug
  packages. 

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Automatic Debug Packages

[Gunnar Wolf]

Steve Langasek dijo [Sun, Aug 09, 2009 at 05:15:39PM -0700]:
  If we are going to enshrine ddebs into policy, we might as well
   teach dpkg about ddebs.
 
 I don't have a strong opinion on whether ddebs should be documented in
 policy, but I certainly don't agree with requiring dpkg to understand them
 as a prerequisite for implementing a general purpose, public archive for
 auto-stripped debugging symbols packages.  There really is no reason for
 dpkg to treat these packages specially - a simple namespace convention
 imposed by Policy (i.e., reserving package names ending in -ddeb for use
 by this archive, which is what has been proposed) is sufficient, and
 requires no changes to dpkg, which is as it should be.
 
 I think the .ddeb extension is a red herring.  There ought not be anything
 new to teach dpkg, here; the only thing of relevance is that there not be
 namespace clashes between the ddebs and the debs in the main archive, and
 the filename is not relevant to that at all.

I understand your concern about this extension, but I do see it as a
merit. Of course, our tools must be aware of it.  And apt should know
-before updating or whatnot- that a package was installed from a ddeb,
if they are to share the base name. But I feel ddebs will allow
debugging packages creation and installation to take place in a much
more transparent, automatic fashion. I think this will be in the
interest of both users and developers.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Bug#466550: Pristine source from upstream VCS repository

[Gunnar Wolf]

Steve Langasek dijo [Thu, Mar 12, 2009 at 02:05:42AM -0700]:
 I think it's perfectly reasonable to want the get-orig-source target to give
 you a *specified* version of an upstream tarball, rather than the *newest*
 version of an upstream tarball.  Packaging a new upstream version doesn't
 necessarily mean packaging the latest that uscan can find.
 
 It's also useful for third parties to be able to easily examine the
 provenance of specific Debian tarballs.  A get-orig-source target provides a
 much more concise description of the Debian changes than examining the diff
 between the two tarballs.
 
 So I certainly agree that uscan doesn't obsolete the get-orig-source target,
 but I disagree that it's not useful to have such a target generate a tarball
 for the 'current' upstream version.

Good point you have here - But (and I know it is not being discussed
yet, maybe you want to teleport this thread a couple of years into the
future) I feel this should clearly be an optional target, and the
canonical location for orig.tar.gz files should still be our archive -
Down the other road lies Gentoo's BSD ports' madness, where an
upstream site restructure means packages become unreachable and
insta-FTBFS. 

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9

[Gunnar Wolf]

Ben Finney dijo [Thu, Mar 05, 2009 at 07:06:58PM +1100]:
 Practice is, I think, changing recently in response to the flowering
 of distributed VCSen. Increasingly many packages are now available
 from upstream *only* as a VCS branch; no static tarball releases are
 available. Yet we must provide a “pristine upstream tarball” for a
 Debian source package.
 
 Common practice is to ignore the issue, until someone points out that
 Lintian is complaining the package has no ‘debian/watch’ file. Then
 the maintainer commonly writes a ‘debian/watch’ file with a static
 comment saying “we get the upstream source from such-and-so VCS URL”.
 
 That satisfies Lintian, but the user is left floundering with figuring
 out exactly how to get the corresponding source from upstream to
 verify Debian's package.
 
 
 That is a poor substitute for a documented, automated method of
 getting a “pristine upstream tarball” of the exact VCS revision from
 which the source package was created. I think the ‘get-orig-source’
 target is perfectly positioned to be that method in the short term.
 
 All we need is to re-vamp the specification so it means what many in
 this discussion want it to mean.

FWIW, I am going more or less with this approach for githubredir.d.n
(which makes debian/rules-friendly index pages pointing to tags in
github-hosted projects). Two tarballs generated from the same tag
(that is, from the same commit) will have the same contents, although
their MD5s will be different (and will thus be rejected for an
upload). 

This has rarely been an issue for me... But it might be a bothering
issue. And, yes, an ideal solution would be for uscan to understand
VCS tags as well.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF



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

Bug#498300: specify that architecture-specific dependencies must have a non-empty list of architectures

[Gunnar Wolf]

Stefano Zacchiroli dijo [Fri, Sep 19, 2008 at 01:46:05PM +0200]:
 (...)
 As per policy the empty architecture list has no defined semantics, I
 guess that the only possible behaviours out there are the following:
 
 1) require at least one entry (as did by python-debian)
 
 2) assume a default polarity, this in turn would lead to one of the
possible two semantics:
 
a) (polarity positive) hence empty arch list means no architecture,
   i.e. useless dependency
 
b) (polarity negative) hence empty arch list means no excluded
   architecture, i.e. always present dependency
 
 We can start betting on this possibilities :-)

Umh... And I think I'd rather go with the negative polarity. This
means that [] is a no-op. Positive polarity just kills all the
dependency information for that dependency... And I doubt it is ever
desirable! 

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnome, kde, xfce use non-policy main menu

[Gunnar Wolf]

Wouter Verhelst dijo [Wed, Jul 09, 2008 at 12:12:23AM +0200]:
 The separation of a Debian menu and a desktop menu has been seen by
 some as a feature. I remember a post on Planet Debian by one of the
 GNOME maintainers (although I don't recall who it was) who explicitly
 said that he would not like to see non-GNOME applications in the GNOME
 menu but outside the Debian section. It is not unreasonable to state
 that it may be confusing for people to have a menu containing both GNOME
 and non-GNOME applications on a shared system; after all, different UI
 toolkits often have different UI guidelines and concepts; mixing those
 is not necessarily a good idea.

Maybe the menu name should be changed - All of the applications that
appear both in the desktop-specific and in the Debian menu are
Debian-provided. I think the Debian section should be renamed, to
avoid confusion, to not desktop-integrated or such.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#291460: Inclusion of Apache Software License versions in /usr/share/common-licenses

[Gunnar Wolf]

Manoj Srivastava dijo [Thu, Mar 27, 2008 at 09:16:17AM -0500]:
  Of course, I'm playing with the numbers. There are still smaller
  machines, there are the embedded-minded people, and of course, there
  would be no sane way to verify the GPL3 was the same GPL3 all over if
  we were to kill common-licenses - But basically, I'd not base the
  definition in diskspace savings.
 
 Then you had better come up with a rationale for having a common
  licences directory at all. Seems to me that making binary packages
  unusable on their own (can't legally distribute without a copyright
  file; so they can only be distributed _with_ the rest of Debian)  is a
  big enough obstacle that unless we have a compelling reason to have a
  common licenses directory, we should not strip out the licenses from
  packages and replace them with a pointer. 

_One_ thing that makes me favor common-licenses is being able to do
wide checks to count the number of packages saying to adhere to a
given license - As I said, nothing guarantees that the COPYING file in
my (upstream) package is the same as in yours (for the very popular
GPL2), we just accept it as such. But, yes, in fact I do have a couple
of source packages around here - and their COPYING files have
different MD5s! Of course, their differences are all basically like:

@@ -2,7 +2,7 @@
   Version 2, June 1991
 
  Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+  675 Mass Ave, Cambridge, MA 02139, USA
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 
@@ -279,7 +279,7 @@
 
 END OF TERMS AND CONDITIONS
 
 
-   How to Apply These Terms to Your New Programs
+   Appendix: How to Apply These Terms to Your New Programs
 
   If you develop a new program, and you want it to be of the greatest
 possible use to the public, the best way to achieve this is to make it
@@ -291,7 +291,7 @@
 the copyright line and a pointer to where the full notice is found.
 
 one line to give the program's name and a brief idea of what it does.
-Copyright (C) year  name of author
+Copyright (C) 19yy  name of author
 
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
@@ -305,15 +305,14 @@
 
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
-Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 
 Also add information on how to contact you by electronic and paper mail.
 
 If the program is interactive, make it output a short notice like this
 when it starts in an interactive mode:
 
-Gnomovision version 69, Copyright (C) year  name of author
+Gnomovision version 69, Copyright (C) 19yy name of author
 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
 This is free software, and you are welcome to redistribute it
 under certain conditions; type `show c' for details.

But, being a license text the only part of a package we accept to be
immutable Would it be better to change such non-substantial
portions of the license, even if they make no real difference? Hmh...

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#291460: Inclusion of Apache Software License versions in /usr/share/common-licenses

[Gunnar Wolf]

Manoj Srivastava dijo [Tue, Mar 25, 2008 at 01:57:30PM -0500]:
 The question is not how many people have installed the package,
  the question is how many packages on a given machine have the same
  copyright, and thus would benefit by savings in disk space by bundling
  them together
 
 This savings in diskspace is supposed to offset the fact that
  the binary package alone is unusable, since it does not contain the
  copyright; and that automated copyright file extractors get handed off
  a pointer, not the actual copyright, which could be an issue.
 
 The rule of thumb I have traditionally applied is to see if 5%
  of the source packages in the archive use the license under
  consideration, and use that as a gating point.
 
 A better, though harder, test would be to poll actual
  installations and see the disk saving that would result by bundling the
  license, divided by the number of systems polled, but I do not know of
  anyone actually conducting such a survey.

If 100% of Debian were to use the same license, we would be talking
about ~22000 license text repetitions. And imagine all of them were
GPL3 (the largest license in /usr/share/common-licenses) - That's
35068 bytes. Yes, that would amount to a whopping total of almost
735MB - Not at all something you can throw away, is it?

Well, but even if all of Debian were mutually installable (i.e. no
packages with conflicts: declared), how much space would _that_ take?
I don't dare to answer, but we were recently talking about the archive
size regarding CD image creation - We are at about 30 CDs now. 
I understand we are sticking with producing 650MB CDs and not larger
images as there are still media that big - and maybe some readers
which won't take larger disks? Never mind... 30 CDs is about
19500MB. We would be losing up to 4% bytes by mindlessly repeating
that single license... Maybe even less, as the CDs are gzipped (they
contain .debs after all).

On an installed system, you say? Well, I have no data, but I guess,
once uncompressed, it would not take less than 35GB. What's 730MB next
to that? Oh, and how long is the HDD in this very generic machine I
got about a year ago? Two-hundred-and-something GB. 

Of course, I'm playing with the numbers. There are still smaller
machines, there are the embedded-minded people, and of course, there
would be no sane way to verify the GPL3 was the same GPL3 all over if
we were to kill common-licenses - But basically, I'd not base the
definition in diskspace savings.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Phoning home

[Gunnar Wolf]

David Nusinow dijo [Sun, Feb 24, 2008 at 08:52:53PM -0500]:
  The problem I see here is that admin != user in all the situations.
  IMO it should ask, or at least warn, the user and not the admin.
  Because in the end is the user's privacy the one affected, not the
  administrator's.
 
 You want each package to notify each user? How do you recommend this
 actually be carried out? Patching every program?

if [ ! -d ~/.phone_home_program ] 
  then
# First time the user runs phone_home_program
ask_user_for_confirmation
create_corresponding_configuration
  fi

Does not sound too hard to make such a complex wrapper :)

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#458385: New version of Artistic License

[Gunnar Wolf]

Russ Allbery dijo [Wed, Jan 09, 2008 at 05:23:17PM -0800]:
  Perl 6 is already distributed under version 2.0, currently included in
  the Parrot package. As are over a hundred Perl 6 modules, currently
  included in the Pugs package. We haven't split them out into separate
  Debian packages yet, but will in the next 6 months or so.
 
 That's additional information that I didn't have.  Are all hundred of
 those modules covered under the Artistic 2.0 license?
 
 I was under the impression that the Perl 6 modules in the archive were
 being packaged independently like the Perl 5 modules, since I think I've
 seen several of them already.  I didn't realize that you had a monolithic
 package that you were going to break up.

The Perl 6 modules currently in the archive are, confusingly as it
seems, for Perl 5. That means, excluding Pugs (which is a Perl 6
ongoing implementation):

libperl6-export-perl - Implements the Perl 6 'is export(...)' trait
libperl6-form-perl - perl - Perl6::Form - Implements the Perl 6 'form' built-in
libperl6-junction-perl - Perl6 style Junction operators in Perl5.
libperl6-say-perl - print -- but no newline needed
libperl6-slurp-perl - Implements the Perl 6 'slurp' built-in

So, (for the simplest example), if in your Perl5 code you say:

use Perl6::Say;
say 'onara';

it will work as it would in Perl6, and put a newline after the
string. 

But anyway, as for the licensing: This module's licensing reads:

   COPYRIGHT
   Copyright (c) 2004, Damian Conway. All Rights Reserved.  This
   module is free software. It may be used, redistributed and/or
   modified under the same terms as Perl itself.

So, once again: What is Perl itself? Here, I'd think it means Perl
5, as it's the only Perl able to use this. But again, if Perl is to
change its licensing... This copyright string becomes ambiguous.

Anyway... Allison, I do agree with Russ on this thread: We still are
not -as said in Spanish- close to the river. We shall see how to cross
the bridge once we get there - The license is not yet a common
license, but it presumably will become soon.

I'm more worried about the tons of changes this will inflict on the
pkg-perl group ;-) But well, that's just me.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#458385: New version of Artistic License

[Gunnar Wolf]

Russ Allbery dijo [Tue, Jan 08, 2008 at 10:16:13AM -0800]:
  I'd like to request the addition of the file:
  
  http://www.perlfoundation.org/attachment/legal/artistic-2_0.txt
  
  as Artistic-2 in /usr/share/common-licenses/.
 
 Licenses are included in common-licenses primarily on the basis of how
 commonly they're used in the archive.  Currently, there are only about
 five packages in the archive covered by this license, so I don't believe
 this is warranted at this time.  Basically, the license isn't common.

Many Perl modules are just licensed under the same terms as Perl
itself, so as soon as Perl is released under this license, we will
have several hundreds of packages automagically under it. Of course,
this will require updating/changing many of them (as Perl6 is not
backwards-compatible)... But I do see a case for including this
license in common-licenses.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Breaks in lenny

[Gunnar Wolf]

Manoj Srivastava dijo [Fri, Dec 21, 2007 at 03:26:38PM -0600]:
  IMHO, the use cases are fundamentally different here - dpatch and
  quilt are, in my eyes, mostly geared towards diffs used by packagers,
  not as much by developers.
 
 Can you qualify why you hold such an opinion? I ask because I
  mostly disagree; I see no fundamental difference is
  creating/maintaining separate lines of development or added feature
  sets, or even bug fixes (because, fundamentally, bug fixes and
  behaviour changes are similar in nature; the difference being in the
  opinions about the behaviour before the change being inherently
  undesirable).

Well, really this thread (which, as you also said, is among the rare
interesting and useful threads in our mailing lists nowadays) has
shown me what I already know - That I should get more into DVCSs ;-) I
won't repeat what Russ already replied to you (as I'm also among those
content enough with SVN to push for something more
ellaborate)... The only argument I still have is that purpose-specific
systems are easier on the casual maintainer to understand and properly
use than a complete DVCS with its workflow. For one, I know I'd end up
doing a single line of development, not a series of branches to be
kept separate.

Until I read this thread, that is. 

  Most Debian work is, of course, packaging. In the case of devotee, I
  am sure dpatch/quilt are not in a better position than any other
  diffing solution. But for figuring out changesets in Debian packages,
  I ofteh find them to be the right tool.
 
 Again, you are expressing an opinion, without giving us a hint
  as to how you arrived at such a conclusion. Care to share?

Extrapolation from what I've experienced is a wonderful, if inexact, tool.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Breaks in lenny

[Gunnar Wolf]

Joey Hess dijo [Tue, Dec 18, 2007 at 05:16:17PM -0500]:
 Russ Allbery wrote:
  Well, basically every discussion about this that I've seen on -devel,
  discussions on -mentors, the teams that I'm familiar with (pkg-perl is
  standardizing on quilt
 
 I'm a member of pkg-perl, and 52 packages out of ~500 use quilt. We also
 have 20 packages using dpatch, and 45 using dbs. One or two pkg-perl
 members like quilt, others, such as myself, find it of dubious benefit
 on top of a proper version control system (though certianly better than
 dbs!).

The benefit is small if you (or your group, in any case) are the only
person working on the package - but as soon as somebody else tries to
make sense of your patches -possibly by running dpkg-source -x over
its dsc- it all becomes unclear. Having named, independent patches
_is_ much clearer for the adopter, the NMUer and similar cases.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Breaks in lenny

[Gunnar Wolf]

Manoj Srivastava dijo [Tue, Dec 18, 2007 at 06:40:25PM -0600]:
 Are you suggesting that somehow dpatch/quilt would have been
  even more effective?  How do you quickly get diffs between several
  parrallel lines of development that I am trying out from a quilt'ed
  patch set?

IMHO, the use cases are fundamentally different here - dpatch and
quilt are, in my eyes, mostly geared towards diffs used by packagers,
not as much by developers. Most Debian work is, of course,
packaging. In the case of devotee, I am sure dpatch/quilt are not in a
better position than any other diffing solution. But for figuring out
changesets in Debian packages, I ofteh find them to be the right
tool. 

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#432564: Allow debian/rules to not be a makefile

[Gunnar Wolf]

Otavio Salvador dijo [Tue, Jul 10, 2007 at 05:53:56PM -0300]:
  There is no technical reason why this has to be a makefile.  I propose:
 
  What is the use case of the change? I already see enough bad code
  right now, and it would only get worse if people start to write their
  make file in lets say ruby.
 
 While I agree with you that majority of people might do bad code I
 also think  that some very complicated packages (OO, X, Kernel and
 like) can use it and make maintainers life easier.

Maybe we should keep a recommendation for people to write makefiles,
for ease of maintainability - but we should not keep it as a
requeriment. 

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Gunnar Wolf]

Ian Jackson dijo [Tue, Jul 10, 2007 at 04:30:00PM +0100]:
 Package: debian-policy
 Version: 3.7.2.2
 
 Currently, we have:
 
   4.9 Main building script: debian/rules
 
   This file must be an executable makefile, and contains the
   package-specific recipes for compiling the package and building
   binary package(s) from the source.
 
   It must start with the line #!/usr/bin/make -f, so that it can be
   invoked by saying its name rather than invoking make explicitly.
 
 There is no technical reason why this has to be a makefile.  I propose:
 
   4.9 Main building script: debian/rules
 
   This file is normally an executable makefile, and contains the
   package-specific recipes for compiling the package and building
   binary package(s) from the source.
 
   debian/rules must be an executable script with an appropriate #!
   line (so, if it is a makefile it must start with the line
   #!/usr/bin/make -f) so that it can be invoked by saying its name.
   It should use a widely-used language, and should restrict itself to
   features portable even to older versions of its interpreter.

I completely second this. It makes sense, and has been the subject of
too many sterile discussions. 

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgpeFIgmAFKZF.pgp
Description: PGP signature

Re: migration away from /etc/init.d/ style to supervision style?

[Gunnar Wolf]

Adam Megacz dijo [Tue, May 29, 2007 at 04:57:17PM -0700]:
 I've recently moved all of my machines to runit, and I've been
 immensely pleased with the results.  In particular, the process
 supervision, clean process state, uniform and well-organized logging,
 elimination of pidfiles, and general simplicity of the whole system
 has been wonderful.
 (...)
 So, my main question: has there been any consideration given to moving
 official debian policy from /etc/init.d and start-stop-daemon to a
 supervision-based system like runit or daemontools?
 
 I understand that there are several solutions in this category
 (another is daemontools, but I believe that its licensing situation is
 not acceptable for debian).  This question is not specific to runit --
 more of a general inquiry about the type of solution it is
 representative of.

Hi,

This does not surprise me at all, and it does encourage me :) I wanted
to be a bit more active on this, but so far, I've got only some ideas
- I can just hope we can get something drafted while working on a
higher-bandwidth medium (i.e. on a real-life meeting).

We had some interesting posts some weeks ago on Debian Planet - The
ones I've noted are:

http://blog.incase.de/index.php/2007/04/13/init-hackfest-new-init-systems-in-debian/

http://web.glandium.org/blog/?p=126

http://gwolf.org/index.php?gadget=Blogaction=SingleViewid=Init-followup

http://www.joachim-breitner.de/blog/archives/231-Debian-Ideas-Instance-Capable-Init-Scripts.html

http://blog.drinsama.de/erich/en/linux/2007041001-system-init-part1.html

http://blog.drinsama.de/erich/en/linux/2007041101-system-init-part2.html

http://blog.drinsama.de/erich/en/linux/2007041202-system-init-part3.html

http://gwolf.org/index.php?gadget=Blogaction=SingleViewid=On-system-init-schemes

http://blog.drinsama.de/erich/en/linux/2007041301-init-followup.html

http://blog.incase.de/index.php/2007/04/17/init-script-generators/

http://wiki.debian.org/HackFests/Init

...So I proposed the following BoF session for Debconf:

There are several different init systems present in Debian -
However, we are only supporting currently one of them, good ol'
sysv-rc - We have close to a thousand packages providing init
scripts suitable for it, and close to none for all of the other
systems. 

In current systems, full of hot-pluggable devices, changing network
configurations and so on, however, I think this situation is quite
prone to change - sysv-rc and its runlevels are better suited for
stable server-like systems, and is hard to adapt for future needs.

We will talk about the potential difficulties Debian will face in
order to better support more init schemes, and discuss some ideas
to solve them.

This should be a brainstorming session, not much material will be
prepared (maybe some sketches by each of us, but nothing
formal). If you plan on attending, take a look at the messages
linked to in the 'links' section.

So... Where is the complexity? In that Debian will not just switch
from one scheme to a different one. We will continue providing several
schemes. But what we want to work on (and I must first of all
recognize I'm by no means an expert on this topic!) is a way to
provide hooks to probably be able to generate the needed scripts for
at least most of our packages, most of the init schemes. Explicitly
providing init schemes for the complete combination is... Well, just
not going to happen :) 

Stay tuned - I invite you to participate in this BoF. I don't know yet
if all/some/this BoFs will be streamed during Debconf or not, but if
so, I hope everybody interested can tune in and take part via IRC or
so.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#402975: debian-policy: Introduce a requirement for internationalisation of debconf templates

[Gunnar Wolf]

Christian Perrier dijo [Wed, Dec 13, 2006 at 10:33:51PM +0100]:
 --- policy.sgml.old   2006-12-13 22:24:05.534361649 +0100
 +++ policy.sgml   2006-12-13 22:26:52.159683953 +0100
 @@ -1221,6 +1221,13 @@
 /p
  
 p
 + Packages which use the Debian Configuration management
 + specification must allow for translation of their messages
 + by using a gettext-based system such as the one provided by
 + the packagepo-debconf/package package.
 +   /p
 +
 +   p
   Packages should try to minimize the amount of prompting
   they need to do, and they should ensure that the user
   will only ever be asked each question once.  This means

Seconded

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


signature.asc
Description: Digital signature

Re: Hopefully final version of ~ version number policy

[Gunnar Wolf]

Russ Allbery dijo [Thu, Nov 23, 2006 at 12:05:21PM -0800]:
  @@ -2713,7 +2713,15 @@
 which may be empty) are compared lexically.  If a difference
 is found it is returned.  The lexical comparison is a
 comparison of ASCII values modified so that all the letters
  -  sort earlier than all the non-letters.
  +  sort earlier than all the non-letters and so that a tilde
  +  sorts before anything, even the end of a part.  For example,
  +  the following parts are in sorted order: tt~~/tt,
  +  tt~~a/tt, tt~/tt, the empty part,
 
  So, is the greatest version number at the beginning or at the end of
  that sorted list? Yes, this is clear from context, but IMO an example
  should be more explicit.
 
 How about if I make that in sorted order from earliest to latest?

Maybe making it a bit more graphical:

   1.0~~  1.0~~a  1.0~  1.0

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Make use of invoke-rc.d, if available, mandatory?

[Gunnar Wolf]

Lars Wirzenius dijo [Mon, Apr 03, 2006 at 12:38:12AM +0300]:
 Current policy states in section 9.3.3.2 (Running initscripts) the
 following: The use of invoke-rc.d to invoke the /etc/init.d/*
 initscripts is strongly recommended[51], instead of calling them
 directly. 
 (...)
 I propose that the future has arrived.

Good. Just fixed my packages (haven't uploaded yet, of course, but
will do so).

 (...)
 I would like to see this policy change happen in time for all packages
 to be updated in etch. This would mean that sysadmins can, finally, rely
 on policy-rc.d working reliably. Also it means that it would be easier
 to build chroots, and not have to worry about services and daemons being
 started inside them unnecessarily.
 
 I realize that my script doesn't find all problematic packages. It is
 meant as a quick estimate. For proper testing, I have recently
 implemented changes into piuparts that should make it possible to find
 all problematic packages: in my development version /proc now gets
 mounted (ergo, start-stop-daemon works), and after packages have been
 installed, lsof checks that no processes run inside the chroot. This
 will, I hope, catch packages that don't use invoke-rc.d when they
 should.

My main purpose for this mail is to ensure you there many, many more
packages. Take a look at cherokee, for example - Both its postinst and
prerm had a straight /etc/init.d/cherokee something, and it was not
in the list. So, maintainers, beware of your children's misbehaviour.

Greetings

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#220779: ITP: zope-epoz -- Cross-browser-wysiwyg-editor for Zope

[Gunnar Wolf]

Chris Waters dijo [Thu, Nov 20, 2003 at 02:46:22PM -0800]:
 But I still think that the vast majority of us would
 disagree with a claim that a package homepage URL is merely
 administrivia in any case.
 
 Now, I suppose it could be argued that if a home page for a package
 doesn't contain any useful information about that package (unlikely
 but possible), then the URL *would* qualify as adminstrivia, but I
 think you'd have to show that the home page is useless before making
 such a claim, and such arguments would have to be done on a
 package-by-package basis.

Unlikely but possible? That's how most of my package's homepages are
like - An entry in CPAN, no more and no less. It is of absolutely no
use for the casual user who wants to install the package. It is only
useful when you want to download the sources and install it by
yourself, maybe after some modifications - and that renders the
package useless.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Policy for 32-bit uids/gids?

[Gunnar Wolf]

David B Harris dijo [Thu, Jul 03, 2003 at 04:23:03AM -0400]:
 I certainly agree with the general idea, as well as the specific
 proposal of allocating 2^16 UIDs for Samba's idmap usage.
 
 That being said, will Sarge release with the minimum requisites for the
 2^32 UIDs? If so, I'm happy. But somebody should ask the RM to be sure.
 Otherwise, I would think it'd have to wait until Sarge+1.
 
 Specifically, quota stuff. Every tree but Marcello's has implemented 32
 bit quotas, as far as I know, but not his. So 32 bit quotas aren't
 official yet. Might need Xu to patch the default kernel images.

Not only that... Are 32-bit UIDs legal in *BSD or HURD? I don't think
Samba should be limited to Linux-only installs.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgpur1P6AixW7.pgp
Description: PGP signature