On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote:
> > > > - the service fails to start in the postinst.
>
> This implies that "the service is running" is part of "the service is
> configured", which is where I disagree.
What Steve said is that if
- The service fails to start,
On Fri, Jan 20, 2023 at 05:16:43PM +, Simon McVittie wrote:
> On Fri, 20 Jan 2023 at 09:54:21 -0700, Anthony Fok wrote:
> > supposedly some older Chinese websites are still using "GBK" as
> > encoding, probably something like:
> >
> >
> >
> > which has less than 30,000 characters and
On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote:
> Preferring to use Unicode does seem to be the direction that all of
> computing is going in, as a simplifying assumption - for example W3C
> advice for HTML is "You should always use the UTF-8 character encoding"[1]
> - and as we
On Thu, Sep 22, 2022 at 07:11:38PM -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
> > On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
> >> Wouter Verhelst writes:
>
> >>> Thanks, yeah, I missed that. I'll have a stab at a patch some time s
On Sat, Sep 24, 2022 at 10:16:12AM +, Holger Levsen wrote:
> On Fri, Sep 23, 2022 at 04:17:04PM +0100, Simon McVittie wrote:
> > On Thu, 22 Sep 2022 at 19:11:38 -0700, Russ Allbery wrote:
> > > I also reworded the paragraph about backports to hopefully address
> > > Holger's reading. It's
On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
> > On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
> >> Wouter Verhelst writes:
>
> >>> -policy: this is a question that has come up before
> >>> (
On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote:
> Guillem Jover writes:
>
> > Oh! I've completely missed this all this time, I think because that
> > feels very weird given that it has no synopsis and the text is added
> > already on the first line on the spec. :/
>
> Other
On Fri, Aug 13, 2021 at 09:43:32AM -0700, Felix Lechner wrote:
> Hi,
>
> On Fri, Aug 13, 2021 at 9:12 AM Bill Allombert wrote:
> >
> > Then I would suggest that a new lintian category is designed to catter
> > for such usage, so that tools might chose not to display such warnings
> > as they do
On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
>
> > -policy: this is a question that has come up before
> > (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
> > example that springs to mind, but I'm pretty
Package: debian-policy
On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote:
> I understand what you're saying, and indeed trying to encode
> "Build-Depends-If-Available: foo" as "Build-Depends: foo | something"
> is a bad idea from the get-go. After all, foo can have three states
On Mon, Feb 10, 2020 at 05:48:42AM -0500, Sam Hartman wrote:
> I'm not really sure that policy is the best place for this sort of
> discouragement though.
Why not? Policy discourages loads of things. If we agree that it's not
the right thing to do (I'm inclined to agree with that), then we should
On Sun, Feb 02, 2020 at 01:59:30PM +0100, Bill Allombert wrote:
> On Sun, Feb 02, 2020 at 08:08:34AM +0200, Wouter Verhelst wrote:
> > On Sun, Feb 02, 2020 at 01:31:14AM +0100, Bill Allombert wrote:
> > > On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote:
> &
On Sun, Feb 02, 2020 at 01:31:14AM +0100, Bill Allombert wrote:
> On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote:
> > I've never liked the rule that you don't have to declare dependencies on
> > essential packages and would love to phase it out as much as possible (I
> > think even
On Fri, Sep 06, 2019 at 11:32:06AM +0200, Bill Allombert wrote:
> On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit :
> > > On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wou
On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> I have come to wonder if these two functions shouldn't be separated, in
> different bodies (eventually with different nomination rules, etc.). This
> "steering" question had also been phrased, slightly differently, by Mehdi,
On Fri, Jul 26, 2019 at 06:45:35PM +0200, Guillem Jover wrote:
> * This is a body composed of members that come and go, these might have
> wide experience in Debian in general (although not necessarily) or
> might had expertise in specific fields. The problem is that this body
> gets
On Fri, Sep 07, 2018 at 02:14:15PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers
> not universally applied"):
> > To me, the core message of the current text is that you should ensure
> > that bug reports which
On Thu, Sep 06, 2018 at 09:05:04PM +0200, Moritz Muehlenhoff wrote:
> Source: developers-reference
> Severity: normal
>
> "3.1.4. Coordination with upstream developers" says
>
> "You have to forward these bug reports to the upstream developers so that they
> can be fixed in a future upstream
On Sat, Jul 28, 2018 at 01:51:12PM -0700, Russ Allbery wrote:
> One remaining question in my mind is whether we should take the
> opportunity of a format change to achieve a few other goals. The most
> obvious one would be to reconcile our short license identifiers with SPDX
> (probably by making
On Thu, Jun 28, 2018 at 04:27:12PM +0200, Guillem Jover wrote:
> On Thu, 2018-06-28 at 14:34:06 +0200, Wouter Verhelst wrote:
> > On Thu, Jun 28, 2018 at 01:43:17PM +0200, Guillem Jover wrote:
> > > On Thu, 2018-06-28 at 13:03:56 +0200, Wouter Verhelst wrote:
> > > >
On Thu, Jun 28, 2018 at 01:43:17PM +0200, Guillem Jover wrote:
> On Thu, 2018-06-28 at 13:03:56 +0200, Wouter Verhelst wrote:
> > On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote:
> > > The requirement to consult d-d has worked very well with Pre-Depends.
&g
On Thu, Jun 28, 2018 at 12:58:28PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: Bug#891216: seconded 891216: Requre d-devel
> consultation for epoch bump"):
> > Incorrect epochs are a nuisance at best.
>
> The problem is that they are a permanen
On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Bug#891216: seconded 891216: Requre d-devel
> consultation for epoch bump"):
> > I would oppose this change.
>
> > Documenting why you should not use epochs in certain c
I would oppose this change.
On Wed, Jun 13, 2018 at 11:13:27PM +0200, Paul Gevers wrote:
> I second the diff below.
>
> Paul
>
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 0771346..166cdd8 100644
> --- a/policy/ch-controlfields.rst
> +++
On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
[...maintaining non-Debian-specific software as a native package...]
> I certainly think it's not good practice.
I think it depends on the particulars of the situation.
I am upstream for two of the packages I maintain for Debian: nbd
On Wed, May 31, 2017 at 10:02:53AM -0700, Russ Allbery wrote:
> Wouter Verhelst <wou...@debian.org> writes:
> > On Mon, May 29, 2017 at 05:35:47PM -0700, Russ Allbery wrote:
>
> >> As part of the XML conversion, I noticed the GPL notices on the three
> >> d
On Mon, May 29, 2017 at 05:35:47PM -0700, Russ Allbery wrote:
> As part of the XML conversion, I noticed the GPL notices on the three
> documents released under the GPL were the older form that had an FSF
> street address. I updated them to the current recommended form, including
> switching to
On Sun, May 14, 2017 at 11:15:26PM +, Holger Levsen wrote:
> On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> > On Sun, May 14, 2017 at 03:20:54PM +, Holger Levsen wrote:
> > > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > > a.) go to
Hi Mark,
On Wed, Apr 05, 2017 at 11:06:32AM -0400, Mark Gabrielli wrote:
> We are using your software with a lighting controller. Is there anything we
> need to do to legally include this once we retail the unit?
The licenses of the software which we ship can be found in
On Tue, Dec 08, 2015 at 08:44:22PM +, Vesa Paatero wrote:
> Thanks for the link. Even as you admit in the article that "it is a frequent
> beef against Debian that on Debian, network services get started immediately
> after the package was installed", maybe we should keep our antennas up for
>
On Tue, Oct 13, 2015 at 07:56:03AM -0400, Sam Hartman wrote:
> >>>>> "Wouter" == Wouter Verhelst <wou...@debian.org> writes:
>
>
> Wouter> So, I'm with Guillem on this one.
>
>
> Wouter> But _forbidding_ maintainers who want to
On Tue, Sep 29, 2015 at 11:39:47AM +0200, Didier 'OdyX' Raboud wrote:
> Le mardi, 29 septembre 2015, 02.10:01 Guillem Jover a écrit :
> > Wow, this is such terrible policy… So we have supporters of the XDG
> > format, and supporters of the menu format. Some of those would and
> > have accepted
Hi Sam,
[side note: while I joined the original discussion, I don't really have
a stake in the outcome, other than the desire to have a working menu]
On Tue, Jul 21, 2015 at 09:06:08AM +, Sam Hartman wrote:
Should Bill have recused?
Your current process does not describe when policy
On 03-08-13 08:40, Charles Plessy wrote:
tag 676784 pending
thanks
Le Tue, Jul 30, 2013 at 10:13:37PM +0900, Charles Plessy a écrit :
Unless there is objection, I will add the note in parenthesis as a
non-normative change, and then mark the bug pending.
Hello everybody,
here is what
On 14-05-13 23:28, Bill Allombert wrote:
On Sun, May 12, 2013 at 12:51:13PM +0200, Sune Vuorela wrote:
For fluxbox, openbox, blackbox, fvwm, icewm, windowmaker, gnustep and
probably
others, there exists scripts that convert a XDG menu structure into their
own
formats, not unlike
On 15-05-13 08:23, Raphael Hertzog wrote:
(Your last mail was not sent to the BTS but to the ML directly)
On Tue, 14 May 2013, Wouter Verhelst wrote:
I didn't mean to imply someone other than the relevant UI maintainers
would need to write code for this to happen; we could simply add some
On 14-05-13 23:31, Bill Allombert wrote:
On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
On 13-05-13 10:02, Josselin Mouette wrote:
Packages can, to be compatible with Debian additions to some
legacy window managers
Hi,
On 12-05-13 02:04, Michael Biebl wrote:
Hi Russ, hi Sune,
I'd like to second this request to reword the current section in the
policy regarding menu files, suggesting fdo .desktop files as the
recommended mechanism and make it clear that .menu files are only really
relevant for legacy
On 13-05-13 10:02, Josselin Mouette wrote:
* The maintainer should use the “debian-desktop” mailing
list too coordinate with maintainers of menu
implementations, in order to avoid bad interactions with
other icons or wrong
, however, this seems as good a time as any to at least think
about the issues. If some of them can be implemented by adding the
correct wording to policy, then why not?
On 14-05-13 20:42, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
It refers to some (unspecified) window manager
On 10-04-13 12:07, Raphael Hertzog wrote:
“prgndpkg/prgn triggers allows packages to monitor events caused by
It should be allow here, not allows, since the subject (triggers)
of this sentence is in plural form.
[...]
+ whitespace, everything after the first hash character (tt#/tt)
On 10-04-13 12:37, Simon McVittie wrote:
hat class=native-en_GB-speaker
On 10/04/13 11:24, Wouter Verhelst wrote:
On 10-04-13 12:07, Raphael Hertzog wrote:
+whitespace, everything after the first hash character (tt#/tt)
whitespaces ? (with s)
No, absolutely not. The word whitespace
On 10-04-13 18:19, Don Armstrong wrote:
On Wed, 10 Apr 2013, Simon McVittie wrote:
hat class=native-en_GB-speaker
I've mostly seen whitespace used as a mass noun, like water or
sand: you can say whitespace is ignored or a sequence of
whitespace, but not a whitespace or whitespaces, in the
On 30-03-13 06:11, Charles Plessy wrote:
Le Mon, Mar 25, 2013 at 01:32:50PM +0100, Wouter Verhelst a écrit :
The fact that we don't have a solution (yet) doesn't mean we don't want
a solution, nor does it mean we should give up. wontfix is for things
that the maintainer disagrees is a problem
On 28-03-13 00:16, Charles Plessy wrote:
I have corrected the typo in the Policy. Sorry Salvatore, I did not
realise on time that your patch was a Git patch, so the commit is on
my name, but you are properly thanked in the changelog and the commit
message.
git commit --amend --author
Hi Charles,
On 24-03-13 12:01, Charles Plessy wrote:
Given that this bug report asks for a policy about the encoding of filenames,
doing nothing is equivalent to reject it. I therefore propose one more round
of concertation, and if it is not conclusive, I will tag this bug wontfix and
close
Hi all,
About a week ago, I gave a course at a customer about packaging Debian
packages. While preparing and giving the course, I was reminded of
something I'd been meaning to bring up before:
Debian's policy document, and many of Debian's tools, assume that any
built Debian package is always
On Mon, Mar 12, 2012 at 06:19:47PM -0400, David Prévot wrote:
Le 12/03/2012 13:44, Wouter Verhelst a écrit :
On Sat, Feb 25, 2012 at 01:56:17AM +0100, Carsten Hey wrote:
[…] how a possible mechanism to let users choose between always prefer
free packages and follow the maintainer's
On Sat, Feb 25, 2012 at 01:56:17AM +0100, Carsten Hey wrote:
This reads like you ask if main | non-free should be allowed. In my
opinion, the question should rather be if it must be main | non-free
or if both, main | non-free and non-free | main, should be allowed
and how a possible mechanism
On Wed, Feb 22, 2012 at 12:09:15AM +0100, Joerg Jaspert wrote:
There's more than just my /usr. This system runs off a 160GB SSD, so
500MB is more like 0.5% of the available storage space here.
160GB is in the low end of the available storage of modern systems, and
probably (gut
On Tue, Feb 21, 2012 at 09:01:42AM +0100, Raphael Hertzog wrote:
On Tue, 21 Feb 2012, Wouter Verhelst wrote:
On Mon, Feb 20, 2012 at 07:09:40PM +0100, Wouter Verhelst wrote:
On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote:
Debian is used on small systems where users still
On Mon, Feb 20, 2012 at 06:49:15PM +0100, Jakub Wilk wrote:
* Bill Allombert bill.allomb...@math.u-bordeaux1.fr, 2012-02-20, 18:02:
iceweasel handle compressed file fine
Oh, does it? I just tried to open
/usr/share/doc/ccache/changelog.html.gz and it gave me the following
options:
* Open
On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote:
On Mon, Feb 20, 2012 at 08:22:52AM +0100, Wouter Verhelst wrote:
Hi,
During a recent discussion on debian-devel about multiarch, it was shown
that gzip does not always produce the exact same output from a given
input file
Package: debian-policy
Version: 3.9.2
Severity: wishlist
On Mon, Feb 20, 2012 at 09:17:16PM +0100, Iustin Pop wrote:
On Mon, Feb 20, 2012 at 08:22:52AM +0100, Wouter Verhelst wrote:
Hi,
During a recent discussion on debian-devel about multiarch, it was shown
that gzip does not always
On Mon, Feb 20, 2012 at 07:09:40PM +0100, Wouter Verhelst wrote:
On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote:
Debian is used on small systems where users still like to have
documentation, and
support zlib compression is almost universal.
I would not have any objection
Hi,
During a recent discussion on debian-devel about multiarch, it was shown
that gzip does not always produce the exact same output from a given
input file.
While it was shown that removing the requirement to compress
documentation would not solve the issue (i.e., the problem was larger
than
On Mon, Feb 28, 2011 at 07:12:00PM +, Roger Leigh wrote:
On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote:
On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
This is correct. I was thinking about drafting a patch for Policy
about this. Current Policy defines
Hi Roger,
On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote:
I disagree here.
Alternatives in build-* relationships *are* mentioned by policy. In fact,
there's even an example in section 7.1.
This is correct.
On Mon, Jan 18, 2010 at 01:56:17AM -0800, Steve Langasek wrote:
On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote:
There was no further discussion on this item since the above date.
FWIW, I for one hadn't commented up to now because I find that
fundamentally, implementing
On Sat, Jan 16, 2010 at 06:09:19PM +0100, Bill Allombert wrote:
On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote:
On Thu, Nov 05, 2009 at 09:54:37AM +0100, martin f krafft wrote:
[...response that is not very relevant to this mail...]
There was no further discussion
On Thu, Nov 05, 2009 at 09:54:37AM +0100, martin f krafft wrote:
[...response that is not very relevant to this mail...]
There was no further discussion on this item since the above date. Since
I've recently uploaded ipcfg, I'd like this to be finalized. It
currently uses 'ifupdown' as the name
Hi,
I'm a bit late to the party, but:
On Fri, Nov 20, 2009 at 12:33:50PM -0600, Manoj Srivastava wrote:
This patch explicitly allows /sys and /selinux as additional
directories int he root file system allowed under the policy.
We should probably add /spu to that list, which is where spufs is
On Mon, Oct 05, 2009 at 08:11:57AM +0200, Luk Claes wrote:
Manoj Srivastava wrote:
Actually, udev, while nice, is optional, and I think I have read
reports of admins opting _not_ to have udev on the system, so in some
cases one may have systems without udev and with MAKEDEV.
On Wed, Nov 04, 2009 at 10:52:00AM +0100, martin f krafft wrote:
also sprach Wouter Verhelst wou...@debian.org [2009.11.04.0230 +0100]:
Since to me the point of this exercise is so that I can usefully
put ipcfg into the archive, and since ipcfg does not actually
support /etc/network
On Tue, Nov 03, 2009 at 08:02:31PM +0100, martin f krafft wrote:
also sprach Wouter Verhelst w...@uter.be [2009.11.03.1915 +0100]:
As such, I'd like to propose the addition of a virtual package
name, network-config-tool, that would be used for any package
which provides /sbin/ifup and /sbin
Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, ifupd...@packages.debian.org
Hi all,
As you may or may not know, I've been working on an alternative
implementation of ifup and ifdown, which I call 'ipcfg', for a few
months now[1]. The code is now nearly at
On Mon, Sep 21, 2009 at 01:40:51PM +0200, Bill Allombert wrote:
Debian Policy has a more formal process than developers-reference and
I am concerned that mixing both discussions on the same channel would cause
confusion.
debian-de...@l.d.o could be a better channel for the
Hi,
(sorry, missed this mail)
On Sun, Sep 13, 2009 at 08:38:58PM +0200, Emilio Pozuelo Monfort wrote:
Emilio Pozuelo Monfort wrote:
Given the recent thread in debian-devel[1], I think we should document in
policy that packages that are not tightly related to Debian shouldn't be
native.
On Sat, Sep 05, 2009 at 01:55:09PM -0700, Steve Langasek wrote:
Maybe I would be happier about dealing with native packages if there was a
clear policy that packaging software as native implies that any DD is
allowed to release a new upstream version of the software. :-)
That would seem
On Fri, Sep 04, 2009 at 08:26:10PM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
Given the recent thread in debian-devel[1], I think we should document in
policy that packages that are not tightly related to Debian shouldn't be
native.
*sigh*
So I spent a whole subthread trying
On Fri, Sep 04, 2009 at 10:56:43AM +0200, Emilio Pozuelo Monfort wrote:
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
Hi,
Given the recent thread in debian-devel[1], I think we should document in
policy that packages that are not tightly related to Debian shouldn't be
On Mon, Aug 24, 2009 at 10:33:14PM +0100, Chris Lamb wrote:
Package: debian-policy
Version: 3.8.3.0
Hi Policy hackers.
I feel there is a problem with §4.14 (Source package handling:
debian/README.source) that is a little harmful at present.
Basically, I feel that assuming that all
On Thu, Mar 05, 2009 at 11:03:57AM +0100, Giacomo A. Catenazzi wrote:
Jon Dowland wrote:
A brief explanation as to their meaning. Doom games are
divided into engine and world-resource components. The
former is captured by 'doom-engine'.
I don't understand why we need a 'doom-engine' virtual
On Sat, Jul 05, 2008 at 03:15:28AM -0500, William Pitcock wrote:
Hi,
On Sat, 2008-07-05 at 02:42 -0400, Daniel Dickinson wrote:
For discussion:
Gnome, KDE, and XFCE are the the top three desktops used in debian and
cover most users of desktops in debian.
They all use xdg
On Thu, Jul 03, 2008 at 11:02:13PM +0200, Iñaki Baz Castillo wrote:
I think being LSB compliant is good for Debian.
That may be so; but changing a long-standing interface with no migration
is /not/ good for Debian.
--
Lo-lan-do Home is where you have to wash the dishes.
-- #debian-devel,
On Tue, Jan 08, 2008 at 12:36:07PM -0800, Russ Allbery wrote:
Jörg Sommer [EMAIL PROTECTED] writes:
The rest looks good and I agree that such a source is useful, but it
should also be allowed to refer to a central document like
/u/s/d/dpatch/README.source. I expect that many README.source
Hi Russ,
First, thanks for your great work on this bug.
On Tue, Jan 01, 2008 at 10:54:06PM -0800, Russ Allbery wrote:
This is the last Policy bug I had tagged as wording. It started with a
proposal for a README.source file documenting how to do things with a
package that uses a non-trivial
On Wed, Aug 22, 2007 at 12:07:50PM -0700, Ben Pfaff wrote:
Russ Allbery [EMAIL PROTECTED] writes:
Bill Allombert [EMAIL PROTECTED] writes:
I find the wording convenience copy of library from other software
packages much more telling than convenience copy of code from other
software
On Fri, Jul 27, 2007 at 04:56:14PM +0200, Matthias Klose wrote:
- What to do if that option is not present? Should a package be
allowed to build in parallel anyway, determing the number of
processes itself, or should it be a sequential build?
I think it should behave as is currently
On Wed, Mar 21, 2007 at 05:52:05AM +0200, Guillem Jover wrote:
Personally I'd favour DEB_BUILD_OPTIONS_PARALLEL.
Yes, I'll second that. It makes no sense at all to try to have the
package predict how much memory it will need for the build; this amount
of memory will be different depending on the
On Fri, Dec 01, 2006 at 12:54:32PM -0800, Russ Allbery wrote:
On Fri, 1 Dec 2006, Jari Aalto wrote:
SUGGESTION
Please add more standard license texts in the directory. Like:
- GFDL
- MIT/X license
- Apache License
- PHP License
- http://creativecommons.org/ (when DFSG ready)
On Sun, Nov 05, 2006 at 07:41:40PM -0800, Russ Allbery wrote:
Russ Allbery [EMAIL PROTECTED] writes:
Manoj Srivastava [EMAIL PROTECTED] writes:
This flows from the Release policy. Not specifying /bin/bash
in scripts is not considered a RC bug.
I can try to propose better
On Fri, Oct 27, 2006 at 09:04:51AM -0300, Otavio Salvador wrote:
Steve Langasek [EMAIL PROTECTED] writes:
Unusable or mostly so does not mean unusable in select, minority
configurations explicitly enabled by the user. dash as /bin/sh is a corner
case, not the common case; which means such
On Thu, Oct 26, 2006 at 10:18:00AM -0300, Otavio Salvador wrote:
Really? Have you read the message where Luk said that #!/bin/sh bugs
using no POSIX features isn't RC? That just make me think one thing:
Let's release fast, whatever this means!
No, it means Let's release at _some_ point, rather
On Thu, Oct 26, 2006 at 12:10:44PM -0300, Otavio Salvador wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
No, it means Let's release at _some_ point, rather than waiting for
five years. It's not as if we haven't been taking this type of
shortcuts for woody and sarge either.
I disagree
On Wed, Aug 16, 2006 at 11:32:01AM -0400, Carl Fink wrote:
Really? See, I'd automatically use mc, which also handles compression just
fine but doesn't require Apache (and isn't as slow and bloated as Firefox).
That's also an option, but not all HTML files look great in lynx -dump
output. And
On Tue, Aug 15, 2006 at 08:56:41PM +0200, Peter Eisentraut wrote:
The underlying question here was really, Should PDF documentation be
installed compressed? (Or PostScript or OpenOffice etc. in place of
PDF.) The policy is not worded precisely enough on that subject.
Obviously, you don't
Hi,
It has come to my attention that the gem package is currently built
using 'make -j 4', to have four compiler processes running at the same
time. This is a bit troublesome for the poor m68k buildd, which is now
suffering under High Load And Constant Swapping (HLACS).
I was going to file a
On Sun, Jun 25, 2006 at 06:11:24PM +0300, Lars Wirzenius wrote:
su, 2006-06-25 kello 16:36 +0200, Wouter Verhelst kirjoitti:
It has come to my attention that the gem package is currently built
using 'make -j 4', to have four compiler processes running at the same
time. This is a bit
On Wed, Jun 21, 2006 at 02:08:57PM +0200, Goswin von Brederlow wrote:
Policy says Build-Depends-Indep must be installed for the build
target, which sbuild calls. But sbuild does not install
Build-Depends-Indep. Same goes for dpkg-checkbuildep -B, it does not
test for Build-Depends-Indep while
On Tue, Jun 20, 2006 at 07:52:01PM -0700, Thomas Bushnell BSG wrote:
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only looks at build-depends. So in order
On Tue, Jun 20, 2006 at 10:50:46AM -0700, Thomas Bushnell BSG wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only looks at build-depends. So in order
for build-depends to be useful at this time if you want a package to
build, you need to list mostly
On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote:
On 16 Jun 2006, Goswin Brederlow stated:
The existance of either of the two makes build-arch mandatory.
The old fields change their meaning:
Build-Depends, Build-Conflicts
The Build-Depends and Build-Conflicts fields
Hi,
The last post to this bug was done on 2004-08-23, which is ages ago. I
think it's safe to say that Bill's proposal (create
debian/rules.{version,targets} files which define what interfaces are
implemented by the debian/rules file) did not get enough seconds.
Personally, I happen to think that
On Tue, May 23, 2006 at 11:15:14PM +0200, Bill Allombert wrote:
Hello Wouter,
First thank for bringing back this issue, however...
On Tue, May 23, 2006 at 10:17:01PM +0200, Wouter Verhelst wrote:
The last post to this bug was done on 2004-08-23, which is ages ago. I
think it's safe
On Wed, May 03, 2006 at 03:02:49PM +0200, Alexis Sukrieh wrote:
I plan to do the following for the bugzilla package:
1/ Add a debconf note for notyfing the user about the location change.
Eh, no. Please don't.
Debconf notes about things that were done to follow policy are the worst
cases
On Sun, Apr 02, 2006 at 07:34:52PM -0400, Joey Hess wrote:
Lars Wirzenius wrote:
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.
On Wed, Mar 29, 2006 at 03:39:27AM +0300, Guillem Jover wrote:
[...]
Proposal
I'd like «Section 5.2. Source package control files -- `debian/control'»
to specify clearly[0] that the following fields contain logical lines:
Build-Depends, Build-Depends-Indep, Build-Conflicts,
On Mon, Jan 23, 2006 at 11:21:55PM +0100, Bill Allombert wrote:
On Mon, Jan 23, 2006 at 11:08:00PM +0100, Wouter Verhelst wrote:
And I would strongly suggest you to consider Simon Richter's proposal,
which sounds a lot cleaner to me: if you have build-depends-indep in
your debian/control
On Mon, Jan 23, 2006 at 02:17:36PM -0600, Bill Allombert wrote:
On Mon, Jan 23, 2006 at 07:45:10PM +0100, Michael Banck wrote:
The difference between the two is that -q checks whether a target is
uptodate and return an appropriate exit code, while -p prints out the
data base (i.e. the rules
1 - 100 of 128 matches
Mail list logo
