Re: Debian Installer team monthly meeting minutes (20051214 meeting)
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 switching between 2.4 and 2.6 kernels, so it's something users have always needed to be aware about. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run
[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 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. So I find at least these within the definitions of the FHS. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch release plan (was Re: congratulations to our ftp-master team)
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]
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
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 citizen - AIUI just like suse does): If, instead of, iface 00:00:C0:A1:E7:CD inet static name lan0 you had iface lan0 mac 00:00:C0:A1:E7:CD address 10.0.0.3 network 10.0.0.0 netmask 255.255.255.0 broadcast 10.0.0.255 gateway 10.0.0.1 up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.0.0.1 || true and a pre-up command (in /etc/network/if-pre-up.d/) that renames the interface with the given mac to lan0 (nameif $IFACE $IF_MAC), the above should work now. As a bonus, ifup lan0 is much more pleasant than ifup 00:00:C0:A1:E7:CD too. Cheers, aj signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
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 would be an appropriate claim if Manoj had said it looked okay. Agreed. Fortunately, I didn't claim that. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
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 gigabyte in most parts of the world. I wish we could get it that cheap for my day job. What we have to pay to get useful bandwidth has more zeros in it. Are you paying 10 $/gb? Where is it that expensive?
Re: /run vs /var/run
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. So I find at least these within the definitions of the FHS. If you reinterpret library in a way that makes every directory a library, sure; /usr/share/doc is a library of documentation, and /home/glenn is a library of my stuff. (The FHS actually says shared library images, though, which is a specific term that clearly excludes shell scripts.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
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 can be trivially worked around by: nameif blah 00:30:4F:04:C1:61 nameif eth0 00:50:BF:91:28:E5 nameif eth1 00:30:4F:04:C1:61 Too bad, nameif is currently unable to use this workaround on its own, need to write this by hand. 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 citizen - AIUI just like suse does): iface 00:00:C0:A1:E7:CD inet static name lan0 address 10.0.0.3 network 10.0.0.0 netmask 255.255.255.0 broadcast 10.0.0.255 gateway 10.0.0.1 up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.0.0.1 || true We could even just change the kernel to asign a name eth, then most likely no new features are needed. This is a WONDERFUL idea! nameif has /etc/mactab which uses a similar concept, however: 1. all data about interfaces should be kept together, instead of being strewn across 92587239839 files. Having the ifname-MAC mapping in the same place as ifname-IP and ifname-netmask would be the logical thing to do. 2. nameif has issues when using /etc/mactab. I can't remember the exact problems as I can't access that machine right now, but I couldn't get nameif to work that way. 3. nameif doesn't work unless the interface being renamed is down. It doesn't know that anything that is up can go down for a moment -- but, the code which reads /etc/network/interfaces does exactly what we need: it puts down all interfaces, reconfigures them and then brings them up again. Renaming them to what the sysadmin wants is a natural step to do. Regards. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
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 notes. This often happens anyway when switching between 2.4 and 2.6 kernels, so it's something users have always needed to be aware about. Except, you switch from 2.4 to 2.6 only once per server, and this is a big change where one _expects_ things to possibly go wrong. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
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 (for performance reasons). So I think not. Notice, in any case, that the xvidcap packages in NEW *don't* use ffmpeg, the source code is there: $ ldd /usr/bin/xvidcap . 'ldd' does not mean anything: most versions of xvidcap ship a copy of ffmpeg in their own sources: $ wget http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3-p7.tar.gz $ tar xzf xvidcap-1.1.3-p7.tar.gz $ du -s xvidcap-1.1.3-p7/ffmpeg/ 6420xvidcap-1.1.3-p7/ffmpeg/ $ wget http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3.tar.gz $ tar xzf xvidcap-1.1.3.tar.gz $ du -s xvidcap-1.1.3/ffmpeg/ 6340xvidcap-1.1.3/ffmpeg/ a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: display-dhammapada
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 since few years. But there is new version of this software since few years also. I have send long time ago request to the package owner if he could make new version. There was no answer, so I guess he is busy with some other work. I have though that maybe I could help maintaining this package? I have never done it before, but I am debian user since years and I am software engineer working in IT company, so I think I could manage it. What do you think I should do? * File a wishlist bug against the package to update to the new version, if someone else didn't already do so * Read section 7.4 of the Developers' reference, which talks about how to handle inactive and/or unreachable maintainers, and do what's being suggested there * Prepare an updated package and offer it to the maintainer (if you get some reaction from him) or to other Debian Developers (if not) with a request to sponsor an upload. Thanks a lot! I will do it this way. greetings, Jakub -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I did ask, Re: congratulations to our ftp-master team
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 mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... yes, your memory failed :-) (you are in the CC of the attached email) I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. (sorry my english fails me here) To the best of my knowledge, mpeg encoding stuff is nowhere near the core funcionality of mplayer anyway, isn't it? yes AFAIK mencoder cannot encode MPEG2 in this version (that is in NEW queue) Of course, if this way is choosen and is turning out to work out, later inclusion of the mpeg encoding stuff in mplayer must be discussed with ftp-master prior to it happening -- we (as in, Debian users in general) just get to have a chance of a slightly crippled mplayer in the archive in the meanwhile. I agree As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member Of course. This is what I have been waiting for. For 880 days, roughly. a. From debdev Mon Sep 26 11:33:39 2005 Date: Mon, 26 Sep 2005 11:33:39 +0200 To: [EMAIL PROTECTED] Cc: Diego Biurrun [EMAIL PROTECTED], MJ Ray [EMAIL PROTECTED], Dariush Pietrzak [EMAIL PROTECTED], Joerg Jaspert [EMAIL PROTECTED], Jeroen van Wolffelaar [EMAIL PROTECTED] Subject: questions on mplayer Message-ID: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=nFreZHaLTZJo0R7j Content-Disposition: inline User-Agent: Mutt/1.5.9i Status: RO Content-Length: 2300 Lines: 64 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear ftp-masters,=20 (and in particular Jeroen van Wolffelaar and Joerg Jaspert, who have discussed the problem before), in April 2005, during a thread discussing inclusion of mplayer in Debian, at http://lists.debian.org/debian-devel/2005/04/msg00997.html J. van Wolffelaar expressed the opinion that nowadays the only issue still blocking acceptance of mplayer in Debian may be=20 the (*) presence of MPEG encoding software.=20 [(*) as a matter of fact, up to some time ago AFAIK mplayer was unable to encode MPEG stream; but I heard that they are working on it] J. van Wolffelaar also said though that We're not (yet?) saying it's *required* to strip MPEG encoding stuff, but in my personal opinion, it seems likely that this is what it'll turn out to be. I would be very grateful if the ftp-masters team may finally decide what are the requirements so that mplayer be accepted into Debian; in doing so, they may want to read http://people.debian.org/~mjr/legal/mplayer.html where M J Ray summarizes and links many info. To fix ideas, I would need official (at least privately to us) answers to these questions: 1) can mplayer be included into Debian, possibly with some fixes, including removal of source from the mplayer...orig.tar.gz ? 2) (if yes) do we need to remove MPEG decoding stuff? 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) The above questions are somewhat urgent, since the current version of mplayer in NEW has a security bug, so I would love to prepare a new version, and I would love to prepare it to comply to any request by the ftp-masters, so that I may upload it into NEW for their review. a. --=20 Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDN8Bz9B/tjjP8QKQRAmxfAJ9IJ686tgGjSRBIbqBqQaACm7OROwCdH94G ulHqI6eqYyiOis8K8mrKz/8= =6Wc/ -END PGP SIGNATURE- --nFreZHaLTZJo0R7j-- signature.asc Description: OpenPGP digital signature
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
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 or not it's in the release notes. This often happens anyway when switching between 2.4 and 2.6 kernels, so it's something users have always needed to be aware about. How wonderful then that udev now gives us the opportunity to make upgrades completely seamless for users of 2.4 *and* 2.6 kernels! Indeed, if that's the case, why should we settle for anything less? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
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 least) From [EMAIL PROTECTED] Mon Aug 16 00:54:00 2004 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from sns.it (mail.sns.it [192.167.206.31]) by tonelli (Postfix) with ESMTP id 68F2517601 for debian; Mon, 16 Aug 2004 00:54:00 +0200 (CEST) Received: from newraff.debian.org ([208.185.25.31] verified) by sns.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 20014347 for [EMAIL PROTECTED]; Mon, 16 Aug 2004 01:01:46 +0200 Received: from troup by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1BwTic-00016O-00; Sun, 15 Aug 2004 18:43:14 -0400 From: James Troup [EMAIL PROTECTED] To: A Mennucc1 [EMAIL PROTECTED], Dariush Pietrzak [EMAIL PROTECTED] X-Katie: lisa $Revision: 1.30 $ Cc: Debian Installer [EMAIL PROTECTED] Precedence: bulk Subject: mplayer_1.0.cvs20030324-1_i386.changes REJECTED Message-Id: [EMAIL PROTECTED] Sender: James Troup [EMAIL PROTECTED] Date: Sun, 15 Aug 2004 18:43:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on tonelli.sns.it X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4.5 tests=AWL,BAYES_00 autolearn=ham version=2.63 Status: RO X-Status: A Content-Length: 299 Lines: 16 Hi, Sorry for the delay in processing this package. Please upload a version with a sane copyright file - the one currently in the package still just says GPL. -- James === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email.
Re: /run vs /var/run (was: Please test new sysvinit)
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 local admin.) I think that packages Depending on initscripts = 2.86.ds1-7 should be entitled to assume that /run/* is a writable location available very early after boot. Yes, they should. Initscripts 2.86.ds1-7 includes /run and mountvirtfs mounts a tmpfs on it, thus causing this assumption to be true. If the local admin wants something else then he or she can edit the script in such a way that the aforementioned assumption remains true. No, having to edit init scripts sucks. So does having mounts that aren't controlled via /etc/fstab. 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)? If not, why can't we mount /run using /etc/fstab as part of checkroot.sh, and leave the details to the admin? This optimizes for the common case, and leaves the way open for solutions to uncommon requirements. If there is demand for an alternative standard operation mode that satisfies the assumption then that can be implemented, of course, but offhand I can't think of why anyone would need anything but the default configuration. The two use cases that were raised when /run was first discussed were: - NFS-mounted /var filesystem - read-only / filesystem Having a /run directory for early-boot volatile data addresses the needs of both of these use cases (even simultaneously -- hurray!), but by constraining the actual *implementation* of /run (barring ugly hacking of the init scripts), you've made the system less suitable for a third use case: - memory is at a premium, disk is not I'm not going to claim that I know of any particular users that are affected by this change; files that are candidates for /run (or /lib/run) are typically small enough that it's fairly unlikely for this alone to impact what they can or can't do with Debian. But that's also not the point: the point is that design-wise, there's simply no reason to make the choice for the user of *what* is mounted on /run, only to specify that *something* must be (and that it must be writable); given that the existing default is perfectly suitable for the majority of users, I believe we're better off not touching it. If you really want to be clever though about supporting upgrades for users that may already have read-only root, I guess you could do something like this: if grep -q '[[:space:]]/run' /etc/fstab; then mount $options /run elif grep -q '[[:space:]]/[[:space:]].*\bro\b' /etc/fstab; then mount $options -t tmpfs tmpfs /run fi And then everyone can be happy. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
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 only for those very few purposes for which /var/run cannot be used. If there are worries about abuse then I would suggest the addition of a sentence to Policy forbidding such abuse. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
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. /run should be used only for junk that needs to be stored early in the boot sequence, and everything else should go in /var/run. /var/run is *tiny*. In fact on my system it's close to 4 orders of magnitude smaller than /usr/lib. I know why /usr isn't assumed to be on the root filesystem, and it's not at all related to why a /run ramfs that has to exist anyway might be inappropriate for /var/run. On the contrary; on some of my systems, I have at least /var/run/samba and /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. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
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 nice if mtab could be kept in /run so that it could be written to as filesystems are being mounted. Currently these sorts of things are delayed using one trick or another. by constraining the actual *implementation* of /run (barring ugly hacking of the init scripts), you've made the system less suitable for a third use case: - memory is at a premium, disk is not Tmpfs memory can be swapped out, so is this even a hypothetical problem? [...] the point is that design-wise, there's simply no reason to make the choice for the user of *what* is mounted on /run, only to specify that *something* must be (and that it must be writable); One advantage to supporting only tmpfs on /run is that the assumption can then be made that the hierarchy is empty at boot; there are no stale files and no cleaning has to be done. If there are reasons why some users would not want to put a tmpfs at /run (which there may well be, although I haven't heard them yet) then we can of course support this. Then either initscripts will have to clean the directory or programs using it will have to contend with stale files. Cleaning cannot occur until the filesystem underlying /run is mounted read-write and programs must not use /run before the cleaning has been completed; it would probably be easier to drop the cleanliness-at-boot guarantee and let programs clean out their own stale files. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test the new sysvinit
So, has anyone tested the new packages? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 cache if it were on a disk-backed fs). I just looked at my /var/run directory and I found only 5 files (4 of them are sockets) that are used often (often = at least once in every 5 minutes here). The rest should definitely not occupy my VM space in any form. And you cant really move the run ressources. What you mean by that? /run is needed to store things before the real /var is mounted for a very few things that _must_ run before /var is mounted. If something is capable to be started _after_ /var is mounted, I think it has no right to use /run. For the few things that really needs /run it could be easy to implement moving data out of /run after /var is mounted. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 especially /need/ to be a tmpfs fs does it? It could The current proposal does. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
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 /lib/init. Especially given our use of /usr/lib, it seems the most suitable dumping ground for random stuff like /run; and a far better one than / itself. ACK. -- ciao, Marco signature.asc Description: Digital signature
Re: Debian menu entries(was Re: Debian and the desktop)
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, but it does not go that far. Debian menu already handles package descriptions. What is does not do is internationalization. Support for internationalized entries would allow KDE and GNOME to drop separate menus and incorporate Debian Menu directly (what I consider the right thing to do). Of course all of this requires a lot of work from Debian Devs, so this is only theory so far. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-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 specifically for POSIX-SHM? Tell us... Do you have reasons to believe that we will be forced to remove /dev/shm/ in the future? Yes. Being an implementation detail of POSIX-SHM, the kernel or libc are free to change the POSIX-SHM implementation at any time, so there are no guarantees. As Christoph mentioned, there is no requirement for it to be user visible; it's not mandated by any standard. As long as shm_open(3) et. al. continue to work, any change could be made without breaking backwards compatibility. This is independent of it being inappropriate to use for non-SHM uses. /run doesn't especially /need/ to be a tmpfs fs does it? It could The current proposal does. Only if you want a read-only root. If you don't, you could create /run on the root filesystem, or symlink it to /var/run. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpq4MVcFcaSW/uEgRApOcAKCrCNtGKhJfbpAkk7zzF4htyCFbmQCgzoCf dJdXsvgDyA7b+r6bQj44OZM= =nYK8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test the new sysvinit
-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 wants to test them. I did file a bug about tmpfs size limits (#344001), but this is really a wishlist item. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpq7vVcFcaSW/uEgRArdlAJwNMWMCNln85pgzyn1Kq721nd5fsQCg6qf0 80I/xIAZpYaxtcW3K5Y4IeA= =MpSd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 other implementation for shm_open(), then it has no reason to stay. /run doesn't especially /need/ to be a tmpfs fs does it? It could It does not have much sense if it is not a tmpfs, since we already have /var/run. Gabog -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 tmpfs fs does it? It could It does not have much sense if it is not a tmpfs, since we already have /var/run. I understand that some people want a writeable file system available before / is mounted rw. -- ciao, Marco signature.asc Description: Digital signature
Bug#344012: ITP: sylpheed-claws-gtk2-feeds-reader -- Feeds (RSS/Atom) reader plugin for Sylpheed Claws GTK2
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 : Feeds (RSS/Atom) reader plugin for Sylpheed Claws GTK2 The RSSyl plugin provides feeds reading capability for Sylpheed Claws GTK2 mailer. . Supported formats are RSS (1.0, 2.0 and probably 0.9x versions) and Atom feeds. . It integrates also with dillo viewer plugin to allow online browsing of entries, and has per-feed customization features, transforming your Sylpheed Claws into a powerful lightweight feeds reader. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-11-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
About GFS
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]
Re: /run vs /var/run
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, /lib/alsa-utils, /lib/discover and /lib/init. 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. So I find at least these within the definitions of the FHS. 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. Shared library image seems a pretty clear reference to .so files, and binaries is usually used to talk about ELF executables as opposed to scripts (executables being the general term). /lib is the right place for the above, and the FHS's too-limited definition is wrong. To my mind, /lib also seems the right place for a /run directory. 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 is Variable state information and This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Combining these two, and adding the ...needed to boot the system qualifier seems like it would perfectly cover the above requirements and /run. Cheers, aj signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
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. Fortunately, I didn't claim that. ] Has anyone talked to the FHS guys about this? ] Yes, I have talked to them about it and there is no objection. -- http://lists.debian.org/debian-devel/2005/12/msg00764.html Anyway, what you meant seems cleared up now. Cheers, aj signature.asc Description: Digital signature
Re: I did ask, Re: congratulations to our ftp-master team
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. Jeroen van Wolffelaar wrote: While you indeed haven't got a later mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... yes, your memory failed :-) (you are in the CC of the attached email) Yes, and I got it via ftpmaster@ too. I indeed failed to answer this mail, and so did we as ftp-master team. I'm sorry for that, I do my best to reply to all mails that I can answer to, but september was an increadibly busy month for me. Only speaking for myself here, if you haven't recieved an answer for a month or so and you expected one, you're welcome to prod me via mail, repeating every month if needed, I don't mind that for genuine questions that are not written in an offensive way. I know it's not nice, but I get a lot of mail, and as time passes, chances decrease significantly I'll ever get around to replying old mail. Alternative ways to solve this like adding more hours to days have proven hard to implement. I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. (sorry my english fails me here) Basicly: Drop mpeg encoding from mplayer source package - definitely less problems getting through NEW. As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member Of course. This is what I have been waiting for. For 880 days, roughly. I suggest you upload stripping all the mpeg encoding stuff, pending answer to that difficult question. However, what you do, is your choice -- if you prefer to wait and are not planning to strip mpeg encoding support out of the source package, that's not something the ftp-master team will have any say on. To answer the questions from your mail of september: 1) can mplayer be included into Debian, possibly with some fixes, including removal of source from the mplayer...orig.tar.gz ? I'm not aware of any fundamental reason why mplayer couldn't be in Debian. 2) (if yes) do we need to remove MPEG decoding stuff? Encoding, I assume you mean. 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. However, removing encoding stuff would bypass the main problem that we have with mplayer right now, and then the answer to this question can then be researched in parallel to an mplayer-with-only-mpeg-decoding being available from Debian. 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) I don't know of any at this moment, but I also cannot promise there won't be any more problems that need fixing found between now and the package being checked in the NEW queue. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344017: ITP: libalgorithm-dependency-perl -- Base class for implementing various dependency trees in Perl
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 : Base class for implementing various dependency trees in Perl Algorithm::Dependency is a framework for creating simple read-only dependency heirachies, where you have a set of items that rely on other items in the set, and require actions on them as well. New build depend for #329990 -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-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, since there are many other uses too for a tmpfs. There are many uses for an ext3fs, but that doesn't mean we only have one ext3 filesystem. What exactly is your reasoning here? - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpsHvVcFcaSW/uEgRAnluAJ0WyacE//0kdGWFXl5DFQbW1/UXSQCg4Esk C32DoJ4AGfP1FmnPDqDfePs= =gqVX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITP: gcx -- astronomical image processing and photometry gtk+
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 image processing and photometry gtk+ applicatio n Gcx is an astronomical image processing and data reduction tool, with an easy to use graphical user interface. It provides a complete set of data reduction functions for CCD photometry, with frame WCS fitting, automatic star identification, aperture photometry of target and standard stars, single-frame ensemble photometry solution finding, multi-frame color coefficient fitting, extinction coefficient fitting, and all-sky photometry; as well as general-purpose astronomical image processing functions (bias, dark, flat, frame alignment and stacking); It can function as a FITS viewer. . The program can control CCD cameras and telescopes, and implement automatic observation scripting. Cameras are controlled through a hardware-specific server, to which gcx connects through a TCP socket. It generates FITS files with comprehensive header information. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
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 /sbin together are 156M; /usr/share/zoneinfo is 5.5M. So, while a 3.5% increase in the size of / would fix it, it seems rather wasteful for the need of ~1K. Maybe just copy (in, e.g., postinst) the one file needed to /lib/zoneinfo, and create the symlink to that. It really shouldn't be in /etc; binary files do not belong there. I was only proposing to copy the one file. I don't think it's quite so important to put it in /lib and then put a symlink from /etc/localtime to /lib/localtime. There _are_ other binary files in /etc. Just do: find /etc -type f | xargs file | grep data and you'll find files such as /etc/apt/trusted.gpg /etc/ld.so.cache /etc/prelink.cache ...as well as image files, PPD files, pcmcia data files, and many others. 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? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
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 think it sounds quite acceptable. The (compiled) time zone data files are pretty small (there's just a lot of them, and the each use a disk block). -- Yet another quit message no-one will ever comment on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
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 appropriate for. I think that everyone agrees that /run is to be used only for those very few purposes for which /var/run cannot be used. If there are worries about abuse then I would suggest the addition of a sentence to Policy forbidding such abuse. Developers have been known not to be completely familiar with policy, but it's admins and upstream programmers that I'm particularly thinking of. Cheers, aj signature.asc Description: Digital signature
Bug#344037: ITP: gcx -- gcx -- astronomical image processing and photometry gtk+ applicati
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 photometry gtk+ applicati Gcx is an astronomical image processing and data reduction tool, with an easy to use graphical user interface. It provides a complete set of data reduction functions for CCD photometry, with frame WCS fitting, automatic star identification, aperture photometry of target and standard stars, single-frame ensemble photometry solution finding, multi-frame color coefficient fitting, extinction coefficient fitting, and all-sky photometry; as well as general-purpose astronomical image processing functions (bias, dark, flat, frame alignment and stacking); It can function as a FITS viewer. . The program can control CCD cameras and telescopes, and implement automatic observation scripting. Cameras are controlled through a hardware-specific server, to which gcx connects through a TCP socket. It generates FITS files with comprehensive header information. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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. Shared library image seems a pretty clear reference to .so files, and binaries is usually used to talk about ELF executables as opposed to scripts (executables being the general term). /lib is the right place for the above, and the FHS's too-limited definition is wrong. To my mind, /lib also seems the right place for a /run directory. 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 is Variable state information and This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Combining these two, and adding the ...needed to boot the system qualifier seems like it would perfectly cover the above requirements and /run. Let me see if I have understood the argument. Let's call the new directory 'R' for now. attempt to paraphrase /lib is, like R, a directory required for programs needed to boot the system and run commands in the root filesystem; and /var/lib is, like R, a place where data is stored. We just heard lib twice! So /lib is the right place for R. /attempt to paraphrase I don't think that an argument from the meaning of lib can get much traction because /lib, /usr/lib and /var/lib are so different. (I'll guess that these differences are there because: * /usr/lib contained both application code and application data in the old days; * When application data was removed from /usr/lib it was placed in /var/lib, which missed the opportunity to choose a more appropriate name such as '/var/data'; * When /usr/share was split out of /usr/lib, no /share was split out of /lib. So whereas scripts can be kept out of /usr/lib, they can't be kept out of /lib because there is no better place to put them if they have to be on the root filesystem.) But there are problems with this particular argument as I have paraphrased it (probably distorting it). First, if we accept the reasoning steps then the conclusion ought to be that the right value for R is /lib/lib. What went wrong? Well, first, we missed the fact that /lib isn't the only directory required for programs needed to boot the system and run commands on the root filesystem; /sbin and /bin and sometimes other top-level directories are also required. So if we add _another_ directory with the same supporting role as them then it should be, like them, in the root directory. Hence R should be /something. Second, we missed the fact that the function of R is more analogous to /var/run than to /var/lib, and so should have a basename of 'run' rather than 'lib'. Hence R should be /run. Briefly, if R is like /var/run except that it supports programs needed to boot the system and run commands on the root filesystem, then it should be another run directory, but at the top level. Here's another possible argument: Putting R in /lib spoils the otherwise read-only character of that directory. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
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 for Etch while we can do it slowly and without trouble. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
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 there at all 3. There is no guareteee that it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. These points apply to the proposed tmpfs-based /run as well. /run would have no other special function, so it is much more future-proof than using /dev/shm for stuff it was not created for. Sounds it sounds to me like it is a bad idea to use it. Only because you have no clue of what you are talking about. That was uncalled for, and he gave much better argumentation than those YOU provided. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
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 systems. As for upstream programmers, most of them can't use /run because their software doesn't run with root privileges. Others can only use /run insofar as Debian and admins let them do so. So this brings us back to policy. I don't think that Debian would ever be accused of lacking zeal in enforcing its Policy. :) Cheers, -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 tmpfs. Sure, but why do we have to keep using one whose main purpose is something else? /run doesn't especially /need/ to be a tmpfs fs does it? It could Yes, it does, it needs to always be rw and available very early. I understand that some people want a writeable file system available before / is mounted rw. Exactly. I suspect some of the /dev/shm usage would have shifted to /run if we had it at the time. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I did ask, Re: congratulations to our ftp-master team
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 actually research a comprehensive answer on this. Note that This is the same as such-n-such other package isn't an answer -- it only indicates that other package may have problems too. Any such answer should include a summary of relevant patents, what countries they're valid for, what functionality is claimed, whether it does or doesn't appear to cover the software in question, and what the patent holder's attitude seems to be -- support free software, ignore the little people, prosecute anyone they can, or what. Last time I looked at this, the mplayer folks had their page blacked out with a comment to the effect of if Europe gets software patents, mplayer will be illegal; but Debian operates outside Europe in places that already have software patents, and Debian tries to avoid illegal software... At the time, I believe the Debian mplayer folks were saying ignore the upstream stuff, which isn't really very helpful. MJ Ray's page only mentions patents once, saying: There were problems with copyright and patents (according to this summary of the history). The summary linked just says ffmpeg made it in, so it must be okay. Please, someone go all groklaw on the issue already... Cheers, aj signature.asc Description: Digital signature
Re: /run vs /var/run
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, but that doesn't mean we only have one ext3 filesystem. What exactly is your reasoning here? That tmpfs will not be removed from the kernel just because shm_open() will switch to a different implementation. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
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 remove it from a future release. 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 it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. These points apply to the proposed tmpfs-based /run as well. /run would have no other special function, so it is much more future-proof than using /dev/shm for stuff it was not created for. You keep saying this, but fail to provide any arguments except handwaving. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run
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 is Variable state information and This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Combining these two, and adding the ...needed to boot the system qualifier seems like it would perfectly cover the above requirements and /run. Let me see if I have understood the argument. Let's call the new directory 'R' for now. attempt to paraphrase /lib is, like R, a directory required for programs needed to boot the system and run commands in the root filesystem; and /var/lib is, like R, a place where data is stored. We just heard lib twice! So /lib is the right place for R. /attempt to paraphrase We just heard lib twice! ? You either get to fairly summarise an argument or mock it; don't try to do both at once. The line of thinking is this: we would like to put everything in a single namespace under /, but we can't for two reasons: one is that / has to be small in some circumstances, so we use a separate namespace, /usr, that doesn't have that limitation; the other is that it's better to have separate read-only and read-write namespaces; so we put non-static information in /tmp, and /var. But beyond that, /, /usr, and /var are more or less the same -- hence /bin and /usr/bin, /lib and /usr/lib, and /tmp and /var/tmp, in each case, both directories containing the same sort of contents -- with the provisos that changing data goes in /var/foo, large static data goes in /usr/foo, and we limit /foo to stuff that's needed to boot or recover the system. If the question is what does /lib contain? the answer, then, is the same sort of stuff that /usr/lib or /var/lib contains, but limited to that necessary to boot the system. I don't think that an argument from the meaning of lib can get much traction because /lib, /usr/lib and /var/lib are so different. They don't seem very different to me. /lib and /usr/lib both contain static libraries. /usr/lib and /var/lib both contain subdirectories of package specific data, split by the requirements of /usr and /var. /lib, /usr/lib and /var/lib are all a good default place for random data that people hadn't previously thought of. (I'll guess that these differences are there because: * /usr/lib contained both application code and application data in the old days; So did /etc. Unlike /etc, /usr/lib remains *designed* to contain application code and data, currently. /lib in practice does the same thing today: containing .so files, kernel modules, script fragments, and terminal information. * When application data was removed from /usr/lib it was placed in /var/lib, which missed the opportunity to choose a more appropriate name such as '/var/data'; For a brief time, /var/lib was renamed to /var/state, as it happens; it was renamed back when that proved unnecessarily cumbersome. * When /usr/share was split out of /usr/lib, no /share was split out of /lib. That would be because it's no easier to share /share across different machines than /usr/share, and because creating new directories in / is a bad idea. But there are problems with this particular argument as I have paraphrased it (probably distorting it). First, if we accept the reasoning steps then the conclusion ought to be that the right value for R is /lib/lib. What went wrong? You pulled a lib from nowhere -- following the theory the right value for R in that case would be package or misc. But that doesn't help distinguish an early read-write namespace, and seems kinda pointlessly pedantic. Afterall, if you're going to be that pedantic, /lib already forbids non shared libraries and non modules, so clearly /lib/run is unpossible. So if we add _another_ directory with the same supporting role as them then it should be, like them, in the root directory. Only if you also want to say supporting directories of apps in /usr/bin should be, like them, in /usr, thus /usr/var/ And while you might well say that, we don't. Second, we missed the fact that the function of R is more analogous to /var/run than to /var/lib, Actually we (I) deliberately ignored it; mostly because /var/run is a subset of the functionality of /var/lib, and needed for boot doesn't warrant breaking up the functionality like that. /lib/var would be the obvious alternative, and more accurately indicate variable data needed early in bootup. *shrug* and so should have a basename of 'run' rather than 'lib'. Hence R should be /run. Heh. I'm shocked -- shocked!! -- by your conclusion. Briefly, if R is like /var/run except that it supports programs In
Always get the lowest vacation, not a dream
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, the lowest price to go to Vegas, Bahamas, Barbados, Caribbean, Europe, France, or wherever? Expedia, Travelocity, Itravel2000, Priceline, Orbitz, Escapenow, Hotel.com. Who is offering the best deal? When are they offering the best deal? I have a fixed vacation schedule, when is the most suitable time to place my order? I only want non-stop flight, but I still want the best deal, the cheapest price, the lowest price. How can I get it? I only want to stay in 4-star hotel, but I still want the best deal, the cheapest price, the lowest price. How can I get it? Your dream and your answer can be fulfilled by Travellers Dream Hunter, your best tools for your vacation, trip and travel planning. Grasp the Chances, Save the Bucks!!! Want to know more details: http://www.google.ca/search?hl=enq=%22traveller%27s+dream+hunter%22btnG=Google+Searchmeta= Note: You received this email, only because you subscribed to Hunter service. To remove yourself from the mailing list, please simply sendmail email to [EMAIL PROTECTED], subject 'Unscribe'.
Re: /run vs /var/run
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 they are not used be constant directory reads/stats in /var/run, methinks. Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. )[EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+49721151516129 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-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, since there are many other uses too for a tmpfs. There are many uses for an ext3fs, but that doesn't mean we only have one ext3 filesystem. What exactly is your reasoning here? 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. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpwgzVcFcaSW/uEgRAqwyAJ9YqGshjfse9RYlNuxti7iz3p15qQCfROXn RskcNKCR5yffZlelQTPyJeU= =JEPf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-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 it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. These points apply to the proposed tmpfs-based /run as well. /run would have no other special function, so it is much more future-proof than using /dev/shm for stuff it was not created for. You keep saying this, but fail to provide any arguments except handwaving. I provided you with a functional program code sample that demonstrates how shm_open interacts with the filesystem. Did you try it? [link with -lrt, BTW] 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 would be ftruncated, zeroed and corrupted beyond repair. Depending on who alters it last, this will 1) Cause POSIX-SHM using applications to fail with SIGBUS as the backing store is removed. 2) Cause POSIX-SHM using applications to segfault or misbehave as their data gets changed behind their back. 3) Cause the program abusing /dev/shm to fail as its datafiles are trashed and/or unlinked behind their back. Namespace conflicts aren't pretty. Sure, you can call it handwaving, but to me it's something that's going to break at some point in the future. I can't believe you are condoning that, especially when the fix is so simple. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpwqNVcFcaSW/uEgRAq4fAJ0Q1k15xDzEaAOXo86sZ9TCSwHingCfaQUV OPeVLczGK4GqyxXWJTw5YUU= =vadq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/run vs. /lib/run
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]
(no subject)
Please remove me from callwave because I didn't sign up for it.
Re: /run vs. /lib/run
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 dependencies make this hard). 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 if it's not, fall back on /run? That way, /run could be created during the boot process, then moved to /var/run and removed again once /var is available, making it a transient aspect of the boot process and not hanging around as a new top-level directory. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 name for a SHM object (well, they would share it, as it's designed to be). The real lesson in this is that object names should be choosed carefully. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run
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. There is no reason why it should be moved. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run
-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 fail outright. If a regular file was opened, it And so would two programs using the same name for a SHM object (well, they would share it, as it's designed to be). Yes. You would however be cooperating, and using O_CREAT|O_EXCL and unlinking at the appropriate times so as to avoid any trouble. The real lesson in this is that object names should be choosed carefully. That's correct, but you should still not be using the namespace for non-SHM activities. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpxmCVcFcaSW/uEgRAgU5AJ0TnZc1ljigaWcDg4tOBnc19aVliQCfeGZw qhipCtZj2sARpU8FyketWo8= =wzMr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 keep /dev/shm mounted; you would need to use an alternate location. There is no reason why it should be moved. How could anyone know that today? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: /run vs /var/run (was: Please test new sysvinit)
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 we use it then it's reasonable to assume that we would not suddenly remove it from a future release. Of course, if we start using this filesystem for random purposes that have nothing to do with the reason it was created first, we couldn't remove it if the shared memory implementation is changed. Then we'd have to stick with a stupid filesystem that would require a transition to get rid of. Following your line of reasoning, we could put all files in the root directory. After all, do we really need to follow the FHS? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: switching to vim-tiny for standard vi?
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 as the standard PHUX editor be a reason to drop it instead? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: /run vs. /lib/run
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] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Bug#344073: ITP: libfile-path-expand-perl -- expand user directories in filenames
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 (like Perl itself)
Description : expand user directories in filenames
File::Path::Expand expands user directories in filenames. For the simple
case it's no more complex than s{^~/}{$HOME/}, but for other cases it
consults getpwent and does the right thing.
This module is a dependency for Email::LocalDelivery, which is a
dependency for Email::Filter.
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian and the desktop
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 install a sarge system and try plugging a USB stick or playing sound. This means that I have access to those devices even as a remote user, which is almost certainly not what anyone on a true multiuser system wants. - The Redhat way, using pam_console. The user logging in gains rights on some devices. The problem is that when the user logs out, there's no way to force her to release the rights acquired. This is a limitation of the Linux kernel, which cannot revoke privileges. AFAIK, that's why it isn't used by default in Debian. But would be a lot better than unconditionally granting access. The there is no way to revoke that problem has an obvious solution: Go through a system service. The kernel is not the place to make or enforce policy, as it will not fit all use cases (and this is exactly what we're seeing here). If you want things to move, you should provide a framework for the kernel to handle a new revocation system call - far from an easy task. I think it can and needs to be done in userspace. [wireless configuration] Some desktop tools doing that exist, but they seriously lack integration in Debian. I think they seriously lack integration period. The overall trend on Linux in the last years has made it become an open-source Windows, with a lot of bloated applications fighting over the last 100 MiB of memory and a lot of works for me kind of solutions. Kernel capabilities have been misunderstood as a way to grant limited privileges to users, while in fact they are meant as a way to remove privileges from system services that do not need them. Simon signature.asc Description: OpenPGP digital signature
Re: /run vs. /lib/run
-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/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpyceVcFcaSW/uEgRAhI0AKDdTi2N0xT//1jAerLRE2x/BXy6ogCg35wP 58H/gghiCj/KUwan63x7Vsg= =wCE3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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
Re: /run vs. /lib/run
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
Re: /run vs /var/run
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 alternate location. There is no reason why it should be moved. How could anyone know that today? Common sense. Stuff like not trying to invent unplausible situations for the sake of an argument... -- ciao, Marco signature.asc Description: Digital signature
Bug#344081: ITP: xen-debiantools -- Tools to manage debian XEN virtual servers
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 Description : Tools to manage debian XEN virtual servers This package contains tools to manage debian based XEN virtual servers With them you can create, duplicate, update or delete virtual servers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I got a new address!
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
Re: /run vs. /lib/run
* 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 top-level directories, but moving it under /lib doesn't really make sense. It more surprising and less consistent to have it under /lib. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Bug#344081: ITP: xen-debiantools -- Tools to manage debian XEN virtual servers
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 Description: Digital signature
Re: Please test new sysvinit, sysv-rc, initscripts
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}.
You should have a rotated /var/log/dmesg, and /var/log/boot if you are using
bootlogd.
fsck logs are OK, /var/log/dmesg.0 is root:root instead of root:adm.
bottlogd is still broken.
Please check /etc/motd. Is this now a symlink to /var/run/motd and are its
contents
correct?
Correct.
Try switching to runlevel 1. Does this work as expected?
Did not try it yet.
Now shut down. Any problems?
Well, the reboot already used the new scripts and it went OK.
Boot with INIT_VERBOSE=yes kernel parameter. Is the boot more verbose?
I'd say yes, but it scrolls too fast, and first fonty then gdm makes
scrollback impossible (and framebuffer with bigger resolution is out of
question because the fglrx driver does not like it).
Any glitches in any of the messages?
Without a working bootlogd it is hard to tell.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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
Re: Bug#344081: ITP: xen-debiantools -- Tools to manage debian XEN virtual servers
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 to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new sysvinit, sysv-rc, initscripts
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 Description: PGP signature
Re: /run vs /var/run
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 and sockets would be in memory even if they are not used be constant directory reads/stats in /var/run, methinks. I don't have any symlinks under /var/run. Bound sockets do consume kernel memory; the extra VM usage in case of tmpfs is orthogonal to that. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
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 that already.
--
see shy jo
signature.asc
Description: Digital signature
Re: /run vs /var/run
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_open(/network/ifstate, O_RDWR|O_CREAT|O_TRUNC), which is perfectly legal for any random application to do. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: switching to vim-tiny for standard vi?
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 vi, these include autoindent being defaulted to on in the system wide vimrc, and nocompatible being turned on there also, which makes vim -C not behave as expected and enables lots of divergant behavior. vim's maintainer may want to consider documenting/otherwise dealing with these if vim-tiny goes into base and becomes the program people get when running vi by default. I'd still like to know what Steve Greenland thinks of this, since he maintains nvi. I think that if the maintainers of vim and nvi agree to swap the one that is in base, that's their perogative to do now since the thread hasn't turned up any particular reasons not to do it. -- see shy jo signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
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 editor than nvi. 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. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: /run vs /var/run
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 daemon, and that might have otherwise used /var in general. That's why I'd like to have a check for /run (or /lib/run or whatever) being empty at the end of the boot process, and complain if it isn't (possibly also remounting it r/o so abusers break noisily). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
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 :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
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 if it's not, fall back on /run? That way, /run could be created during the boot process, then moved to /var/run and removed again once /var is available, making it a transient aspect of the boot process and not hanging around as a new top-level directory. /run cannot be created during the boot process since it may be needed before / is writeable. Also, if /run does not exist when the system is up, the admin may think that the name is available and put real data there (or just simply expect it to be present once he/she mkdir'ed it), so removing it is dangerous. What may be possible (and I'd prefer) is to use a name like /.run, but AFAIK there are people here who dislike dot-names in /. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
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 / to be writeable. Nor does mounting something over any other subdirectory. Cheers, aj signature.asc Description: Digital signature
Re: /run vs. /lib/run
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
Re: switching to vim-tiny for standard vi?
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, which makes vim -C not behave as expected and enables lots of divergant behavior. TBH, I think these are showstoppers. Otherwise, as long as the space issue is fixed as you say it is, sounds fine. Cheers, aj signature.asc Description: Digital signature
Re: /run vs. /lib/run
[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
Re: switching to vim-tiny for standard vi?
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 the system wide vimrc, and nocompatible being turned on there also, which makes vim -C not behave as expected and enables lots of divergant behavior. Hmm. It's unexpected--on its face, though the reason is obvious--that setting nocompatible in vimrc breaks -C. I wonder if there's a way for vimrc to say turn on nocompatible unless -C was used. 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? (:set compatible noautoindent in /etc/vim/vimrc.) I havn't seen any significant differences between vi and vim mentioned that aren't trivially fixed. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
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 offers. I won't lose lots of sleep if I lose this argument. :) One of Vim's selling points is that it can be made 100% vi-compatible [1], so I assume any incompatibilities with vi are considered bugs. I've never used old vi, so I don't know the accuracy of the claim, but everything listed so far are things that :set compatible fixes. (Except maybe the display of cw--I'm not sure if nvi or vim's display is how vi did it.) [1] http://www.vim.org/viusers.php -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
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 possibility for a variety of reasons /., /bin, /etc, /lib, and /sbin all need to be on the same filesystem (or at least all mounted by the time init is invoked). There's no practical difference between expecting /run and /lib/run being writable -- you're either expecting / to be writable, or you're using it as the mountpoint for a new writable filesystem. Also, /dev/shm can already be an example of a rw filesystem mounted on top of a readonly subdirectory on the root filesystem, eg. Pros and cons of /run: + already implemented + name and purpose roughly match /var/run - new directory in / - promotes the files it contains from /etc etc into first class citizens, overstating their importance - provides a more prominent namespace than /var/run, encouraging misuse Pros and cons of /lib/var or /lib/run: + use of /lib corresponds with use of /usr/lib and /var/lib + keeps files out of the way - have to introduce a separate dir to separate behaviour corresponding to /var/lib from behaviour corresponding to /usr/lib Pros and cons of /var/run: + requires no software changes, just policy ones - leaves the burden of ensuring /var is mounted early enough on Debian users There aren't any technical differences between the first two options. 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 than /etc/network/ifstate or /var/run/ifstate would be; in the second, it's in having to introduce a new subdirectory name to separate the variable parts of /lib out; in the third, it's the system specific ugliness of having to ensure /var is mounted early. (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. If you need to use a tmpfs because you can't mount /var without writing somewhere (to determine drivers, perhaps), it doesn't seem that unreasonable to setup something like: /: var/run - /root/run mount -t tmpfs tmpfs /root/run /var: run - /root/run Local read-only / and NFS mounted /var might also require something similar; but leaving the special cases for the systems that need it seems a more reasonable idea than forcing it on everyone. Also, note that onion mounts will probably eventually mean all this only needs to be a temporary hack) Cheers, aj signature.asc Description: Digital signature
Re: /run vs. /lib/run
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 seem more important than /etc/network/ifstate or /var/run/ifstate would be; in the second, it's in having to introduce a new subdirectory name to separate the variable parts of /lib out; in the third, it's the system specific ugliness of having to ensure /var is mounted early. That's not the ugliness that I care about with /lib/run; the uglyness that I care about is that it's introducing /var content into /lib, which feels like a serious violation of the spirit of the FHS to me (yes, we're already violating the letter, but only because there's no /share and /lib is essentially a merger of /lib and /share). /run is not equivalent to /var/lib; it's equivalent to /var/run, which is not at all a lib directory to me. But it's all just aesthetics. (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 with this too. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
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 like a showstopper. (:set compatible noautoindent in /etc/vim/vimrc.) Just commenting out the nocompatible and autoindent lines in the default config works too. Cheers, aj signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
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 a showstopper? 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. I guess there are two competing goals here: acting like vi by default, for the people in a time capsule, and acting like vim by default, to show off vim's cool features. I wonder if there's a sensible way to do both, eg. argv[0] for vi and vim. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
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. Same here. That's why I do not care what the default editor in base is :-) Well, I get to use other people's systems now and then, and I'm always having to ask people to install vim. If vim is the default, and configured to act like vi by default, then people who like old vi get it, and people who like new vim can change it with just .vimrc. A rare opportunity--everybody wins. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
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 with this too. So why don't we go with this? Thomas? Here are the cases: (a) /var on /, mounted rw during normal operation (b) /var a local fs, separate to / (c) / and /var separate NFS mounts (d) / local, /var an NFS mount (e) /var local, can't be mounted 'til a writable fs is available For (a) you just need to wait until S10checkroot.sh has finished. For (b) you need to wait until S35mountall.sh has finished. For (d) and (e) you need special handling; using /run as a tmpfs and setting up /var/run - /run symlinks on both / and /var. That's pretty special handling, and probably needs something like shared subtrees to be done automatically at upgrade time (http://lwn.net/Articles/159077/). For (c) you could either do the same handling as (d) and (e), or just expect the admin to mount it rw as part of bootup. As far as the but programmers/admins might be confused concern goes; adding a brief /run/README at bootup seems feasible. That'd mean: /var is available after: S10checkroot.sh (/var on rootfs) S35mountall.sh (/var local) S40hotplug (/var local, but requires hotplug drivers) S45mountnfs.sh (/var on NFS not mounted before init) /var/run is thus available after one of: S10checkroot.sh S35mountall.sh S36mountvirtfs And /var/run is used before /var is necessarily available by (on my system): S39dns-clean S40networking S41hotplug-net S43portmap Hrm. Special casing in mountvirtfs and mountnfs.sh could be: mountvirtfs: if touch /var/run/.rw_var_run /dev/null 21; then rm -f /var/run/.rw_var_run elif [ $EARLY_RUN_FS ] [ -d $EARLY_RUN_FS ]; then echo Mounting /var/run tmpfs on $EARLY_RUN_FS... mount -t tmpfs tmpfs $EARLY_RUN_FS ln -s . $EARLY_RUN_FS/run mount --bind $EARLY_RUN_FS /var touch /var/.bind_var else echo Error: no early writable filesystem available # ... fi mountnfs.sh: if [ -e /var/.bind_var ]; then rm -f /var/.bind_var /var/run umount /var fi # ... mount -a at which point you only need to mkdir $EARLY_FUN_FS and ensure /var/run is a symlink to it when setting up that behaviour on upgrade. Alternatively you could just make the directory and mount --bind $EARLY_RUN_FS /var/run after mounting /var. (If $EARLY_RUN_FS is /run, you'd have to work out in advance when it's needed so as not to add useless stuff to / when it's not needed; adding a pointless dir to /etc or /lib would likely be okay though) Note that in that scenario programs are FHS compliant in that they only access files throug the /var/run namespace, and if an admin prefers /etc/run or /lib/run, it's just a matter of local configuration rather than recompiling apps. Cheers, aj signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
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 arguments about defaults. If it's trivial to change, that's great; but until the defaults are changed it's still a showstopper. I guess there are two competing goals here: acting like vi by default, for the people in a time capsule, *sigh* and acting like vim by default, to show off vim's cool features. I wonder if there's a sensible way to do both, eg. argv[0] for vi and vim. The following patch lets you have a /usr/share/vim/virc (which should be a symlink to /etc, like /usr/share/vim/vimrc) to specify different behaviour when vim's invoked as vi instead of vim. --- vim-6.4.old/vim64/src/main.c2005-02-15 23:09:15.0 +1000 +++ vim-6.4/vim64/src/main.c2005-12-20 16:36:49.0 +1000 @@ -1363,6 +1363,10 @@ * Get system wide defaults, if the file name is defined. */ #ifdef SYS_VIMRC_FILE +# ifdef SYS_VIM_VIRC_FILE +if (STRCMP(initstr, vi) != 0 || + do_source((char_u *)SYS_VIM_VIRC_FILE, FALSE, FALSE) == FAIL) +# endif (void)do_source((char_u *)SYS_VIMRC_FILE, FALSE, FALSE); #endif --- vim-6.4.old/vim64/src/os_unix.h 2003-11-10 19:53:44.0 +1000 +++ vim-6.4/vim64/src/os_unix.h 2005-12-20 16:14:07.0 +1000 @@ -233,6 +233,9 @@ #ifndef SYS_VIMRC_FILE # define SYS_VIMRC_FILE $VIM/vimrc #endif +#ifndef SYS_VIM_VIRC_FILE +# define SYS_VIM_VIRC_FILE $VIM/virc +#endif #ifndef SYS_GVIMRC_FILE # define SYS_GVIMRC_FILE $VIM/gvimrc #endif Cheers, aj signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
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 in /run until /var/log/ is available for writing. It would be nice if mtab could be kept in /run so that it could be written to as filesystems are being mounted. Currently these sorts of things are delayed using one trick or another. Ok, that's fair. by constraining the actual *implementation* of /run (barring ugly hacking of the init scripts), you've made the system less suitable for a third use case: - memory is at a premium, disk is not Tmpfs memory can be swapped out, so is this even a hypothetical problem? Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out. That still leaves the question of just which features we want to require from our non-Linux kernels for basic operation, I guess. [...] the point is that design-wise, there's simply no reason to make the choice for the user of *what* is mounted on /run, only to specify that *something* must be (and that it must be writable); One advantage to supporting only tmpfs on /run is that the assumption can then be made that the hierarchy is empty at boot; there are no stale files and no cleaning has to be done. Seems to me that we have a handle on the process of cleaning directories by now though, no? :) If there are reasons why some users would not want to put a tmpfs at /run (which there may well be, although I haven't heard them yet) then we can of course support this. Then either initscripts will have to clean the directory or programs using it will have to contend with stale files. Cleaning cannot occur until the filesystem underlying /run is mounted read-write and programs must not use /run before the cleaning has been completed; it would probably be easier to drop the cleanliness-at-boot guarantee and let programs clean out their own stale files. Sounds to me like this will play havoc with idempotence of init scripts; anyway, why would mount /run and clean it be anything less than an atomic operation from the viewpoint of other init scripts? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
