Re: runlevels remodeled
On Fri, Aug 12, 2005 at 03:52:50PM +, Miquel van Smoorenburg wrote: Yes, all mounts from fstab, including NFS mounts, are done in single user mode. But you should only put essential,static mounts in /etc/fstab (say, /usr or so). For the rest you should use automount. The NFS volumes should always be mounted during normal operation (there are system services using data on NFS) so they satisfy both the essential and static criteria. Automount would be just unneccessary bloat. Also there were a couple of situations when I'd preferred if single-user mode did not try to mount /home or /var even if they were just regular local file systems. 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: libnss-db and /usr/lib/* libraries
On Fri, Aug 12, 2005 at 11:07:09AM -0300, Henrique de Moraes Holschuh wrote: 2. any dynamic libraries needed are in /lib, and *all* of them use versioned symbols Look at the earlier discussions about libnss-ldap. You'd quickly find half of /usr/lib being moved to /lib. I do not think this is desirable... Otherwise you have a critical bug in the system, waiting to happen. No. You have a configuration problem. Just document that if you are using bash as /bin/sh, then the only NSS modules you can use safely during shutdown are the ones supplied by glibc (that means files, dns, nis, nisplus, hesiod and compat). Any other NSS modules will likely to cause trouble during shutdown if bash is in the picture. If you can't get all of the above to be true, it is time to remove that particular libnss module from Debian. No, it's just time to realize the consequences and special requirements of complex NSS setups. libnss modules are *extremely* critical to the system. They are implicitly linked to *EVERY* running binnary that is linked against libc (instead of, say, dietlibc). Yep, and that means they pose special configuratuion requirements for the system (like avoiding using bash as /bin/sh). 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: libnss-db and /usr/lib/* libraries
On Fri, Aug 12, 2005 at 04:41:01PM +0200, Goswin von Brederlow wrote: I believe nss modules are even dlopened in a static libc. There is no way to link them in static. I believe Henrique didn't mean the NSS modules being static, just linking all dependant libraries statically into the NSS module (so the NSS module itself would not directly depend on any other shared library). But that will not help NSS modules that try to dlopen other modules themselves (like libnss_ldap which opens SASL authentication modules dynamically). 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: runlevels remodeled
On Fri, Aug 12, 2005 at 04:05:43PM +0300, Timo Aaltonen wrote: Single-user mode is a fiasco, because in /etc/rcS.d/* there are a number of services that really should not belong there. Examples: -network -all disks (including NFS) mounted Well, I have no strong feelings without the multiuser levels, but starting NFS in single user mode is a _major_ PITA. I really-really hated Debian for this when I was administering NFS-using computers. For example, the Solaris way (just do enough to be able to launch /bin/sh, and leave everything else to the admin) is much more useful in practice. 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: runlevels remodeled
On Fri, Aug 12, 2005 at 04:23:04PM +0200, Petter Reinholdtsen wrote: Personally, I hate that it isn't a standardized way to get down to a minimal system, or a standardized way to start everything bug *dm/X. I do not think that X should be anything special. Yes, there is the case when you have X misconfigured and you have crappy hardware so you cannot go back to text mode after X has started; but this could be handled in a more generic way by introducing interactive startup where the startup script of every service asks if it should be started or not. That would be much more useful than a new run level. There is a similar argument for networking: there are cases when being able not to start networking is good but this could also be addressed by an interactive startup without a new run level. (Well, if you implement interactive startup using a new run level, that I would definitely support.) Not being able to cleanly go down to single-user is another matter which can be considered as a normal bug. 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: Please participate in popularity-contest
On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote: Nothing garanties that cron jobs are run at the right time. Running it a bit later (whenever you boot) is just like it being delayed due to excess load. If there are things that shouldn't be run at the wrong time we should find them and protect them in the job itself. Running a job a little later is not a problem. Running a job during work hours when it was scheduled to run during the night _is_ a problem since such jobs can (and usually do) hog both memory and I/O bandwidth, making interactive work difficult. In such cases not running the job for a day or two is way better than running it at a time it was not meant to run; not because it causes damage but because it causes real user inconvenience. 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: SUMMARY: Re: shared library -dev package naming proposal
On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote: Why is this better? I have to change my perfectly normal, standard Unix link command to use something that completely hides the actual link command and makes debugging problems nearly impossible? Exercise: let's say I have an application that uses GSSAPI, and has to be able to be built statically. Requirements: - It should build with Heimdal's libgssapi - It should build with MIT's libgssapi - It should build with Globus GSI All these cases require a completely different set of dependant static libraries even though I'm only using the GSSAPI interface. With libtool, it's trivial, since all the information you need is already expressed in the .la files. Care to explain a method that is - better than libtool - works already (the most important requirement being that Globus must support it out-of-the-box) - not Debian-specific (only a minor set of the target machines runs Debian)? I really don't get it. And, for the record, the company I work for ships code for a variety of Unices. I spend a *lot* more of my time debugging libtool brokenness (not to mention auto* brokeness) than I do tracking down which libraries need which other libraries. So when I say I don't get it, it's not lack of experience with the tools, I'm just completely mystified why people think that libtool is an *improvement*. Well, I have used libtool on a couple of architectures and my opinion is that using libtool is still way more effective than re-inventing it over and over again. Yes, it has bugs (for example the AIX support is notoriously buggy), but they can be fixed just like any other software. 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: SUMMARY: Re: shared library -dev package naming proposal
On Thu, Jul 28, 2005 at 07:05:34AM -0400, Stephen Frost wrote: We've had that discussion before. Last I recall there wasn't really a huge fight to keep them. Well, Debian developers do not really need them. But there are people who do not develop Debian but develop other software _using_ Debian and static linking is important for them (for example, if you have to submit a job to a remote machine where you have no knowledge nor control over what software is installed, you have no other choice than to link everything (except maybe libc) statically into your application). 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: SUMMARY: Re: shared library -dev package naming proposal
On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
I'd think we could come up with a way to detect the version of libtool
in use, somehow. :)
LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH=${LTMAIN_SH_PATH:-.}
grep ^VERSION $LTMAIN_SH_PATH/ltmain.sh | cut -d= -f2
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: SUMMARY: Re: shared library -dev package naming proposal
On Fri, Jul 29, 2005 at 12:06:38PM -0400, Jay Berkenbilt wrote: This is nice, but I think it's not really very autoconfish [tm] in spirit. It is not meant to be autoconfish. It is meant to be run _before_ configure, so you can decide if you have to re-libtoolize the package or not. Also, this invokes autoconf, which we don't necessarily want to do at package build time since this will cause packages to require a build dependency on autotools, a topic which has been discussed at length before. I think I know what you miss: you think about checking the version of the _installed_ libtool package. But that is completely uninteresting as it will _not_ be used during the build. You want to know the libtool version that was used for _generating_ the source package (or upstream tarball). And if that version is wrong, then you have to re-run libtoolize and autoconf anyway, so you do need to have autotools installed. If you do not want to build-depend on autotools then it is too late to check the libtool version at build time (well, you can still check it and generate an explicit FTBFS if it is wrong so forgetting to re-libtoolize the package will be detected more easily). 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: aspell upgrade woes
On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote: Christ, not another one. Is there any sort of automated way that we can check for these sorts of libraries before messing things up again? Theoretically libraries should export only the symbols of their public API, and such a check could be done by looking for C++-mangled names in the list of exported symbols. Practically libraries tend to be rather lousy and also export a lot of internal symbols so you have to manually check if those symbols are meant to be public or not (and if not then are there any applications that use them regardless). For example, both libaspell15 and libglu1-xorg export a lot of C++ symbols that are not meant to be part of the public API... 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: Structured (XML-like) input/output for shell apps?
Hi, On Sat, Jun 11, 2005 at 07:40:10PM +0200, Olaf van der Spek wrote: Many shell apps/scripts output data in tables, for example ls -l, ps aux, top, netstat, etc. At the moment, most of these apps use fixed-width columns with a variable-width last-column. This results in (unnecessary) truncation, for example: Debian- 11918 0.0 0.1 4428 1464 ?Ss Jun05 0:00 /usr/sbin/exim4 -bd -q30m tcp 0 0 TC218-187-80-45.2:35589 bananensaft.inline.:www ESTABLISHEDproxy 153239 Also, because the output isn't structured (in way easily readable by machines), using the data in a script isn't (very) easy and is likely to break due to strict dependency on the syntax. Are there already any plans to solve these issues? Yes. The commands you mention were designed for _human_ consumption. Do not use them in scripts without good reasons. There are a lot of commands to get well-formatted output without truncation. For example, ls has a -n option for exactly this reason; stat(1) can be used instead of ls -l to avoid clipping; ps has a _lot_ of formatting options itself and all the data can be found under /proc in an easily parseable format etc. You just have to select the right tool for the job (that also includes using more powerful scripting languages if the task is complicated). I was thinking, using structured output (and maybe input) in an XML-like way would solve these and allow neat post-processing. XML is just _terrible_ for human input/output. 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: RFC on mysql 4.1 in sarge
On Thu, May 19, 2005 at 02:49:13AM -0700, Steve Langasek wrote: 3 does not sound so bad to me; it's arguably user error anyway to replace a package-provided directory with a symlink in this manner If you consider this an user error, then what is the officially blessed way of relocating a package-prodived directory to a different (already mounted) file system? 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: /usr/lib vs /usr/libexec
On Tue, May 10, 2005 at 05:42:31AM +0200, Bernd Eckenfels wrote: - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing problems for /boot. Why is that? Missing bootloader support. - a larger FS has more chance of failing so you risk having a fully broken system more often And two file systems have even more chance. One read only file system is pretty stable. Sure, that's why I have /usr mounted read-only. - /usr can be easily network (shared accross the same arch) mounted while / (due to /etc) can't - / needs functioning device nodes on it while usr can be mounted nodev I agreee, those arguments and the netboot stuff is an argment for a smaller root partition. However our root filesystem is too big anyway. That's true: $ df -h FilesystemSize Used Avail Use% Mounted on /dev/hda5 99M 75M 19M 80% / [...] $ du -sh /etc/gconf 26M /etc/gconf That's 1/3 of my root fs. It's damn too much. 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: /usr/lib vs /usr/libexec
On Tue, May 10, 2005 at 11:16:54AM +0200, Bernd Eckenfels wrote: the bootloader does not need to access the root filesystem. It only loads the kernel and the initrd from /boot. (I assume that /boot is on /. If not, the following still applies to /boot.) Well, grub _does_ access the filesystem directly so it needs explicit support for every filesystem you want to boot from. I think reiserfs is OK nowadays (I do not use it so I'm not sure). xfs + lilo (from the XFS FAQ): No, for root partition installations because the XFS superblock is written at block zero, where LILO would be installed. This is to maintain compatibility with the IRIX on-disk format, and will not be changed. lvm, raid0, raid5: the boot loader must understand the lvm/raid descriptors to be able to determine where to load the kernel/initrd from (and in case of raid5, it has to be able to reconstruct the data using the parity disk if one of the non-parity chunks is inaccessible). AFAIK neither lilo nor Grub supports these. 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: Minimizing ld dependencies with --as-needed
On Fri, Apr 01, 2005 at 06:01:27AM -0600, Ron Johnson wrote: And since these are (always?) dependencies on shared objects, these libraries never get used, except to say, Here I am!, right? The runtime linker still loads them, which can be expensive (esp. if there are many relocation records), and unneccessarily consumes virtual address space (which can be a problem for applications with large working set on 32-bit systems). 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: Minimizing ld dependencies with --as-needed
On Fri, Apr 01, 2005 at 12:53:27PM +0200, Josselin Mouette wrote: I'm moving all my packages to use it. It's not only a workaround for libtool or pkgconfig bugs, it's also a great tool when some upstream authors gratuitously adds unneeded -l flags. General note: you have to be careful with --as-needed if you link with libraries having global constructors/desctuctors as these can alter the execution of the program even if no symbol is used directly from the library in question. Not many libraries have constructors (at least not many C libraries, with C++ it is much more common) so in the majority of cases this is not an issue, but you have to be aware that you cannot just blindly add --as-needed everywhere. 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: dh_movefiles, tar vs. mv
On Fri, Feb 25, 2005 at 01:14:00PM -0500, Daniel Burrows wrote: Anyway, I thought you were joking in your first message, but it looks like you're serious, so I'll answer this time. If you're copying between files on the same device, mv will use the rename(2) system call, which is an atomic operation: Well, if we are nitpicking, then rename(2) is atomic only in the sense that after it returns, you can either access the old name (if rename failed) or the new name (if it succeeded) (modulo of course journaling, disk write cache, yadda yadda if you want to extend the atomicity over a crash). _But_ it is not neccessarily atomic wrt. other operations, especially getdents(2). So it is equally possible that a readdir(3) during the rename(2) returns the old name, the new name, both or neither, depending on file system implementation and how the parent directory(/ies) is(/are) actually allocated on the disk. Not very important for dh_install, though :-) 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: dh_movefiles, tar vs. mv
On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Kster wrote: Correct. So, why not use mv? Add a new --move flag to dh_installfiles, come up with some exact numbers showing the build time/disk usage savings for your favorite Big Package (hard numbers usually very helpful for promoting new features), and send the numbers together with the patch to the debhelper maintainer. Someone already mentioned that a complex package might want to install the same file to multiple different locations, so making this the default is probably not feasible. 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: what is /.udev for ?
On Thu, Feb 17, 2005 at 01:04:34AM +0100, Marco d'Itri wrote: I do believe that the right thing is to be disabled by default. No. Well, I've just checked and mount --move /dev /temp-mount-point mount --bind /dev /where-you-want-it mount --move /temp-mount-point /dev works on a live system (modulo bug #282205), so you can leave it disabled by default and provide a little helper script to turn it on on request. Of course this is a bad idea as long as 2.4 kernels are officially supported, so in sarge the default should be on, and after sarge the default can be switched to off. 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: First line in /etc/hosts
On Sun, Feb 13, 2005 at 11:21:09AM -0600, John Hasler wrote: Every machine with more than one interface has at least two hostnames: localhost on network 127 and something else on the external networks. Nitpicking: every machine have exactly one hostname, that is contained in /proc/sys/kernel/hostname. The host _may_ have one or more network interfaces, every network interface _may_ have one or more addresses, and those addresses _may_ resolve to domain names (which are also called hostnames, but are completely independent from /proc/sys/kernel/hostname). I think there are two problems here: some packages make assumptions about *the* IP number and/or *the* hostname, and /etc/hosts gets misconfigured either by buggy software or the admin. Well, there is a quite sensible default for desktop machines with just one physical network interface. You just have to realize that this may not work for an increasing number of machines (think about laptops with both a wireless and a TP interface, connected to two different DHCP-managed networks at the same time). The biggest mistake people are used to make is thinking that the contents of /proc/sys/kernel/hostname has _anything_ to do with any address on any network interface, and just blindly use the output of `hostname`. 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: what is /.udev for ?
On Thu, Feb 10, 2005 at 02:08:16AM +0100, Norbert Tretkowski wrote: Remove /.dev/ does not mean rm -rf it. What does it mean instead? It's what politicians do: quote something out-of-context and pretend it means something entirely different than in the original context :-) /etc/init.d/udev has: # if you don't like this, remove /.dev/. [ -d /.dev ] mount -n --bind /dev /.dev Meaning: if you rmdir /.dev _before_ udev is started, then /etc/init.d/udev will not bind-mount the original /dev over it. If you do not know basic shell programming to understand at least that much, then you should better not rm -rf things at random (or at least do not complain about the results). 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: what is /.udev for ?
On Wed, Feb 09, 2005 at 10:46:03PM +0100, Olaf Conradi wrote: I've always found the existence of ./dev a bit weird in a directory listing of /. I'd rather have it in /var/lib/dev, but maybe that's just me ;) ... which would mean that it would become unaccessible (and thus meaningless) as the real /var gets mounted later in the boot process. You cannot reliably put it under a directory that is not guaranteed to be on the root file system; that leaves roughly /, /etc, /bin, /lib and /sbin. Pick your favourite :-) 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]
