Bug#998282: Please make Section a required field for the source paragraph in d/control

[David Bremner]

Felix Lechner  writes:

>
> The installable stanzas in d/control (called "binary package
> paragraphs" in policy) inherit the Section field from the source
> paragraph. There is no reason to provide inheritance the other way
> around.
>
> Also, sources may not build successfully on all architectures. People
> do not often use Debian's sources directly, but we distribute them
> just like installation packages.
>
> The Section field in the source paragraph (called "general paragraph"
> in policy) reveals important clues about the DFSG-classification of
> the sources. It should be required. Policy section 5.2 presently shows
> the field as merely recommended. Thanks!
>

Hi Felix;

So, you probably know my biases. I think Debian would be better off if
we eliminated sections, with potential exceptions for where they are
needed by tooling (debian-installer might be such a case, it isn't
really clear to from the discussion I read so far). I would be fine with
mandating some indication of debian archive area in the source as well
as binary packages. That's just my personal view, and probably doesn't
(and shouldn't) weigh too much in the policy review.

On the other hand, what is not just my personal opinion is that policy
should follow practice, and policy changes should generally not make a
large number of packages buggy. So, do you have some numbers for how
widespread the adoption of this idea is? Usually I would suggest that
someone with an idea like this (assuming some degree of project
concensus) should start with a lintian check. I assume you are aware of
this, but you don't mention in your message whether such a check exists,
and if not why not (does it not make sense for some reason?).

Finally, I would suggest you consult with the ftp-master team about how
they feel about the potential extra work managing overrides for source
packages, and if there are any technical/process issues preventing
adoption of this policy.

Bug#986320: Stronger advice on when to use native packages

[David Bremner]

Russ Allbery  writes:

> Currently, Debian Policy is silent on when it's appropriate to use a
> native package, but there may be a project consensus aganist using
> native packages when the software has an existence outside of Debian.

Personally I don't think Debian policy should be concerned with what
happens outside Debian. As long as a given process serves the users and
contributors of/to Debian well, that seems sufficient to me. I
understand that others disagree, particularly on how much we should
consider the needs of derivative distributions.

> Even if that consensus does not exist, there is probably consensus
> that native packages are a poor match for large packages (because of
> the inefficiency of making small updates to the packaging of native
> packages), and there may be other cases where we can give stronger
> guidance.

That seems more like something that could be documented in devref as a
best practice, rather than something needing normative language.


signature.asc
Description: PGP signature

Bug#941198: In support of mandatory unit files

[David Bremner]

Bill Allombert  writes:

>
> In any case, this is an upstream choice, not a packaging choice, so we
> have to use what upstream provide.
>

Just to be clear using /etc/default is not an upstream choice, it's a
Debian convention. I know you probably didn't mean to imply that, but
that's how it read to me.

d

Bug#944920: Revise terminology used to specify requirements

[David Bremner]

Sean Whitton  writes:

>
>> -No package for a 64 bit architecture may install files in
>> -``/usr/lib64/`` or in a subdirectory of it.
>> +Packages must not install files in ``/usr/lib64`` or in a subdirectory
>> +of it.
>
> This seems to be a semantic change, generalising the requirement to all
> packages?

Well, I think you're both right. A lawyerly reading of policy might say
32 bit packages can install in /usr/lib64, but wouldn't that just be
nonsensical, and maybe contradict other wording about FHS conformance

Bug#940234: debian-policy: add a section about source reproducibility

[David Bremner]

Aurelien Jarno  writes:

> Package: debian-policy
> Version: 4.4.0.1
> Severity: wishlist
>
> There is already a section about reproducibility in the debian-policy,
> but it only mentions the binary packages. It might be a good idea to
> add a new requirement that repeatedly building the source package in
> the same environment produces identical .dsc file modulo the GPG
> signature.
>
> I haven't checked how many packages do not fulfill this condition, but
> there are for sure packages where the Build-Depends: entry in the dsc
> file does not match the debian/control file, as they have been added
> manually after the package build. TTBOMK there is nothing preventing
> that in the debian policy.

I'm not sure if this is exactly the same issue, but I've recently been
thinking about (and messing up) source package reproducibility from git
repos. It is probably to early for policy language to be talking about
git, but it might be worth keeping in mind the fact that there are
various tools producing source packages, sometimes in non-obvious ways.

d

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

[David Bremner]

Sean Whitton  writes:

>
> diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
> index 1de221f..e990f34 100644
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -255,32 +255,45 @@ files may be installed into ``/usr/share/doc/package``.
>  
>  .. _s-changelogs:
>  
> -Changelog files
> 
> +Changelog files and release notes
> +-
>  
>  Packages that are not Debian-native must contain a compressed copy of
>  the ``debian/changelog`` file from the Debian source tree in
>  ``/usr/share/doc/package`` with the name ``changelog.Debian.gz``.
>  
> -If an upstream changelog is available, it should be accessible as
> -``/usr/share/doc/package/changelog.gz`` in plain text. If the upstream
> -changelog is distributed in HTML, it should be made available in that
> -form as ``/usr/share/doc/package/changelog.html.gz`` and a plain text
> -``changelog.gz`` should be generated from it using, for example,
> -``lynx -dump -nolist``. If the upstream changelog files do not already
> -conform to this naming convention, then this may be achieved either by
> -renaming the files, or by adding a symbolic link, at the maintainer's
> +If an upstream release notes file is available, containing a summary
> +of changes between upstream releases intended for end users of the
> +package and often called ``NEWS``, it should be accessible as
> +``/usr/share/doc/package/NEWS.gz``.  An older practice of installing
> +the upstream release notes as ``/usr/share/doc/package/changelog.gz``
> +is permitted but deprecated.
> +
> +If there is an upstream changelog available, it may be made available
> +as ``/usr/share/doc/package/changelog.gz``.
> +
> +If either of these files are distributed in HTML, they should be made
> +available at ``/usr/share/doc/package/NEWS.html.gz`` and
> +``/usr/share/doc/package/changelog.html.gz`` respectively, and plain
> +text versions ``NEWS.gz`` and ``changelog.gz`` should be generated
> +from them, using, for example, ``lynx -dump -nolist``.
> +
> +If the upstream release notes or changelog do not already conform to
> +this naming convention, then this may be achieved either by renaming
> +the files, or by adding a symbolic link, at the maintainer's
>  discretion.  [#]_
>  
>  All of these files should be installed compressed using ``gzip -9``, as
>  they will become large with time even if they start out small.
>  
> -If the package has only one changelog which is used both as the Debian
> -changelog and the upstream one because there is no separate upstream
> -maintainer then that changelog should usually be installed as
> -``/usr/share/doc/package/changelog.gz``; if there is a separate upstream
> -maintainer, but no upstream changelog, then the Debian changelog should
> -still be called ``changelog.Debian.gz``.
> +If the package has only one file which is used both as the Debian
> +changelog and the upstream release notes or changelog, because there
> +is no separate upstream maintainer, then that file should usually be
> +installed as ``/usr/share/doc/package/NEWS.gz`` or
> +``/usr/share/doc/package/changelog.gz`` (depending on whether the file
> +is release notes or a changelog); if there is a separate upstream
> +maintainer, but no upstream release notes or changelog, then the
> +Debian changelog should still be called ``changelog.Debian.gz``.
>  
>  For details about the format and contents of the Debian changelog file,
>  please see :ref:`s-dpkgchangelog`.
>

seconded

d

Bug#628515: Seeking seconds for patch to recommend verbose logs and define DEB_BUILD_OPTIONS=terse

[David Bremner]

Ian Jackson  writes:

> Sean Whitton writes ("Bug#628515: Seeking seconds for patch to recommend 
> verbose logs and define DEB_BUILD_OPTIONS=terse"):
>> I think that the use of 'maximally' is fine given that the previous
>> sentence is now qualified with 'reasonably'.
>
> Yes.
>
>> Here is the revised patch; David and Andrey, hopefully you will renew
>> your seconds:
>
> LGTM.
>
> Ian.

Revised version seconded.

d

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

[David Bremner]

Sean Whitton  writes:

>
> Here is a revised patch; David, hopefully you will renew your second.
>
>> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> index 9e7d79c..890c479 100644
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -278,7 +278,8 @@ non-interactive. It also follows that any target that 
>> these targets
>>  depend on must also be non-interactive.
>>
>>  For packages in the main archive, no required targets may attempt
>> -network access.
>> +network access, except, via the loopback interface, to services on the
>> +build host that have been started by the build.
>>
>>  The targets are as follows:
>>

Second-seconded.

d

Bug#628515: Seeking seconds for patch to recommend verbose logs and define DEB_BUILD_OPTIONS=terse

[David Bremner]

Sean Whitton  writes:
>
> I am therefore seeking seconds for the following patch.  In seconding
> this, please remember that to second something is not simply to say that
> you agree with the change, but also to indicate agreement with my
> judgement that the change reflects project consensus.

seconded.

d


signature.asc
Description: PGP signature

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

[David Bremner]

Sean Whitton  writes:

> control: tag -1 +patch
>
> Hello,
>
> Here is a patch, for which I am seeking seconds, that tries to capture
> the points raised by Osamu, Guillem and Paul without getting into
> legalese -- Bill has a point.  In particular, I think we can trust
> package maintainers to interpret "started by the build" sensibly.
>
> Discussion by Ian and Simon cloned into a separate bug and continued
> there.  Gunnar's discussion should be a separate bug, so setting it
> aside for now.
>
>> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> index 9e7d79c..34c90b3 100644
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -278,7 +278,8 @@ non-interactive. It also follows that any target that 
>> these targets
>>  depend on must also be non-interactive.
>>  
>>  For packages in the main archive, no required targets may attempt
>> -network access.
>> +network access, except to services on the build host that have been
>> +started by the build, via the loopback interface.
>>  
>>  The targets are as follows:
>>  
>
> -- 
> Sean Whitton

Seconded.

d


signature.asc
Description: PGP signature

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

[David Bremner]

Sean Whitton  writes:


>> diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
>> index 1de221f..1503ed8 100644
>> --- a/policy/ch-docs.rst
>> +++ b/policy/ch-docs.rst
>> @@ -255,32 +255,48 @@ files may be installed into ``/usr/share/doc/package``.
>>
>>  .. _s-changelogs:
>>
>> -Changelog files
>> 
>> +Changelog files and release notes
>> +-
>>
>>  Packages that are not Debian-native must contain a compressed copy of
>>  the ``debian/changelog`` file from the Debian source tree in
>>  ``/usr/share/doc/package`` with the name ``changelog.Debian.gz``.
>>
>> -If an upstream changelog is available, it should be accessible as
>> -``/usr/share/doc/package/changelog.gz`` in plain text. If the upstream
>> -changelog is distributed in HTML, it should be made available in that
>> -form as ``/usr/share/doc/package/changelog.html.gz`` and a plain text
>> -``changelog.gz`` should be generated from it using, for example,
>> -``lynx -dump -nolist``. If the upstream changelog files do not already
>> -conform to this naming convention, then this may be achieved either by
>> -renaming the files, or by adding a symbolic link, at the maintainer's
>> +If an upstream release notes file is available, containing a summary
>> +of changes between upstream releases intended for end users of the
>> +package and often called ``NEWS``, it should be accessible as
>> +``/usr/share/doc/package/NEWS.gz``.  An older practice of installing
>> +the upstream release notes as ``/usr/share/doc/package/changelog.gz``
>> +is permitted but deprecated.
>> +
>> +If there is no release notes file available, but there is an upstream
>> +changelog, it should be accessible as
>> +``/usr/share/doc/package/changelog.gz``.  If there are both upstream
>> +release notes and an upstream changelog available, it is recommended
>> +to install the former but not the latter.
>> +
>> +If either of these files are distributed in HTML, they should be made
>> +available at ``/usr/share/doc/package/NEWS.html.gz`` and
>> +``/usr/share/doc/package/changelog.html.gz`` respectively, and plain
>> +text versions ``NEWS.gz`` and ``changelog.gz`` should be generated
>> +from them, using, for example, ``lynx -dump -nolist``.
>> +
>> +If the upstream release notes or changelog do not already conform to
>> +this naming convention, then this may be achieved either by renaming
>> +the files, or by adding a symbolic link, at the maintainer's
>>  discretion.  [#]_
>>
>>  All of these files should be installed compressed using ``gzip -9``, as
>>  they will become large with time even if they start out small.
>>
>> -If the package has only one changelog which is used both as the Debian
>> -changelog and the upstream one because there is no separate upstream
>> -maintainer then that changelog should usually be installed as
>> -``/usr/share/doc/package/changelog.gz``; if there is a separate upstream
>> -maintainer, but no upstream changelog, then the Debian changelog should
>> -still be called ``changelog.Debian.gz``.
>> +If the package has only one file which is used both as the Debian
>> +changelog and the upstream release notes or changelog, because there
>> +is no separate upstream maintainer, then that file should usually be
>> +installed as ``/usr/share/doc/package/NEWS.gz`` or
>> +``/usr/share/doc/package/changelog.gz`` (depending on whether the file
>> +is release notes or a changelog); if there is a separate upstream
>> +maintainer, but no upstream release notes or changelog, then the
>> +Debian changelog should still be called ``changelog.Debian.gz``.
>>
>>  For details about the format and contents of the Debian changelog file,
>>  please see :ref:`s-dpkgchangelog`.

Seconded.

d


signature.asc
Description: PGP signature

Bug#902612: Packages should not touch users' home directories

[David Bremner]

Sean Whitton  writes:

>> OK. Something like this?
>>
>> Packages must not contain files in /home, and packages' maintainer
>> scripts must not write to users' home directories. The programs in
>> those packages may create directory hierarchies as described in
>> §3.8.3 "Home Directory Specifications and Conventions" when run by
>> a user.
>>
>> I'm not so sure whether this belongs in the FHS section?
>
> Indeed.  I thought that the requirement that packages don't contain
> files in /home was in Policy already, but it seems that it is not.
>

> So filing as a separate bug.
>
>> I think it's a point about how our packages are required to behave,
>> rather than about the directories that can exist and their
>> purposes. The directory hierarchies are still the same, regardless of
>> how they're created.
>
> The wording of FHS is not about directories that can exist -- it says
> that distributions "can create" or "may create" the dirs.  That's what
> we want to forbid.

By the way there are packages (gitolite3 is the one I know) that create
user home directories in /var for some package dedicated user. I'm not
sure how to distinguish cleanly between that case and the human users
case. I guess having a home directory in /home is a reasonable proxy for being 
human.

d

Bug#881431: proposed wording

[David Bremner]

Adam Borowski  writes:

>
> Sounds better than mine.  I'd re-add "once that package has been accepted
> into the archive", to make it obvious that resubmissions to NEW and/or
> mentors are expected to reuse version numbers of what they amend.

Personally, I usually increase version numbers in those situations. It's
not like we're going to run out of version numbers...

d

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

[David Bremner]

Ian Jackson  writes:

> Package: debian-policy
> Version: 4.1.3.0
>
> We had another thread on debian-devel recently, in which it once again
> became evident that epochs are misunderstood.  Epoch bumps should be
> rare and there are often better solutions.  I suggest that we should
> ask people to consult debian-devel.
>
> Also we should encourage the +really convention rather than epoch
> bumps.

Without taking a position on epochs...

I find the existing use of the debian-devel list in policy strange, and
am unenthusiastic about expanding it.  It's not a "must-read" list for
debian contributors, and it is (or was, last time I subscribed) an
extremely noisy forum.  I concede that your proposed use of the list is
consistent with existing ones.

d

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

[David Bremner]

Sean Whitton  writes:

> Let me first say exactly what change I'd recommend:
>
> - out-of-date-standards-version should be I: or P: instead of W:
> - ancient-standards-version should remain W:
> - ancient-standards-version should be triggered when S-V contains a
>   release of Policy from the previous stable release cycle
>
> The third point is mostly covered already because our stable release
> cycles are roughly two years, but possibly there is a better mechanism.

This sounds good to me.

> On the contrary, I argue that
> - the only thing that should be /required/ when uploading a package is
>   making the package non-trivially better than the current version in
>   unstable
> - updating S-V should never block uploading other improvements
> - there are good reasons to release the Policy Manual frequently, and
>   this should not be blocked by the expectation that everyone respond to
>   those new versions in their very next uploads.

Agreed.

People who have time and motivation to polish their packages to
perfection are probably already using --pedantic.

As Princess Leia would say, the more lintian tightens its grip, the
more maintainers will slip through its fingers.

d

Bug#679751: Patch to close out this bug

[David Bremner]

Sean Whitton  writes:

> +.. _s-nonexistent:
> +
> +Non-existent home directories
> +~
> +
> +The canonical non-existent home directory is ``/nonexistent``.  Users
> +who should not have a home directory should have their home directory
> +set to this value.
> +
> +The Debian autobuilders set HOME to ``/nonexistent`` so that packages
> +which try to write to a home directory will fail to build.
> +
>  .. _s-sysvinit:
>  
>  System run levels and ``init.d`` scripts
>
>
> -- 
> Sean Whitton

Seconded.

d


signature.asc
Description: PGP signature

Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[David Bremner]

Sean Whitton  writes:

> diff --git a/policy.xml b/policy.xml
> index 3daa532..934a85b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -8990,14 +8990,8 @@ Reloading description 
> configuration...done.
>  receive extra contributions such as translations.
>
>
> -Packages can, to be compatible with Debian additions to some
> -window managers that do not support the FreeDesktop standard, also
> -provide a Debian menu file, following the
> -Debian menu policy, which can be found in the
> -menu-policy files in the
> -debian-policy package.  It is also available
> -from the Debian web mirrors at  -
> url="https://www.debian.org/doc/packaging-manuals/menu-policy/;>https://www.debian.org/doc/packaging-manuals/menu-policy/.
> +If a package installs a FreeDesktop desktop entries, it must
> +not also install a Debian menu entry.
>
>  
>
> -- 
> Sean Whitton

I looked at the older version from Didier, and this one. Both ok for me,
but I have a slight preference for the shorter version. So consider
Sean's proposal seconded.

d


signature.asc
Description: PGP signature

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

[David Bremner]

> 
> So yes at any time they are a number of active, hard-working team, but there
> also a larger number of phantom team that used to be active, but whose
> packages are still maintained in Debian. It is important they carry some
> valid information about the effective maintainers.
> 

What are the advantages of the Uploaders field over debian/changelog?
I can see some tooling issues, but nothing insurmountable (see
e.g. who-uploads from devscripts). There are also some advantages for
relying on changelog: e.g. it reveals packages only uploaded via NMUs
with the last X months/years, and of course the changelog is typically
even more up to date than the Uploaders field.




signature.asc
Description: PGP signature

Bug#822430: debian-policy: Please update 8.1.1 to use the "ldconfig" trigger instead

[David Bremner]

On Sun, Apr 24, 2016 at 01:14:49PM +0200, Niels Thykier wrote:
> 
> """
> Any package installing shared libraries in one of the default library
> directories of the dynamic linker (which are currently /usr/lib and
> /lib) or a directory that is listed in /etc/ld.so.conf[60] must use
> ldconfig to update the shared library system.
> 
> Any such package must have an "activate-noawait ldconfig" line in
> their "triggers" control file.
> """
> (replacing the entire section).
> 
> Alternative wordings welcome; I am not entirely certain the one above
> is all that well.

seconded, with the suggestion of adding "(i.e. DEBIAN/triggers)" before the 
final '.'

But feel free to not take the suggestion also.




signature.asc
Description: PGP signature

Bug#758124: Seconded

[David Bremner]

On Tue, Aug 01, 2017 at 04:23:05PM -0400, Sean Whitton wrote:
> Hello,
> 
> I second Charles' patch.
> 
> I'll note that as a policy delegate I'll make the following
> purely informative changes to the patch once committed:
> 
> - don't qualify with dpkg version number since it is older than the
>   version in oldstable
> 
> - move the text out of  tags since we're trying to reduce the
>   number of footnotes in Policy.
> 
> -- 
> Sean Whitton

Seconded

David Bremner


signature.asc
Description: PGP signature

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

[David Bremner]

On Fri, Jul 14, 2017 at 04:51:51PM -0700, Sean Whitton wrote:
> I'm not sure why Jonathan thinks his patch is a strawman.  It addresses
> the main issue of this bug.  I don't think the explanation of what an
> upstream contact is needs to be relegated to a footnote.  So I am
> seeking seconds for the following patch, which uses Jonathan's wording:
> 
> diff --git a/policy.xml b/policy.xml
> index ce5960b..725a951 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -11777,8 +11777,12 @@ END-INFO-DIR-ENTRY
>
>
>  In addition, the copyright file must say where the upstream
> -sources (if any) were obtained, and should name the original
> -authors.
> +sources (if any) were obtained, and should include a name or
> +contact address for the upstream authors.  This can be the
> +name of an individual or an organization, an email address, a
> +web forum or bugtracker, or any other means to unambiguously
> +identify who to contact to participate in the development of
> +the upstream source code.
>
>
>  Packages in the contrib or
> 
> -- 
> Sean Whitton

seconded



signature.asc
Description: PGP signature

Bug#769219: function moved

[David Bremner]

Bill Allombert ballo...@debian.org writes:


 Do you know if there is a org to XML (or SGML) conversion option ?


There is HTML output (which you are already using) and ODT output. Both
are in some sense XML. I didn't work through how to get uncompressed XML
from the ODT export, but attached find README.org converted to XML by
extracting from the zip file produced by default. I had a quick look and
the HTML output is indeed XHTML.



README.xml
Description: XML document

Bug#769219: function moved

[David Bremner]

Bill Allombert ballo...@debian.org writes:

 E: debian-policy: privacy-breach-may-use-debian-package 
 usr/share/doc/debian-policy/Process.html
 You may use libjs-mathjax package. (http://orgmode.org/mathjax/mathjax.js)

Hmm. I don't have much experience with that js stuff. It might be
possible to turn off mathjax support completely during the export.


 Also I suppose I need to update the Build-Depends field.
 Which version of emacs is required for this to work ?

Either emacs24_24.4+1~ or org-mode_8.2.10~ + emacs24_24.3.1 should be
ok. I haven't tested with earlier versions; I guess backporting is not
such an important issue for debian-policy.


-- 
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/874mu0n4t5@maritornes.cs.unb.ca

Bug#769219: function moved

[David Bremner]

Bill Allombert ballo...@debian.org writes:


 E: debian-policy: privacy-breach-may-use-debian-package 
 usr/share/doc/debian-policy/Process.html
 You may use libjs-mathjax package. (http://orgmode.org/mathjax/mathjax.js)

OK, so this is all a bit silly to display π, but you can either

diff --git a/Process.org b/Process.org
index a0f6ab7..b7de14c 100644
--- a/Process.org
+++ b/Process.org
@@ -8,6 +8,7 @@
 #+OPTIONS:   H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t 
LaTeX:nil skip:t d:nil tags:not-in-toc
 #+LINK_HOME: http://wiki.debian.org/Teams/Policy
 #+LINK_UP: http://www.debian.org/
+#+HTML_MATHJAX: path:/usr/share/javascript/mathjax
 
 \usepackage{landscape}
 
Or


 #+OPTIONS: tex:dvipng

   or:

 #+OPTIONS: tex:imagemagick

I have only tested the first one. In all cases build-depends may need
adjusting.  I also noticed that the same hacking out of TeX stuff I did
to README.org is needed for Process.org.


--
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/871tp4n22j@maritornes.cs.unb.ca

Bug#769219: function moved

[David Bremner]

Rob Browning r...@debian.org writes:

 Bill Allombert ballo...@debian.org writes:

 What to do for ascii :

 emacs24 --batch -Q -l ./README-css.el -l org -l org-ascii
 --visit Process.org --funcall org-export-as-ascii


Attached is a better patch series that fixes the ascii export,
and deals with all the (unused) TeX crap that was showing up in the
output.

In case it's not 100% obvious, you can apply the series with git am
foo.mbox, and inspect the results in git.



policy-patches.mbox
Description: application/mbox

Bug#769219: function moved

[David Bremner]

That function is now in ox-html.el

Maybe loading that explicitly (as well as org?) helps.

d


-- 
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/87a93wntyp@maritornes.cs.unb.ca

Bug#769219: function moved

[David Bremner]

Bill Allombert ballo...@debian.org writes:
 That function is now in ox-html.el

 Are you sure ?
 grep org-export-as-html-batch  /usr/share/emacs/site-lisp/org-mode/ox-html.el
 does not return anything.

Sorry, I was misled by emacs function name completion.  The following is
a partial solution. There is still some cruft at the top of the
generated html. Hopefully I'll get a chance to look at that in the next
few days, if nobody else figures it out first. The messages about
missing htmlize.el are strange since it is included in the org-mode
package, but apparently not in the version of org included with emacs.

diff --git a/Makefile b/Makefile
index a10b93d..794678c 100644
--- a/Makefile
+++ b/Makefile
@@ -11,7 +11,7 @@ perl-policy.sgml: version.ent
perl -pli -e 's,./Process.org,Process.txt,g' $@
 %.html: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
-  --funcall org-export-as-html-batch /dev/null 21
+  --funcall org-html-export-to-html
 
 %.validate: %
nsgmls -wall -gues $


-- 
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/877fz0no4b@maritornes.cs.unb.ca

Re: [PATCH] Specify policy for use of revision IDs in version numbers

[David Bremner]

On May 1, 2011 seanius wrote:
  On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:

  I don't think it's Policy's place to tell people that they can't use
  hashes because they *might* result in long version numbers.  They
  usually don't.

 +1.  otherwise, this seems more like a guideline that ought to be in
 the developer's reference rather than enshrined as a MUST in policy.

I agree with the position articulated by Russ and Sean here. In any
cases hashes are only one way that version numbers can get long. Even if
you think putting hashes in version numbers is not useful, I'm pretty
sure we don't want to enumerate every possible thing that is not
permitted in version numbers.

I'd think the obvious place to start would be for policy to specify
limits on version length. Maybe I missed something, but I didn't see
anything like that.

David.

P.S. I'm not subscribed to the list.



pgpEKYcIRbhI8.pgp
Description: PGP signature

Bug#604193: 7.4: non-working email should be a serious bug?

[David Bremner]

Package: developers-reference
Version: 3.4.3
Severity: normal

As far as I can tell (in particular from policy 3.3) a non-working
maintainer email violates a must policy directive, and is thus a
serious bug.  If this is the case, perhaps the paragraph about sending
email to the maintainer should have a note to this effect.  That is, I
think it is probably worth distinguishing here between email that
bounces and a non-responsive maintainer.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy 3.9.1.0Debian Policy Manual and related d

Versions of packages developers-reference suggests:
ii  doc-base  0.9.5  utilities to manage online documen

-- no debconf information



-- 
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/20101121045917.4176.40144.report...@rocinante.cs.unb.ca