Re: seeking new maintainer: lilo
On Sat, 30 Jan 1999, Bernd Eckenfels wrote:
who would liek to take the lilo package over?
There are a few pending bugs, most of the dealing with the lack of an
intelligent install script (which should be included in the bootfloppies,
too).
I'll have a try at it unless nobody else really wants it.
Cordialement,
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-Microsoft est à l'informatique ce que le grumeau est à la crépe... -
Re: stupid stats (was Re: xfree86_3.3.2.3a-9 (source i386 all) uploaded to master)
David Welton wrote: Well, often times, those packages are more complex than single binary packages. No way is epic as difficult to maintain as X, yet, if I'm not mistaken, they each have just one source package. It would be neat to do both stats, and then compare. I actually did the other way first, it wasn't siginificantly different except Brandon Robinson was in 3rd place (X). -- see shy jo
Re: i18n'g the Debian Menu System
Have you looked at how the author of the package intended this to be handled? See /etc/menu-methods/translate-menus. An example from that file: #translate id-title # include /usr/lib/menus/LANGUAGE/finnish # menu/apps/editors TekstVeranderaars #endtranslate This can make translating the actual names of the menus easier. The translation of the menu items probably shouldn't be done this way though. -- see shy jo
Re: cron has gone to UTC time?
On Fri, 29 Jan 1999, Joey Hess wrote: Craig Sanders wrote: i've noticed this behaviour in the past, when xntp gets upgraded in the same dselect run as cron or sysklogd. I doubt this is it because I've experienced the problem on 2 machines; neither runs xntpd or any other time synchronization program. Hit me as well. I noticed when my computer asked why I was up so late and it was only dinner time. Johnie, what happened? I don't see anything in a quick skim of the change logs, nor do I see anything on the bug list. Thanks, Brandon +------+ | Brandon Mitchell * [EMAIL PROTECTED] * http://www.resnet.wm.edu/~bhmit1 | | The above is a completely random sequence of bits, any relation to an | | actual message is purely accidental. |
Re: -rpath with libtool and Debian Linux
use -rpath /usr/lib for their programs. Just to make it clear, since I don't think this has come up yet, /usr/lib isn't the only problem -- /usr/X11R6/lib is as well (or was, at some point; I haven't looked at the upstream XFree86 Imake configuration recently, but it did use --rpath at one point in the libc5 days.) Thus the substitution approach needs to be a slightly more general mapping.
Re: cron has gone to UTC time?
to your cron file that does 'date' and 'date -u'? Set it to run more I haven't seen the problem yet myself, but throw in an env too... I've noted (in a bug report in regard to inetd) that doing apt-get upgrade with sudo or su with a full *user* environment often means that you end up with an incorrect environment for daemons that get upgraded -- cron is vulnerable to the same bug, and probably amenable to a similar fix: use env - TZ=$(cat /etc/timezone) PATH=/sbin start-stop-daemon ... cron instead of just using start-stop-daemon... One could argue that the sysadmin should know better; however, it's a mistake that people have been making since the 4.2BSD days (I've seen this with sendmail and $USER on charon.mit.edu when it was a VAX 11/750, and more recently on an otherwise well-managed Solaris box) that I think we should really (1) prevent the problem in the postinst scripts (2) document such... I'll also note that there's perhaps value to getting start-stop-daemon to do the work (with a --base-environment option?) just for consistency, but it *still* means modifying all the postinst scripts, so why wait...
Re: Intent to package : xmem
I'm pretty sure xmem was in procps or xproc at one point, and got dropped because it wasn't being maintained upstream, or something like that...
Re: Seeking Helmut Geyer Helmut.Geyer@iwr.uni-heidelberg.de
Daniel Martin [EMAIL PROTECTED] writes: Helmut Geyer is listed as the maintainer for xxgdb and bzip - xxgdb hasn't had a maintainer upload since when bo was frozen, and bzip's last maintainer upload was longer ago than that. Mail sent to his listed address goes unanswered, but maybe that's because I only waited a week. Is he still with us? Helmut, are you out there? I don't think he is with the project anymore, he used to be libc6 maintainer and the package had to be taken over from him when he disappeared. Martin.
Re: LyX copyright
On Fri, Jan 29, 1999 at 03:18:18PM -0500, Shaleh wrote: I just learned that the LyX copyright file was corrected to explicitely state that linking against a non-free library is okay. This however wasn't really needed as 'The law is quite clear that the release of the software by the original authors and copyright holders changed the licenses.' AFAIK the new file was written by a lawyer. That allows it to live in contrib -- woopie. Until they have a non forms based GUI, it matters little. It matters to whomever filed the bug report after we did this the first time, obviously. =p Considering that this is the SECOND time we've done this and gotten the same response, hopefully we can call the issue settled now? -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: libtool rpath
Hamish Moffatt [EMAIL PROTECTED] writes: A package I maintain uses libtool. To remove the rpath stuff, I apply this patch to configure.in. Actually, I sort of like the following technique better: Add the following to debian/rules right before calling $(MAKE) all (but after configure): sed libtool libtool-2 \ -e 's/^hardcode_libdir_flag_spec.*$$/hardcode_libdir_flag_spec= -D__L IBTOOL_IS_A_FOOL__ /' \ -e '/^archive_cmds=/s/$$/ \\$$deplibs/' That way, there is no need to patch configure.in and rerun autoconf. Also, because this package (geda) includes a library, debhelper is generating an shlibs file for it. But then the package ends up depending on itself, because of the shlib:Depends expansion. Is there an easy fix for that? Splitting the packages is a possibility, but libgeda is of absolutely no use on its own yet, and I don't think there is anything for a libgeda-dev. Try: LD_LIBRARY_PATH=debian/tmp/usr/lib dh_shlibdeps -V The LD_LIBRARY_PATH prevents ldd from linking to a library that is installed on the system, so dpkg-shlibdeps doesn't find the associated package (so there is no dependency created). Cheers, - Jim
Re: What hack in ld.so?
Buddha Buck [EMAIL PROTECTED] writes: does it know that libc5 and libc6 are incompatable versions of the same library (different sonames), or does it feel that loading two libraries (libfoo, libc6) is better than loading three (libfoo, libc5, libc6). It recognizes libc, libm, and libdl in special code. That is why every shared library must be linked against at least one of those. Guy
Re: [Fwd: [Jikes-License] Jikes Parser Generator now available i
Brent Fulgham [EMAIL PROTECTED] writes: Try Japhar/Classpath: www.japhar.org -- free JDK (compiler, runtime, debugger, etc.) www.classpath.org -- free implementation of the essential java libraries Plus... www.transvirtual.com -- Kaffe JIT www.mozilla.org -- ElectricalFire JIT Cheers, - Jim
Re: /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version
Ivan E. Moore II [EMAIL PROTECTED] writes: /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version This happens with some of the GNOME based packages I've installed from both slink and potatoe lately... Any ideas what I'm missing or what I did??? You probably have mixed some of the 0.99.x packages and the 0.30 packages. Cheers, - Jim
Re: Call for mascot! :-)
Ben Pfaff [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Martin Bialasinski) writes: Hmm, with a strong enough improbability field, you will see dragons in the sky. Dragons and octopi in the sky are Somebody Else's Problem. Flying Octopi? Sounds like a Detroit Red Wings game... Cheers, - Jim
Re: Getting Slink compatible with Linux-2.2.0
Avery Pennarun [EMAIL PROTECTED] writes: Six orders of magnitude?? Bandwidth and latency are not the same thing. Guy
Re: /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version
On Sat, Jan 30, 1999 at 12:07:29AM -0800, Jim Pick wrote: /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version You probably have mixed some of the 0.99.x packages and the 0.30 packages. ---end quoted text--- yup..after digging and playing I found out that some of the programs I am using want 0.30 stuff and some want 0.99 stuff...and one cancels out the other basically..it's whacky.. Ivan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ivan E. Moore II Rev. Krusty http://www.tdyc.com [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Imagination is more important than knowledge - Albert Einstien -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- GPG KeyID=0E1A75E3 GPG Fingerprint=3291 F65F 01C9 A4EC DD46 C6AB FBBC D7FF 0E1A 75E3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: seeking new maintainer: lilo
On Sat, Jan 30, 1999 at 12:35:31AM +0100, Bernd Eckenfels wrote: Hello, who would liek to take the lilo package over? There are a few pending bugs, most of the dealing with the lack of an intelligent install script (which should be included in the bootfloppies, too). I wouldn't mind taking lilo, package does not look too complex (other than that I will need to make sure I have a few good boot floppies in case a version fails to work properly when I test it...) Looks like a fun package to work with, actually.. -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: gnuserv/gnuclient problem
Amos Shapira [EMAIL PROTECTED] writes: On Fri, January 29 1999, Ionutz Borcoman [EMAIL PROTECTED] wro te: |Hi, | |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions |from potato I am no more able to start a gnuclient :-( Is anybody else |experiencing this ? I've reported this bug with slink months ago with no response. I still can't use gnuclient with xemacs under slink. It seems to work for me here (gnuclient.xemac20) ii xemacs20-bin20.4-13Editor and kitchen sink -- support binaries ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule binary ii xemacs20-suppor 20.4-13Editor and kitchen sink -- architecture inde ii xemacs20-suppor 20.4-13Editor and kitchen sink -- non-required libr Cheers, - Jim
Re: LyX copyright
On Fri, Jan 29, 1999 at 03:18:18PM -0500, Shaleh wrote: That allows it to live in contrib -- woopie. Until they have a non forms based GUI, it matters little. But noone will ask for the removal of LyX anymore. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Conflicts in libgtk*-dev
Am I overlooking something obvious here? libgtk1.1.13-dev provides libgtk-dev and libgtk1.1-dev but libgtk1.1-dev conflicts with libgtk-dev this means that gnome-apt refuses to install libgtk1.1.13-dev, a package that I sorely need. Aren't these relationships somewhat odd. -- Eschew obfuscation(go on; look them both up) (Brian White) [EMAIL PROTECTED] [-: .elOle. :-] [EMAIL PROTECTED]
Re: Conflicts in libgtk*-dev
On 30 Jan 1999, Ole J. Tetlie wrote: Am I overlooking something obvious here? libgtk1.1.13-dev provides libgtk-dev and libgtk1.1-dev but libgtk1.1-dev conflicts with libgtk-dev this means that gnome-apt refuses to install libgtk1.1.13-dev, a package that I sorely need. Aren't these relationships somewhat odd. Nothing odd there. libgtk1.1-dev conflicts with libgtk-dev so that it won't be installed at the same time as any other package which provides: libgtk-dev. In fact, all the libgtk*-dev packages should provide: libgtk-dev and conflict:libgtk-dev - so only one can be installed at any time. For example: pear# apt-get install libgtk1.1.13-dev Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: libglib1.1.13-dev The following packages will be REMOVED: libgtk-dev The following NEW packages will be installed: libglib1.1.13-dev libgtk1.1.13-dev 0 packages upgraded, 2 newly installed, 1 to remove and 0 not upgraded. Need to get 893k of archives. After unpacking 1186k will be used. Do you want to continue? [Y/n] Looks fine to me.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: /usr/lib/apt/methods/http - close(-1)
Russell Coker [EMAIL PROTECTED] writes: What is a close(-1) supposed to do? The http program does one and I'm curious as to why... It usually means someone isn't checking the return value from open/socket/etc... -- http://www.greenend.org.uk/rjk/
Re: Conflicts in libgtk*-dev
*-Jules Bean [EMAIL PROTECTED] | | On 30 Jan 1999, Ole J. Tetlie wrote: | | Am I overlooking something obvious here? | | libgtk1.1.13-dev provides libgtk-dev and libgtk1.1-dev | | but | | libgtk1.1-dev conflicts with libgtk-dev | | this means that gnome-apt refuses to install libgtk1.1.13-dev, | a package that I sorely need. Aren't these relationships somewhat odd. | | Nothing odd there. | | libgtk1.1-dev conflicts with libgtk-dev so that it won't be installed at | the same time as any other package which provides: libgtk-dev. OK, I have probably misunderstood something. libgtk1.1-dev conflicts with libgtk-dev, and does not provide libgtk-dev. I read the packaging-manual in a way that makes it impossible to install _any_ package that provides both. The relevant sections(?): When one package declares a conflict with another dpkg will refuse to allow them to be installed on the system at the same time. A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing something. -- ...Unix, MS-DOS, and MS Windows (also known as the Good, the Bad, and the Ugly). (Matt Welsh) [EMAIL PROTECTED] [-: .elOle. :-] [EMAIL PROTECTED]
Re: Conflicts in libgtk*-dev
On 30 Jan 1999, Ole J. Tetlie wrote: *-Jules Bean [EMAIL PROTECTED] | | On 30 Jan 1999, Ole J. Tetlie wrote: | | Am I overlooking something obvious here? | | libgtk1.1.13-dev provides libgtk-dev and libgtk1.1-dev | | but | | libgtk1.1-dev conflicts with libgtk-dev | | this means that gnome-apt refuses to install libgtk1.1.13-dev, | a package that I sorely need. Aren't these relationships somewhat odd. | | Nothing odd there. | | libgtk1.1-dev conflicts with libgtk-dev so that it won't be installed at | the same time as any other package which provides: libgtk-dev. OK, I have probably misunderstood something. libgtk1.1-dev conflicts with libgtk-dev, and does not provide libgtk-dev. I read the packaging-manual in a way that makes it impossible to install _any_ package that provides both. No. The fact that the *actual* libgtk1.1-dev package conflicts with libgtk-dev, does not mean that the package libgtk1.13-dev, which provides libgtk1.1-dev, must conflict with libgtk-dev. Or, in the abstract: If A conflicts with B, and C provides A, then C need not conflict with B. The relevant sections(?): When one package declares a conflict with another dpkg will refuse to allow them to be installed on the system at the same time. A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing something. -- ...Unix, MS-DOS, and MS Windows (also known as the Good, the Bad, and the Ugly). (Matt Welsh) [EMAIL PROTECTED] [-: .elOle. :-] [EMAIL PROTECTED] /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Conflicts in libgtk*-dev
*-Jules Bean [EMAIL PROTECTED] | | The fact that the *actual* libgtk1.1-dev package conflicts with | libgtk-dev, does not mean that the package libgtk1.13-dev, which provides | libgtk1.1-dev, must conflict with libgtk-dev. | | Or, in the abstract: | | If A conflicts with B, and C provides A, then C need not conflict with B. So this would imply that gnome-apt is wrong to deny me installing libgtk1.1.13-dev, right? -- The only way tcsh rocks is when the rocks are attached to its feet in the deepest part of a very deep lake. (Linus Torvalds) [EMAIL PROTECTED] [-: .elOle. :-] [EMAIL PROTECTED]
Re: Conflicts in libgtk*-dev
On 30 Jan 1999, Ole J. Tetlie wrote: *-Jules Bean [EMAIL PROTECTED] | | The fact that the *actual* libgtk1.1-dev package conflicts with | libgtk-dev, does not mean that the package libgtk1.13-dev, which provides | libgtk1.1-dev, must conflict with libgtk-dev. | | Or, in the abstract: | | If A conflicts with B, and C provides A, then C need not conflict with B. So this would imply that gnome-apt is wrong to deny me installing libgtk1.1.13-dev, right? Yup. As I demonstrated in my first message, plain apt will let you do it.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Call for mascot! :-)
* Chris Waters (Thu, Jan 28, 1999 at 10:14:15AM -0800) 1. Dragon Aye! -- SSM - Stig Sandbeck Mathisen Trust the Computer, the Computer is your Friend pgpBVRhU7iSbR.pgp Description: PGP signature
Re: libtool rpath
On Fri, Jan 29, 1999 at 11:39:27PM -0800, Jim Pick wrote: Hamish Moffatt [EMAIL PROTECTED] writes: A package I maintain uses libtool. To remove the rpath stuff, I apply this patch to configure.in. Actually, I sort of like the following technique better: [...] That way, there is no need to patch configure.in and rerun autoconf. In the past I needed other changes to configure.in, so it was the best way. I no longer need them, so I've moved the patch to debian/rules (as you suggested), which works well. Try: LD_LIBRARY_PATH=debian/tmp/usr/lib dh_shlibdeps -V The LD_LIBRARY_PATH prevents ldd from linking to a library that is installed on the system, so dpkg-shlibdeps doesn't find the associated package (so there is no dependency created). Interesting solution. I decided to split the packages instead (Santiago reminds me that policy requires it presently.) This created some other problems of a similar nature but I have since sorted those out. Thanks, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
suggestion: www.debian.org package list show the URL of the program
how hard would it be to have the Packages pages on the Debian web site show the packages home URL, i.e. where the author is? A few times I have been hunting for this because I needed a bsd or Sun version of a program. Downloading the orig.tar.gz and looking inside can be cumbersome.
Re: suggestion: www.debian.org package list show the URL of the program
Shaleh == Shaleh [EMAIL PROTECTED] writes: Shaleh how hard would it be to have the Packages pages on the Debian Shaleh web site show the packages home URL, i.e. where the author is? Shaleh A few times I have been hunting for this because I needed a Shaleh bsd or Sun version of a program. Downloading the orig.tar.gz Shaleh and looking inside can be cumbersome. Relatively hard, unless we could make an official (optional) dpkg field for the URL, and/or -- dare I imagine it? -- the Freshmeat appindex number - PGP E4 70 6E 59 80 6A F5 78 63 32 BC FB 7A 08 53 4C __ _Debian GNU Johnie Ingram [EMAIL PROTECTED] mm mm / /(_)_ __ _ ___ __ www.netgod.net irc.debian.org mm mm / / | | '_ \| | | \ \/ / m m m / /__| | | | | |_| |World Domination, of course. mm mm \/_|_| |_|\__,_/_/\_\ And scantily clad females. GO BLUE
Re: suggestion: www.debian.org package list show the URL of the program
Shaleh [EMAIL PROTECTED] writes: how hard would it be to have the Packages pages on the Debian web site show the packages home URL, i.e. where the author is? A few times I have been hunting for this because I needed a bsd or Sun version of a program. Downloading the orig.tar.gz and looking inside can be cumbersome. Perhaps the website could mirror the copyright file from each package. This contains the copyright notice from the source as well as the upstream URL. -- MONO - Monochrome Emulation This field is used to store your favorite bit. --FreeVGA Attribute Controller Reference
Re: suggestion: www.debian.org package list show the URL of the
On 30-Jan-99 Johnie Ingram wrote: Shaleh == Shaleh [EMAIL PROTECTED] writes: Shaleh how hard would it be to have the Packages pages on the Debian Shaleh web site show the packages home URL, i.e. where the author is? Shaleh A few times I have been hunting for this because I needed a Shaleh bsd or Sun version of a program. Downloading the orig.tar.gz Shaleh and looking inside can be cumbersome. Relatively hard, unless we could make an official (optional) dpkg field for the URL, and/or -- dare I imagine it? -- the Freshmeat appindex number Depends on a) it being on freshmeat, and b) freshmeat being up and functional. Both are questionable. The URL is stored in the debian/copyright file. Grabbing it from the diff.gz should not be horribly complicated. Especially with debhelper and others using URL -- in the copyright file.
Re: gnuserv/gnuclient problem
In article [EMAIL PROTECTED], Ionutz Borcoman [EMAIL PROTECTED] wrote: Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions from potato I am no more able to start a gnuclient :-( Is anybody else experiencing this ? There have been various problems reported with gnuclient/gnuserv and XEmacs, one by me ;) XEmacs and the 'gnuserv' package do not appear to mix well. This is one problem. Try running 'gnuclient.xemacs20' instead of just 'gnuclient' and see if that helps. I assure you, gnuclient *does* work in XEmacs 20 for some people, I'm sure your problems can be fixed... SRH -- Life's been like dragging feet through sand and never finding the promised land[queensrÿche]
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Enrique Zanardi [EMAIL PROTECTED] writes: On Sun, Jan 31, 1999 at 12:21:00AM +1100, Martin Mitchell wrote: Adam Di Carlo [EMAIL PROTECTED] writes: Package: dpkg Version: 1.4.0.31 Severity: important Please remove the following methods (based on disk): harddisk mounted cdrom nfs These methods are obsolete and buggy. Harddisk/mounted are replaced by dpkg-multicd and apt methods. CDROM is also replaced by dpkg-multicd; in fact, this CDROM method doesn't even *work* anymore with slink since CD-ROMs span two devices. I strongly object to removing all of those except cdrom. I don't find apt adequate for my needs at this stage. What about dpkg-multicd? I have no objection to cdrom being replaced with dpkg-multicd. Removing features to remove bugs is not a proper solution to reducing dpkg's bugs. Ian, please refrain from removing these features, which are still essential. I don't see anything essential in them. There are a lot of methods available on slink (and slink's base system) that work as well than dpkg default methods. Remember that dselect isn't just used to install the system, you also need to maintain it. I don't find the apt method an appropriate tool at this stage for maintenance. Where it excels at present is in the initial installation. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. This should be done in the future, but not at the moment, certainly not just before slink's release. That way only the few users that still don't find any other method adequate for their needs will have to install that package, and have those methods listed in the already crowded dselect's access method menu. I don't call the 6 options currently in my dselect's access menu crowded, I'd say it was flexible. Martin.
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On Sun, Jan 31, 1999 at 02:21:38AM +1100, Martin Mitchell wrote: Enrique Zanardi [EMAIL PROTECTED] writes: On Sun, Jan 31, 1999 at 12:21:00AM +1100, Martin Mitchell wrote: I strongly object to removing all of those except cdrom. I don't find apt adequate for my needs at this stage. What about dpkg-multicd? I have no objection to cdrom being replaced with dpkg-multicd. But dpkg-multicd is more than multiple-cds. There's multi-nfs, multi-mount, ... that replace nfs, mounted, ... That's why we think dpkg default methods can be removed/extracted to a different package. I don't see anything essential in them. There are a lot of methods available on slink (and slink's base system) that work as well than dpkg default methods. Remember that dselect isn't just used to install the system, you also need to maintain it. I don't find the apt method an appropriate tool at this stage for maintenance. Where it excels at present is in the initial installation. Why do you think it's not suited for maintenance? I've been using it on a lot of machines here for ~6 months (with a local mirror, ftp access or http access) and it works a lot better than the other methods. Using autofs it even works with an NFS mounted mirror. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. This should be done in the future, but not at the moment, certainly not just before slink's release. Sounds reasonable. But it should be done for potato. I don't call the 6 options currently in my dselect's access menu crowded, I'd say it was flexible. If some of those options don't work, some are duplicated, and there's no way to get rid of them, that's crowded. -- Enrique Zanardi[EMAIL PROTECTED]
RE: suggestion: www.debian.org package list show the URL of the
D'uh. The copyright file is one of those itsy bitsy links on the lower left. On 30-Jan-99 Shaleh wrote: how hard would it be to have the Packages pages on the Debian web site show the packages home URL, i.e. where the author is? A few times I have been hunting for this because I needed a bsd or Sun version of a program. Downloading the orig.tar.gz and looking inside can be cumbersome. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suggestion: www.debian.org package list show the URL of the program
On Sat, Jan 30, 1999 at 10:13:38AM -0500, Ben Pfaff wrote: Shaleh [EMAIL PROTECTED] writes: how hard would it be to have the Packages pages on the Debian web site show the packages home URL, i.e. where the author is? A few times I have been hunting for this because I needed a bsd or Sun version of a program. Downloading the orig.tar.gz and looking inside can be cumbersome. Perhaps the website could mirror the copyright file from each package. This contains the copyright notice from the source as well as the upstream URL. The copyright files are already available. Unfortunately, many packages don't include the programs homepage. It would be nice if we could put the programs url on the page explicitly, if one exists. The problem is that there is no standard place or format for this. Sure some packages include it in the copyright file, but it is not in a standard format which makes it difficult to extract (grabbing the first url in the copyright file is prone to error given the lack of a standard format). I have been advocating for the creation of a standard place for information such as this for a long time. The information does not need to go into the archives Packages file (they are large enough as it is), as long as it can be extracted from a .deb in a known way. If any of you know of a good way to do this, please bring it up on debian-policy. Jay Treacy
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Jules Bean [EMAIL PROTECTED] writes: On 31 Jan 1999, Martin Mitchell wrote: Adam Di Carlo [EMAIL PROTECTED] writes: Package: dpkg Version: 1.4.0.31 Severity: important Please remove the following methods (based on disk): harddisk mounted cdrom nfs These methods are obsolete and buggy. Harddisk/mounted are replaced by dpkg-multicd and apt methods. CDROM is also replaced by dpkg-multicd; in fact, this CDROM method doesn't even *work* anymore with slink since CD-ROMs span two devices. I strongly object to removing all of those except cdrom. I don't find apt adequate for my needs at this stage. [...] Removing features to remove bugs is not a proper solution to reducing dpkg's bugs. Ian, please refrain from removing these features, which are still essential. Would you outline the ways in which apt is not adequate to your needs, and these packages are? 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. Martin.
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On 31 Jan 1999, Martin Mitchell wrote: 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) Hm. I'm pretty sure the apt with a file:/ URL doesn't copy, it installs straight from the remote. Or is this not true? 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. What problems does apt give? (I assume you're running dpkg-scanpackages to build local packages file?) Incidentally, I'm not claiming Martin's objections are foundless. I'm interested to see what limitations apt has (and then we can request them as features). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: gnuserv/gnuclient problem
Jim Pick [EMAIL PROTECTED] writes: Amos Shapira [EMAIL PROTECTED] writes: On Fri, January 29 1999, Ionutz Borcoman [EMAIL PROTECTED] wro te: |Hi, | |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions |from potato I am no more able to start a gnuclient :-( Is anybody else |experiencing this ? I've reported this bug with slink months ago with no response. I still can't use gnuclient with xemacs under slink. It seems to work for me here (gnuclient.xemac20) ii xemacs20-bin20.4-13Editor and kitchen sink -- support binaries ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule binary ^ The problem only shows up with the mule versions of xemacs. Steve [EMAIL PROTECTED]
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Jules Bean [EMAIL PROTECTED] writes: On 31 Jan 1999, Martin Mitchell wrote: 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) Hm. I'm pretty sure the apt with a file:/ URL doesn't copy, it installs straight from the remote. Or is this not true? 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. What problems does apt give? (I assume you're running dpkg-scanpackages to build local packages file?) Having to run dpkg-scanpackages manually is a bit of a pain Dpkg-mountable asks for a local package directory and will then scan it automatically every time. Having to work out that you need to run the following every time you update the local packages file dpkg-scanpackages . /dev/null | gzip Packages.gz and then add the following to your sources.list file: deb file:///usr/local/debian-archive/ / takes some working out. Answering yes to the question generate a package file for me is easier. Including the above information in the manual - if it hasn't found its way there would be a useful start. Incidentally, I'm not claiming Martin's objections are foundless. I'm interested to see what limitations apt has (and then we can request them as features). One other point. It isn't immediately obvious from the web site that you can intall directly by ftp[1] without manually downloading the packages you need and then installing them as separate steps. The web site links to ftp://ftp.debian.org/debian/dists/stable/main/disks-i386/current/ch-install-methods.html which doesn't mention installing using ftp as a possibility (and neither do the frozen and unstable versions). Writing some notes for this bit of the document would be useful[2] (if it is thought that apt is ready for this sort of use). [1]Useful in UK academia where you have a fast network connection to a mirror site. [2] I wish I had the time to do this. Chris
Re: Conflicts in libgtk*-dev
Ole == Ole J Tetlie [EMAIL PROTECTED] writes: Ole Am I overlooking something obvious here? libgtk1.1.13-dev Ole provides libgtk-dev and libgtk1.1-dev Ole but Ole libgtk1.1-dev conflicts with libgtk-dev libgtk1.1-dev is really an obsolete package in potato. Think of it as a sort of libgtk1.1.12-dev. libgtk1.1.13-dev rightly conflicts with it, as you can't have multiple versions of -dev packages for the same library installed at the same time (they all share /usr/lib/libgtk-1.1.so !) Ben -- Brought to you by the letters F and T and the number 5. You have my pills! Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
Re: Call for mascot! :-)
On Thu, Jan 28, 1999 at 10:14:15AM -0800, Chris Waters wrote: snip I brought this up on IRC, and got the following suggestions: 1. Dragon (well-liked choice on IRC) 2. Octopus (my own suggestion) 3. Monkey 4. Ant 5. Bee Personally, I think octopi are really cute, they're smart (for invertebrae), and I kind of like the symbolism of many arms working together as part of a whole, but perhaps I'm a little crazy. :-) Yes, that you are.. I say we should go for a nice feline, perhaps a tiger cub? Then again, I'm quite insane.. =:] Zephaniah E. Hull. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file. -- PGP EA5198D1-Zephaniah E, Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. pgpm4eG8MRmUp.pgp Description: PGP signature
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On Sat, 30 Jan 1999, Enrique Zanardi wrote: On Sun, Jan 31, 1999 at 02:21:38AM +1100, Martin Mitchell wrote: Enrique Zanardi [EMAIL PROTECTED] writes: What about dpkg-multicd? I have no objection to cdrom being replaced with dpkg-multicd. But dpkg-multicd is more than multiple-cds. There's multi-nfs, multi-mount, ... that replace nfs, mounted, ... That's why we think dpkg default methods can be removed/extracted to a different package. I still use nfs or mounted (I have /sunsite always pointing to sunsite, which is where I get my packages from) and dselect. It's always worked fine for me, so I feel no need to change. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. So then I have to download a bunch of packages if I want to grab a package of my CD, or use nfs, or ftp for when I want something from incoming I don't call the 6 options currently in my dselect's access menu crowded, I'd say it was flexible. If some of those options don't work, some are duplicated, and there's no way to get rid of them, that's crowded. The ones that don't work should be removed, but there should be backwards compatibility in the interface (i.e. people who have used cd/ftp/nfs/mounted depending on circumstances should be able to use all of these as the need takes them without having to install loads of packages) YMMV though, Matthew -- Elen sila lumenn' omentielvo [EMAIL PROTECTED], Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
but I haven't heard any technical reasons besides, Moving spool directories is hard. When I and others have pointed out that moving the spool directory isn't required; just a symlink, I have heard dead silence. So the lack of technical discussion, but just a stony-silence No! is rather disappointing as far as I'm concerned. One simple one - I want my mail on the spool disk. Its in the grows randomly, mostly crap, doesnt cause hassle if it fills for a while category I have no problem with a both paths must one work one or more may be a symlink. At that point however the FHS should mandate one which may be a symlink only. Right now everyone uses /var/spool/mail whats the technical reason for using /var/mail that is good enough to justify the change ? Okay... to summary what I have seen (this being the third time that this list has gone over the /var/mail vs /var/spool/mail issue.) Technical reasons for making the change; a. Compatibility with the majority of existing unix systems. b. See a. It can not be stressed enough. If FHS is ever to get OUT of the Linux camp it's going to have to cause Linux to look more like other unix systems and less like Linux. c. Removal of the special case for Linux in many public domain/freeware software, though this should already be handled via paths.h if the application is written with portability considerations. d. BSD based systems basically made this same change over 15 years ago. It was no real big deal. /usr/spool - /var/spool, then 2 releases later /var/spool/mail - /var/mail. [If my grey matter is recalling history correctly, it was 4.2BSD on the first move and some place close to 4.3Tahoe on the second. Thats it, not a lot of reasons, but IMHO it's A and B that are the real justifiable reasons. -- Rod Grimes - KD7CAX - (RWG25) [EMAIL PROTECTED] Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com
Re: suggestion: www.debian.org package list show the URL of the program
** Please trim the recipient list as appropriate if you reply. Please, don't CC me if you're responding to this message on this list. ** On Sat, Jan 30, 1999 at 10:52:07AM -0500, James A. Treacy wrote: The copyright files are already available. The changelog and copyright file links do not seem to work for all packages. Trying to fetch mixal's copyright file or changelog results in pages like this: No such copyright file and No such changelog mixal I checked; it works for none of my packages but works for many others. Is this my bug or your bug? These packages failed: guitar, chase, libmalaga1, libmalaga-dev, mixal, yard, malaga-bin, malaga-doc, nosql-doc. Many others did not. I checked only a small number of packages. Sure some packages include it in the copyright file, I usually include it in README.Debian. (grabbing the first url in the copyright file is prone to error given the lack of a standard format). My first URL is usually the upstream tarball URL. A good place for the URL would be the control file, IMHO. It's already designed to be machine-parseable, whereas debian/copyright and README.Debian are not. Antti-Juhani -- Antti-Juhani Kaijanaho A7 [EMAIL PROTECTED] ** URL:http://www.iki.fi/gaia/ ** The FAQ is your friend. Trust the FAQ.
Re: Installation Profiles [was: Re: Reality check!]
[ redundant emacs versions ] Well, I'll suggest that for potato. It will start a nice flame-war on debian-devel emacs vs. xemacs. Hey, that's just what we need at this stage for *slink*! :-) Okay, let's be serious again: unfortunately this actually means that some of the most obvious installation profiles of slink stay to be unnecessarily bloated. I consider this to be a bad move because the initial install is something like Debian's advertisement plate (or visiting card) and the installation of three emacs variants gives a rather bad impression IMHO. I mean, who would *really* want to have *three* emacs variants installed at once and above all right at the first installation stage? Especially given I have never been able to get emacs19 and emacs20 to coexist on a debian system: emacs19 works, but it's config script always fails, and so it is flagged as 1/2 configured. I only use it for reading GROGGS, so I guess that doesn't matter too much. Matthew -- Elen sila lumenn' omentielvo [EMAIL PROTECTED], Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
Technical reasons for making the change; a. Compatibility with the majority of existing unix systems. Incompatibility with the majority of Linux systems. Incompatibility with the majority of Linux packages. b. See a. It can not be stressed enough. If FHS is ever to get OUT of the Linux camp it's going to have to cause Linux to look more like other unix systems and less like Linux. Thats an argument for saying there are these symlinks. We specify no more. Not for changing c. Removal of the special case for Linux in many public domain/freeware software, though this should already be handled via paths.h if the application is written with portability considerations. Those applications are already present d. BSD based systems basically made this same change over 15 years ago. It was no real big deal. /usr/spool - /var/spool, then /var/spool was done by Sun and for very big technical reasons - sharable /usr You still don't have a leg to stand on. --- Now something more productive. These are the points being recycled We've proved: a) People want to put their mail where they like it. b) Where you put mail is application dependant FHS 2.0 has mandated /var/mail, the entire vendor population regards it as unacceptable hassle to change, as does the user base in general. In some environments /var/mail helps compatibility with nonLinux --- I'd like to propose that for now the FHS is changed to read The mail spool area location is undefined. It is guaranteed that both /var/mail and /var/spool/mail point to this mail spool area if the system has a mail spool. The preferred reference name is /var/mail. [Rationale: /var/mail is the only name available on some other modern Unix platforms. /var/spool/mail is the older Linux tradition and needed for compatibility] [Rationale2: The physical location of the mail spool is not relevant to an application and is administrator policy. It is thus left open.] Can everyone live with that and bury the thread Alan
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
[ Please, don't CC: me. I'm subscribed to -devel, -boot and -testing. Three copies of the same message are enough. ;-) ] [ Also, I've trimmed down the CC list, as I think this thread is being cross-posted to too many lists... ] On Sat, Jan 30, 1999 at 06:03:54PM +, M.C. Vernon wrote: On Sat, 30 Jan 1999, Enrique Zanardi wrote: But dpkg-multicd is more than multiple-cds. There's multi-nfs, multi-mount, ... that replace nfs, mounted, ... That's why we think dpkg default methods can be removed/extracted to a different package. I still use nfs or mounted (I have /sunsite always pointing to sunsite, which is where I get my packages from) and dselect. It's always worked fine for me, so I feel no need to change. Don't do that then. But not every Debian user feels the same. As there are a lot of different methods available, there should be a way to remove the default ones. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. So then I have to download a bunch of packages if I want to grab a package of my CD, or use nfs, or ftp for when I want something from incoming Two (dpkg and dpkg-defaults) are not a bunch, are they? I proposed just _one_ new package (dpkg-defaults) that provides all those methods. If some of those options don't work, some are duplicated, and there's no way to get rid of them, that's crowded. The ones that don't work should be removed, but there should be backwards compatibility in the interface (i.e. people who have used cd/ftp/nfs/mounted depending on circumstances should be able to use all of these as the need takes them without having to install loads of packages) As I said, those people will have to install just one new package, not loads of them. And the people that don't use those methods will be able to remove them. It's all about freedom of choice. -- Enrique Zanardi[EMAIL PROTECTED]
Re: suggestion: www.debian.org package list show the URL of the program
On Sat, Jan 30, 1999 at 08:08:49PM +0200, Antti-Juhani Kaijanaho wrote: On Sat, Jan 30, 1999 at 10:52:07AM -0500, James A. Treacy wrote: The copyright files are already available. The changelog and copyright file links do not seem to work for all packages. Trying to fetch mixal's copyright file or changelog results in pages like this: The files are only available for those packages that lintian has a laboratory for on master. I have no idea why the packages you listed don't have one - contact the lintian maintainer to find out why. Sure some packages include it in the copyright file, I usually include it in README.Debian. (grabbing the first url in the copyright file is prone to error given the lack of a standard format). My first URL is usually the upstream tarball URL. Exactly my point. It's not standardized. Until there is a standardized way to access them they won't be made available. Jay Treacy
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On Sun, Jan 31, 1999 at 03:00:01AM +1100, Martin Mitchell wrote: Jules Bean [EMAIL PROTECTED] writes: Would you outline the ways in which apt is not adequate to your needs, and these packages are? 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. I use apt's file: method on an NFS mounted mirror, and it doesn't copy anything before installing, it just reads the packages directly as if they were on the local disk (heck, that's what NFS is for, isn't it?). Using autofs I don't even have to remember mounting the mirror before using dselect. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. To use your local mirror with apt you just need to build a Packages file (using dpkg-scanpackages). -- Enrique Zanardi[EMAIL PROTECTED]
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On 30 Jan 1999, Chris Walker wrote: [1]Useful in UK academia where you have a fast network connection to a mirror site. In Uk academia, the most useful site is http://sunsite.doc.ic.ac.uk/packages/debian g J /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Crack? Cops?
I noticed in my slink snapshot (from last month) that 'cracklib2' exists, 'crack-dict' is suggested but *doesn't* exist (either as a package or in the 'Packages' list), and 'crack' is nowhere to be seen. Is the omission of 'crack' deliberate, or does it need a maintainer? US export policy should be no more of a problem than it is with /bin/passwd and /bin/login. On a related note, I noticed that 'cops' is absent. Again, is this deliberate or does it need a maintainer? Neither package is listed on the prospective packages. Bear Giles [EMAIL PROTECTED]
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Sat, 30 Jan 1999, Alan Cox wrote: I'd like to propose that for now the FHS is changed to read The mail spool area location is undefined. It is guaranteed that both /var/mail and /var/spool/mail point to this mail spool area if the system has a mail spool. The preferred reference name is /var/mail. [Rationale: /var/mail is the only name available on some other modern Unix platforms. /var/spool/mail is the older Linux tradition and needed for compatibility] [Rationale2: The physical location of the mail spool is not relevant to an application and is administrator policy. It is thus left open.] Can everyone live with that and bury the thread Works for me. Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Hello, Warning ! this is potato talk. On Sat, Jan 30, 1999 at 04:12:05PM +, Jules Bean wrote: On 31 Jan 1999, Martin Mitchell wrote: 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Not / copy everything - should be an option. It is good if you have the space and slow a connection. Hm. I'm pretty sure the apt with a file:/ URL doesn't copy, it installs straight from the remote. Or is this not true? I have used NFS from local mirror and over a slow link, that worked ok. I also used the mirror to install from local file sysem. The problem with mirror is that it moves lots of stuff that I never use. I now use Apt set for http access from a local Squid proxy. It save diskspace and transfer over Mirror and I am always working with the most current files. There are things that could be done using squid like this, virtual mirrors, cache_peer options for load balancing, addjustable disk use and update rules. One could set up a virtual file system as a front end to it ... etc. It would be good to have an apsolute URL for each file and not server dependent URLs. I also recomend that we stop using deb files and make each package a directory so as not to have to transfer the lot when there is only a change to a single file. I also think we should split the Package-file into a director structure and start thinking in terms of object-oriented design. Then again. The user inserts a floppy into a virgin box, and ends up with a installed system. The support floppy for a CDROM install is the CDROM install floppy. The install floppy for networked computer is the ethernet install floppy and the rest is the hacker you can do-it floppy. And lets have no talk of hosts, access methods, and package selection. Best [EMAIL PROTECTED] this.is/ragnar
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
Alan Cox [EMAIL PROTECTED]: I'd like to propose that for now the FHS is changed to read The mail spool area location is undefined. It is guaranteed that both /var/mail and /var/spool/mail point to this mail spool area if the system has a mail spool. The preferred reference name is /var/mail. [Rationale: /var/mail is the only name available on some other modern Unix platforms. /var/spool/mail is the older Linux tradition and needed for compatibility] [Rationale2: The physical location of the mail spool is not relevant to an application and is administrator policy. It is thus left open.] Can everyone live with that and bury the thread Works for me, too. -- a href=http://www.tuxedo.org/~esr;Eric S. Raymond/a If a thousand men were not to pay their tax-bills this year, that would ... [be] the definition of a peaceable revolution, if any such is possible. -- Henry David Thoreau
Bug#32595: - Big Business
On Sat, 30 Jan 1999, Gudmundur Ragnar wrote: ... I also recomend that we stop using deb files and make each package a directory so as not to have to transfer the lot when there is only a change to a single file. From a users pov, :) Why not go back a step (or two) and have the source online, with scripts to make it look like the files, debs, etc. are online. ... Hmmm, I wonder if those companies that build you a box to spec are interested in providing the resources for a build-it from the OS and hardware up project. ... How far along would such a project need to be before they would become interested? Could Debian handle the `master plan' approach required(?) for such an undertaking? later, Bruce
Re: Installation Profiles [was: Re: Reality check!]
Paul Seelig writes: Myself i do prefer XEmacs over all other variants but wouldn't mind if i had to install it later on my own. I prefer emacs, bu I also wouldn't mind if i had to install it later on my own. In fact, I would not mind at all if emacs was optional. IMHO it would be much wiser to provide a useful *minimum* in each category upon which people can base their own choices. That is what I originally thought the profiles were for. As it stands Basic is far too basic for being an acceptable minimum and the other profiles are far beyond being a truly useable minimum. Might it be possible to include fewer packages in each profile and then present the user with a list of additional packages that might be of interest to them given that they have chosen this particular profile? Something like You have installed the Scientific Workstation profile. The following additional packages may be of interest ... -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
Re: -rpath with libtool and Debian Linux
On Jan 29, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote: Didn't we decide that all of the available alternatives that you have suggested are not a feasable solution (does this mail help make it clear why)? On 29 Jan 1999, Alexandre Oliva wrote: You may have missed the ugly one I was referring to, that I suggested in the very beginning of this discussion, that would work even for packages that were distributed with older versions of libtool: configure the packages to use a gcc or ld wrapper that removes switches such as -rpath /usr/lib from the command line then call the appropriate program. So you agree that we should be able to choose to disable rpath but you feel that we should do extra work to advoid it for libtool because it does not fit your beliefs of how shared libraries work? What about other dists that do the same thing? We are not the only linux dist to use this scheme! I agree that libtool may, some day, allow users to do that in a portable fashion. But I still don't see how modifying the current version of libtool would help you fix the problem of backward compatibility for already compiled programs or for packages distributed with older versions of libtool. Therefore, the fix you really need is not in libtool, is in the dynamic loader. This will have the extra benefit of fixing other packages that don't use libtool, but happen to specify -rpath on their own. Actually virtually every other package we would just hand edit the makefiles, libtool kinda makes that impossible. Yep. Now you have to edit a single libtool script, instead of all the Makefiles of the package. Ain't tha progress? - rpath is bad because it disables LD_LIBRARYPATH It prevents you from using LD_LIBRARY_PATH to superceed the default location of libraries, which is partially what it does Not according to the Posix specification. rpath prevents library searching and thus kills this functionality. It doesn't prevent library searching, it just takes precedence over it. If the library is not found in the rpath specified at link-time, the library is searched in other directories, such as the ones specified in LD_LIBRARY_PATH. - rpath is bad because it disables the linkers automatic versioning mechanism Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the library search path in certain circumstances? The hack is incomplete, you just have to fix it. See the other messages - it is not a hack and it is not horribly incomplete. It doesn't work for applications that have chosen to hard-code /usr/lib or /usr/lib/X11R6 in their code, for whatever reason, therefore I can only see two possible conclusions: 1) your choice to move libraries around was a bad idea, because it causes certain applications to break 2) the code in the dynamic loader that chooses the `right' version of a library is incomplete, in the sense that it doesn't choose the `right' version when shared library paths are hard-coded in the application -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: gnuserv/gnuclient problem
On Sat, January 30 1999, Jim Pick [EMAIL PROTECTED] wrote: | |Amos Shapira [EMAIL PROTECTED] writes: | | On Fri, January 29 1999, Ionutz Borcoman [EMAIL PROTECTED] |wro | te: | |Hi, | | | |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions | |from potato I am no more able to start a gnuclient :-( Is anybody else | |experiencing this ? | | I've reported this bug with slink months ago with no response. I | still can't use gnuclient with xemacs under slink. | |It seems to work for me here (gnuclient.xemac20) | |ii xemacs20-bin20.4-13Editor and kitchen sink -- support binaries |ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule binary |ii xemacs20-suppor 20.4-13Editor and kitchen sink -- architecture ind |e |ii xemacs20-suppor 20.4-13Editor and kitchen sink -- non-required lib |r It's the same version I have as well (latest Slink). Do you have gnuserv installed as well? With gnuserv 2.1alpha-4 installed it doesn't work. I tried purging gnuserv and then run gnuclient.xemacs20 but I still get an error like: (1) (error/warning) Error in process filter: (void-function gnuserv-edit-files) Maybe the previous installation of gnuserv broke it? As far as I remember, I tried to install gnuserv *because* gnuclient didn't work without it. Thanks, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL[EMAIL PROTECTED] | -- Anonymous
Re: gnuserv/gnuclient problem
In article [EMAIL PROTECTED], Steve Dunham [EMAIL PROTECTED] wrote: It seems to work for me here (gnuclient.xemac20) ii xemacs20-bin20.4-13Editor and kitchen sink -- support binaries ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule binary ^ The problem only shows up with the mule versions of xemacs. Does $ xemacs20 -batch -eval (and (require 'gnuserv) (print gnuserv-program)) print out a sensible gnuserv pathname? i.e. /usr/lib/xemacs-20.4/i386-debian-linux//gnuserv -- I am the first and the last I claim this land I am the lost and the hungry I need this land [covenant]
Re: gnuserv/gnuclient problem
On Sat, January 30 1999, Steve Dunham [EMAIL PROTECTED] wrote: |Jim Pick [EMAIL PROTECTED] writes: | | Amos Shapira [EMAIL PROTECTED] writes: | | On Fri, January 29 1999, Ionutz Borcoman [EMAIL PROTECTED] | wro | te: | |Hi, | | | |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions | |from potato I am no more able to start a gnuclient :-( Is anybody else | |experiencing this ? | | I've reported this bug with slink months ago with no response. I | still can't use gnuclient with xemacs under slink. | | It seems to work for me here (gnuclient.xemac20) | | ii xemacs20-bin20.4-13Editor and kitchen sink -- support binari |es | ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule binar |y | ^ |The problem only shows up with the mule versions of xemacs. Yup. It's true for my case - I have the -mule version installed. Thanks, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL[EMAIL PROTECTED] | -- Anonymous
Re: -rpath with libtool and Debian Linux
On Jan 29, 1999, Hamish Moffatt [EMAIL PROTECTED] wrote: On Fri, Jan 29, 1999 at 07:11:54AM -0200, Alexandre Oliva wrote: On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote: Therefore, we chose to solve that particular problem (the libc5-6 transition) by moving libraries around, knowing that our linker was up to the job. It is now clear that it is not. :-( It IS, as long as you don't use rpath. And libtool works perfectly well, as long as you don't replace libraries with incompatible versions. What makes you think the maintainers of libtool should introduce potential problems and break backward compatibility just to fix a (IMHO) bad choice you have made, even knowing that modifying libtool at this point would not contribute in *any* way to fix the problem you currently have? The user is obviously free to use them for locally compiled stuff, and AFAIK it will behave as advertised. Yes, when Debian moves those libraries in the future, those programs will break. The user shouldn't really use rpath. Maybe you should ask distributors of Debian to print this advice in any CD-ROM containing Debian distributions they sell. But there are plenty of other ways for a user to hose their system; we really can't stop them doing it. That's not the point. By replacing libraries with (in)compatible versions, you're actively working to hose users' systems. Modifying libtool to remove -rpath fixes the problem at our end. Nope, because the current problem has to do with pre-installed programs. Modifying the libtool script will, by no means, fix this problem. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: gnuserv/gnuclient problem
On Sat, January 30 1999, [EMAIL PROTECTED] (Frozen Rose) wrote: | |In article [EMAIL PROTECTED], |Steve Dunham [EMAIL PROTECTED] wrote: | | It seems to work for me here (gnuclient.xemac20) | | ii xemacs20-bin20.4-13Editor and kitchen sink -- support binar |ies | ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule bina |ry | ^ |The problem only shows up with the mule versions of xemacs. | |Does | $ xemacs20 -batch -eval (and (require 'gnuserv) (print gnuserv-program)) |print out a sensible gnuserv pathname? |i.e. /usr/lib/xemacs-20.4/i386-debian-linux//gnuserv Yes, it gives the same path: /usr/lib/xemacs-20.4/i386-debian-linux//gnuserv And this file exists. According to dpkg -S gnuserv it comes from xemacs20-bin. Thanks, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL[EMAIL PROTECTED] | -- Anonymous
Re: -rpath with libtool and Debian Linux
On Jan 29, 1999, Hamish Moffatt [EMAIL PROTECTED] wrote: On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote: Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the library search path in certain circumstances? The hack is incomplete, you just have to fix it. Have you checked our ld.so source? The only mentioned of libc5-compat is documentation. Nope, I'm just believing what the people that have complained have told me about it. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Debian-PPC on RS/6000
Anybody been running debian-ppc on an RS/6000 yet? One of my friends and I are playing around with it, but as of yet I have been unable to find any pointers on how to install it on anything but Macintoshes. -- Andreas
Re: -rpath with libtool and Debian Linux
Hi, On Fri, Jan 29, 1999 at 03:41:46PM -0600, Gordon Matzigkeit wrote: I don't understand this comment. Which trouble with --rpath do you mean? AO The exact problem the Debian developers have been complaining AO about. The more I think about the problem, the more I see that AO the problem they're facing is an incomplete hack of ld.so, in AO that it modifies the library search path under certain AO circumstances, but not in all circumstances that would need it. Exactly. Mmh. I think I see the point now, and I have to agree. So, the problem we are facing is twofold: * How can Debian hack around the rpath problem, so user can use third party software which is libc5+rpath. * Is there a better way to do a library transition? I think it is very obvious, that the only correct behaviour is to change the library/soname of all involeved libraries when doing a transition. So we had to move either from libfoo.2 to libfoog.2, libfoo.libc6.2, libc6/libfoo.2 or whatever, until a new library with a new, incompatible, soname is released. Changing the name does not look correct, so we had to change soname or path. I am sorry if this sounds quite confusing, but I hope you get the idea (Gordon, this is exactly what we discussed on the Hurd list, right?). Fortunately, libc6 will use symbol versioning, so we will not experience problems at this scale again (hopefully). Furthermore, it would be great if upstream author, compiler and installer could all influence the linking conditions (rpath or not etc), which seems to be a good goal. This could fix our problem, too, but only as a hack. The theoretical solution is outlined above. There is still the issue of xaw wrappers, can you please comment on this? Shouldn't there be a way to override rpath? Currently,LD_LIBRARY_PATH does override rpath, right? But then, if I want to link a program which was compiled for xaw with xaw3d, to get a better look+feel, I would need a way to override the rpath inside the binary. Maybe another environment variable is needed for this, or should the priority changed? Because, I really think the sysadmin/user should always have the last word on this issue. Currently, rpath overrides everything, which is set by the distributor of the binary. This means, the package can provide a default, which can be overridden at compilation time. Finally, the installer can override both. I should add here that ideally, a user/sysadmin should always be able to override all three. AO That's exactly what I'm looking for. But I wouldn't like to AO install a quick hack now that would later reveal to be a step in AO the wrong direction. That's why I'm being so conservative about AO all this issue. For the record, Alexandre's conservativeness is well-justified. I still don't see if libtools default, rpath, is correct, but I see now what Debian did wrong. I also see that if Debian would have done it correctly, the use of rpath would be a non-issue. The best solution I can come up with is to *always* change a library's soname when its dependencies change. Ah, here you say it what I cludged together above with my limited understanding of the issues :) Thanks, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Call for mascot! :-) -- flying pigs
On Thu, Jan 28, 1999 at 05:57:47PM -0600, Anderson MacKay wrote: The key here is cute. People don't want an ugly chicken-like creature that is clearly ready to attack at the slightest provocation. And furthermore, even if it -was- to attack, it really wouldn't do anything. Linus -was- able to give a convincing, -somewhat- alarming description of an angry penguin and why you wouldn't want to mess with him, but really ... chicken? Are you crazy? A mad chicken will pick your eyes out... :) Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Debian-PPC on RS/6000
On Sat, Jan 30, 1999 at 11:05:17PM +0100, Andreas Plesner Jacobsen wrote: Anybody been running debian-ppc on an RS/6000 yet? One of my friends and I are playing around with it, but as of yet I have been unable to find any pointers on how to install it on anything but Macintoshes. Installing on ANYTHING is a bit undersupported. All of the packages should work, though, once you get them installed. I suggest you join the debian-powerpc mailing list. Dan /\ /\ | Daniel Jacobowitz|__| CMU, CS class of 2002 | | Debian GNU/Linux Developer__ Part-Time Systems Programmer | | [EMAIL PROTECTED] | |[EMAIL PROTECTED] | \/ \/
Re: -rpath with libtool and Debian Linux
On Jan 29, 1999, Steve Dunham [EMAIL PROTECTED] wrote: Maybe we should just agree that libtool is broken, that it won't be fixed upstream, and just fix the Debian version? This would mean that we would have to rerun autoconf co when we build packages Actually, you'd just have to modify the libtool script, after it is generated, so as to set hardcode_libdir_flag_spec to the empty string. The attached script should do it; just run it after configure in any Debian package and you're done. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil /home/msc/oliva/norpath.sh Description: Bourne shell script
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
[CC's trimmed] On Sat, 30 Jan 1999 18:03:54 + (BST), M.C. Vernon [EMAIL PROTECTED] said: I still use nfs or mounted (I have /sunsite always pointing to sunsite, which is where I get my packages from) and dselect. It's always worked fine for me, so I feel no need to change. It hasn't worked very well for loads of other users; see the bug list that I originally reported. The issue isn't whether the older methods works well enough for you; the issue is whether (a) the installation methods have been officially obsoleted by other methods, including dpkg-multicd (which includes NFS, disk, and CDROM support) and/or the apt which is included in slink. Let me point out that I don't think you can find *anyone* who will argue that the 'dpkg -iGROEB' system used by these dpkg/disk methods (harddisk, cdrom, nfs, mounted) is better. In fact, using 'dpkg -iGROEB' is much worse: * it doesn't do proper dependancy ordering * since it doesn't do proper ordering, running it causes lots of scarey message; these messages are bad in two ways: - they are a turn off to new users, who conclude that debian is obscure, and broken - they mask real bugs by all the noise generated * it requires several runs of the configure step to get the packages properly installed, due to the ordering problems Moreover, the issue is also that the these older methods are part of 'dpkg' itself. So long as this is so, these methods will be included in installation systems such as boot-floppies. They have normal, generic looking names like 'harddisk', 'cdrom', 'nfs'. New users *will* use them on slink cds, and they will break break break. I submit that they *must* be removed from the boot-floppies and the *must* be taken out of harms way. Therefore, they must be removed from dpkg. If someone wants to split the pacakge, great. So then I have to download a bunch of packages if I want to grab a package of my CD, or use nfs, or ftp for when I want something from incoming No, one package, as Enrique pointed out. Also, you can use dpkg-multicd or dpkg-mountable for *better* implementations already. The only arguments I've had from people who want to retain these methods have already stated they're simply sticking to these default methods due to inertia. Please, someone give me *one* technical reason how the dpkg-supplied acquisition methods are not obsoleted by dpkg-multicd or apt. Sorry, saying I'm happy with the broken system and too lazy to try non-broken ones does not qualify. Perhaps the dpkg-multicd methods could *divert* the older dpkg methods, just to get those older methods out of harm's way? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: -rpath with libtool and Debian Linux
On Sat, Jan 30, 1999 at 07:46:21PM -0200, Alexandre Oliva wrote: On Jan 29, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote: rpath prevents library searching and thus kills this functionality. It doesn't prevent library searching, it just takes precedence over it. If the library is not found in the rpath specified at link-time, the library is searched in other directories, such as the ones specified in LD_LIBRARY_PATH. I think a way to override even rpath would be great. It doesn't work for applications that have chosen to hard-code /usr/lib or /usr/lib/X11R6 in their code, for whatever reason, therefore I can only see two possible conclusions: 1) your choice to move libraries around was a bad idea, because it causes certain applications to break 2) the code in the dynamic loader that chooses the `right' version of a library is incomplete, in the sense that it doesn't choose the `right' version when shared library paths are hard-coded in the application Why should the application choose to hard code the PATH in the binary? AFAICS, there is no apparent reason for it. What has the path to do with the library? I think the only thing that should be hard coded is the exact soname and library name. Maybe I am missing something? Thanks, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: gnuserv/gnuclient problem
Steve Dunham wrote: ii xemacs20-bin20.4-13Editor and kitchen sink ii xemacs20-nomule 20.4-13Editor and kitchen sink ^ The problem only shows up with the mule versions of xemacs. Nope, because I only have the nomule version installed, and I have the same problem. Gnuclient causes xemacs to generate an error, and then exits immediately. Running slink. ~ $ dpkg --list 'xemacs*' | grep '^[ir]' ii xemacs20-bin20.4-13Editor and kitchen sink ii xemacs20-nomule 20.4-13Editor and kitchen sink ii xemacs20-suppor 20.4-13Editor and kitchen sink ~ $ ~ $ xemacs20 -batch -eval (and (require 'gnuserv) (print gnuserv-program)) Loading [...stuff...] Symbol's value as variable is void: gnuserv-program XEmacs exiting. This may be a useful clue: from inside xemacs, I can determine that gnuserv-program's plist is (saved-value ((concat exec-directory /gnuserv))). When I evaluate that, it says that saved-value's function definition is void. If I execute (concat exec-directory /gnuserv), it looks fine. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: -rpath with libtool and Debian Linux
Date: Sat, 30 Jan 1999 23:30:43 +0100 From: Marcus Brinkmann [EMAIL PROTECTED] Why should the application choose to hard code the PATH in the binary? AFAICS, there is no apparent reason for it. What has the path to do with the library? I think the only thing that should be hard coded is the exact soname and library name. Maybe I am missing something? Suppose you have your own set of shared libraries, in your own directory. Suppose you want to let other people use your programs linked against your own shared libraries. You can tell everyone who uses your programs to set LD_LIBRARY_PATH, or you can simply use -rpath so that your programs can always find your shared libraries. In general, it's convenient to store the path in the executable any time a shared library is installed in a directory which the dynamic linker does not search by default. Incidentally, I don't know what you mean by saying both soname and library name. There is only one name recorded for a shared library: the soname. Ian
Re: What hack in ld.so?
On Jan 29, 1999, Buddha Buck [EMAIL PROTECTED] wrote: [exact description of what I had assumed about the behavior of ld.so, based on previous postings to the libtool mailing list, snipped] This is not how I understand how the ld.so linker works on Linux systems. My understanding is that it caches the locations of all known versions of the libraries, and makes an intelligent decision as to which version to load. [description of what I now understand to b e the current behavior of ld.so snipped] This breaks in the presense of -rpath, because with rpath, bar is not dependent on libfoo, but on /usr/lib/libfoo. It shouldn't break, because -rpath is not associated with particular libraries, it is just a search path, just like the default search path. In order for ld.so to do an intelligent decision about whihc version to load, it should probably take into account the hard-coded rpath in addition to the default search path, preferring hard-coded rpaths as long as they do not introduce conflicts. Obviously, this would have never been needed if old libraries had not been replaced with (in)compatible versions, but the maintainers of Debian have already taken this step, despite the fact that this would break any previously-compiled programs that happened to hard-code /usr/lib or /usr/X11R6/lib. Therefore, new code must be written to support this step. Since modifying the next release of libtool won't contribute at all to fix the problem in already compiled programs, which are the only programs affected by this problem, I don't see much point in introducing a quick hack in libtool to prevent hard-coding of paths in libtool at this point. If/when someone contributes a portable and user/developer-configurable mechanism to do that, we may adopt it. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: -rpath with libtool and Debian Linux
On Sat, Jan 30, 1999 at 05:40:24PM -0500, Ian Lance Taylor wrote: Suppose you have your own set of shared libraries, in your own directory. Suppose you want to let other people use your programs linked against your own shared libraries. You can tell everyone who uses your programs to set LD_LIBRARY_PATH, or you can simply use -rpath so that your programs can always find your shared libraries. Okay. In general, it's convenient to store the path in the executable any time a shared library is installed in a directory which the dynamic linker does not search by default. Yes, I should have narrowed my question to system libraries. Unfortunately, system libraries are most likely to cause the problems, for example if people hard code /usr/X11R6/lib/ for xaw library and you want to use xaw3d... Incidentally, I don't know what you mean by saying both soname and library name. There is only one name recorded for a shared library: the soname. Ignorance I think. I thought soname is only the number, and a lib is stored in libfoo.x.y.z, where foo is the library name and x.y.z the soname. If I got it wrong, I apologize. Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: gnuserv/gnuclient problem
Chris Waters [EMAIL PROTECTED] writes: Steve Dunham wrote: ii xemacs20-bin20.4-13Editor and kitchen sink ii xemacs20-nomule 20.4-13Editor and kitchen sink ^ The problem only shows up with the mule versions of xemacs. Nope, because I only have the nomule version installed, and I have the same problem. Gnuclient causes xemacs to generate an error, and then exits immediately. Running slink. Ok, I'm talking about a different problem (which seems to have mysteriously gone away on my system). Steve [EMAIL PROTECTED]
Re: -rpath with libtool and Debian Linux
Date: Sat, 30 Jan 1999 23:10:26 +0100 From: Marcus Brinkmann [EMAIL PROTECTED] * Is there a better way to do a library transition? I think it is very obvious, that the only correct behaviour is to change the library/soname of all involeved libraries when doing a transition. So we had to move either from libfoo.2 to libfoog.2, libfoo.libc6.2, libc6/libfoo.2 or whatever, until a new library with a new, incompatible, soname is released. Changing the name does not look correct, so we had to change soname or path. When you make an incompatible change to a shared library, change the soname. That's just a matter of choosing a name for the new library and tweaking a symlink. There is no reason to do anything else. What do you mean when you say ``changing the name does not look correct?'' Don't confuse the name of the library found by the runtime linker (libc.so) with the soname used by the dynamic linker (libc.so.6). The runtime linker will normally find a symlink to the soname. When you build a shared library, use the -h/--soname option to set the soname of the shared library. Shouldn't there be a way to override rpath? Currently,LD_LIBRARY_PATH does override rpath, right? No, LD_LIBRARY_PATH does not override rpath. The rpath is searched first, and then the LD_LIBRARY_PATH is searched. I think you may have agreed with that later in your message. Ian
Re: -rpath with libtool and Debian Linux
On Sat, Jan 30, 1999 at 05:49:39PM -0500, Ian Lance Taylor wrote: * Is there a better way to do a library transition? I think it is very obvious, that the only correct behaviour is to change the library/soname of all involeved libraries when doing a transition. So we had to move either from libfoo.2 to libfoog.2, libfoo.libc6.2, libc6/libfoo.2 or whatever, until a new library with a new, incompatible, soname is released. Changing the name does not look correct, so we had to change soname or path. When you make an incompatible change to a shared library, change the soname. That's just a matter of choosing a name for the new library and tweaking a symlink. There is no reason to do anything else. Yes, this is what I meant. Debian should have changed the sonames of the libc6 libraries when the library exists for libc5, too. What do you mean when you say ``changing the name does not look correct?'' Well, you _could_ rename the library, and recompile applications using the new name... for a transition period... OTOH I realized that this would be very ugly and require changes to Makefiles etc... so it does not look correct == is a stupid and brain dead idea. Shouldn't there be a way to override rpath? Currently,LD_LIBRARY_PATH does override rpath, right? No, LD_LIBRARY_PATH does not override rpath. The rpath is searched first, and then the LD_LIBRARY_PATH is searched. I think you may have agreed with that later in your message. Sorry about the typo. I meant to say does not override rpath. Thanks, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: -rpath with libtool and Debian Linux
On Sat, Jan 30, 1999 at 05:49:39PM -0500, Ian Lance Taylor wrote: Shouldn't there be a way to override rpath? Currently,LD_LIBRARY_PATH does override rpath, right? No, LD_LIBRARY_PATH does not override rpath. The rpath is searched first, and then the LD_LIBRARY_PATH is searched. I think you may have agreed with that later in your message. This is another irksome thing about libtool and -rpath. Test programs, even if they are marked noinst, use -rpath, and when they are run using the installed version instead of the newly built one. Which is annoying, since the whole point of test programs is to make sure the library is working *before* you install it. So maybe we should have an explicit -no-rpath switch to libtool to fix this. -Yosh
Re: -rpath with libtool and Debian Linux
Date: Sat, 30 Jan 1999 23:42:32 +0100 From: Marcus Brinkmann [EMAIL PROTECTED] In general, it's convenient to store the path in the executable any time a shared library is installed in a directory which the dynamic linker does not search by default. Yes, I should have narrowed my question to system libraries. Unfortunately, system libraries are most likely to cause the problems, for example if people hard code /usr/X11R6/lib/ for xaw library and you want to use xaw3d... It's hard to distinguish system libraries from non-system libraries, except by the distinction quoted above: a non-system library is a library installed in a directory which the dynamic linker does not search by default. Unfortunately, the GNU/Linux dynamic linker reportedly uses a rather complex algorithm, in which it makes decisions based on the libc version number which libraries are linked against, which would seem to make it hard to determine just which directories the dynamic linker searches by default. In the normal case I think one can assume that the dynamic linker will search any directory listed in /etc/ld.so.conf, and it would be OK to omit a -rpath argument for any shared library installed in one of the directories listed in that file. Note that although you can set up a case in which the xaw library is found in /usr/X11R6/lib, it's not normal. Normally the program will be linked against libxaw.so.N, and will have a specified search path, the rpath, to find that file. Incidentally, I don't know what you mean by saying both soname and library name. There is only one name recorded for a shared library: the soname. Ignorance I think. I thought soname is only the number, and a lib is stored in libfoo.x.y.z, where foo is the library name and x.y.z the soname. If I got it wrong, I apologize. When I, and I think most others, use the word soname, I refer to the DT_SONAME tag in a shared library which appears in a DT_NEEDED tag in the executable. The soname is set in a shared library using the -h/--soname option, and is copied into the executable by the program linker. In this case the soname is the full name of the file: libfoo.x.y.z. Ian
Re: What hack in ld.so?
On 30 Jan 1999, Alexandre Oliva wrote: Obviously, this would have never been needed if old libraries had not been replaced with (in)compatible versions, but the maintainers of Debian have already taken this step, despite the fact that this would Look, it was not us that decided to do this. It was the upstream maintainers, other dists and a huge combination of factors. It is not in our power to choose a different direction to solve these problems, we must have libc6 xlib called libX11.so.6 and we must have libc5 called libX11.so.6 - that is what all the other dists did, that is the default and expected compilation behavoir of xlib and it is what all the new glibc binary-only programs are using (ie netscape) If you want to say that is a dumb way then fine, but you have not proposed an alternative to solving the versioning problem and you have not proposed an alternative way to handle the requirement of identical sonames and libtool continues to perpetuate this 'bad' behavoir and makes it worse by providing no way to get around it with the standard linux ld.so Indeed libtool causes such a severe problem that if you take a libtool program, compile it on a libc5 Slackware and try to run it on -any- glibc system IT WILL NOT WORK. If you wish to make statement that binaries compiled with libtool work only on the host they were compiled for and even then only in specific conditions then fine - but that makes it totaly unsuitable for use by any of the binary distribution maker. Jason
Re: Debian-PPC on RS/6000
-BEGIN PGP SIGNED MESSAGE- On Sat, 30 Jan 1999, Andreas Plesner Jacobsen wrote: Anybody been running debian-ppc on an RS/6000 yet? One of my friends and I are playing around with it, but as of yet I have been unable to find any pointers on how to install it on anything but Macintoshes. Take it from someone who's been there, done that. With RS/6000's, you are *always* better off building everything yourself, and cross-compiling from a PC. And now, for everyone's convience, a quick list of RS/6000's that I *know* will run Linux. I don't garauntee support on the SCSI or sound, but I know that they'll boot Linux. And since they've got PCI, just throw in PCI2.1 compliant hardware. It'll work. :) - --RS/6000's That Will Run Linux 2.2.x or 2.1.101-- R50 Rackmount Server H50 PowerPC Server F50 PowerPC Server F40 PowerPC Server (2 Processor configuration is what I tested on.) E30 Workgroup Server 43P Power240 Workgroup Server 43P Model 150 Workgroup Server 43P Model 140 Workgroup Server F3L Telecommunications Server (Most hardware features unsupported) F40 3D Workstation IBM Intellistation (x86! Bah!) Currently, if an RS/6000 model contains the following hardware or features, assume the entire system unsupported: PowerPC with X5 Cache PowerPC RS64 II MCA 80M or 160M (MicroChannel Architecture) I have tested and worked on an RS/6000 F40 PowerPC Server with 256M, dual processors, dual 6.4G SCSI-UW disks, a Tekram DC390F PCI SCSI controller, a SoundBlaster 16ASP (Jumpered), and a Diamond FireGL 1000 Pro. What'd I get working on it? XFree86 (with a LOT of work), kernel 2.2.0-pre9, a Ricoh MP6200S SCSI CD-RW, mpg123, and some basic services. So it's doable. But all the distributions have a *LONG* way to go. IMHO, the world would be a lot better off with Linux-ApplePPC, and Linux-RS/6000. Two seperate trees. Macs are very different from RS/6000's. Something that works on a Mac, will not necessarily work on an RS/6000. Just my $.02USD. - -Phillip R. Jaenke ([EMAIL PROTECTED]) something is not right, but i don't think it's wrong. --anon. -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNrNJQsES8LwwGtVlAQF2fAQAow+oOupRFy6keaOdEUHIo9+Pe9aRuhRh 55gaMJzpyIGG8chiL+kH4u1EA/luEF2m7yXDuWSnK+XiVtnsnjIzAlEgO6UHN65t 6q8r1nwlvO4aCnH6UfDy2yEMMZXGMnD12H3soGEn3kkzs/SkPKfQBx0UPZ7R9t3b 6//k58ZKWIY= =L9tV -END PGP SIGNATURE-
Re: -rpath with libtool and Debian Linux
On Jan 30, 1999, Ian Lance Taylor [EMAIL PROTECTED] wrote: In the normal case I think one can assume that the dynamic linker will search any directory listed in /etc/ld.so.conf, and it would be OK to omit a -rpath argument for any shared library installed in one of the directories listed in that file. This seems to be a reasonable assumption, as long as no directory is ever removed from /etc/ld.so.conf. But then, there's also the problem of finding the wrong version of a library, if it is found before the correct one in the search path. Anyway, as Thomas Tanner argued, hard-coding rpath won't always solve this problem either (although it would solve it in some cases), so I'd welcome a patch that would cause libtool to: 1) use information from /etc/ld.so.conf, instead of having a hard-coded list of directories, to set sys_lib_search_path_spec 2) refrain from hard-coding directories listed in sys_lib_search_path_spec (but not in $shlibpath_var) in executables -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: -rpath with libtool and Debian Linux
Marcus Brinkmann [EMAIL PROTECTED] writes: On Fri, Jan 29, 1999 at 03:41:46PM -0600, Gordon Matzigkeit wrote: I don't understand this comment. Which trouble with --rpath do you mean? AO The exact problem the Debian developers have been complaining AO about. The more I think about the problem, the more I see that AO the problem they're facing is an incomplete hack of ld.so, in AO that it modifies the library search path under certain AO circumstances, but not in all circumstances that would need it. Exactly. Mmh. I think I see the point now, and I have to agree. So, the problem we are facing is twofold: * How can Debian hack around the rpath problem, so user can use third party software which is libc5+rpath. * Is there a better way to do a library transition? I think it is very obvious, that the only correct behaviour is to change the library/soname of all involeved libraries when doing a transition. So we had to move either from libfoo.2 to libfoog.2, libfoo.libc6.2, libc6/libfoo.2 or whatever, until a new library with a new, incompatible, soname is released. Changing the name does not look correct, so we had to change soname or path. Caveat: I'm a novice at these issues. IMHO (with 20/20 hindsight), it would have been much nicer if the libc5-libc6 transition had used a different mechanism -- something akin to $_RLD_ROOT of IRIX. The idea of _RLD_ROOT is that if that env. variable is set, it is prepended to every runpath in the binary + every default path. E.g. if _RLD_ROOT=/mnt1:/mnt2:, and you have a binary with -rpath set to /usr/foo/lib and, the default library search path is /lib:/usr/lib. The set of paths searched by the linker are, in order: /mnt1/usr/foo/lib /mnt2/usr/foo/lib /usr/foo/lib $LD_LIBRARY_PATH /mnt1/lib /mnt2/lib /lib /mnt1/usr/lib /mnt2/usr/lib /usr/lib (I may have got the specifics wrong, but this should be the general idea.) The better way for libc5/6 hack would have been to modify ld-linux.so.1 (the libc5 ELF loader) to act _as if_ the _RLD_ROOT env. var. was set to `/usr/compat-glibc1:'. This way, the libc5 libraries could have been moved into to the /usr/compat-glibc1 tree maintaining the same tree structure, and would automatically have worked with any `-rpath's. E.g., xlib6 (the libc5 compatible X library) could have put its libraries in /usr/compat-glibc1/usr/X11R6/lib (if it originally put it in `/usr/X11R6/lib') and libc5 could have put its library either in /lib or in /usr/compat-glibc1/lib. Moving from `bo' to `hamm' for libc5 libraries could just have been a matter of dpkg-repack or some similar tool. Of course, I'm not conversant with all the issues, and could be completely wrong. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash
Re: -rpath with libtool and Debian Linux
On Jan 30, 1999, Manish Singh [EMAIL PROTECTED] wrote: No, LD_LIBRARY_PATH does not override rpath. The rpath is searched first, and then the LD_LIBRARY_PATH is searched. I think you may have agreed with that later in your message. This is another irksome thing about libtool and -rpath. Test programs, even if they are marked noinst, use -rpath, and when they are run using the installed version instead of the newly built one. Which is annoying, since the whole point of test programs is to make sure the library is working *before* you install it. Yep, this is a known bug in libtool, and a partial fix for it, by Edouard Parmelan, is already installed in the CVS tree. Hopefully, someone will soon be able to complete his work, based on the short description of what is missing he recently provided. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: What hack in ld.so?
On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote: If you wish to make statement that binaries compiled with libtool work only on the host they were compiled for and even then only in specific conditions then fine - but that makes it totaly unsuitable for use by any of the binary distribution maker. That's not what I'd like libtool to do. I agree there is a problem to be fixed, I just think that libtool is not the only piece of software that may have to be changed to fix it, because it is not the only piece of software that uses -rpath. However, there is a risk that dropping -rpath will cause programs not to work in hosts other than the one in which they were installed. Assume libtool is modified so as to not hard-code directories listed in /etc/ld.so.conf. Then, the Devian (pun intended) distribution adds /dev/lib (*) to /etc/ld.so.conf, and configures some of their packages to install with --prefix=/dev (wouldn't that be beautiful? :-) (*) /dev is for Devian, not devices; I won't tell you that they have decided to move devices elsewhere too :-) When users of other distributions installed their pre-compiled .dev packages, programs that would run on Devian distributions would not run in any other, because /dev/lib is not listed in /etc/ld.so.conf, and libtool had failed to add /dev/lib to the rpath of Devian programs. Who's to blame for that? Of course, the solution is easy: adding the directory to ld.so.conf or to LD_LIBRARY_PATH. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Sat, 30 Jan 1999, Alan Cox wrote: I'd like to propose that for now the FHS is changed to read The mail spool area location is undefined. It is guaranteed that both /var/mail and /var/spool/mail point to this mail spool area if the system has a mail spool. The preferred reference name is /var/mail. [Rationale: /var/mail is the only name available on some other modern Unix platforms. /var/spool/mail is the older Linux tradition and needed for compatibility] [Rationale2: The physical location of the mail spool is not relevant to an application and is administrator policy. It is thus left open.] Sounds a lot like what I said last week. :) And HPA before that. ;) Seriously, I think that this solution is the one that the most people can agree on, as it seems to make everyone happy (except for maybe the ~/Mailbox people, but they should be drawn and quartered ;). +-++ | Jakob 'sparky' Kaivo| [EMAIL PROTECTED] | | NoDomainName Networks |http://www.nodomainname.net | | AtDot E-mail Services | http://www.atdot.org | +-++
Re: What hack in ld.so?
On 30 Jan 1999, Alexandre Oliva wrote: On Jan 30, 1999, Jason Gunthorpe [EMAIL PROTECTED] wrote: If you wish to make statement that binaries compiled with libtool work only on the host they were compiled for and even then only in specific conditions then fine - but that makes it totaly unsuitable for use by any of the binary distribution maker. That's not what I'd like libtool to do. I agree there is a problem to be fixed, I just think that libtool is not the only piece of software that may have to be changed to fix it, because it is not the only piece of software that uses -rpath. libtool is however the only piece of software that we cannot easially change. When users of other distributions installed their pre-compiled .dev packages, programs that would run on Devian distributions would not run in any other, because /dev/lib is not listed in /etc/ld.so.conf, and libtool had failed to add /dev/lib to the rpath of Devian programs. Who's to blame for that? It doesn't really matter who is to blame because it -can- be fixed and fixed fairly easially by the installer, the -rpath situation -cannot- be fixed at all by the installer, I think that is the key difference to realize. Jason
Re: WARNING: Re: debhelper /usr/bin/passwd
On Mon, 25 Jan 1999, Joey Hess wrote: Joey Hess wrote: I'd say installing debhelper 1.2.28 with --force-conflicts is a _very_ bad idea. Unfortunatly, it looks like the current version of dpkg has --force-overwrite (which is what I meant to say above) enabled by default. And so anyone who ran dselect in the past 24 hours and upgraded from unstable has probably beeen bitten by this bad package. Is there any way of changing that default behaviour (e.g. some config file) apart from recompiling dpkg? I'd like to leave it disabled at all times no matter what the default is in the current dpkg package. Remco -- rd31-144: 12:50am up 5 days, 38 min, 10 users, load average: 1.00, 1.02, 1.00
Re: What hack in ld.so?
Hi, On Sat, Jan 30, 1999 at 04:06:04PM -0700, Jason Gunthorpe wrote: On 30 Jan 1999, Alexandre Oliva wrote: Obviously, this would have never been needed if old libraries had not been replaced with (in)compatible versions, but the maintainers of Debian have already taken this step, despite the fact that this would Look, it was not us that decided to do this. Debian was the first distribution to make a decision about the libc6 transition. Certainly we have decided to do it the way we did. It was the upstream maintainers, other dists and a huge combination of factors. It is true that these determined the options and Debians final decision, but still we decided to follow this. It is not in our power to choose a different direction to solve these problems, we must have libc6 xlib called libX11.so.6 and we must have libc5 called libX11.so.6 - that is what all the other dists did, that is the default and expected compilation behavoir of xlib and it is what all the new glibc binary-only programs are using (ie netscape) And Alexandre is right that this is - in general - the cause of our problems with rpath, and it is indeed _wrong_ (in general). That it works in Linux is only due to a smart hack in the linker, and the hack does obviously not take rpath into account. So, ask yourself the question: Why do you expect it to work? Why do you expect it to be fixed in libtool, when libtool has nothing to do with it? If you want to say that is a dumb way then fine, but you have not proposed an alternative to solving the versioning problem and you have not proposed an alternative way to handle the requirement of identical sonames and libtool continues to perpetuate this 'bad' behavoir and makes it worse by providing no way to get around it with the standard linux ld.so There is no right way to get identical sonames but different libraries. The bad behaviour has to be searched for (and can be found) on the Linux side. The only solution to this problem would be to allow multiple libraries with the same soname but different dependencies staying in the same place. There is currently no way doing so. The way the Linux linker does circumvent the missing feature does work surprisingly well, but it is still not the correct thing. Indeed libtool causes such a severe problem that if you take a libtool program, compile it on a libc5 Slackware and try to run it on -any- glibc system IT WILL NOT WORK. How could you expect it to work? If you wish to make statement that binaries compiled with libtool work only on the host they were compiled for and even then only in specific conditions then fine - but that makes it totaly unsuitable for use by any of the binary distribution maker. I think you got it wrong. You are right that Debian had hardly any alternative for the libc5-libc6 transition. But still, the problem is a missing feature: An implicit addition to the soname in dependence of the library dependencies. So you would have /usr/lib/libfoo.2 as rpath, but really would use /usr/lib/libfoo-libc6.2 or libfoo-libc5.2, you get the idea. However, the situation is not so easy, because you would need a multi dimensional table. As this is not possible (currently), the only thing you can do is to grant that the library is always compatible, as Alexandre correctly pointed out. We broke this, because it was more convenient for us not to change all Makefiles of our packages to use different sonames for libc6 libraries with the same version as their libc5 counterpart. However, the hack in the linker doesn't work for rpath binaries. libtool is not the cause for our problems, and rpath isn't, too. Our problems are the result of the following: * an incompatible upgrade path, together with an incomplete work-around in the linker. * the lack of a way to override rpath. Thanks, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
