Re: /usr/etc and /usr/local/etc?
On 5 Oct 1999 [EMAIL PROTECTED] wrote: Date: 05 Oct 1999 23:39:05 +0200 From: [EMAIL PROTECTED] To: Richard Kaszeta [EMAIL PROTECTED] Cc: Martin Schulze [EMAIL PROTECTED], debian-devel@lists.debian.org Subject: Re: /usr/etc and /usr/local/etc? Resent-Date: 5 Oct 1999 21:39:55 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; Richard Kaszeta [EMAIL PROTECTED] writes: Martin Schulze writes (Re: /usr/etc and /usr/local/etc?): Aaron Van Couwenberghe wrote: Just a quick inquiry -- Why is it that we exclude /usr/etc from our distribution? FHS and FSSTND Because configuration belongs to /etc. Period. Good point, but etc blows up to quite a size and can´t be shared across hosts. ... Config files are, by their nature, host-specific, and should not be in /usr They are not. e.g. /etc/hosts should be the same across a pool. Nearly all files in /etc can be shared and none should be rewritten on the fly. This is what NIS and NIS+ are for, to share these files across hosts. A lot of UNIX derived systems end up modifying the normal placement of files because a few people feel they have a better way to do things. The end result is the mess /etc has become over the years. I would LOVE to see /etc become configuration files only, with NO binaries in there at all. To be able to do an rgrep in /etc to find a config, and never have binary garbage fly across the screen would make life a LOT easier. Programs such as gated which install themselves in /etc as the default also drive me crazy. Now, back on topic, if you need to share a file NIS/NIS+ will work. Someone else may have a better solution, such as Samba. David Bristel Apart from /etc/mtab (which can be linked to /proc/mounts) normaly nothing gets written to /etc and / can be ro. For diskless systems /usr/etc and /usr/share/etc could reduce the size of the ramdisk or root fs needed to boot and more data could be shared across a pool. Alternatively /etc/share/, /etc/arch and /etc/local could be used. Just as one likes. May the Source be with you. Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recompile needed for xlib6g (= 3.3.5-1) instead of (= 3.3.2.3a-2) ?
On Tue, Oct 05, 1999 at 11:43:14AM +0200, Santiago Vila wrote: On Fri, 1 Oct 1999, Peter S Galbraith wrote: Should I rebuild the i386 binaries with the new xlib6g-dev and upload them with .0.1 version number suffix? Or perhaps it doesn't matter? As far as xlib6g is concerned, I don't think it does matter. But it might. There *have* been changes to the libraries between 3.3.2.3 and 3.3.5. No, I don't think any interfaces have changed. But just to err on the side of caution, would anyone doing what Santiago is doing PLEASE recompile their packages against the latest versions of the potato libraries shortly before the potato freeze? Mixed slink/potato systems are temporary things. Potato will be around for a long time. So let us please make it internally consistent. -- G. Branden Robinson | One man's theology is another man's Debian GNU/Linux | belly laugh. [EMAIL PROTECTED] | -- Robert Heinlein cartoon.ecn.purdue.edu/~branden/ | pgpZYewiWNMsA.pgp Description: PGP signature
vim/nvi priority Re: moving mutt to standard priority
On 05-Oct-99, 04:00 (CDT), Marco d'Itri [EMAIL PROTECTED] wrote: I agree... Why does it [vim] have a lower priority in alternatives than nvi? I don't know. That's not what I remember from the discussion amongst the various vi and editor maintainers when we set the relative priorities, but unfortunately I cleaned out that discusssion just a few months ago. If I remember correctly, Dale Sheetz guided that discussion, maybe he can post the final list. What I remember as a general concept is that the package that is installed by default (nvi, in this case), should have the *lowest* priority wrt update-alternatives, under the assumption that if the sysadmin goes to the effort to install an option vi clone, they probably prefer that one. As to why nvi is Standard and vim/elvis/etc. are Optional, it's because nvi is closest to a standard, classic, BSD Bill Joy vi, warts and all. Also, I think it's the smallest full-fledged vi. Certainly that choice can be argued, but I'm not really interested in discussing it: everybody has a favorite, and it's not worth changing. If there is *consensus* that vim or elvis should be Standard, and nvi Optional, I'm happy to change, but lacking that (and I don't forsee it happening, after various other x should be the standard y flamefests), I think things should stay as they are. (In the Standard vs. Optional debate, that is. I suspect the update-alternatives priority for vim should be looked at.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
RE: DO NOT UPGRADE TO POTATO. MENU UPLOAD ON OCT 2 KILLS SYSTEMS
2.1.3-2 is one that does it ... It doesn't totally kill the system .. It seems to start up the various wm's, and they run at about 95% cpu and 88%+ memory for about 2-5 mins (each), but they do die (or finish?) and everything is fine (my worst case, I saw gnome-panel running at 95% for about 3 mins, then wmaker running at that for 3 mins.. (in console mode))... Its an annoyance, but it doesn't kill the system .. (at least on 3 of mine it didn't) Terry Adam == Adam Heath [EMAIL PROTECTED] writes: Adam I just did an upgrade. The menu pkg ate memory like no Adam tomorrow. [...] Adam Cease and desist at all costs. Adam I have just been informed on irc that a fixed menu is in Adam incoming. So, it should all be fixed tomorrow. [...] Adam, thanks. What are the menu package versions (broken and fixed)? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DO NOT UPGRADE TO POTATO. MENU UPLOAD ON OCT 2 KILLS SYSTEMS
So that's what did that! It was not anywhere near as disastrous as some of the things which update-xaw-wrappers has done to my system. In any case, I grabbed the new menu from incoming. On Tue, Oct 05, 1999 at 08:13:41PM -0400, Terry Katz wrote: 2.1.3-2 is one that does it ... It doesn't totally kill the system .. It seems to start up the various wm's, and they run at about 95% cpu and 88%+ memory for about 2-5 mins (each), but they do die (or finish?) and everything is fine (my worst case, I saw gnome-panel running at 95% for about 3 mins, then wmaker running at that for 3 mins.. (in console mode))... Its an annoyance, but it doesn't kill the system .. (at least on 3 of mine it didn't) Terry Adam == Adam Heath [EMAIL PROTECTED] writes: Adam I just did an upgrade. The menu pkg ate memory like no Adam tomorrow. [...] Adam Cease and desist at all costs. Adam I have just been informed on irc that a fixed menu is in Adam incoming. So, it should all be fixed tomorrow. [...] Adam, thanks. What are the menu package versions (broken and fixed)? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen
Re: So whos going to ALS
-BEGIN PGP SIGNED MESSAGE- Johnie Ingram [EMAIL PROTECTED] writes: ... and would be willing to help at the Debian booth (#503, community pavillion, check it out), or who knows good places to stay at in Atlanta? Or who wants to planepool with the Novare team from Dallas? I'm going to be there for the whole thing or close to it (arriving Wednesday evening, leaving Saturday afternoon, staying in the conference hotel)... I'm not sure what my schedule will be other than that I'm speaking at 11 AM Friday. I'd be happy to help out, time permitting. - --Rob - -- Rob Tillotson N9MTB [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE3+p9DCvU7mQ6Z9HYRARujAJ9VvaGwQe91Dr5q++oOvACvTmdHYACgu263 i2qbstnHnuWIwYDVh65CpEs= =TMXe -END PGP SIGNATURE-
RE: DO NOT UPGRADE TO POTATO. MENU UPLOAD ON OCT 2 KILLS SYSTEMS
It doesn't totally kill the system .. It seems to start up the various wm's, and they run at about 95% cpu and 88%+ memory for about 2-5 mins (each), but they do die (or finish?) and everything is fine (my worst case, I saw gnome-panel running at 95% for about 3 mins, then wmaker running at that for 3 mins.. (in console mode))... Its an annoyance, but it doesn't kill the system .. (at least on 3 of mine it didn't) Could we have a potato mailing lists? It would be really nice to e-mail fellow potato users and check for the latest bugs, features, etc. Also... someone commented to me about how unstable debian is. After some clarifications... I realized that he was talking about the potato debian release which was always discussed on the debian-user mailing lists. regards, = == Andre M. Varon - Technical Head = = == Lasaltech, Inc. - http://andre.lasaltech.com = === = = = = If I cannot bend Heaven, I shall move Hell. = = -- Publius Vergilius Maro (Virgil)
Package giveaway, will sponsor if necessary.
I'm just looking to create some free time to put into other projects. If no one wants these I'll just keep going, but updates will be seldom. I'll sponsor new maintainers of these until they get their upload privs. rtf2latex - simple C program. New upstream waiting at CTAN. Excellent first package. empire-ptkei - Surely there must be another empire fanatic out there? I've never actually played with this client, nor do I know python. Newer upstream available. gtkglareamm - C++ wrapper library around the GtkGLArea widget. Not used by any binaries at present, so it would be a good first lib package. gtkglarea - I'm still using this, but if someone wants to lighten my load it could go with gtkglareamm. -- Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302 John Curtin School of Medical Research, Australian National University 0200 Replies to other than [EMAIL PROTECTED] will be routed off-planet
Re: dpkg -l format
On Tue, 5 Oct 1999, Colin Walters wrote: The output format of dpkg -l is terrible. Many package names exceed the measly 16 characters allotted. Many, many times when trying to Yes. what I really want to do is dpkg -l '*netscape*' | xargs dpkg --purge. I recommend dpkg --get-selections '*netscape*' instead. But the whole bunch of 'informative' dpkg options is rather weird: * dpkg --list doesn't list all available packages, but just the ones that have been 'touched' by a selection. dpkg -- list '*' lists all available and some unavailble (old cruft) packages. (not documented) * same with dpkg --get selections. (not documented) * dpkg -l '*netscape*' lists (on my system, continuously upgraded since Debian 1.3) MORE packages than dpkg --get-selections '*netscape*' but the difference is again never-installed cruft. (not documented) * there is no obvious reason (except that the dpkg developers may have more important things to fight with) why dpkg --status and dpkg --print-avail shouldn't accept wildcards, too, but they don't. (documented) Bjorn Brill [EMAIL PROTECTED] Frankfurt am Main, Germany
Re: Some developers still using slink?
On Tue, Oct 05, 1999 at 11:00:46AM +0100, Edward Betts wrote: So how many other developers are not using unstable? Raul Miller wrote: Perhaps this should be taken up on another list, if you expect input from more than a few people. On Tue, Oct 05, 1999 at 02:43:25PM -0700, Joey Hess wrote: A list other than debian-devel? A list with a charter of This is the main discussion list for development topics. All developers should be subscribed to this list.. His message was fine for this list, but when inviting a lot of followups of an information gathering sort, sometimes it might be better to redirect replies elsewhere. Then again, maybe that doesn't matter for this particular example. -- Raul
Re: So whos going to ALS
On Tue, Oct 05, 1999 at 04:55:12PM -0400, Johnie Ingram wrote: ... and would be willing to help at the Debian booth (#503, community pavillion, check it out), or who knows good places to stay at in Atlanta? Or who wants to planepool with the Novare team from Dallas? I'll be there for the duration, at the FSF booth. I'll be sure to stop by the Debian booth to see how things are going. Peter
Re: DO NOT UPGRADE TO POTATO. MENU UPLOAD ON OCT 2 KILLS SYSTEMS
A. M. Varon [EMAIL PROTECTED] writes: Could we have a potato mailing lists? That's part of what debian-devel *is* for. Why would we want another list for it? -- MONO - Monochrome Emulation This field is used to store your favorite bit. --FreeVGA Attribute Controller Reference
Re: linking binfmt_misc with mime-types
On Tue, 5 Oct 1999, Brian May wrote: [...] What I really would like is a filesystem that can store a mime-type for every file... That way no magic databases are required. In addition, the kernel could be configured to assign default mime-types for different file extensions, or something. This would mean instead of having lots of different programs trying to determine file types (each with a very different method - some use extensions, others use magic databases or a combination of the two). Programs like Apache wouldn't have to work out the mime type from the extension, but could just look at the value given by the filesystem. Changing the mime-type for one file would automatically effect all programs. [ runs for cover... ] Apples MacOS does nearly that (not really MIME types, but a proprietary code with the same intention). First I liked the idea, but after some time the whole thing started to suck deadly and when I work on a Mac now, one of the most important utilities I use is named 'Set its type!'. I think file(1) does quite a good job and I believe that specifying what you want to do with a file is much better than 'click it and wait for the magic'. There are far too many useful actions available for some file types. Now that doesn't mean you have to cover. My mailer still doesn't support x-application/flamethrower :)~~ Bjorn Brill [EMAIL PROTECTED] Frankfurt am Main, Germany
Re: Intent to give away or REMOVE: tkstep
On Tue, Oct 05, 1999 at 09:39:14PM +0200, Federico Di Gregorio wrote: I state my complete lack of interest for tkstep, in both its 4.2 and 8.0 incarnations. 4.2 is now obsolete (as tk 4.2 is) and 8.0 is not kept updated by its upstream author. I use very few tk programs myself, so i'd like to find someone to give these packages to. IMHO both packages can go out of debian and I will ask the ftp maintainer to do that if nobody steps forward in a couple of week to take care of them. I know very little TCL/TK, but I would be annoyed if tkstep8.0 were to disappear as I find TK to be frustrating to the point of agonizing without tkstep (It's a little better with, tollerable at least..) ...not a fan of TK. -- Joseph Carter [EMAIL PROTECTED] Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -- ahzz_ i figured 17G oughta be enough. pgpr4SFfHHm3J.pgp Description: PGP signature
Re: should installed daemons automatically restart upon upgrade?
On Wed, Oct 06, 1999 at 12:14:11AM +0200, Ingo Saitz wrote: Perhaps every postinst shold do something like this: if test -e /etc/rc`runlevel | cut -d\ -f2`.d/S??$DAEMON; then /etc/init.d/$DAEMON start fi This doesn't work for people using file-rc (which uses files to describe runlevels instead of directories and symlinks). Cheers, aj, who'd love to see a proper way of doing that -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgp2WlXBIn4r6.pgp Description: PGP signature
Splitting debian-user (was Re: DO NOT UPGRADE TO POTATO...)
Ben Pfaff [EMAIL PROTECTED] writes: A. M. Varon [EMAIL PROTECTED] writes: Could we have a potato mailing lists? That's part of what debian-devel *is* for. Why would we want another list for it? Ben answered on _debian-devel_, but not on _debian-user_; I hope he doesn't mind my posting in both places (this discussion has been going on in both places). A.M. said (I'm paraphrasing) that casual readers of debian-user may come away thinking Debian has lots of problems, when in fact the problems discussed are mostly in the unstable (currently potato) distribution. A.M's suggestion may have merit: a new _debian-user-unstable_ list could separate the user bleeding edge discussions from the stable user discussions. As Ben said, _debian-devel_ is already a place to discuss problems with unstable -- but there's lots of cruft there that's uninteresting to unstable users unless they're considering becoming developers. But if we create _debian-user-unstable_, the _debian-user_ readers would miss (would they care?) the discussions -- some of them interesting -- about changes, and might therefore be less well prepared to handle the upgrade to potato when it becomes stable. So I obviously can't make up my mind; I think we should let the _debian-user_ population decide: would you like to split the group? Here (from the http://www.debian.org/MailingLists/subscribe page) is how the above-mentioned lists are currently described: debian-user This is the main mailing list for all users and developers of Debian GNU/Linux systems. Many developers also follow the threads and step in to help every now and then. debian-devel This is the main discussion list for development topics. All developers should be subscribed to this list. As it is open to the public anyone can join the discussion.
ITP: rtf2latex (was: Package giveaway, will sponsor if necessary.)
On Wed, 6 Oct 1999, Drake Diedrich wrote: rtf2latex - simple C program. New upstream waiting at CTAN. Excellent first package. It'll technically be my second now, but first actually put into the distro. ;p I would like to package rtf2latex. If you'd like to give it to me let me know. Thanks. --Kevin R. Bullock [EMAIL PROTECTED] | [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] One World, one Web, one Program - Microsoft promotional ad Ein Volk, ein Reich, ein Fuhrer - Adolf Hitler
Re: couple of nits/warnings
In article [EMAIL PROTECTED] you wrote: tar -zxf control.tar.gz control ./control You can also use tar -zxf control.tar.gz *control which does not produce an error, and extracts either one. This is the fix I supplied for lintian when the tar upstream changed the way pathname whacking happens in tar... which our tools depended on. Given that we know what's in a control.tar.gz, the wildcard is not problematic. Bdale
perl dependancy problem
I have a package (debconf) that uses lib.pm. This is in perl-5.00[54]. It depends on perl5. I just installed a fresh unstable system, using the defaults. perl-5.004-base and perl-5.004 were installed, as was perl-5.005-base. perl-5.005 itself was not installed. perl -v says perl 5.005 is being used as the perl command. When debconf was installed, nothing in the dependancies pulled in perl-5.005. So the program fails. What am I supposed to do? I could make debconf depend on perl-5.005, but it really works with any version of perl 5. Also, if only perl-5.004-base, perl-5.005, and perl-5.005-base were installed, and the alternatives pointed /usr/bin/perl to perl 5.004, then it would still fail! I realize that would require manual intervention to change the alternattives priorities, but it still worries me. It seems the only completly safe thing to do is depend on perl-5.005 and explicitly use /usr/bin/perl-5.005. I hate being forced to do that, with a package that will work with any perl 5. -- see shy jo
Re: perl dependancy problem
On Tue, Oct 05, 1999 at 10:27:00PM -0700, Joey Hess wrote: I have a package (debconf) that uses lib.pm. This is in perl-5.00[54]. It depends on perl5. I just installed a fresh unstable system, using the defaults. perl-5.004-base and perl-5.004 were installed, as was perl-5.005-base. perl-5.005 itself was not installed. Huh? perl-5.005 is priority: important, and it doesn't seem to conflict with anything else. How come it didn't get installed? My first suspicion was that having the dummy `perl' package still around might've been causing problems, but I can't see how it could be. perl -v says perl 5.005 is being used as the perl command. When debconf was installed, nothing in the dependancies pulled in perl-5.005. So the program fails. Yick. Perhaps the alternative priorities could be arranged differently? Something like perl-5.004-base with a priority of 5004 perl-5.005-base with a priority of 5005 perl-5.004 with a priority of 15004 perl-5.005 with a priority of 15005 ? Can this even be done, though? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpnG2eQB7CMK.pgp Description: PGP signature
procps trying to overwrite /bin/kill
Package: procps Version: 1:2.0.3-3 Preparing to replace procps 1:2.0.3-3 (using .../procps_1%3a2.0.3-4_i386.deb) ..
Re: perl dependancy problem
Anthony Towns wrote: Huh? perl-5.005 is priority: important, and it doesn't seem to conflict with anything else. How come it didn't get installed? I dunno. I installed the base system from cd, went into dselect, selected nothing that wasn't automatically selected, and installed, then went on to install a few more packages peicmeal with apt. Yick. Perhaps the alternative priorities could be arranged differently? That doesn't address the real problem, which is that one version of perl may be installed and satisfy the dependancy, while the alternatives system makes another one be used. -- see shy jo
Re: procps trying to overwrite /bin/kill
On Wed, Oct 06, 1999 at 02:24:35AM -0400, Colin Walters wrote: Package: procps Version: 1:2.0.3-3 Preparing to replace procps 1:2.0.3-3 (using .../procps_1%3a2.0.3-4_i386.deb) .. . Unpacking replacement procps ... dpkg: error processing /var/cache/apt/archives/procps_1%3a2.0.3-4_i386.deb (--un pack): trying to overwrite `/bin/kill', which is also in package bsdutils dpkg-deb: subprocess paste killed by signal (Broken pipe) This seems to be seriously broken. No, news bsdutils package is without kill. Mirek
Re: perl dependancy problem
On Tue, Oct 05, 1999 at 11:28:34PM -0700, Joey Hess wrote: Yick. Perhaps the alternative priorities could be arranged differently? That doesn't address the real problem, which is that one version of perl may be installed and satisfy the dependancy, while the alternatives system makes another one be used. The idea was to make the default alternative be the fullest and latest perl available, no matter which combination of perls are installed. If the admin specifically changes things so that /usr/bin/perl refers to something that doesn't let you `use foo', then that's eir decision. They could just as easily symlink /usr/bin/perl to a shell script that echoes `PeRL SuX!!!11!!' and dies if they wanted to. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgp1qJqvJgYuq.pgp Description: PGP signature
Re: procps trying to overwrite /bin/kill
Mirek Kwasniak [EMAIL PROTECTED] writes: On Wed, Oct 06, 1999 at 02:24:35AM -0400, Colin Walters wrote: Package: procps Version: 1:2.0.3-3 Preparing to replace procps 1:2.0.3-3 (using .../procps_1%3a2.0.3-4_i386.deb) .. . Unpacking replacement procps ... dpkg: error processing /var/cache/apt/archives/procps_1%3a2.0.3-4_i386.deb (--un pack): trying to overwrite `/bin/kill', which is also in package bsdutils dpkg-deb: subprocess paste killed by signal (Broken pipe) This seems to be seriously broken. No, news bsdutils package is without kill. Then there should be a proper conflicts or replaces header in the procps package. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: vim/nvi priority Re: moving mutt to standard priority
On Tue, Oct 05, 1999 at 07:15:10PM -0500, Steve Greenland wrote: As to why nvi is Standard and vim/elvis/etc. are Optional, it's because nvi is closest to a standard, classic, BSD Bill Joy vi, warts and all. Also, I think it's the smallest full-fledged vi. Certainly Yes, and those are good reasons to keep it that way, please. Hamish (plain nvi only, thanks) -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: DO NOT UPGRADE TO POTATO. MENU UPLOAD ON OCT 2 KILLS SYSTEMS
On Tue, Oct 05, 1999 at 08:13:41PM -0400, Terry Katz wrote: 2.1.3-2 is one that does it ... Seems to behave itself here. But then I only have fvwm2 installed, none of these fancy new wms. hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: perl dependancy problem
Le Tue, Oct 05, 1999 at 10:27:00PM -0700, Joey Hess écrivait: What am I supposed to do? I could make debconf depend on perl-5.005, but it really works with any version of perl 5. Also, if only perl-5.004-base, perl-5.005, and perl-5.005-base were installed, and the alternatives pointed /usr/bin/perl to perl 5.004, then it would still fail! I realize that would require manual intervention to change the alternattives priorities, but it still worries me. Yes this is a problem. How can we force perl-5.005 by default instead of perl-5.004 ... we need to add a dependency somewhere. BTW, Darren, what happened to perl-base ? It doesn't depend on perl5-base anymore ... perl-base should depend on perl-5.005-base | perl5-base in order to install perl-5.005-base by default. And perl-5.005-base will suggest perl-5.005 but this is not enough to be sure that a perl5 dependency will give us a complete perl environment. Maybe we should put the alternatives for /usr/bin/perl in perl-5.00X and simply create a link in perl-5.00X-base if one doesn't exist ... this way /usr/bin/perl would always exist and always point to the more complete perl installation (perl-5.00X and perl-5.00X-base instead of -base only). Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd /pub
Re: DO NOT UPGRADE TO POTATO. MENU UPLOAD ON OCT 2 KILLS SYSTEMS
On 5 Oct 1999, Ben Pfaff wrote: A. M. Varon [EMAIL PROTECTED] writes: Could we have a potato mailing lists? That's part of what debian-devel *is* for. Why would we want another list for it? Maybe a debian-design would care of long-terms management and a debian-devel would care of the unstable version specific problems. But it would create some redundancy, for sure. -- Jean-Christophe Dubacq
Re: Package giveaway, will sponsor if necessary.
On Wednesday 6 October 1999, at 11 h 29, the keyboard of Drake Diedrich [EMAIL PROTECTED] wrote: gtkglarea - I'm still using this, but if someone wants to lighten my load it could go with gtkglareamm. I maintain xt, which uses it. And another GtkGl library, which is no longer developed upstream and not used by anything in Debian. So, I can take this one and orphan libgtkgl.
Re: Intent to give away or REMOVE: tkstep
On Tue, Oct 05, 1999 at 10:45:59PM -0400, Steve Kostecke wrote: -BEGIN PGP SIGNED MESSAGE- In article [EMAIL PROTECTED] you wrote: Ciao *, I state my complete lack of interest for tkstep, in both its 4.2 and 8.0 incarnations. 4.2 is now obsolete (as tk 4.2 is) and 8.0 is not kept updated by its upstream author. I use very few tk programs myself, so i'd like to find someone to give these packages to. IMHO both packages can go out of debian and I will ask the ftp maintainer to do that if nobody steps forward in a couple of week to take care of them. I know very little about tk. But I do use tkstep to make exmh look better. I'll take the packages if no one else steps forward before October 20th. If nobody else wants it, it's your. Just upload new version with your name in it... ciao, Federico
Re: Uninstallable Packages
Joseph Carter wrote: On Tue, Oct 05, 1999 at 10:13:51PM +1000, Anthony Towns wrote: Depends: libgl1 ; which doesn't exist This exists in CVS. libGL.so.1 is what is used by the latest versions of GLX and Mesa. I think the problem was coming up with a sane way to make alternatives work for the purpose since libgl1 is almost certainly a virtual package provided by Mesa, GLX, and probably commercial offerings as well. Compound this with Mesa and GLX merging and you've got something close to a nightmare. IMO there's yet another issue to consider (which brings another complication with it): there may be people who will want both mesa and glx, if they own a Riva or Matrox + Voodoo* add-on board. As long as Mesa keeps using the name libMesa* it can probably coexists with GLX (exept perhaps for include files?), but I've heard that they will change to libGL* as well. If they are planning on merging with GLX, the problem of multiple video cards (and drivers) will be theirs I guess.
Re: recompile needed for xlib6g (= 3.3.5-1) instead of (= 3.3.2.3a-2) ?
On Tue, 5 Oct 1999, Branden Robinson wrote: On Tue, Oct 05, 1999 at 11:43:14AM +0200, Santiago Vila wrote: On Fri, 1 Oct 1999, Peter S Galbraith wrote: Should I rebuild the i386 binaries with the new xlib6g-dev and upload them with .0.1 version number suffix? Or perhaps it doesn't matter? As far as xlib6g is concerned, I don't think it does matter. But it might. There *have* been changes to the libraries between 3.3.2.3 and 3.3.5. No, I don't think any interfaces have changed. But just to err on the side of caution, would anyone doing what Santiago is doing PLEASE recompile their packages against the latest versions of the potato libraries shortly before the potato freeze? Mixed slink/potato systems are temporary things. Potato will be around for a long time. So let us please make it internally consistent. You seem to imply that a package compiled under slink saying xlib6g (= 3.3.2.3a-2) might not work ok under potato. Well, if this is the case, then IMHO it would be a bug, that we should better discover and fix rather than not discover and not fix it. Thanks. -- d3b4a86229ffa32d21ca6b60a5e15b21 (a truly random sig)
Re: /usr/etc and /usr/local/etc?
In article [EMAIL PROTECTED] you write:
Config files are, by their nature, host-specific, and should not be in
/usr
They are not. e.g. /etc/hosts should be the same across a pool. Nearly
all files in /etc can be shared and none should be rewritten on the
fly.
Agreed. My diskless package needlessly has to copy the entire
contents of /etc for every host, since it cannot be shared.
However, how would you distinguish a shareable config file from a
non-shareable config file? eg would {samba,squid,etc} be sharable???
(not that you would normally run these on a diskless system).
I think if you are going to use /usr/etc, programs should first check
/etc, in case the system administrator wishes to override the sharable
config file for the given host.
IMHO, only a few files in /etc are not sharable, eg /etc/hostname
/etc/mailname, /etc/news/whoami (I may have these names wrong), possibly
mail configuration, network configuration (actually, this is sharable if
kernel level auto IP configuration is enabled). Please tell me if I missed
anything.
On the downside, it is possible that it might simplify my diskless
package (need to think about this more). Yuck - can't have that ;-).
Apart from /etc/mtab (which can be linked to /proc/mounts) normaly
nothing gets written to /etc and / can be ro. For diskless systems
/usr/etc and /usr/share/etc could reduce the size of the ramdisk or
root fs needed to boot and more data could be shared across a pool.
Alternatively /etc/share/, /etc/arch and /etc/local could be
used. Just as one likes.
I prefer /usr/etc, as this means a seperate mount point is
not required, as /usr is already shared.
--
Brian May [EMAIL PROTECTED]
Re: linking binfmt_misc with mime-types
In article [EMAIL PROTECTED] you write: Mmh. I like to think of the file utility as the standard reference. I didn't knew about any other such databases. That apache uses file extensions is bad, but it's reasonable for a browser which only serves a well defined set of files. Any program that reads multiple file formats does some sought of automatic file type detection. Some of these are so deeply engrained (eg gcc), that I doubt they will ever be changed. eg: - gcc looks at the file extension to determine what type the input file is. - gimp does the same. - magicfilter (do I need to say more?) - can't remember what xv does. - lots more - I am not wide awake at the moment ;-) Currently, the file extension is used for a lot of things, but I think the filename should be for user identification of the file, and not for system identification. -- Brian May [EMAIL PROTECTED]
Re: /usr/etc and /usr/local/etc?
On Wed, Oct 06, 1999 at 08:31:02PM +1000, Brian May wrote:
In article [EMAIL PROTECTED] you write:
Config files are, by their nature, host-specific, and should not be in
/usr
They are not. e.g. /etc/hosts should be the same across a pool. Nearly
all files in /etc can be shared and none should be rewritten on the
fly.
Agreed. My diskless package needlessly has to copy the entire
contents of /etc for every host, since it cannot be shared.
However, how would you distinguish a shareable config file from a
non-shareable config file? eg would {samba,squid,etc} be sharable???
(not that you would normally run these on a diskless system).
I think if you are going to use /usr/etc, programs should first check
/etc, in case the system administrator wishes to override the sharable
config file for the given host.
This is a good idea for programs that live in /usr/bin or /usr/sbin, but
would require program support to check for configs in multiple locations.
However, I suggest that programs living in /bin and /sbin MUST have
their configs in /etc in case /usr is not available.
IMHO, only a few files in /etc are not sharable, eg /etc/hostname
/etc/mailname, /etc/news/whoami (I may have these names wrong), possibly
mail configuration, network configuration (actually, this is sharable if
kernel level auto IP configuration is enabled). Please tell me if I missed
anything.
See above.
On the downside, it is possible that it might simplify my diskless
package (need to think about this more). Yuck - can't have that ;-).
Apart from /etc/mtab (which can be linked to /proc/mounts) normaly
nothing gets written to /etc and / can be ro. For diskless systems
/usr/etc and /usr/share/etc could reduce the size of the ramdisk or
root fs needed to boot and more data could be shared across a pool.
Alternatively /etc/share/, /etc/arch and /etc/local could be
used. Just as one likes.
I prefer /usr/etc, as this means a seperate mount point is
not required, as /usr is already shared.
--
Brian May [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Steve Bowman [EMAIL PROTECTED][EMAIL PROTECTED]
Buckeye, AZ
Powered by Debian GNU/Linux http://www.debian.org
Re: A new axis for bugs?
[moved to -devel] On Wed, Oct 06, 1999 at 02:34:20AM -0400, Branden Robinson wrote: I like this idea, but I think it is orthogonal to the existing bug categories. I don't know what you would call it, but I imagine a 4-way status switch: unreproduced reproduced possible fix known fix Basically I see bug fixing as proceeding sequentially down this list. There's a state above unreproduced, which is not a bug, and you close it almost immediately. There's also the state after known fix, which is implementation, and is reflected by closing it or setting its severity to fixed. This is great. The BTS is our institutional memory, and we really need a mechanism for organizing it. This might do it. It would also make things easier for people who are trying to help fix bugs--they could filter out already-fixed bugs more easily and focus their attention on the stuff that really needs work. Mike Stone pgp18TFzhGlgN.pgp Description: PGP signature
Re: linking binfmt_misc with mime-types
What I really would like is a filesystem that can store a mime-type for every file... That way no magic databases are required. In addition, the kernel could be configured to assign default mime-types for different file extensions, or something. This would mean instead of having lots of different programs trying to determine file types (each with a very different method - some use extensions, others use magic databases or a combination of the two). Programs like Apache wouldn't have to work out the mime type from the extension, but could just look at the value given by the filesystem. Changing the mime-type for one file would automatically effect all programs. [ runs for cover... ] Apples MacOS does nearly that (not really MIME types, but a proprietary code with the same intention). First I liked the idea, but after some time the whole thing started to suck deadly and when I work on a Mac now, one of the most important utilities I use is named 'Set its type!'. Where Macintosh fails, IMHO, is due to - No easy way to change the file type. - The information it proprietary, and not used anywhere else. - I am not very familar with the operating system, so there might be more points that I have missed. Perhaps there are difficulties loading a file for one application inside another application? - AFAIK, Macintosh doesn't really store file type but rather which application is this file associated with. So if you have multiple programs that deal with the same file type, the file has to be associated with *exactly one* application. (not sure about this) - just curious: what other times do you need to change this file type? If you did what I proposed, instead of having to configure each and every program manually that mypicture is image/gif, you would just set the mime-type ONCE. If at a latter date, you suddenly realize that PNG would be a better format, you don't have to change the name of the file, and you want break any links to that file (especially external http links). When you loaded that image, whether you used apache, gimp, xv, or something else, it would automatically know what file type it is without any excessive overhead. Currently most programs use the file extension, which IMHO is very similar to my proposal, except: - mime types are standard, not just defacto standard. - not part of the file name, ie a seperate attribute, like the date and time. Put another way, the filename is independant of what type the file is. I think file(1) does quite a good job and I believe that specifying what you want to do with a file is much better than 'click it and wait for the magic'. There are far too many useful actions available for some file types. File is not used by many programs that check the file type. I think it is too slow for some applications (Apache), while for others (eg magicfilter) I can't remember the reasons given (but I know that good reasons exist). I am not proposing any click it and wait for the magic type think here, that was more related to the binfmt_misc proposal, where executing a file would automatically open the file with the correct program. However, this is already done with WWW, and I don't see any problems there (except misconfigured MIME types on some servers - something that would benifit from my proposal, at least for HTTP). I don't know how reliable file is either, but I strongly suspect that there will be files which will confuse it. -- Brian May [EMAIL PROTECTED]
Re: linking binfmt_misc with mime-types
In addition, the kernel could be configured to assign default mime-types for different file extensions, or something. You say a magic type database is a hack, and on the other hand file exetensions are a better indicator? Phew. Microsoft uses file extension (.tgz file if it can't recognize). I think examining the content is a much better strategy. This is one thing I didn't like myself. The difficulty is when I create a new file, eg vim myfile.html (or just myfile). what initialy mime type should be set? Perhaps the default should be no mime type, which translates to a binary file. The user would manually set the type as required. This is an extra step though, which currently is only required for executable files, to set execute permission. perhaps vim --mimetype=text/html myfile.html vim would check that text/html is a valid mime type, eg by inspecting /etc/mime.types As for Microsoft, do programs like Outlook even look at the mimetype? I remember sending some people a plain/text mime type attachment, and outlook got confused because it didn't recognise the file extension, and forced the user to save the file to disk... -- Brian May [EMAIL PROTECTED]
Re: perl dependancy problem
On Tue, Oct 05, 1999 at 10:27:00PM -0700, Joey Hess wrote:
What am I supposed to do? I could make debconf depend on perl-5.005, but it
really works with any version of perl 5. Also, if only perl-5.004-base,
perl-5.005, and perl-5.005-base were installed, and the alternatives pointed
/usr/bin/perl to perl 5.004, then it would still fail! I realize that would
require manual intervention to change the alternattives priorities, but it
still worries me.
If you want debconf to work before the perl packages get fixed you could
do something like (maybe use a different use statement):
#!/bin/sh
eval 'perl -e use POSIX 2/dev/null exec /usr/bin/perl -S $0 ${1+$@}'
if $running_under_binsh;
eval 'exec /usr/bin/perl5.004 -S $0 ${1+$@}'
if $running_under_binsh;
--
Raul
Re: Splitting debian-user (was Re: DO NOT UPGRADE TO POTATO...)
But if we create _debian-user-unstable_, the _debian-user_ readers would miss (would they care?) the discussions -- some of them interesting -- about changes, and might therefore be less well prepared to handle the upgrade to potato when it becomes stable. So I obviously can't make up my mind; I think we should let the _debian-user_ population decide: would you like to split the group? I don't think it's a good idea to split them up. Many issues discussed in debian-user apply to both stable and unstable, not to mention Linux in general. I like the idea of reading one list and being able to beneift from the experiences of people running both distributions. Occasionally when I want to know more about the bleeding edge, I'll subscribe to debian-devel for a while and see what's going on. Tom
Re: /usr/etc and /usr/local/etc?
On Wed, Oct 06, 1999 at 03:43:07AM -0700, Steve Bowman wrote: I think if you are going to use /usr/etc, programs should first check /etc, in case the system administrator wishes to override the sharable config file for the given host. This is a good idea for programs that live in /usr/bin or /usr/sbin, but would require program support to check for configs in multiple locations. However, I suggest that programs living in /bin and /sbin MUST have their configs in /etc in case /usr is not available. What files would you consider fall into this catagory? -- Brian May [EMAIL PROTECTED]
Re: ITP: Re: Must hand off XEmacs21 project!
On 02 Oct 1999 18:49:59 -0400 Dres == James LewisMoss [EMAIL PROTECTED] wrote... Dres So, to all on devel consider this a ITP on xemacs21 and I would Dres appreciate anyone who has a chance to test the packages. Apt line Dres that should work: deb http://va.debian.org/~dres xemacs21/. I tried your xemacs21-21.1.7-1 package (mule). Installed with apt, apt-get install xemacs21-mule. But, xemacs21 had segmentation fault on my machines.(3 machines, I tried) % xemacs21 segmentation fault xemacs21 or % xemacs21 illegal hardware instruction xemacs21 Sorry, have no informations, just results. Regards. -- Takuo KITAME [EMAIL PROTECTED]
Re: So whos going to ALS
I could haul my printer in again. Also, I've got a real machine this year... AMD K6-III 450MHz Viper 770, NetGear 10/100 NIC... 19 Optiquest monitor. Who's coordinating? TIA -- Greg. - Original Message - From: Sean 'Shaleh' Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; debian-user@lists.debian.org; debian-devel@lists.debian.org Sent: Tuesday, October 05, 1999 2:12 PM Subject: RE: So whos going to ALS On 05-Oct-99 Johnie Ingram wrote: ... and would be willing to help at the Debian booth (#503, community pavillion, check it out), or who knows good places to stay at in Atlanta? Or who wants to planepool with the Novare team from Dallas? Joey Hess and myself are going. We have one extra space in the hotel room. Preferably for a Debian developer, preferably one who needs to save the money. We have two double beds and currently three people, a fourth is welcome. If you want a spot on the floor, well that can be arranged as well (-: We arrive Wednesday night at 7:30pm, so room is available from Wednesday night on thru Saturday night. -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Uninstallable Packages
* Filip == Filip Van Raemdonck [EMAIL PROTECTED] wrote: Filip IMO there's yet another issue to consider (which brings another Filip complication with it): there may be people who will want both Filip mesa and glx, if they own a Riva or Matrox + Voodoo* add-on Filip board. /me waves his hand. Matrox G200 and Vodoo Graphics. BTW: is there a mesa deb with glide support somewhere? Ciao, Martin
Re: SSH never free
Marco d'Itri [EMAIL PROTECTED] wrote:
On Oct 02, Herbert Xu [EMAIL PROTECTED] wrote:
The patent makes it non-free, so does the new license.
Really? In my country RSA is not patented, why should I care about what
happens in someone else country?
Please have a look at our policy.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Unstable release
On Tue, 05 Oct 1999, Stephane Bortzmeyer wrote: If I could just get it installed properly (I run it at home, but had to do a lot of manual tuning, and adding all packages I wanted using dpkg --force* NO, NO, NO, this is not redhat.com! Do this on a Debian only if you really know what you are doing or you may destroy your system. As far as I can see there is often not another way to do it. Ie., program complains over a lib that is too old. If you try to install the lib it complains over that there is already an old version there. That's one of the problems I've encountered quite a lot of times with Debian, and one of the times I've had to use the force options. As for the problem with conflicting library versions or whatever you risk getting into when using --force*, I find that to be a smaller problem than the problems I get when dpkg complains about old versions that risk being overwritten. Btw, is it possible to tell dpkg to install all dependencies automagically? /Staffan
Re: linking binfmt_misc with mime-types
On Wed, 6 Oct 1999, Brian May wrote: [snip] - The information it proprietary, and not used anywhere else. That's true... - I am not very familar with the operating system, so there might be more points that I have missed. Perhaps there are difficulties loading a file for one application inside another application? This isn't a problem. There are two different values here; creator and the filetype. - AFAIK, Macintosh doesn't really store file type but rather which application is this file associated with. So if you have multiple programs that deal with the same file type, the file has to be associated with *exactly one* application. (not sure about this) Sort of, yes. You associate the type with one program, which will be the default program to open if you double-click on such a file. This won't influence the possibility to edit the file in another program, however. - just curious: what other times do you need to change this file type? The time is stored in the resource-fork on the Mac, and sometimes it gets screwed (programs that can't transfer dual/multi forked programs over the net properly, etc.) [snip] /David Weinehall _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire /
Re: /usr/etc and /usr/local/etc?
On Wed, Oct 06, 1999 at 09:20:32PM +1000, Brian May wrote: On Wed, Oct 06, 1999 at 03:43:07AM -0700, Steve Bowman wrote: I think if you are going to use /usr/etc, programs should first check /etc, in case the system administrator wishes to override the sharable config file for the given host. This is a good idea for programs that live in /usr/bin or /usr/sbin, but would require program support to check for configs in multiple locations. However, I suggest that programs living in /bin and /sbin MUST have their configs in /etc in case /usr is not available. What files would you consider fall into this catagory? Well, I was speaking hypothetically; however, I just did a quick check on the 780 packages I have installed as follows (extracted from history): 600 cd /var/lib/dpkg/info 603 egrep ^/bin/|^/sbin/ *.list /tmp/tmp.pkginfo 605 cd /tmp 607 cut -f1 -d':' tmp.pkginfo | sort -u /tmp/tmp.pkginfo2 610 sed s/\.list$// tmp.pkginfo2 tmp.pkginfo3 616 for i in `cat tmp.pkginfo3`; do cat /var/lib/dpkg/info/$i.conffiles; done tmp.pkginfo4 2/dev/null And here's the output file (tmp.pkginfo4): /etc/ae.rc /etc/profile /etc/skel/.bash_profile /etc/skel/.bashrc /etc/console-tools/config /etc/init.d/keymaps-lct.sh /etc/init.d/console-screen.sh /etc/init.d/hwtools /etc/isapnp.conf /etc/init.d/isapnp /etc/isapnp.gone /etc/security/access.conf /etc/security/group.conf /etc/security/limits.conf /etc/security/pam_env.conf /etc/security/time.conf /etc/conf.linuxconf /etc/init.d/linuxconf /etc/logrotate.d/linuxconf /etc/pam.d/linuxconf /etc/login.defs /etc/pam.d/login /etc/pam.d/su /etc/init.d/logoutd /etc/init.d/makedev /etc/init.d/mdutils /etc/mgetty/login.config /etc/mgetty/dialin.config /etc/mgetty/sendfax.config /etc/mgetty/mgetty.config /etc/mgetty/new_fax /etc/cron.daily/mgetty /etc/issue.mgetty /etc/cron.d/modutils /etc/init.d/modutils /etc/init.d/kerneld /etc/modules /etc/modutils/aliases /etc/modutils/paths /etc/modutils/arch/i386 /etc/modutils/arch/m68k.generic /etc/modutils/arch/m68k.amiga /etc/modutils/arch/m68k.atari /etc/modutils/arch/m68k.mac /etc/init.d/inetd /etc/init.d/portmap /etc/init.d/networking /etc/cron.daily/netbase /etc/gateways /etc/protocols /etc/services /etc/hosts.allow /etc/hosts.deny /etc/rpc /etc/network/interfaces /etc/netgroup /etc/init.d/nis /etc/ypserv.conf /etc/ypserv.securenets /etc/yp.conf /var/yp/Makefile /etc/init.d/setserial /etc/serial.conf /etc/syslog.conf /etc/init.d/sysklogd /etc/cron.daily/sysklogd /etc/cron.weekly/sysklogd /etc/init.d/bootmisc.sh /etc/init.d/checkfs.sh /etc/init.d/checkroot.sh /etc/init.d/halt /etc/init.d/hostname.sh /etc/init.d/mountall.sh /etc/init.d/mountnfs.sh /etc/init.d/reboot /etc/init.d/rmnologin /etc/init.d/sendsigs /etc/init.d/single /etc/init.d/umountfs /etc/init.d/urandom /etc/init.d/hwclock.sh /etc/fdprm /etc/pam.d/kbdrate And then, there's the packages I don't have installed that didn't get checked. I think there's a few files missing that are built during installation, by postinst's, or by hand, too, including /etc/hosts (you or someone already mentioned) /etc/fstab /etc/lilo.conf /etc/exports and there may be others since searching for these isn't so easy. Some of these could probably be shared anyway, such as /etc/login.defs to establish a common policy across machines or /etc/init.d/halt since there's no obvious reason why it needs to be customized. In fact, most of the init.d scripts could probably be shared But again, what if /usr isn't available because, say, the network's down. BTW, I *like* the idea of moving stuff out of /etc to /usr/etc or maybe /usr/local/etc. It's not the /etc is too big, it's too messy. I just think that stuff in /bin and /sbin set an upper bound on what can be moved without breaking things. Regards, Steve Bowman -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Steve Bowman [EMAIL PROTECTED][EMAIL PROTECTED] Buckeye, AZ Powered by Debian GNU/Linux http://www.debian.org
Re: Unstable release
On Wed, Oct 06, 1999 at 02:12:08PM +0200, Staffan Hämälä was heard to say: NO, NO, NO, this is not redhat.com! Do this on a Debian only if you really know what you are doing or you may destroy your system. As far as I can see there is often not another way to do it. Ie., program complains over a lib that is too old. If you try to install the lib it complains over that there is already an old version there. That's one of the problems I've encountered quite a lot of times with Debian, and one of the times I've had to use the force options. Could you give an example? I'm vague here on what your problem is. As for the problem with conflicting library versions or whatever you risk getting into when using --force*, I find that to be a smaller problem than the problems I get when dpkg complains about old versions that risk being overwritten. Btw, is it possible to tell dpkg to install all dependencies automagically? /Staffan apt is for dependency resolution. Use it. (if there's a reason you can't use it, file bug reports until you can :) ) Daniel -- DROP THE SCYTHE AND TURN AROUND SLOWLY. -- Terry Pratchett, Reaper Man
Re: couple of nits/warnings
On Tue, 5 Oct 1999, Bdale Garbee wrote: In article [EMAIL PROTECTED] you wrote: tar -zxf control.tar.gz control ./control You can also use tar -zxf control.tar.gz *control which does not produce an error, and extracts either one. This is the fix I supplied for lintian when the tar upstream changed the way pathname whacking happens in tar... which our tools depended on. Given that we know what's in a control.tar.gz, the wildcard is not problematic. slaps palm to forehead and mutters I should have guessed Yep, in this special case that is equivalent. Thanks! I'm very happy to get rid of two error messages per package ;-) Luck, 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: /usr/etc and /usr/local/etc?
On Wed, Oct 06, 1999 at 05:30:13AM -0700, Steve Bowman wrote: BTW, I *like* the idea of moving stuff out of /etc to /usr/etc or maybe /usr/local/etc. It's not the /etc is too big, it's too messy. I just think that stuff in /bin and /sbin set an upper bound on what can be moved without breaking things. Sorry to reply to my own post, but I think I overstated my case a little bit on two counts First, I should have said *risk* of breaking things. Of course they'll work fine normally. Second, the search I did makes an unstated assumption since it was done by package. There may be packages that have multiple binaries and the conffiles are used by binaries in /usr/bin or /usr/sbin and not even used by the binaries in /bin or /sbin. I don't have an easy answer for how to winnow out unneeded conffiles to remove this assumption. Probably case-by-case examination is needed. Regards, Steve Bowman
permission denied on owned files
Something else strange just happened during an autobuild pass. All of the subdirectories in my build tree have suddenly become inaccessable to the build user, who owns all the files and directories. Here is what I get: --begin paste- $ user build $ pwd /Debian/build $ cd sbuild sh: cd: sbuild: Permission denied $ ls -l total 9 -rw-rw-r-- 1 buildbuild 59 Oct 5 15:53 build.list -rw-rw-r-- 1 buildbuild1153 Oct 6 09:47 buildpkgs.log drw-rw-r-- 2 buildbuild1024 Sep 19 12:06 lists drw-rw-r-- 2 buildbuild1024 Oct 5 16:04 logs -rw-rw-r-- 1 buildbuild 131 Sep 20 06:54 oldbuild.list -rw-rw-r-- 1 buildbuild 63 Oct 1 11:12 prebuild.list -rw-rw-r-- 1 buildbuild 193 Oct 2 18:09 prebuild1.list drw-rw-r-- 2 buildbuild1024 Oct 6 09:47 sbuild $ cd logs sh: cd: logs: Permission denied $ ls -l ../ total 4 drwxrwxr-x 7 buildbuild1024 Oct 5 15:56 build drwxr-xr-x 2 root root 1024 Sep 19 10:52 dists drwxr-xr-x 2 root root 1024 Sep 16 06:50 lost+found drwxr-xr-x 5 root root 1024 Oct 4 20:03 pkgwork $ --end paste--- Since I couldn't get into them as the build user, I took a look as su and found: $ su Password: dwarf:/Debian/build# ls -l sbuild total 2699 -rw-rw-r-- 1 buildbuild 442398 Oct 6 09:47 tk8.2_8.2.0-3.diff.gz -rw-rw-r-- 1 buildbuild 623 Oct 6 09:47 tk8.2_8.2.0-3.dsc -rw-rw-r-- 1 buildbuild 2305473 Oct 6 09:47 tk8.2_8.2.0.orig.tar.gz So, where do I look to figure out why I am not allowed access to these files/directories? TIA, 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
start daemons according to current runlevel upon upgrade
MoiN On Wed, Oct 06, 1999 at 12:37:48PM +1000, Anthony Towns wrote: On Wed, Oct 06, 1999 at 12:14:11AM +0200, Ingo Saitz wrote: Perhaps every postinst shold do something like this: if test -e /etc/rc`runlevel | cut -d\ -f2`.d/S??$DAEMON; then /etc/init.d/$DAEMON start fi This doesn't work for people using file-rc (which uses files to describe runlevels instead of directories and symlinks). OK, you're right. But that would be too complicated to include it in every postinst skript. I have created two scripts named start-rc.d. One for runlevel links and one for file-rc. I think, they should be included in the corresponding packages which contain the update-rc.d skript (dpkg and file-rc). I have attached these two files to this email. Please have a look if you like them and feel free to include them. I think that every package that would start a daemon in its postinst should use these files to start it. Ingo -- What's the difference between cold tee and cold coffee? Cold coffe doesn't taste good even if it would still be hot.
Re: permission denied on owned files
Dale Scheetz [EMAIL PROTECTED] writes: Something else strange just happened during an autobuild pass. All of the subdirectories in my build tree have suddenly become inaccessable to the build user, who owns all the files and directories. Here is what I get: $ cd sbuild sh: cd: sbuild: Permission denied $ ls -l total 9 drw-rw-r-- 2 buildbuild1024 Oct 6 09:47 sbuild So, where do I look to figure out why I am not allowed access to these files/directories? In order to access a directory you must have execute permission (the x-bit) on it. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: permission denied on owned files
On Wed, Oct 06, 1999 at 02:02:57PM +, Dale Scheetz wrote: Something else strange just happened during an autobuild pass. All of the subdirectories in my build tree have suddenly become inaccessable to the build user, who owns all the files and directories. Here is what I get: drw-rw-r-- 2 buildbuild1024 Sep 19 12:06 lists drw-rw-r-- 2 buildbuild1024 Oct 5 16:04 logs $ ls -l ../ total 4 drwxrwxr-x 7 buildbuild1024 Oct 5 15:56 build Note the missing +x permissions on the directory. You need +x permissions to be able to cd into the directory. It sounds like autobuild is doing some recursive chmod'n that it shouldn't be. -- Ryan Murray ([EMAIL PROTECTED], [EMAIL PROTECTED]) Software Designer, Glenayre Technologies Inc. The opinions expressed here are my own.
Suggestion: controlling the load average
I think the Debian installation tools need something to monitor the load average, to prevent systems from [ct]rashing during install. Cfr. sendmail which stops processing mail when it detects that the load average is above a specified threshold. A lot of programs start update-menus in the background upon installation. If you install (or upgrade) 50 of them, you get 50 running update-menus processes fighting for CPU cycles. [ correction: according to some people, this is not normal behavior, so it must be a bug in the current update-menus on PPC ] It may sound hard to update all helper scripts (like update-menus) used for installation, but even adding a simple load average check to dpkg only would cure most of the problems. If you do that dpkg just pauses until the load average is lower, i.e. until the background scripts are finished. This idea was inspired by the problem I had with update-menus, where they all kept running in the background when I did `apt-get upgrade -u'. All those update-menus processes consumed CPU cycles and tried to exhaust memory (I `only' have 128 MB in my PPC box). Greetings, Geert -- Geert Uytterhoeven - Sony Suprastructure Center Europe (SUPC-E) [EMAIL PROTECTED] --- Sint Stevens Woluwestraat 55 Phone +32-2-7248632 Fax +32-2-7262686 B-1130 Brussels, Belgium
Re: ITP: Re: Must hand off XEmacs21 project!
On Wed, Oct 06, 1999 at 08:25:03PM +0900, Takuo KITAME wrote: On 02 Oct 1999 18:49:59 -0400 Dres == James LewisMoss [EMAIL PROTECTED] wrote... Dres So, to all on devel consider this a ITP on xemacs21 and I would Dres appreciate anyone who has a chance to test the packages. Apt line Dres that should work: deb http://va.debian.org/~dres xemacs21/. I tried your xemacs21-21.1.7-1 package (mule). Installed with apt, apt-get install xemacs21-mule. But, xemacs21 had segmentation fault on my machines.(3 machines, I tried) % xemacs21 segmentation fault xemacs21 or % xemacs21 illegal hardware instruction xemacs21 xemacs21-nomule segfaults for me, as well (I submitted a bug report on it). It also made xemacs20 lose track of bbdb, so that I had to uninstall and reinstall xemacs20 and bbdb (purging xemacs21 didn't fix it). And now, I can't install xemacs21-nomule at all, because it depends on xemacs21-basesupport, which is not installable (there is no such package in http://va.debian.org/~dres/xemacs21/). Yikes! Peace, * Kurt Starsinic ([EMAIL PROTECTED]) - Technical Specialist * | `If we knew what it was we were doing, it wouldn't be called| |research, would it?' -- Albert Einstein| Institute for Scientific Information http://www.isinet.com/
Re: So whos going to ALS
Woohoo.. Just got the permission to skip two days from office for ALS. Will be there with my machine.. Dual celeron (300 oc'd 450) with a 19' monitor. Who's co ordinating... Regards, Vaidhy On Wed, Oct 06, 1999 at 07:30:30AM -0700, Greg Heather Vence wrote: I could haul my printer in again. Also, I've got a real machine this year... AMD K6-III 450MHz Viper 770, NetGear 10/100 NIC... 19 Optiquest monitor. Who's coordinating? TIA -- Greg. - Original Message - From: Sean 'Shaleh' Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; debian-user@lists.debian.org; debian-devel@lists.debian.org Sent: Tuesday, October 05, 1999 2:12 PM Subject: RE: So whos going to ALS On 05-Oct-99 Johnie Ingram wrote: ... and would be willing to help at the Debian booth (#503, community pavillion, check it out), or who knows good places to stay at in Atlanta? Or who wants to planepool with the Novare team from Dallas? Joey Hess and myself are going. We have one extra space in the hotel room. Preferably for a Debian developer, preferably one who needs to save the money. We have two double beds and currently three people, a fourth is welcome. If you want a spot on the floor, well that can be arranged as well (-: We arrive Wednesday night at 7:30pm, so room is available from Wednesday night on thru Saturday night. -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
start daemons corresponding to the current runlever upon upgrade
MoiN Uups, I forgot to include the actual skripts. So here they are: Ingo -- What's the difference between cold tee and cold coffee? Cold coffe doesn't taste good even if it would still be hot. start-rc.d.tgz Description: GNU Unix tar archive
bootpd/tftpd bug
I have only noticed it on a slink machine, I ask someone who has potatoes to test it too... I am configuring one machine as a boot server in order to install Debian in a PowerPC (IBM 43P) I have here, but one strange thing is happening. bootpd gets the request and sends the machine an IP number ok, and tells it that the file to get is /rescue2200prep.bin (notice the slash). but when it asks tftp to send /rescue2200prep.bin it gets an access violation, if I manually invoke a tftp session and ask for rescue2200prep.bin it comes right. The problem is that there is no way of preventing bootpd from adding the slash to the bootfile name, neither making tftpd accept the slash (it does not accept it for security reasons I think). I looked at the bug database and it seems that noone reported such thing before, maybe it can be in potato too. If so, I can file a bug report (against netstd). Regards, --macan
Re: A new axis for bugs?
Michael Stone [EMAIL PROTECTED] writes: [...] On Wed, Oct 06, 1999 at 02:34:20AM -0400, Branden Robinson wrote: [...] unreproduced reproduced possible fix known fix Basically I see bug fixing as proceeding sequentially down this list. There's a state above unreproduced, which is not a bug, and you close it almost immediately. There's also the state after known fix, which is implementation, and is reflected by closing it or setting its severity to fixed. There's another state before unreproduced -- maybe unacknowledged; i.e. the maintainer has not responded to the submitter (via the BTS). We could then more easily find old bugs that have apparently been ignored.
Re: bootpd/tftpd bug
Eduardo Marcel Macan [EMAIL PROTECTED] writes: I have only noticed it on a slink machine, I ask someone who has potatoes to test it too... I am configuring one machine as a boot server in order to install Debian in a PowerPC (IBM 43P) I have here, but one strange thing is happening. bootpd gets the request and sends the machine an IP number ok, and tells it that the file to get is /rescue2200prep.bin (notice the slash). but when it asks tftp to send /rescue2200prep.bin it gets an access violation, if I manually invoke a tftp session and ask for rescue2200prep.bin it comes right. The problem is that there is no way of preventing bootpd from adding the slash to the bootfile name, neither making tftpd accept the slash (it does not accept it for security reasons I think). I looked at the bug database and it seems that noone reported such thing before, maybe it can be in potato too. If so, I can file a bug report (against netstd). By default, tftpd is set up to serve only files from /boot, which is also the default directory if a relative path is specified (this is documented in the manual page tftpd(8)). You can change this behaviour by editing the tftpd line in /etc/inetd.conf: change the occurrence of /boot to / . If bootpd silently translates a relative path into an absolute one, that sounds like a bug against bootpd. Please use the bug reporting system to file a bug, then. As a workaround, you could configure bootpd to send the path /boot/rescue2200prep.bin to the client, which will be allowed by the tftpd server. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: permission denied on owned files
On Wed, Oct 06, 1999 at 02:02:57PM +, Dale Scheetz wrote: Something else strange just happened during an autobuild pass. All of the subdirectories in my build tree have suddenly become inaccessable to the build user, who owns all the files and directories. Here is what I get: --begin paste- $ user build $ pwd /Debian/build $ cd sbuild sh: cd: sbuild: Permission denied $ ls -l total 9 -rw-rw-r-- 1 buildbuild 59 Oct 5 15:53 build.list -rw-rw-r-- 1 buildbuild1153 Oct 6 09:47 buildpkgs.log drw-rw-r-- 2 buildbuild1024 Sep 19 12:06 lists drw-rw-r-- 2 buildbuild1024 Oct 5 16:04 logs -rw-rw-r-- 1 buildbuild 131 Sep 20 06:54 oldbuild.list -rw-rw-r-- 1 buildbuild 63 Oct 1 11:12 prebuild.list -rw-rw-r-- 1 buildbuild 193 Oct 2 18:09 prebuild1.list drw-rw-r-- 2 buildbuild1024 Oct 6 09:47 sbuild chmod +x sbuild lists logs Seems you lost the execute bits. Ben
Re: linking binfmt_misc with mime-types
On Wed, 6 Oct 1999, Brian May wrote: What I really would like is a filesystem that can store a mime-type for every file... That way no magic databases are required. In addition, the kernel could be configured to assign default mime-types for different file extensions, or something. [...] Apples MacOS does nearly that (not really MIME types, but a proprietary code with the same intention). First I liked the idea, but after some time the whole thing started to suck deadly and when I work on a Mac now, one of the most important utilities I use is named 'Set its type!'. Where Macintosh fails, IMHO, is due to - No easy way to change the file type. Yes. - The information it proprietary, and not used anywhere else. Part of the problem. Mapping works well with WWW downloads, but bad with floppies from other OSes. - I am not very familar with the operating system, so there might be more points that I have missed. Perhaps there are difficulties loading a file for one application inside another application? Most programs are AppleThink and refuse to open files of types they don't know. A few try to determine the type based on the contents. The rest (development tools or very tiny programs mostly) bluntly ignores the type and tries to open anything. - AFAIK, Macintosh doesn't really store file type but rather which application is this file associated with. So if you have multiple programs that deal with the same file type, the file has to be associated with *exactly one* application. (not sure about this) It stores 'type' and 'creator'. Creator is the default application. - just curious: what other times do you need to change this file type? Seldom, but the one problem is sufficiently ennerving. [...] I am not proposing any click it and wait for the magic type think here, that was more related to the binfmt_misc proposal, where executing a file would automatically open the file with the correct program. Sorry, then. I understood it that way. However, this is already done with WWW, and I don't see any problems there (except misconfigured MIME types on some servers - something that would benifit from my proposal, at least for HTTP). The problem I see is that the same file can be a lot of different things at the same time. Take a C header file. Sometimes you want it to be a text file. Sometimes you want it to be a C header file (I know I can say text/C-header which makes MIME better than MacOS, but read on). Sometimes you want it to be a C++ header file. Perhaps it is also an icon saved by a program that chose to save icons so that they can be easily included as arrays into C programs. To make things even more amusing the file could be gzipped. So there may be moments the MIME type won't do the right things for you. I admit it DOES very often. Just carry a MIME type with the file is, of course, no problem. If it is used to determine possible actions on a file, it may get in your way. If Netscape or pine or something won't do the right thing, I can go and save the file and do with it whatever I want. If my OS starts do do the same strange stuff as Netscape, I have to start kinda hacking until it doesn't. If the type is never used, what's it good for? It makes life easier for Apache, OK. Yours, Bjorn Brill [EMAIL PROTECTED] Frankfurt am Main, Germany P.S.: I hope you did not feel offended by my previous posting, as that was not my intention. I just wanted to report some non-Linux experience on problems caused by the (too?) systematic use of a system similar to MIME.
Re: permission denied on owned files
On 6 Oct 1999, Ruud de Rooij wrote: Dale Scheetz [EMAIL PROTECTED] writes: Something else strange just happened during an autobuild pass. All of the subdirectories in my build tree have suddenly become inaccessable to the build user, who owns all the files and directories. Here is what I get: $ cd sbuild sh: cd: sbuild: Permission denied $ ls -l total 9 drw-rw-r-- 2 buildbuild1024 Oct 6 09:47 sbuild So, where do I look to figure out why I am not allowed access to these files/directories? In order to access a directory you must have execute permission (the x-bit) on it. Thanks, I don't know why I didn't see that...(i.e. I knew that! ;-) Now the only thing I don't understand is how it got that way in the first place. This is the directory where the script unpacks and builds the source files. It has been working just fine up until I tried to build tk8.2 and dpkg-source failed to unpack the source. After that point, the script returned permission denied when it tried to create a log file in the parent directory. It seems that all of the directories owned by build are now without execute permissions. I'm using dpkg 1.4.1.9, and David Engle (the tk maintainer) suggestes that the several versions of dpkg that he has tried unpack the source just fine. Somehow, when dpkg-source fails, the directories have their execute permissions removed? Actually the effects are broader than that. All of the files in the working directory have their execute permission bits set true, so it looks like the operation simply toggled all execute permission bits that it had access to. At least this isn't as bad as the last time I had such a failure (much data was eaten by Zule on that night, I can tell you ;-) Thanks for the feedback. It looks like I need to find a better version of dpkg. Waiting is, 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: linking binfmt_misc with mime-types
Brian May wrote: When you loaded that image, whether you used apache, gimp, xv, or something else, it would automatically know what file type it is without any excessive overhead. In my opinion one of the best features of BeOS is that the file type is an extra attribute stored at file system level. I would really like to have something, and mime types seem to be the best way for it (I do not know how BeOS stores the type). greets, Rene
Re: So whos going to ALS
I've got an 8 port 10/100 switch we can use also... Nothing fancy just a NetGear box, but it works fine. Vaidhyanathan G Mayilrangam wrote: Woohoo.. Just got the permission to skip two days from office for ALS. Will be there with my machine.. Dual celeron (300 oc'd 450) with a 19' monitor. Who's co ordinating... Regards, Vaidhy On Wed, Oct 06, 1999 at 07:30:30AM -0700, Greg Heather Vence wrote: I could haul my printer in again. Also, I've got a real machine this year... AMD K6-III 450MHz Viper 770, NetGear 10/100 NIC... 19 Optiquest monitor. Who's coordinating? TIA -- Greg. - Original Message - From: Sean 'Shaleh' Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; debian-user@lists.debian.org; debian-devel@lists.debian.org Sent: Tuesday, October 05, 1999 2:12 PM Subject: RE: So whos going to ALS On 05-Oct-99 Johnie Ingram wrote: ... and would be willing to help at the Debian booth (#503, community pavillion, check it out), or who knows good places to stay at in Atlanta? Or who wants to planepool with the Novare team from Dallas? Joey Hess and myself are going. We have one extra space in the hotel room. Preferably for a Debian developer, preferably one who needs to save the money. We have two double beds and currently three people, a fourth is welcome. If you want a spot on the floor, well that can be arranged as well (-: We arrive Wednesday night at 7:30pm, so room is available from Wednesday night on thru Saturday night. -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- What do you want to spend today? Debian GNU/Linux (Free for an UNLIMITED time) http://www.debian.org/social_contract.html Greg VenceKH2EA/4
Re: Weird errors from update-alternatives
On Tue, Oct 05, 1999 at 03:30:29PM +0200, Wichert Akkerman was heard to say: Previously Daniel Burrows wrote: My system upgrade today (from yesterday's potato to today's potato) produced the following odd output: What version of dpkg do you have? Wichert. Currently 1.4.1.13 . However, I think dpkg may have upgraded itself from 1.4.1.11 during that upgrade run. Daniel -- I've struggled with reality for thirty-five years, but I'm glad to say that I finally won. -- _Harvey_
Re: procps trying to overwrite /bin/kill
On Wed, Oct 06, 1999 at 09:44:46AM +0200, Mirek Kwasniak wrote: No, news bsdutils package is without kill. Oh, wee, another portable program bites the dust. Is the kill in procps linux specific, eg, does it make use of the proc filesystem? This won't work in the Hurd, so the Hurd would be without a kill. But then, we haven't ported util-linux yet (we can still use their kill even if linux ports don't). Maybe we should just fork out our own version of kill, as this seems to be the last fashion here. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
App crashes XServer
I am trying to display a commercial app on a Debian System (the application runs on a remote Solaris system). The application fails and crashes even the X-Server on a potato system. Can anybody tell me what the appropiate procedure is to report the bug (simply filing this message as a bug against the XServer does not make much sense, because the maintainer can't reproduce it). A short description: 1.) I run a remote application via ssh. 2.) The remote application demands 8 Bit color depth, otherwise it fails both on Soalris and linus. 3.) Switching to 8 Bit, I see the error X Error: BadName Request Major code 45 () Request Minor code 0 ResourceID 0x204 Error Serial #23 Current Serial #85 on a slink system. A potato system (other computer and graphics adapter) simply crashes the XServer (SVGA, Matrox MGA G200 adapter). Has anybody an idea how to proceed that 1.) The problem in the potato X-Server is fixed 2.) The tool runs on the linux system. Thanks. --Rainer.
Re: Weird errors from update-alternatives
On Tue, Oct 05, 1999 at 05:21:31PM -0400, Andrew Pimlott was heard to say: See bug 37252--I believe it is responsible for what you are seeking. tkstep8.0 registers slave alternatives (under wish) for /usr/man/man1/wish8.0.1.gz and /usr/bin/wish8.0 . This is bad because 1) tk8.0 does not register these as slave alternatives, and 2) these are actually files in tk8.0! However, I do not know why it would give this message about /usr/bin/wish8.0 and not about /usr/man/man1/wish8.0.1.gz . If you want help pursuing this further, let me know. You can also see bug 37254 I reported against dpkg for its role in the fiasco. Andrew Ai! Those are *old* bugs! (although given that dpkg is involved, I shouldn't be too surprised..) It doesn't seem to have trashed my system, and unfortunately I don't have a log of the messages -- I may have had something similar for the manpage that I didn't catch -- so I think I'll just let it go and wait for the slowly-turning gears of Debian to fix it. Daniel -- Inconceivable! -- The Princess Bride
