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 release notes.
This often happens anyway when
[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, /lib/alsa-utils, /lib/discover and /lib/init.
I did not look closely at the
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]
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
class
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 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 costs a few EUR per
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 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, 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 release
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 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 been updated
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 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, whether
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 (at
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
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 used
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.
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
So, has anyone tested the new packages?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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 doesn't
On Dec 19, Anthony Towns aj@azure.humbug.org.au 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
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,
-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 being
-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
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 some
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 be a
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 :
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]
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,
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 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 reply.
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 :
-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 either,
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
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, /lib, and
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 proposal?
I
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
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
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.
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
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
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
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 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 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 an ext3fs,
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 suddenly
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. and /var/lib
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 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
-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 go away either,
-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 guareteee that
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]
Please remove me from callwave because I didn't sign up for
it.
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
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
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 same
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 location.
-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 link. These
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 reason to
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 future.
If
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 crappy
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]
`. `'
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/Artistic
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
-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/
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
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, 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 use an
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
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
* 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
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
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,fs}.
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
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, email
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
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 symlinks
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 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,
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
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
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
--
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 a
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 is
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 only
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
require /
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 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 also,
[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 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 in
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 vim
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 a
Anthony Towns aj@azure.humbug.org.au 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
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 seems
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 change is
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
imaginable.
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 agree
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, I hate
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 stored
1 - 100 of 160 matches
Mail list logo
