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 t
kg 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
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 u
>
> 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
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.
>
>
> -Pac
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 D
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 previ
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
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
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 Direct
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
>
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 int
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.
sec
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 rev
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
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
> ---
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 pac
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 requi
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
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
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 architecture
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 li
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@maritor
Bill Allombert 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 s
Rob Browning writes:
> Bill Allombert 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 cr
Bill Allombert 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
Bill Allombert 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/P
Bill Allombert 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 conve
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 ha
29 matches
Mail list logo
