On Mon, Dec 19, 2005 at 07:06:34PM -0500, Joey Hess wrote:
> A few places were identified where vim's defaults are particularly
> umcomfortable to people who expect a standard vi, these include
> autoindent being defaulted to on in the system wide vimrc, and
> nocompatible being turned on there als
On Mon, Dec 19, 2005 at 07:00:53PM -0500, Joey Hess wrote:
> > The vimtutor content is not available if vim-runtime is not installed,
> > and it wont be in the base system ('vim-runtime' is the huge 13 Mb
> > monster package).
> In that case perhaps vimtutor should move from vim-common to
> vim-run
On Mon, Dec 19, 2005 at 12:23:00PM +0100, Thomas Hood wrote:
> Steve Langasek wrote:
> > Are there really any init scripts that need to write out data prior
> > to checkroot.sh (the point at which /run would be writeable by
> > default on the rootfs)?
> Well, it would be nice if fsck logs could be
On Tue, Dec 20, 2005 at 12:11:37AM -0500, Glenn Maynard wrote:
> > Yeah; vi not behaving like vi by default seems like a showstopper.
> "Can't make vim act like vi" might be a showstopper. "The default
> configuration makes vim not act like vi" isn't a showstopper--it's
> trivial to change.
Geez,
On Mon, Dec 19, 2005 at 08:45:45PM -0800, Russ Allbery wrote:
> > (TBH, I'd be much happier just making the technical changes necessary to
> > ensure /var is mounted early -- keeps the filesystem sane, and it's just
> > a simple matter of programming, rather than arguing over what's ugly.
> Yeah, I
On Tue, Dec 20, 2005 at 01:35:08AM +0100, Gabor Gombas wrote:
> On Mon, Dec 19, 2005 at 03:33:35PM -0800, John H. Robinson, IV wrote:
>
> > One of the first things I do on any debian install is to install vim,
> > and set that to be a far higher priority for editor than anything else
> > imaginabl
On Tue, Dec 20, 2005 at 02:37:59PM +1000, Anthony Towns wrote:
> On Mon, Dec 19, 2005 at 10:58:02PM -0500, Glenn Maynard wrote:
> > > TBH, I think these are showstoppers. Otherwise, as long as the space issue
> > > is fixed as you say it is, sounds fine.
> > I'm confused. A simple configuration ch
On Mon, Dec 19, 2005 at 10:58:02PM -0500, Glenn Maynard wrote:
> > TBH, I think these are showstoppers. Otherwise, as long as the space issue
> > is fixed as you say it is, sounds fine.
> I'm confused. A simple configuration change is a showstopper?
Yeah; vi not behaving like vi by default seem
Anthony Towns writes:
> There aren't any technical differences between the first two options.
I agree with that.
> Each of the solutions has a degree of ugliness -- in the first case,
> the ugliness is in violating the "no new directories in /" rule and
> making /run/ifstate seem more important
On Mon, Dec 19, 2005 at 11:41:26AM -0800, Russ Allbery wrote:
> Thomas Hood <[EMAIL PROTECTED]> writes:
> > Any other defenders of /lib/run? Of /run?
> /run makes much more sense to me. /lib/run just seems unbearably ugly,
> not to mention that it would be kind of nice to have a read-only /lib be
On Sun, Dec 18, 2005 at 01:11:32PM -0800, Russ Allbery wrote:
> (Of course, nvi isn't exactly vi either, but it's a lot closer.)
>
> This isn't really new information. I guess I'm just speaking up to
> represent those people who do indeed care about tighter compatibility to
> the original vi than
On Tue, Dec 20, 2005 at 11:42:35AM +1000, Anthony Towns wrote:
> On Mon, Dec 19, 2005 at 07:06:34PM -0500, Joey Hess wrote:
> > A few places were identified where vim's defaults are particularly
> > umcomfortable to people who expect a standard vi, these include
> > autoindent being defaulted to on
[Thomas Hood]
> Any other defenders of /lib/run? Of /run?
/etc/run. mtab and resolv.conf and the lvm1 state files and so forth
always lived in /etc before, so there's continuity.
signature.asc
Description: Digital signature
On Mon, Dec 19, 2005 at 07:06:34PM -0500, Joey Hess wrote:
> A few places were identified where vim's defaults are particularly
> umcomfortable to people who expect a standard vi, these include
> autoindent being defaulted to on in the system wide vimrc, and
> nocompatible being turned on there als
On Mon, Dec 19, 2005 at 08:12:37PM +0100, Thomas Hood wrote:
> Any other defenders of /lib/run? Of /run?
Heh. You know, you could've just said "Yes, my heart is set on /run"
right at the start and saved us all a lot of trouble...
Cheers,
aj
signature.asc
Description: Digital signature
On Tue, Dec 20, 2005 at 01:32:41AM +0100, Gabor Gombas wrote:
> On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote:
> > Putting R in / spoils the otherwise read-only character of that
> > directory. *shrug*
> No, it's not. Mounting something over a top-level subdirectory does not
> requi
On Mon, Dec 19, 2005 at 11:41:26AM -0800, Russ Allbery wrote:
> Perhaps this is a bad idea (or perhaps this is even how it's already
> done), but given the very limited number of things that would have to use
> /run, would it be possible to write them all to use /var/run if it's
> available and on
On Mon, Dec 19, 2005 at 03:33:35PM -0800, John H. Robinson, IV wrote:
> One of the first things I do on any debian install is to install vim,
> and set that to be a far higher priority for editor than anything else
> imaginable.
Same here. That's why I do not care what the default editor in base
On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote:
> Putting R in / spoils the otherwise read-only character of that
> directory. *shrug*
No, it's not. Mounting something over a top-level subdirectory does not
require / to be writeable.
> That is, pretty much everything that runs as
On Mon, Dec 19, 2005 at 09:11:42PM +0100, Marco d'Itri wrote:
> The real lesson in this is that object names should be choosed
> carefully.
Exactly. Therefore any object not created by shm_open() should not use
the /dev/shm/ path prefix. Glad you finally agree :-)
Gabor
--
---
Joey Hess wrote:
> Stefano suggested that vim-tiny could replace nvi and become part of
> base, and I think it's a good idea.
I would personally vote for vim-tiny over nvi. nvi may be bug-for-bug
compatible with vi, but I don't want bugs in my editor. I find vim to be
a more user-friendly vi-like
Summarising the thread so far, the issue does not seem to be very
contentious, there are some who like nvi but noone who feels very
strongly that it needs to remain the editor in base.
A few places were identified where vim's defaults are particularly
umcomfortable to people who expect a standard
On Mon, Dec 19, 2005 at 09:12:22PM +0100, Marco d'Itri wrote:
> There is no reason why it should be moved.
But there is a reason why its current abusers should get fixed to use
something else. Just think what happens if an app does something like
shm_open("/network", ...), or even better, shm_ope
Stefano Zacchiroli wrote:
> The vimtutor content is not available if vim-runtime is not installed,
> and it wont be in the base system ('vim-runtime' is the huge 13 Mb
> monster package).
In that case perhaps vimtutor should move from vim-common to
vim-runtime? Although you've probably considered
On Mon, Dec 19, 2005 at 07:40:24PM +0100, Bernd Eckenfels wrote:
> Yes, we are talking about a few pages in swap space at most.
It's 55 pages (220k) on this machine (368k on ext3). And it's a simple
desktop with not much running state.
> And I am not sure if "not used" is valid here, since symli
On Tuesday 20 December 2005 00:29, Gabor Gombas wrote:
> fsck logs are OK, /var/log/dmesg.0 is root:root instead of root:adm.
> bottlogd is still broken.
Did you move bootlogd init script before udev? That should at least get
you a log and allow you to check the rest.
pgp8wK5rjLGkN.pgp
Descript
Matthew Palmer wrote:
> On Mon, Dec 19, 2005 at 11:54:26PM +0200, Radu Spineanu wrote:
>
> Considering the upstream author, have you discussed your plans to upload
> this with Steve?
I've been coordinating everything with Steve. He will also comaintain
this package.
Radu
--
To UNSUBSCRIBE, em
On Monday 19 December 2005 17:11, Marco d'Itri wrote:
> The real lesson in this is that object names should be choosed
> carefully.
AFAIK, the namespace is part of the object name, an thus should be chosen
carefully too.
--
Felipe Sateler
pgpHMa4cCTsTl.pgp
Description: PGP signature
On Sat, Dec 17, 2005 at 11:49:55PM +0100, Thomas Hood wrote:
> A new version of sysvinit (binary packages sysvinit, sysv-rc and initscripts)
> has
> just been uploaded to experimental.
Just tried it on amd64.
> After rebooting you should have logs of the fsck runs in
> /var/log/fsck/check{root,
On Mon, Dec 19, 2005 at 11:54:26PM +0200, Radu Spineanu wrote:
> * Package name: xen-debiantools
> Version : 0.2
> Upstream Author : Steve Kemp <[EMAIL PROTECTED]>
Considering the upstream author, have you discussed your plans to upload
this with Steve?
- Matt
signature.asc
Desc
* Josselin Mouette ([EMAIL PROTECTED]) wrote:
> Le lundi 19 décembre 2005 à 20:12 +0100, Thomas Hood a écrit :
> > Any other defenders of /lib/run? Of /run?
>
> Please go ahead with /run. This has to the right place as no other
> proposed location makes sense.
I agree, it's no fun creating new t
Hey, can you send me dueling banjos sheet music for the viola, I met someone and they play the viola and they love it.
Regards,
Martin
Package: wnpp
Severity: wishlist
Owner: Radu Spineanu <[EMAIL PROTECTED]>
* Package name: xen-debiantools
Version : 0.2
Upstream Author : Steve Kemp <[EMAIL PROTECTED]>
* URL : http://www.steve.org.uk/Software/xen-tools/
* License : Perl: GPL/Artistic
Descrip
On Dec 19, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > > > That tmpfs will not be removed from the kernel just because shm_open()
> > > > will switch to a different implementation.
> > > Of course. But if that happened there would be no reason to keep
> > > /dev/shm mounted; you would need to
On Dec 19, Thomas Hood <[EMAIL PROTECTED]> wrote:
> Any other defenders of /lib/run? Of /run?
If it really needs to exist, something of which I am not persuaded, then
at least it should not go in /.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> That's correct, but you should still not be using the namespace for
> non-SHM activities.
Because?
--
ciao,
Marco
signature.asc
Description: Digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Hood <[EMAIL PROTECTED]> writes:
> Any other defenders of /lib/run? Of /run?
I prefer /run. It certainly doesn't belong in /lib (IMO).
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Hi,
Josselin Mouette wrote:
[Permissions on device nodes]
Currently, there are two ways of handling this situation:
- The Debian way, where this is controlled by Unix groups, and where the
default user belongs to these groups. Your message seems to imply the
opposite, and I welcome you to inst
Package: wnpp
Severity: wishlist
Owner: Niko Tyni <[EMAIL PROTECTED]>
* Package name: libfile-path-expand-perl
Version : 1.01
Upstream Author : Richard Clamp <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~rclamp/File-Path-Expand-1.01/
* License : GPL/Artist
Le lundi 19 décembre 2005 à 20:12 +0100, Thomas Hood a écrit :
> Any other defenders of /lib/run? Of /run?
Please go ahead with /run. This has to the right place as no other
proposed location makes sense.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'
Le dimanche 18 décembre 2005 à 18:54 +, Andrew M.A. Cater a écrit :
> Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
> /AIX admins who may have got used to nvi? Unfortunately, the vi/vim
> flamewars are not yet concluded :(
Erm, wouldn't the fact nvi is almost as crap
Le lundi 19 décembre 2005 à 18:45 +0100, Marco d'Itri a écrit :
> On Dec 19, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
>
> > > Debian guarantees that it exists on debian systems.
> > No, we don't. We guarantee it exists on Sarge. It may or may not exist in
> > Etch and Sid in the fu
Le lundi 19 décembre 2005 à 21:12 +0100, Marco d'Itri a écrit :
> On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
>
> > > That tmpfs will not be removed from the kernel just because shm_open()
> > > will switch to a different implementation.
> > Of course. But if that happened there would be no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
>
>> With this example, it's trivial to trigger namespace conflicts and
>> break shm_open(). "mkdir /dev/shm/foobar", for example, or create a
>> symbolic li
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > That tmpfs will not be removed from the kernel just because shm_open()
> > will switch to a different implementation.
> Of course. But if that happened there would be no reason to keep
> /dev/shm mounted; you would need to use an alternate loc
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> With this example, it's trivial to trigger namespace conflicts and
> break shm_open(). "mkdir /dev/shm/foobar", for example, or create a
> symbolic link. These fail outright. If a regular file was opened, it
And so would two programs using the
In article <[EMAIL PROTECTED]> you wrote:
> /var/run/screen, which aren't guaranteed to stay small at all. On one
> particular samba fileserver I checked, /var/run is less than two orders of
> magnitude smaller than /usr/lib. :)
if this is a busy fileserver, it is mapped to memory anyway.
Gruss
Thomas Hood <[EMAIL PROTECTED]> writes:
> Any other defenders of /lib/run? Of /run?
/run makes much more sense to me. /lib/run just seems unbearably ugly,
not to mention that it would be kind of nice to have a read-only /lib be a
possibility for a variety of reasons (yes, I know, module depende
Please remove me from callwave because I didn't sign up for
it.
Any other defenders of /lib/run? Of /run?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 19, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
>
>> > > 1. It exists only on Linux-based OS's
>> > > 2. There is no gaurentee that it will continue to be there at all
>> > > 3. There is no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
>
>> >> If in the future glibc decides to choose some other implementation
>> >> for shm_open(), then it has no reason to stay.
>> > But it has no reason to g
On Mon, Dec 19, 2005 at 01:04:23PM +0100, Gabor Gombas wrote:
> Quite the contrary. tmpfs needs vm space even if nobody needs the data
Yes, we are talking about a few pages in swap space at most.
And I am not sure if "not used" is valid here, since symlinks and
sockets would be in memory even if
To ensure your Hunter Service is delivered to your inbox, be sure to add [EMAIL
PROTECTED] to your email address book or contact list.
Travellers Dream Hunter (Xmas Sale Coupon: SAMX-74P3-ER)
How can I save bucks, moneys, $$, for my dream trip?
When will be the best deal, the cheapest price,
On Mon, Dec 19, 2005 at 05:48:45PM +0100, Thomas Hood wrote:
> > Note the definition for /usr/lib is "Libraries for programming and
> > packages" and "/usr/lib includes object files, libraries, and internal
> > binaries that are not intended to be executed directly by users or
> > shell scripts." a
On Dec 19, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > Debian guarantees that it exists on debian systems.
> No, we don't. We guarantee it exists on Sarge. It may or may not exist in
> Etch and Sid in the future.
If we use it then it's reasonable to assume that we would not sudden
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> >> If in the future glibc decides to choose some other implementation
> >> for shm_open(), then it has no reason to stay.
> > But it has no reason to go away either, since there are many other uses
> > too for a tmpfs.
> There are many uses for a
On Mon, Dec 19, 2005 at 03:03:54PM +0100, Jeroen van Wolffelaar wrote:
> > 2) (if yes) do we need to remove MPEG decoding stuff?
> Unsure, as I explained above and in earlier mails. It's a very difficult
> question, and we don't have an answer on it yet.
It would be really helpful if someone would
On Mon, 19 Dec 2005, Marco d'Itri wrote:
> On Dec 19, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > If in the future glibc decides to choose some other implementation
> > for shm_open(), then it has no reason to stay.
> But it has no reason to go away either, since there are many other uses
> too for
Anthony Towns wrote:
> Developers have been known not to be completely familiar with policy,
> but it's admins and upstream programmers that I'm particularly
> thinking of.
I don't see any problems arising from rampant /run use by _admins_.
They are always free to do what they want with their syst
On Sun, 18 Dec 2005, Marco d'Itri wrote:
> Debian guarantees that it exists on debian systems.
No, we don't. We guarantee it exists on Sarge. It may or may not exist in
Etch and Sid in the future.
> > 1. It exists only on Linux-based OS's
> > 2. There is no gaurentee that it will continue to be
On Sun, 18 Dec 2005, Marco d'Itri wrote:
> Reality check: packages have been using it for a long time and the world
> has not fallen yet.
Debian-style reality check: if it is broken, we better fix it before it does
any damage.
Since we are talking namespace violation, I'd say we better fix this f
Anthony Towns:
> Sorry, I was paraphrasing above. The actual definition is "Essential
> shared libraries and kernel modules", and "The /lib directory contains
> those shared library images needed to boot the system and run the
> commands in the root filesystem, ie. by binaries in /bin and /sbin."
>
Package: wnpp
Severity: wishlist
Owner: Radu Corlan <[EMAIL PROTECTED]>
* Package name: gcx
Version : 0.9.8
Upstream Author : Radu Corlan <[EMAIL PROTECTED]>
* URL : http://gcx.sf.net/
* License : GPL
Description : gcx -- astronomical image processing and
On Mon, Dec 19, 2005 at 09:57:48AM +0100, Thomas Hood wrote:
> Anthony Towns wrote:
> > A possible concern is people seeing /run and thinking "ah, there's a
> > directory I can use for stuff", and having it be used instead of
> > /var/run or $TMPDIR or /var/lib or /var/cache for things it's not
> >
ma, 2005-12-19 kello 10:21 -0500, Theodore Ts'o kirjoitti:
> Specifically, what I would propose is /etc/localtime.conf contain
> something like "US/Eastern", and let /etc/zoneinfo be a copy of the
> file /usr/share/zoneinfo/`cat /etc/zoneinfo`.
>
> Does anyone have any objections with this proposa
On Sun, Dec 18, 2005 at 10:37:06PM -0500, Anthony DeRobertis wrote:
> Theodore Ts'o wrote:
> > (for example if the US Congress
> > changes the definition of daylight savings time),
>
> That should be "when", not "if", unfortunately. AFAIK, they've already
> done it.
>
> On my system, /bin, /etc,
application
Reply-To:
Package: wnpp
Severity: wishlist
Owner: Radu Corlan <[EMAIL PROTECTED]>
* Package name: gcx
Version : 0.9.8
Upstream Author : Radu Corlan <[EMAIL PROTECTED]>
* URL : http://gcx.sf.net/
* License : GPL
Description : astronomical i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 19, Gabor Gombas <[EMAIL PROTECTED]> wrote:
>
>> If in the future glibc decides to choose some other implementation
>> for shm_open(), then it has no reason to stay.
> But it has no reason to go away e
Package: wnpp
Severity: wishlist
Owner: Jonas Genannt <[EMAIL PROTECTED]>
* Package name: libalgorithm-dependency-perl
Version : 1.101
Upstream Author : Adam Kennedy <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~adamk/
* License : GPL
Description :
On Mon, Dec 19, 2005 at 10:22:33AM +0100, A Mennucc wrote:
> Dear Jeroen and everybody,
>
> here attached is an email I sent in September.
>
> Yes, I did ask to ftp-masters clarifications about your proposal in
> http://lists.debian.org/debian-devel/2005/04/msg00997.html
> and never received a re
On Mon, Dec 19, 2005 at 09:31:28AM +0100, Thomas Hood wrote:
> Anthony Towns:
> > Claiming support from the FHS guys on the basis of a conversation with
> > Chris doesn't seem appropriate; anymore than "-policy support" would be an
> > appropriate claim if Manoj had said it looked okay.
> Agreed.
On Mon, Dec 19, 2005 at 09:18:29AM +0100, Petter Reinholdtsen wrote:
> [Anthony Towns]
> > I note the FHS's limited definition of /lib (essential libraries and
> > kernel modules) is already incorrect for /lib/udev,
> > /lib/lsb/init-functions, /lib/linux-sound-base, /lib/terminfo,
> > /lib/alsa, /
Hi all,
When will be gfs-tools and redhat free clustering tools included
under etch?? Exists some roadmap??
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: wnpp
Severity: wishlist
Owner: Ricardo Mones <[EMAIL PROTECTED]>
* Package name: sylpheed-claws-gtk2-feeds-reader
Version : 0.3
Upstream Author : Andrej Kacian <[EMAIL PROTECTED]>
* URL : http://ticho.yweb.sk/rssyl/
* License : GPL
Description :
On Dec 19, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> If in the future glibc decides to choose some other implementation
> for shm_open(), then it has no reason to stay.
But it has no reason to go away either, since there are many other uses
too for a tmpfs.
> > > /run doesn't especially /need/ to
On Mon, Dec 19, 2005 at 01:14:45PM +0100, Marco d'Itri wrote:
> > But what about the future, and what about it being specifically for
> > POSIX-SHM?
> Tell us... Do you have reasons to believe that we will be forced to
> remove /dev/shm/ in the future?
If in the future glibc decides to choose som
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Thomas Hood) writes:
> So, has anyone tested the new packages?
Yes. It works just fine on my system (powerpc, current unstable), and
I'll do some more testing later. I also uploaded the powerpc packages
to experimental, if anyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
[no need to CC me; I'm subscribed to the list]
> On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote:
>
>> > Debian guarantees that it exists on debian systems.
>> But what about the future, and what about it bei
Eduardo Silva wrote:
As a lurker to debian-devel, I would like to point to
all a deficiency in the current KDE way of naming
menus, and hope that if Debian menu goes this way, it
should improve on it.
There is currently a discussion about improving Debian Menu at
debian-policy mailing list, b
On Dec 19, Anthony Towns wrote:
> I note the FHS's limited definition of /lib (essential
> libraries and kernel modules) is already incorrect for /lib/udev,
> /lib/lsb/init-functions, /lib/linux-sound-base, /lib/terminfo, /lib/alsa,
> /lib/alsa-utils, /lib/discover and /lib/init. Especially given
On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > Debian guarantees that it exists on debian systems.
> But what about the future, and what about it being specifically for
> POSIX-SHM?
Tell us... Do you have reasons to believe that we will be forced to
remove /dev/shm/ in the future?
> /run d
On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
> tmpfs stores run ressources in vm more efficiently (since they are otherwise
> in th buffercache and the filesystem).
Quite the contrary. tmpfs needs vm space even if nobody needs the data
(thus, it could be evicted from the page
So, has anyone tested the new packages?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Steve Langasek wrote:
> Are there really any init scripts that need to write out data prior
> to checkroot.sh (the point at which /run would be writeable by
> default on the rootfs)?
Well, it would be nice if fsck logs could be stored in /run until
/var/log/ is available for writing. It would be
On Sat, Dec 17, 2005 at 10:13:35PM -0600, Peter Samuelson wrote:
> [Steve Langasek]
> > Given the reality of /lib, is there any need for a separate /usr/lib?
> > The principle is the same: /lib is used only for the minimal system
> > required for booting, and everything else should go in /usr/lib
Anthony Towns wrote:
> A possible concern is people seeing /run and thinking "ah, there's a
> directory I can use for stuff", and having it be used instead of
> /var/run or $TMPDIR or /var/lib or /var/cache for things it's not
> appropriate for.
I think that everyone agrees that /run is to be use
On Sun, Dec 18, 2005 at 01:26:45PM +0100, [EMAIL PROTECTED] wrote:
> Steve Langasek wrote:
> > (We also shouldn't need to specify a policy for mounting any
> > particular filesystem on /run, but merely mount /run early iff it's
> > present in /etc/fstab and leave the implementation details to the
actually, there was a response in Aug 2004, as in attachment
A Mennucc wrote:
> The oldest upload of 'mplayer' that I still find in my harddisk was
> 'Wed Jul 23 10:44:54 2003' (see attachment)
>
> So 'mplayer' has been waiting in NEW queue for some response from
> ftp-masters for 876 days (a
On Mon, Dec 19, 2005 at 09:13:01AM +0100, Marco d'Itri wrote:
> On Dec 19, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Is there some reason we should be unable to provide a smooth upgrade path
> > for users of sarge? Having your network devices scramble themselves on
> > reboot is a Big Deal, w
Dear Jeroen and everybody,
here attached is an email I sent in September.
Yes, I did ask to ftp-masters clarifications about your proposal in
http://lists.debian.org/debian-devel/2005/04/msg00997.html
and never received a reply.
Jeroen van Wolffelaar wrote:
> While you indeed haven't got a later
On Sat, Dec 17, 2005 at 10:58:07AM +0100, Wouter Verhelst wrote:
> On Thu, Dec 15, 2005 at 04:44:28PM +0100, Jakub Nadolny wrote:
> > Hi,
> >
> > I am new to the list and would like to ask you what can I do in
> > following subject.
> > There is a package called 'display-dhammapada'. It has not be
Javier Fernández-Sanguino Peña wrote:
> On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote:
> I *guess* mplayer could do likewise.
>
MPlayer was once very picky regarding the versions of ffmpeg that it
does compile with. Moreover MPlayer want to link all core libraries
together (
On Mon, 19 Dec 2005, Marco d'Itri wrote:
On Dec 19, Steve Langasek <[EMAIL PROTECTED]> wrote:
Is there some reason we should be unable to provide a smooth upgrade path
for users of sarge? Having your network devices scramble themselves on
reboot is a Big Deal, whether or not it's in the releas
On Mon, 19 Dec 2005, Bernd Eckenfels wrote:
In article <[EMAIL PROTECTED]> you wrote:
use nameif.
This has been suggested before but AIUI nameif has problems/limitations
renaming eth0.
Well, you just cant use existing names (this could be fixed, however i am
not sure if this is needed)
It
On Mon, Dec 19, 2005 at 09:18:29AM +0100, Petter Reinholdtsen wrote:
> I did not look closely at the others, but /lib/lsb/init-functions is a
> library of shell functions, and /lib/terminfo/ is a library of
> terminal definitions. Both are essential for the function of several
> systems in Debian.
On 12/19/05, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 08:27:36PM +0100, Florian Weimer wrote:
> > * Steinar H. Gunderson:
> >
> > > My comments are about the same as on IRC:
> > >
> > > - Disk space is cheap, bandwidth is cheap.
> >
> > Depends. Decent IP service cost
Anthony Towns:
> Mmm; privately asking someone who works on the FHS is a different thing
> to asking on the FHS lists, or actually talking to our users.
True.
> Claiming support from the FHS guys on the basis of a conversation with
> Chris doesn't seem appropriate; anymore than "-policy support
On Mon, Dec 19, 2005 at 06:40:53AM +0100, Bernd Eckenfels wrote:
> We could enhance the ifup interfaces file format to use MACs as interface
> identifiers and have an additional labeling statement. (i know it can be
> done with other means right now but I think it sould be introduced as first
> cla
sorry, I was remembering incorrectly the dates
(and by no means meaning that I want the release to be 3 months later
than what Steve announced)
a.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 102 matches
Mail list logo