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, *AND*
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 th
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 kno
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 t
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 just
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 formatt
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 w
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 pr
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 in
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
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 rele
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.
> &
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 permanent nuis
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
> +++ b/policy/ch-controlfie
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 a
On Wed, May 31, 2017 at 10:02:53AM -0700, Russ Allbery wrote:
> Wouter Verhelst 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
> >> documents released under th
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 al
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 http://reproducib
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
/usr/share/doc//copyrigh
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 writes:
>
>
> Wouter> So, I'm with Guillem on this one.
>
>
> Wouter> But _forbidding_ maintainers who want to from shippi
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 file
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 edito
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,
>
>
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 unlik
On 14-05-13 23:31, Bill Allombert wrote:
> On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote:
>> Wouter Verhelst writes:
>>> On 13-05-13 10:02, Josselin Mouette wrote:
>>
>>>> Packages can, to be compatible with Debian additions to some
>&
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 h
s now, 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 writes:
>
>> It refers to some (unspecifie
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 catego
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 le
On 10-04-13 18:19, Don Armstrong wrote:
> On Wed, 10 Apr 2013, Simon McVittie wrote:
>>
>> 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 same
>> way tha
On 10-04-13 12:37, Simon McVittie wrote:
>
>
> 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 (#)
>>>
>>> whitespaces ? (with "s")
>&g
On 10-04-13 12:07, Raphael Hertzog wrote:
> “dpkg 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 (#)
>
> whitesp
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"
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 "Sal
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
> clo
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 int
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
> >
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 possibl
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 (gu
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
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.
>
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
&
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 exa
On Mon, Feb 20, 2012 at 06:49:15PM +0100, Jakub Wilk wrote:
> * Bill Allombert , 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 with /bin/tar (default)
>
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 jus
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
> >
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 co
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
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...]
> >
>
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 to
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 Wed, Nov 04, 2009 at 10:52:00AM +0100, martin f krafft wrote:
> also sprach Wouter Verhelst [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/ne
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.
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 t
On Tue, Nov 03, 2009 at 08:02:31PM +0100, martin f krafft wrote:
> also sprach Wouter Verhelst [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
> > wh
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 developers-ref
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
> > nati
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 obvi
On Tue, Sep 08, 2009 at 12:48:25AM +0100, Chris Lamb wrote:
> But would such a pointer be valuable enough to mitigate these concerns? For
> a newbie, the answer might very well be "yes". However, this seems like a
> weak and relatively rare case to optimise for, compounded by the high cost
> of exc
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.
>
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 tha
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'
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 us
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.
--
Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 20
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.
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 o
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 r
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://creativecom
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 pro
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
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 ty
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, r
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. An
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
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 sam
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 flam
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 whi
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 e
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
> > bui
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-Con
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
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
> > dir
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-Confli
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-inde
1 - 100 of 135 matches
Mail list logo
