Le Wed, Jul 07, 1999 at 05:38:04PM +0200, Santiago Vila écrivait:
We could have some sort of FHS-threshold for the release:
We will not release until 90% of all priority = standard packages are
converted to use /usr/share/doc or else we will not release until 80% of
the 300 most popular
Le Wed, Aug 04, 1999 at 02:17:44PM +0300, Antti-Juhani Kaijanaho écrivait:
On Wed, Aug 04, 1999 at 12:29:29AM +0100, Julian Gilbey wrote:
why don't we follow the Perl team's lead
I most definitely agree with your plan.
I also agree that there's no perfect solution and that we should just
Le Wed, Aug 04, 1999 at 02:15:56AM -0700, Joseph Carter écrivait:
I'm going to wait to see the reaction to this, however I wanted to say
that I fully agree with you. Debian at large is suffering from a too
many chiefs and not enough indians syndrome. Everything, EVERYTHING
seems to need the
Le Wed, Aug 04, 1999 at 02:15:38PM -0700, Joey Hess écrivait:
So debian's new statement WRT partial upgrades will be you can install
packages from unstable. However, you may have to edit arbitrary files
and change your system in arbitrary undocumented ways to make them work
as you would
Le Wed, Aug 04, 1999 at 09:44:41PM +0200, Wichert Akkerman écrivait:
Previously Raphael Hertzog wrote:
The only working solution I see is that we should have a group of
(known) developers that would decide in such difficult cases.
Someone should request the technical committee for a ruling
Le Sat, Sep 18, 1999 at 04:10:42AM -0300, Nicolás Lichtmaier écrivait:
Package: debian-policy
Severity: wishlist
Version: 3.0.1.1
Most configuration files have manpages, but not all. It would be useful
if every config file (intended to be edited) would be forced to be
documented in a
Le Sat, Sep 18, 1999 at 01:23:53PM -0700, Seth R Arnold écrivait:
How would you feel about a symlink to the manpage of the program that uses
the conf file, if no manpage specific to that conf file is supplied?
Symlinks should be easy to do for maintainers..
That is acceptable.
Cheers,
--
Hi,
i've just subscribed to -policy but I read some mails in the archive about
configuration management. The configuration management thread has started
with the need of a non-interactive installation process, I believe.
We are now talking about a big registry containing the informations needed
Hello,
i've read many mails in the archive in order to make me an opinion
about the configuration management system discussed here.
The orientation is good I think. But the proposed implementation
is IMHO too much complicated. Here's a list of my thoughts on
various points of the problem.
1.
Le Wed, Nov 11, 1998 at 02:18:56AM +0100, Wichert Akkerman écrivait:
Why? This is a lot less flexible imho. And it does not reduce the
complexity (read my design again).
Read Ian's argument. This design make it difficult to say : Now I
want to remove all mail-transport-agent/* keys.
And the
Le Wed, Nov 11, 1998 at 02:13:56PM +0100, Wichert Akkerman écrivait:
Sorry to say this, but this is complete and utter nonsense. The only
difference was if you used a virtual database that can consist of
multiple sources or a single database. How you access that database
is the same for both
Le Sat, Jan 23, 1999 at 04:29:38PM -0800, Aaron Van Couwenberghe écrivait:
If there were a group that, during freeze, were given the task of
handling difficult looking bugs before they became stale, debian could
possibly begin getting its releases out on time.
I'm just curious,
Le Wed, Jan 27, 1999 at 11:34:42PM -0600, John Goerzen écrivait:
I am not proposing throwing people out for having bugs in their packages, or
even for having lots of them. Rather, what I am proposing is a way to
prevent people that ignore their responsibility from becoming a hindrance to
the
Le Thu, Jan 28, 1999 at 09:13:04AM -0600, John Goerzen écrivait:
Again, as I said in my message, I'm not proposing removing developers that
maintain packages with bugs, or packages with very old bugs. This case is
different. The developer has literally *ignored* bugs for over 700 or 800
Le Sun, Mar 28, 1999 at 09:55:16PM +0200, Martin Schulze écrivait:
The following is extracted from a text Vincent Renardias wrote in
February 1997. I'm not modifying it in order to be able to discuss it
properly. Please keep in mind that parts of it may be out dated by
now.
OK, i'm all for
Le Wed, Apr 14, 1999 at 02:51:23AM -0700, Joey Hess écrivait:
So I'm looking for non-technical corrections to the above, seconds for
the proposal, and hopefully a consensus on the list that this should become
a policy amendment.
Seconded.
--
Hertzog Raphaël 0C4CABF1
Le Fri, Apr 16, 1999 at 12:53:27PM -0700, Joey Hess écrivait:
PROPOSED:
I propose that section 2.3.8, paragraph 2 of policy be amended to replace
/etc/nntpserver with /etc/news/server.
Seconded.
--
Hertzog Raphaël 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Le Wed, Apr 28, 1999 at 11:08:08AM +0200, Balazs Scheidler écrivait:
It is the best solution I have seen so far, so I suggest moving to logrotate.
This is not an easy transition, since each package has to drop files to
/etc/logrotate.d/ instead of /etc/cron.xxx.
This requires some policy
Le Sun, May 09, 1999 at 03:19:19AM +0200, Wichert Akkerman écrivait:
There is a slight problem though: utmp. Currently only root can update
the utmp. To solve this I propose we create an utmp group and put in
policy that programs that want to modify the utmp should be setgid utmp
instead of
On Mon, 01 Mar 2010, Mike Hommey wrote:
On Sun, Feb 28, 2010 at 11:29:52AM +0100, Julien Cristau wrote:
On Mon, Feb 22, 2010 at 09:34:50 +0100, Mike Hommey wrote:
Package: debian-policy
Version: 3.8.4.0
Severity: wishlist
AFAIK, the current version of dpkg in stable supports
On Mon, 01 Mar 2010, Goswin von Brederlow wrote:
Russ Allbery r...@debian.org writes:
Mike Hommey m...@glandium.org writes:
I first though having dh_makeshlibs do the right thing would be good
enough, but that would also put an unnecessary burden on those that
don't use debhelper.
tags 573110 + pending
thanks
On Tue, 09 Mar 2010, Charles Plessy wrote:
The formalisation of team uploads would help team members to show the priority
they have in the packages maintained by their team, by being Uploader for some
but not all.
I agree this is a good thing in general. I saw
Package: debian-policy
Severity: wishlist
With dpkg 1.15.7 just uploaded to sid, there's now a dpkg-buildflags
command that should be used to initialize CFLAGS, LDFLAGS, CPPFLAGS,
FFLAGS, CXXFLAGS. It offers some flexibility for the local admin and for
the user to override/extend the default
On Wed, 21 Apr 2010, Jonathan Nieder wrote:
On the other hand, many packages already support the noopt option,
usually with code like the following:
ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS = -g -O2
else
CFLAGS = -g -O0
endif
In particular, they override any value
On Wed, 21 Apr 2010, Bill Allombert wrote:
Suppose user set CFLAGS to XXX. How C files should build ?
Have you read the dpkg-buildflags manual page? If the user wants to modify
CFLAGS he doesn't set it manually but he uses one of the facility to
extend/override it. The result returned by
Hi,
On Sat, 01 May 2010, Loïc Minier wrote:
On Wed, Apr 21, 2010, Raphael Hertzog wrote:
The desired outcome is that all package grab the values directly from
dpkg-buildflags and that we can stop exporting the variables from
dpkg-buildpackage. That way calling debian/rules directly and via
severity 575786 important
thanks
On Sun, 09 May 2010, Eugene V. Lyubimkin wrote:
Totally tired with having this bug here and there with different
packages, I change my mind and bump the severity of this bug to
serious, as dpkg fails to comply with §7.6.2 of Debian policy,
including an example
On Fri, 21 May 2010, Santiago Vila wrote:
Known affected packages: adduser, base-files
Fix: Trivial: s/2/5/
I'm looking for seconds for this proposal.
Seconded.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian
On Tue, 01 Jun 2010, Russ Allbery wrote:
Here is proposed wording, which hopefully reflects the subsequent
discussion. I'm looking for seconds.
[...]
p
+ Be careful of using ttset -e/tt in fileinit.d/file
+ scripts. Writing correct fileinit.d/file scripts requires
On Thu, 03 Jun 2010, Russ Allbery wrote:
Niko Tyni nt...@debian.org writes:
I would like to see all the packages use DESTDIR so that the patch
could be removed. As a first step, lintian was recently changed to warn
about overriding PREFIX. See #568748 and
On Tue, 15 Jun 2010, Steve Langasek wrote:
On Tue, Jun 15, 2010 at 06:51:34PM -0700, Russ Allbery wrote:
But it's also overly aggressive, since it forces 'a' version 2 to be
unpacked first, *before* unpacking package 'b' - in which case, what do
we need the Replaces: for at all? This
On Thu, 17 Jun 2010, Russ Allbery wrote:
Here is updated proposed wording incorporating fixes for the various
issues raised on the list since yesterday.
Seconded.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals:
Hello,
On Thu, 01 Jul 2010, Russ Allbery wrote:
Raphael Geissert geiss...@debian.org writes:
I think it should be more clear and mention that --package must be used
when adding or removing diversions. --list{,name} and --truename don't
require --package.
Good point. Here's an updated
On Thu, 01 Jul 2010, Julien Cristau wrote:
On Thu, Jul 1, 2010 at 12:19:42 -0700, Russ Allbery wrote:
diff --git a/policy.sgml b/policy.sgml
index 9a72be5..2a634b8 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5654,7 +5654,11 @@ objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
On Wed, 07 Jul 2010, Russ Allbery wrote:
Russ Allbery r...@debian.org writes:
Yeah, there's that too. We're probably best off just saying that every
package needs a maintainer. Hopefully it's clear enough since we're
saying that the package needs one, not just the software.
Here's a
On Thu, 08 Jul 2010, Russ Allbery wrote:
Objections, sections, or other review?
Looks mostly good, I have some fixes and suggestions below.
- sect id=sharedlibs-runtime
- headingRun-time shared libraries/heading
+ p
+ A shared library must be uniquely identified by an
Hi,
On Mon, 12 Jul 2010, Russ Allbery wrote:
+ If the maintainer of a package no longer has time or desire to
+ maintain a package, it will be orphaned according to the
+ procedure described in the Debian Developer's Reference
+ (see ref id=related). The maintainer
On Mon, 12 Jul 2010, Russ Allbery wrote:
Russ Allbery r...@debian.org writes:
There was a lot of background information missing from Policy, which in
my opinion made it unnecessarily difficult to understand the motivation
and implications of the various Policy requirements. Here's a
Hi,
On Mon, 12 Jul 2010, Steve Langasek wrote:
On Tue, Jul 13, 2010 at 08:02:43AM +0200, Raphael Hertzog wrote:
On Mon, 12 Jul 2010, Russ Allbery wrote:
+ If the maintainer of a package no longer has time or desire to
+ maintain a package, it will be orphaned according
On Mon, 26 Jul 2010, Russ Allbery wrote:
I like this general approach. Thank you! I played with a bit and came up
with the following. This retains a Policy should only for the correct
setting of the Maintainer field for an orphaned package and remains silent
on when packages are orphaned.
On Mon, 26 Jul 2010, Russ Allbery wrote:
Here is an updated version of the proposed patch, reflecting additional
feedback. I think we should hopefully be close to a final wording now.
I have reviewed the patch and did not found any problem.
Seconded.
p
The prgnDEBIAN/prgn
Hello,
On Sun, 08 Aug 2010, nore...@alioth.debian.org wrote:
Hello, I've been talking to Lucas Nussbaum for helping with the
Developer's Reference but I need access to the ddp SVN module. As
I'm a DD, my username in Alioth is 'ender'. I'm planning to first
of all kill the
Package: developers-reference
Version: 3.4.3
Severity: wishlist
In the publicity Bof at debconf, we agreed that we need to better
communicate to DD the various communication channels that are available
and the way that they are expected to use them.
Among important things:
- we want to make sure
Hi,
On Wed, 11 Aug 2010, Russ Allbery wrote:
Manoj proposes making each normative requirement in Policy a separate
XML entity, which allows building different merged documents in
different orders incorporating all or some of those rules. Those
sections could have separate rationales that are
On Sun, 15 Aug 2010, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org writes:
On Mon, 26 Jul 2010, Russ Allbery wrote:
p
The prgnDEBIAN/prgn directory will not appear in the
file system archive of the package, and so won't be installed
-by prgndpkg/prgn when
On Sat, 14 Aug 2010, Bill Allombert wrote:
d-d-a should be for stuff relevant to developers. It does not seems
reasonable to
block something because it can be relevant to non-developers, especially
since almost
everything posted to d-d-a is relevant to some non-developers.
It's not
On Wed, 18 Aug 2010, Russ Allbery wrote:
Yann Dirson ydir...@mygale.org writes:
Richard Braakman writes:
Yesterday I noticed that Debian policy is incorrect on this:
Only packages that are tagged *conflicting* with each other may
specify the same file as `conffile'. A
On Wed, 18 Aug 2010, Russ Allbery wrote:
Charles Plessy ple...@debian.org writes:
Information about the initial Debian maintainers partially overlaps the
information in debian/changelog, and the copyright statements for the
packaging work.
Under normal circumstances, it always
On Fri, 20 Aug 2010, Russ Allbery wrote:
diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt
index 9ba66e5..2308d39 100644
--- a/virtual-package-names-list.txt
+++ b/virtual-package-names-list.txt
@@ -123,6 +123,8 @@ News and Mail
imap-server an IMAP
On Fri, 20 Aug 2010, Russ Allbery wrote:
Don Armstrong d...@debian.org writes:
On Thu, 19 Aug 2010, Felipe Sateler wrote:
One person I'm sponsoring misread this and put my name in the
changelog, since I'm the one actually doing the upload. I can't
think of a better wording, though.
On Sat, 21 Aug 2010, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org writes:
On Fri, 20 Aug 2010, Russ Allbery wrote:
+p
+ A package that declares the same ttconffile/tt as another,
+ conflicting package may see left-over configuration files from
+ that other
On Thu, 02 Sep 2010, Russ Allbery wrote:
I believe this is true of all binary relationship fields and all build
relationship fields as well. The dpkg-dev tools unfold all of those
fields when generating *.dsc, *.changes, and DEBIAN/control files, and
parers of those generated files do not
Hi,
On Wed, 22 Sep 2010, Bill Allombert wrote:
The maintainer name and email address used in the changelog
- should be the details of the person uploading emthis/em
- version. They are emnot/em necessarily those of the
- usual package maintainer.footnote
- If
On Sat, 25 Sep 2010, Jonathan Yu wrote:
22:02:40 rra jawnsy: I don't think we say that explicitly, but RFC
5322 requires it and I can't imagine ever not enforcing that.
Although you should check with the dpkg maintainers to be sure.
Could we/should we make the Debian Policy more
Hi,
On Fri, 03 Dec 2010, Lucas Nussbaum wrote:
Hi,
Please either commit or file as a bug, so it's not lost.
Rhonda committed it apparently but a changelog entry is missing.
Can you fix that, Rhonda? Thanks.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶
On Fri, 14 Jan 2011, Christoph Anton Mitterer wrote:
The Homepage control filed is according to chapter 5.2 allowed in both,
the source package and the binary packages paragraphs.
IMHO, this makes (semantically even sense - perhaps that should be pointed
out,
too) as e.g. a -doc, or a -dev
tag 453313 + patch
thanks
Hi,
please find attached a proposed patch for this bug. Any review/ack welcome.
Since the patch might not be very readable, I'll paste here the
rewritten section (beware, it's rather long):
section id=sponsoring
titleSponsoring packages/title
para
Sponsoring a
Hi,
On Sat, 12 Feb 2011, Steve Langasek wrote:
On Sat, Feb 12, 2011 at 10:32:34PM +0100, Julien Cristau wrote:
CFLAGS := $(CFLAGS) -Wall -g
That would be wrong. A package build shouldn't depend on random env
variables.
Depend on, or respect?
Why shouldn't we expect packages to
On Wed, 16 Feb 2011, Charles Plessy wrote:
Dear Raphaël,
here are a couple of comments :
Ok, I integrated your comments. A new revision of the patch is attached.
Only Debian Developers with upload rights can. I propose to either write this
explicitely, or remove the word “Any”.
I dropped
tag 548867 + patch
thanks
Hello,
please find attatched 3 patches that try to update the Debian Developer's
Duties chapter to make it more clear that package maintainers have
responsibilities in making the next stable release happen and in
maintaining their packages in stable (and not only in
Hi,
On Fri, 04 Mar 2011, Jonathan Nieder wrote:
) I suspect others like it, too, but who knows? Patch attached.
Seconds or objections welcome.
Seconded. It's long and I might have missed some inaccuracies but I think
it's an improvement in clarity.
Cheers,
--
Raphaël Hertzog ◈ Debian
Hi,
On Tue, 01 Mar 2011, Raphael Hertzog wrote:
The most interesting patch to review is the third one and it's this one
where I would like to have some feedback. In the absence of objections, I
will commit this sometimes next week.
Anyone willing to review it?
Cheers,
--
Raphaël Hertzog
Hi,
On Tue, 08 Mar 2011, Charles Plessy wrote:
+section id=help-release
+titleWork towards the next stable release/title
+para
+Providing high-quality packages in unstable is not enough, most users will
+only benefit from your packages when they are released as part of the next
On Fri, 11 Mar 2011, Charles Plessy wrote:
Yes, I think that the release is important, and no, I do not think that we
should write vague encouragements the Developers reference. I think that it is
a place for precise informations, not for morale lessons.
I think that my patch contains precise
Hello,
I have written a patch for the developers-reference where I update the
chapter about debian developer's duties. Most notably I have added
that a maintainer ought to support the (stable) release process
by collaborating with the release team.
Charles Plessy is worried that my text would
On Sat, 12 Mar 2011, Charles Plessy wrote:
I do not like for instance, the way you write:
Lack of attention to RC bugs is grounds for the QA team to orphan the
package.
In the pledge that inspired your patch, you present orphaning by the QA as a
sanction:
[I will] not complain if
On Sun, 13 Mar 2011, Lucas Nussbaum wrote:
I'd like to suggest changes to the last paragraph, though:
Lack of attention to RC bugs is often interpreted by the QA team as a sign
that the maintainer has disappeared without properly orphaning his package.
-Don't be surprised if the MIA team
Hi Bill,
On Sun, 13 Mar 2011, Bill Allombert wrote:
As the name imply, this a reference document, not a prescriptive document. It
should
provide technical answer to technical question. Fundamentally it only
provides advices.
Patronizing would be bad form.
Please be specific, can you tell
Hi,
On Sun, 13 Mar 2011, Bill Allombert wrote:
But in anycase, I do not think that statement like
As a package maintainer, you're supposed to fulfill the Debian
Social Contract by providing high-quality packages that are well integrated
in the system and that adhere to the Debian Policy.
On Mon, 14 Mar 2011, Andrew McMillan wrote:
-Don't be surprised if the MIA team enters in action and ends up orphaning
-your packages (see xref linkend=mia-qa /). But you should really avoid
-that situation in the first place and ensure that your packages get the
attention
-that they
On Mon, 21 Mar 2011, Steve Langasek wrote:
Attached is a patch to update policy's FHS exception to reflect the current
consensus among the gcc, eglibc, and dpkg maintainers around the paths to
use for implementation and the interface packages should use to query these
paths.
[...]
From
Hello,
ftpmasters requested a new field in the .dsc files to ease their work.
I just implemented it and it will be part of dpkg 1.16.0.
This has been done on short notice so I wanted to inform policy people
so that you can review the discussions and the design in case anyone has
On Thu, 24 Mar 2011, Bill Allombert wrote:
On Thu, Mar 24, 2011 at 03:14:00PM +0100, Raphael Hertzog wrote:
Package-List:
src:dpkg admin required
dpkg admin required
dpkg-dev utils optional
libdpkg-dev libdevel optional
libdpkg-perl perl optional
udeb:dselect admin optional
On Thu, 24 Mar 2011, Julien Cristau wrote:
Does XC-Package-Type also work? debhelper uses
/^(?:X[BC]*-)?Package-Type:\s*(.*)/ to populate the package type.
Yes. I was simplifying somewhat.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com
:
On Thu, Mar 24, 2011 at 03:14:00PM +0100, Raphael Hertzog wrote:
It looks like this:
Package-List:
src:dpkg admin required
Is there a reason for not listing the type explicit for every entry?
Something like this:
dpkg source admin required
dpkg deb admin required
dselect udeb admin
On Sat, 26 Mar 2011, Bastian Blank wrote:
On Thu, Mar 24, 2011 at 04:25:46PM +0100, Raphael Hertzog wrote:
First line is always
the source entry.
Do you want this constraint part of the definition or a implementation
detail?
I don't
On Wed, 30 Mar 2011, Jonathan Nieder wrote:
Package: debian-policy
Version: 3.9.1.0
Raphael Hertzog wrote[1]:
It has been discussed on -release, not on -devel:
http://lists.debian.org/debian-release/2011/02/threads.html#00381
(I don't think it matters much given that all important
On Wed, 30 Mar 2011, Jonathan Nieder wrote:
Well, I want to interpret it as meaning *something* --- though I'm not
filing RC bugs or anything. I had thought that the general rule is
that violating a policy should is always a bug (either in your
package or in policy), though not necessarily an
On Wed, 30 Mar 2011, Jonathan Nieder wrote:
I like your proposed alternative. Maybe the policy could say that you
should (in the policy sense) thoroughly analyze the consequences and
alternatives before adding pre-depends, and that one way to do so (in
a friendly advice sense) is to ask on
On Thu, 31 Mar 2011, Bill Allombert wrote:
First this might force users to use UTF-8 locale. While this is the default,
this is not
mandatory in Debian. I know users that stays with ISO8859-1 because they have
a lot of
text files in that encoding.
Until the C.UTF-8 proposal is
On Sun, 03 Apr 2011, Russ Allbery wrote:
The bug:
http://bugs.debian.org/89038
is still looking for two more seconds. This would allow us to retire the
tiny separate mime-policy document. Could other folks take a look and
confirm that all looks well?
Seconded. It's fine for me.
Hi,
On Mon, 04 Apr 2011, Bill Allombert wrote:
1. upstream_version must start with a digit;
Unfortunately, we cannot force upstream to use a version that start by a
digit,
We would need to document a mangling process for upstream version that start
by a letter.
We have no upstream with
On Fri, 08 Apr 2011, Goswin von Brederlow wrote:
It does not allow them in available though breaking many systems that
have or in the past had a package with such a version available. At
least 4 people on irc have run into that problem that I saw already.
It does allow them in available. Those
On Wed, 20 Apr 2011, Chris Leick wrote:
Hi,
while translating this reference to german, I've found some typos
and punctuation errors. The patch attached will fix them.
No it will not. You need to fix the errors in the .dbk files.
But it's nice to avoid fuzzying the translations, so it's
Hello,
On Fri, 22 Apr 2011, Martin Eberhard Schauer wrote:
reviewing the German translation I found that this section is
outdated. I rewrote some
of the stuff with my background as Debian translator.
Can you send your suggestions as a patch to the docbook files?
$ svn co
Hi,
On Mon, 16 May 2011, Guillem Jover wrote:
+The list may include (or consist solely of) the special
This has switched from tabs to spaces.
This is due to a bad vim modeline. I fixed it as well. Looks like policy
editors mainly use emacs :)
With those fixed, seconded.
Hi,
On Tue, 24 May 2011, Bill Allombert wrote:
2) This change breaks actual packages. Even if no such package exist in
squeeze, users
could still want to install older or unofficial packages, or created with
dpkg-repack.
The next version of dpkg has --force-bad-version to work around this.
Hi,
On Mon, 06 Jun 2011, Roger Leigh wrote:
Has the following been considered:
- adding a command-line option for dpkg-buildpackage to explicitly
enable particular build-features (overriding the feature in the
source package).
This has not been suggested yet, I'm not opposed to the idea
Hi David,
On Wed, 08 Jun 2011, David Prévot wrote:
Lucas, Raphaël, could we consider moving away of pdflatex build? This
may allow to build the Japanese PDF, which would also be an improvement.
I don't care much of the build process (as long as it works and it stays
out of my way).
If
Hi,
On Thu, 16 Jun 2011, chris h wrote:
We (Grml) would like to switch back to short Version: strings for our
kernel packages, as they already have the major version number in
the package name, to allow co-installation of multiple versions, and
there's no point in duplicating this info in the
Hi,
to better understand this mail you can refer to this diagram
http://people.debian.org/~srivasta/MaintainerScripts.html#sec-3.4.3
During an upgrade from V1 to V2, if V1-prerm upgrade V2 fails, dpkg tries
to run V2-prerm failed-upgrade V1 and if it works the upgrade
continues normally.
This
Hi,
On Sat, 18 Jun 2011, Jonathan Nieder wrote:
Raphael Hertzog wrote:
1/ I'd argue that in the case of downgrade, dpkg should not try to run
the failed-upgrade fallback because there's no way the oldest version
can be aware of how to work-around a problem in a prerm script
On Mon, 04 Jul 2011, David Prévot wrote:
I can't remember how the branches looks like on DDP Subversion
repository, and I can't find an on line view of Subversion repository on
the new Alioth front-end, could someone please refresh my memory or push
developers-reference r8880 content to its
Hi,
On Sat, 03 Sep 2011, Giovanni Mascellani wrote:
I though about this, but couldn't come up with any easy solution. I
mostly consider this tool to be useful for people who just have to check
the very last versions of the policy, so the problem is actually quite
mitigated.
I don't even
On Mon, 15 Aug 2011, Luca Falavigna wrote:
Right. Could someone update the patch?
Patch refreshed with Santiago's suggestions.
I took the time to expand it a little bit.
I merged it but I changed the wording (hopefully improving it!).
Cf attached patch.
Thanks for your contribution!
On Sun, 11 Sep 2011, Charles Plessy wrote:
This adds Built-Using in §5.6.10 (“Package interrelationship fields: Depends,
Pre-Depends, Recommends, Suggests, Breaks, Conflicts, Provides, Replaces,
Enhances”). In Policy's chapter 5, the fields in that list are documented to
be present in source
Hello Jérôme,
you have been filing such bugs in Ubuntu and I closed at least one you
filed against dpkg.
I hope that if this debian-policy request gets turned off, you will stop
filing such wishlist bugs everywhere.
On Sun, 25 Sep 2011, Jérôme wrote:
Most of the time I think that log files
On Mon, 26 Sep 2011, Raphael Hertzog wrote:
Thinking is not enough, we would like to see facts.
I just wanted to add that changing this means changing the names of many
compressed log files and potentially breaking some (custom) scripts which
are relying on the current configuration.
So I think
Hi,
On Sat, 01 Oct 2011, Charles Plessy wrote:
how about also removing ‘unofficial’ in the sentence below ?
Please read the unofficial debian-mentors FAQ at ulink
url=url-mentors;/ulink first.
Agreed, I have made the change locally, will push later.
Cheers,
--
Raphaël Hertzog ◈ Debian
On Fri, 04 Nov 2011, Bill Allombert wrote:
I would suggest we use entities instead of hard-coding 'MUST NOT/SHOULD NOT'.
This way it will be easier to generate policy document with the lower case
variant for people who cannot read uppercase words.
Entities are not translatable. Even if there's
1 - 100 of 301 matches
Mail list logo
