On Fri, Sep 4, 2009 at 1:36 PM, Raphael Hertzog wrote:
> forcemerge 229357 545081
> thanks
>
> On Fri, 04 Sep 2009, Zack Weinberg wrote:
>> As is well known, dpkg-buildpackage -B does not know whether it can
>
> If you knew well, you would have known that this bug already
Package: dpkg-dev
Version: 1.15.3.1
Severity: wishlist
As is well known, dpkg-buildpackage -B does not know whether it can
safely use the 'build-arch' target to debian/rules, so it always uses
'build', which makes the Build-Depends/Build-Depends-Indep distinction
useless unless you bend the rules
I'd like to see this say something about what may be assumed of the
standard shell utilities, as well as the shell itself, and in
particular I'd like to see coreutils bug #339085 addressed [please see
the bug log for my personal very strong opinion on which way it should
be addressed].
zw
--
To
On Mon, Nov 04, 2002 at 11:16:57AM -0900, Britton wrote:
>
> So how does the reference to the now-nonexistent fileutils package ever go
> away?
As I understand it, it can be taken out after sarge is released.
zw
Package: debian-policy
Version: 3.5.7.1
Severity: normal
Tags: sid
The debian-policy package has this control line:
Depends: fileutils (>=3D 4.0)
In sid, fileutils has been subsumed into the coreutils package.
Since a versioned dependency is not satisfied by a Provides:,
having debian-policy ins
This proposal has been marked [rejected] for no reason apparent in the
bug log. Please explain.
zw
On Mon, May 28, 2001 at 10:24:26PM +0200, Marcus Brinkmann wrote:
> On Mon, May 28, 2001 at 01:05:12PM -0700, Zack Weinberg wrote:
> > > So a situation where we have absolutely no idea if and what POSIX
> > > specifies about something should be quite rare, and I'd be sat
On Mon, May 28, 2001 at 10:21:55PM +0200, Patrik Hagglund wrote:
> Zack Weinberg wrote:
> > This misses the point. The phrase being quoted here is _not_ from
> > 1003.2-1992, it's from the XPG/4 webpage describing the shell. It may
> > also be in 1003.2-1992 but can an
On Mon, May 28, 2001 at 10:14:59PM +0200, Arthur Korn wrote:
> Zack Weinberg schrieb:
> > > Further, "identical behaviour" seems a bit strict and hard to
> > > prove to me, OTOH I don't know POSIX well, thus I have no idea
> > > what this would app
> > I will reiterate, however, that the issue from my point of view is
> > that the standard is not specific at all, and even where it is, it is
> > not readily available, so how does anyone know what it specifies?
>
> First thing, in all your proposals is the sentence that says that POSIX is
> ve
On Mon, May 28, 2001 at 08:03:04PM +0200, Arthur Korn wrote:
> Hi
>
> Zack Weinberg schrieb:
> > I apologize for the long delay in responding, I was sick.
>
> Bless you.
Thank you.
> > The POSIX standard for shells leaves important areas
> > unspecifie
On Mon, May 21, 2001 at 09:25:33AM -0500, Steve Greenland wrote:
> On 21-May-01, 05:22 (CDT), Patrik Hagglund <[EMAIL PROTECTED]> wrote:
> > I don't see what you mean by "the initial value of the IFS
> > variable". Is there anything that is unspecified for field
> > splitting in IEEE Std. 1003.2-1
On Mon, May 21, 2001 at 04:43:11AM +0200, Marcus Brinkmann wrote:
> On Sat, May 19, 2001 at 09:13:31PM -0700, Zack Weinberg wrote:
> > I'd like to tighten this up a bit by requiring that /bin/sh adhere to
> > the consensus of implementations, where POSIX leaves things
>
I apologize for the long delay in responding, I was sick.
On Sun, May 20, 2001 at 08:23:44PM +0200, Arthur Korn wrote:
>
> Can we change the last sentence in:
>
> > ! The standard shell interpreter `/bin/sh' is a
> > ! symbolic link to a POSIX compatible shell. Since the POSIX
> > !
On Sun, May 20, 2001 at 11:36:04AM +0200, Arthur Korn wrote:
> Zack Weinberg schrieb:
> >
> > ! The standard shell interpreter `/bin/sh' is a
> > ! symbolic link to a POSIX compatible shell. Since the POSIX
> > ! standard for shells le
Currently the only requirements on the shell interpreter /bin/sh are
that it should adhere to the relevant POSIX standard, and that "echo
-n" should not produce a newline. Unfortunately, POSIX leaves a large
number of shell features unspecified. In most of these cases there is
general agreement a
[EMAIL PROTECTED] (Miquel van Smoorenburg) wrote:
>Zack Weinberg <[EMAIL PROTECTED]> wrote:
>>
>>Joel Klecker wrote:
>>>The main problem is that 2.0 kernels do not support sigaltstack(),
>>>this causes such things as m4 to fail when run on a Linux 2.0 syst
Joel Klecker wrote:
>At 19:15 -0400 1999-05-09, Michael Stone wrote:
>>On Sun, May 09, 1999 at 04:03:01PM -0700, Guy Maor wrote:
>>> Because it requires glibc 2.1 and kernel 2.2.
>>
>>Which reminds me, we should probably make it clear that 2.0 kernels will
>>not work properly with potato if we do
18 matches
Mail list logo
