default ext3 options (was: Re: Debian Installer etch RC1 released)

On 14.11.2006 05:19 schrieb Frans Pop: > * The installer will now create ext3 partitions with important options > like resize_inode and dir_index enabled by default; the first means > that on-line resizing of ext3 partitions is supported. And since some users might be happily running Deb

Re: default ext3 options (was: Re: Debian Installer etch RC1 released)

On Tuesday 14 November 2006 09:44, Bastian Venthur wrote: > And where can I get the full list of ext3-options which are enabled now > by default? Enabled by default when creating a new file system: $ less /etc/mke2fs.conf Cheers, FJP pgphSiVM6R856.pgp Description: PGP signature

Re: Bug#397715: ITP: dudki -- a process maintenance daemon

Hi, > Can you briefly explain the differences or advantages over monit? I think, dudki is just an alternative to monit. But it has less features. Its task is just to check if processes it had to survey are running, and if not it will try to reload them and report actions by mail. M. -- mai

Bug#398528: ITP: upstream -- Tools to send log and data to support personnel

Package: wnpp Severity: wishlist Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]> * Package name: upstream Version : 0.1.0 Upstream Author : Mahangu Weerasinghe <[EMAIL PROTECTED]> Ryan Zeigler <[EMAIL PROTECTED]> Joel Pan <[EMAIL PROTECTED

Re: default ext3 options

On Tue, 14 Nov 2006 13:10:06 +0100, Petter Reinholdtsen wrote: > [Bastian Venthur] >> And since some users might be happily running Debian for years without >> needing the Debian installer -- what can we do to let those users >> benefit from enhancements a new Debian Installer brings? > > As far a

Re: Bug#398601: ITP: retty -- lets you attach processes running on other terminals

On Tue, Nov 14, 2006 at 02:33:14PM +0100, Christoph Berg wrote: > Programming Lang: C and i386 asm (it doesn't work on amd64) > Description : lets you attach processes running on other terminals To anyone else who was curious about this: What it seems to be doing is injecting code onto th

Re: default ext3 options

On Tuesday 14 November 2006 13:35, Sam Morris wrote: > filesystem. However, to get the benefit of the indexing for > already-created directories, e2fsck -D should be run after dir_index > has been added; therefore it's probably best to just document the > procedure in the release notes. If you'd r

Re: default ext3 options

* Sam Morris ([EMAIL PROTECTED]) [061114 13:36]: > , > it should be perfectly safe to add dir_index to an existing filesystem. > However, to get the benefit of the indexing for already-created > directories, e2fsck -D should

Re: default ext3 options

[Bastian Venthur] > On 14.11.2006 05:19 schrieb Frans Pop: >> * The installer will now create ext3 partitions with important options >> like resize_inode and dir_index enabled by default; the first means >> that on-line resizing of ext3 partitions is supported. > > And since some users m

Bug#398601: ITP: retty -- lets you attach processes running on other terminals

Package: wnpp Severity: wishlist Owner: Christoph Berg <[EMAIL PROTECTED]> * Package name: retty Version : 1.0 Upstream Author : Petr Baudis, Jan Sembera * URL : http://pasky.or.cz/~pasky/dev/retty/ * License : GPL Programming Lang: C and i386 asm (it doesn't

Re: Proposed new POSIX sh policy

On Nov 14, David Weinehall <[EMAIL PROTECTED]> wrote: > > busybox? > Such a requirement would at least be wonderful for us embedded developers... But hardly practical, IIRC there are some commonly used shell features supported by dash but not busybox. -- ciao, Marco signature.asc Description:

Something wrong with Console-data package

Hi, I'm Brazilian and I'm facing some problems with console-date (I think).When I use the Etch install CD to install on a new machine, everything works fine but the keyboard layout doesn't, I can't use the / key and the 'dot' in numeric pad too. Its just when I'm in terminal, and when I go to X, I

Re: Debian Installer etch RC1 released

* Roberto C. Sanchez ([EMAIL PROTECTED]) [061114 14:58]: > On Tue, Nov 14, 2006 at 05:19:13AM +0100, Frans Pop wrote: > > > > * The 2.6.17 kernel should support installing from most CD-ROM/DVD > > drives in systems with a SATA controller. However, there are known > > issues in 2.6.17 wit

Re: Debian Installer etch RC1 released

On Tue, Nov 14, 2006 at 08:58:00AM -0500, Roberto C. Sanchez wrote: > I understand that the line must be drawn somewhere. However, I am > concerned about Etch shipping with a 2.6.17 kernel because of Xen. Please read further down, to where the next rc is expected to include 2.6.18. -- Daniel Ja

Re: Debian Installer etch RC1 released

On Tue, Nov 14, 2006 at 09:01:48AM -0500, Daniel Jacobowitz wrote: > On Tue, Nov 14, 2006 at 08:58:00AM -0500, Roberto C. Sanchez wrote: > > I understand that the line must be drawn somewhere. However, I am > > concerned about Etch shipping with a 2.6.17 kernel because of Xen. > > Please read fur

Re: Debian Installer etch RC1 released

On Tuesday 14 November 2006 14:58, Roberto C. Sanchez wrote: > I understand that the line must be drawn somewhere. However, I am > concerned about Etch shipping with a 2.6.17 kernel because of Xen. > AIUI, Xen has issues with 2.6.17 kernels (at least those available from > backports). I run some

Re: Debian Installer etch RC1 released

On Tue, Nov 14, 2006 at 05:19:13AM +0100, Frans Pop wrote: > > * The 2.6.17 kernel should support installing from most CD-ROM/DVD > drives in systems with a SATA controller. However, there are known > issues in 2.6.17 with some controllers that have been fixed in 2.6.18. > I understand

Re: Proposed new POSIX sh policy

On Sun, 12 Nov 2006 14:44:41 +0100, Gabor Gombas <[EMAIL PROTECTED]> said: > On Sat, Nov 11, 2006 at 11:10:52PM -0600, Manoj Srivastava wrote: >> It would, at one fell swoop, solve the problem Thomas hinted at >> before, about our specification allowing shell to randomly shadow >> other commands

Re: Proposed new POSIX sh policy

On Sat, 11 Nov 2006 23:10:52 -0600, Manoj Srivastava <[EMAIL PROTECTED]> said: > OK. How about we again step back, and examine the rationale > behind this, and the use cases that we intended to support? Look, > bash is essential, and ships as /bin/sh; nothing is required as far > as s

Re: default ext3 options

I demand that Petter Reinholdtsen may or may not have written... [snip] > As far as I know, neither the resize_inode nore the dir_index ext3 option > can be securely added after the file system is created. I've done the latter, though while the file system was unmounted, and I ran fsck -D on it a

Re: default ext3 options

* Darren Salt ([EMAIL PROTECTED]) [061114 19:54]: > I demand that Petter Reinholdtsen may or may not have written... > > [snip] > > As far as I know, neither the resize_inode nore the dir_index ext3 option > > can be securely added after the file system is created. > > I've done the latter, thoug

Re: XS-Vcs-field

On Mon, 13 Nov 2006 17:31:32 +0100, Stefano Zacchiroli <[EMAIL PROTECTED]> said: > On dom, 2006-11-12 at 14:02 -0600, Manoj Srivastava wrote: >> I suggest that we specify tow headers: and SCM specific header, >> XS-Vcs- where name is one keyword from a specified list (bzr, >> cvs, svn, darcs, gi

Re: Proposed new POSIX sh policy

On Nov 14, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > So, what features do we settle on? we can either standardize > on, well, a standard: POSIX/SUSv3, -- but there are things we use > that come from XSI. I guess we could standardize on SUSv3 +XSI > shells. Would still make local il

Re: Something wrong with Console-data package

Quoting eduardo.oliva barruzi ([EMAIL PROTECTED]): > Hi, I'm Brazilian and I'm facing some problems with console-date (I think). > > When I use the Etch install CD to install on a new machine, everything works > fine but the keyboard layout doesn't, I can't use the / key and the 'dot' in > numeric

Re: default ext3 options

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/06 12:28, Darren Salt wrote: > I demand that Petter Reinholdtsen may or may not have written... > > [snip] >> As far as I know, neither the resize_inode nore the dir_index ext3 option >> can be securely added after the file system is created.

Re: Proposed new POSIX sh policy

On Tue, Nov 14, 2006 at 12:03:06PM -0600, Manoj Srivastava wrote: > What problem exactly are you trying to solve? We have a > working OS now, and have had one for over a decade; and we have been > using bash all along. Reading what you say leads one to imagine all > kinds of dire prole

As imprecision by scale

This is a multi-part message in MIME format. A reference to the Trojan Horse Diseases come on horseback, but steal away on foot. Alternative: Who will act as gatekeeper to the gatekeepers? Doubt is the beginning, not the end, of wisdom. Behind every good man, is a woman -- To UNSUBSCRIBE, email

Re: Proposed new POSIX sh policy

On Tue, Nov 14, 2006 at 05:11:27PM +0100, Marco d'Itri wrote: > On Nov 14, David Weinehall <[EMAIL PROTECTED]> wrote: > > > > busybox? > > Such a requirement would at least be wonderful for us embedded developers... > But hardly practical, IIRC there are some commonly used shell features > support

Re: Proposed new POSIX sh policy

Manoj Srivastava <[EMAIL PROTECTED]> writes: > So, rather than specifying what /bin/sh is supposed to be, > with all the issues about shadowing binaries etc, we start with > specifying what the maintainer scripts must comply with. I'm not as worried about maintainer scripts as I am abou

Re: Proposed new POSIX sh policy

On Tue, 2006-11-14 at 17:58 -0800, Russ Allbery wrote: > This is basically why I think the best approach is to standardize on SUSv3 > plus test -a/-o (with a more complete specification) and local. Our > experience with previous rounds of this discussion is that everyone seems > to be able to agre

Re: Proposed new POSIX sh policy

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > If you are proposing that anything installed as /bin/sh *must* support > feature such-and-such *if* it has a test builtin, then I'm ok with that. Any shell that supports being installed as /bin/sh must currently provide a test builtin to support a

Re: Proposed new POSIX sh policy

On Tue November 14 2006 19:06, Thomas Bushnell BSG wrote: > I refused to stop using test -a in my packages as well, and refused > to declare #!/bin/bash. > > Here's why. > > test -a is not a "bashism". > > It's a feature of the Debian test program. It happens that bash > declares a builtin, but th

Re: Proposed new POSIX sh policy

On Tue, Nov 14, 2006 at 08:03:54PM +0100, Marco d'Itri wrote: > On Nov 14, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > > So, what features do we settle on? we can either standardize > > on, well, a standard: POSIX/SUSv3, -- but there are things we use > > that come from XSI. I guess

Re: Proposed new POSIX sh policy

On Tue, Nov 14, 2006 at 12:36:04PM -0600, Manoj Srivastava wrote: [snip] > So, what features do we settle on? we can either standardize > on, well, a standard: POSIX/SUSv3, -- but there are things we use > that come from XSI. I guess we could standardize on SUSv3 +XSI > shells. Would st

Re: Proposed new POSIX sh policy

On Fri, Nov 10, 2006 at 12:01:10AM -0600, Manoj Srivastava wrote: > Hi, > > Firstly, should we be pointing to the SuS instead of POSIX > (there is work going on a new version of the SUS), since it is open, > and readily available on th 'net, and people can readily see it (as > opposed t

Re: Proposed new POSIX sh policy

David Weinehall <[EMAIL PROTECTED]> writes: > On Fri, Nov 10, 2006 at 12:01:10AM -0600, Manoj Srivastava wrote: >> Secondly, why should we explicity carve out an exception for >> test -a and -o, rather than saying that the XSI extensions need be >> supported? The X/Open System Interface

Re: Proposed new POSIX sh policy

David Weinehall <[EMAIL PROTECTED]> writes: > On Tue, Nov 14, 2006 at 08:03:54PM +0100, Marco d'Itri wrote: >> No, there is no such issue. The issue is that a few people tried to >> remove all use of test -a/-e and local from /bin/sh scripts, > I admit belonging to the group of some people here.

Re: Proposed new POSIX sh policy

On Wed, 2006-11-15 at 02:20 +0100, David Weinehall wrote: > > and failed > > miserably. > > And you belong to the group of people that caused it to fail... I refused to stop using test -a in my packages as well, and refused to declare #!/bin/bash. Here's why. test -a is not a "bashism". It's a

Re: Proposed new POSIX sh policy

> Not in my experience, but I haven't tested for them in particular. On my > system, I see one maintainer script using test -o, none using test -a, and > none using test (). > > I currently see no need to require that test () be supported. I do. Debian test is provided by the coreutils package

Re: Proposed new POSIX sh policy

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > I do. Debian test is provided by the coreutils package. As the man > page says: >( EXPRESSION ) > EXPRESSION is true > And, we have the existing rule in section 10.1 of the policy manual: > "Two different packages must not in

Re: Proposed new POSIX sh policy

On Tue, 2006-11-14 at 18:38 -0800, Russ Allbery wrote: > > "Two different packages must not install programs with different > > functionality but with the same filenames." > > > There does not seem to be any reason to exempt shell builtins from this > > requirement. > > I think there are obvious

Re: Proposed new POSIX sh policy

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > On Tue, 2006-11-14 at 18:38 -0800, Russ Allbery wrote: >> I think there are obvious reasons to exempt shell builtins from this >> requirement, so you're going to have to present more of an argument >> than this. I think this is a very strained rea

Re: Proposed new POSIX sh policy

On Tue, 2006-11-14 at 18:59 -0800, Russ Allbery wrote: > I think this would be a great deal of work for little useful benefit. Why? Surely it would be useful to know what the differences are between various shells. The statement "Posix-compatible" was apparently intended by the authors of that p

Re: Proposed new POSIX sh policy

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > On Tue, 2006-11-14 at 18:59 -0800, Russ Allbery wrote: >> I think this would be a great deal of work for little useful benefit. > Why? Surely it would be useful to know what the differences are between > various shells. I believe that such a doc

Re: Proposed new POSIX sh policy

On Tue, 2006-11-14 at 22:15 -0800, Russ Allbery wrote: > The problem sparking this thread and my initial work on a Policy patch is > not a problem caused by shells with builtins; it is, in fact, not a > technical problem at all in the sense that no user has had their system > broken by the use of

Re: Proposed new POSIX sh policy

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Heck, I'm entirely happy with Manoj's suggestion to drop the whole damn > thing, and simply say "/bin/sh will be bash." Well, I'm not, and neither are a lot of other people judging from this discussion. > No. I'm saying that the existing noticed

Re: Proposed new POSIX sh policy

Zack Weinberg <[EMAIL PROTECTED]> writes: > 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