Re: Improper NMU (Re: NMU for libquota-perl)
* Elie Rosenblum ([EMAIL PROTECTED]) [020902 11:43]: DELAYED is fine. Not submitting a bug is not fine. Can DELAYED be set up to email the maintainer with the changelog? Would that help the unexpected NMU from ambushing the maintainer? Ciao! -- When the only tool you have is a hammer, you tend to treat everything as if it were a nail. -- Abraham Maslow The Doctor What: Un-Humble http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC pgp6CY8dl5wiH.pgp Description: PGP signature
Re: XFree 4.2.0 - again
* Lasse Karkkainen ([EMAIL PROTECTED]) [020415 22:04]: Someone said that X is a difficult package to maintain and that there is nothing wrong if PACKAGING it takes 3+ months. People have managed to install it from sources in matter of HOURS (well, that didn't work for me, dunno why). Based on that packaging it during a single weekend should be possible. As we are talking about UNSTABLE here, no real testing needs to be done before releasing - that's what the Debian Unstable is for, right? I'm going to try to explain why this isn't the case. Just so you know, I was, for the most part, the only developer for TurboLinux version 6.0 through 6.0.4 (give or take). I took over for someone else who did the beginning part of migrating to the new libc. I had someone help by doing the X packages, but I always had to fix inter-packages issues. TurboLinux *never* had a package as good as Debian had at the time. To package something for debian, it must not just *compile* for the developer (which is all we really cared about at the time at TurboLinux), but it must compile on the rebuild server. It also must compile on multiple platforms. That isn't usually a trival task (we only cared about x86 at TL). Dependencies between packages is hard. Since xfree includes the x libs, a *lot* of packages depend on it. No one would be happy if installing X4.2.0 removed all their x applications. In addition, imaging that Brandon created a crappy, done on a weekend, package for x. Can you imagine the number of bugs? And Brandon would have to reply to them all. Under the way bugs are managed in Debian (even under unstable) this would be hell for him. Now, maybe you have some point. Perhaps some packages should be flagged as very alpha (ie, pre-beta). In that case, bugs *wouldn't* be allowed to be posted against it, and maybe the user would have to manually say I understand this package could destroy everything for each alpha package. That might be a nice feature. But then again. When Brandon gets packages that are that quality, he usually makes them available seperately, which has a similar effect. Finally, you mentioned that you thought that maybe someone else should do the new packages since Brandon is busy finishing up X4.1 for woody/testing. On the surface, it seems like a good idea. But in practise, it requires the new developer to be in tight coordination with the goals of the new developer. In practise, it would be better if this (currently fictional) developer finished up 4.1 for Brandon, while Brandon does the starts on the new one. Allowing packages as complex as the X packages to upgrade smoothly is very hard work and Brandon does a very good job. I hope that I have explained why Brandon is doing a very good job and that it *is* very hard, despite the fact that it seems like it should be fairly easy. I understand your fustration, since this is something that impacts whether you can use Debian on your new hardware. But its something that should be done right. I don't know how you'll take this email, or how badly you feel after the responses on the mailing list. It might be worth knowing that every so often (about every few months) a flame-Brandon-fest starts. I don't particularly like this because Brandon does do a good job. I would like to ask you to offer an apology to Brandon, saying that you didn't know that it was a difficult task and maybe say thank you for the work he has done already. But that's your choice. Ciao! -- Quidquid latine dictum sit, altum viditur. (Whatever is said in Latin sounds profound. The Doctor What: fill in the blank http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC pgpt13gb9iLM8.pgp Description: PGP signature
Re: XFree 4.2.0 - again
* Branden Robinson ([EMAIL PROTECTED]) [020417 14:28]: On Wed, Apr 17, 2002 at 11:26:30AM -0500, The Doctor What wrote: I would like to ask you to offer an apology to Brandon, saying that you didn't know that it was a difficult task and maybe say thank you for the work he has done already. But that's your choice. Well, as long as we're in the apology business, you could tell me who this Brandon person is that you're talking about, and what the heck he's doing with my X packages. I think he owes me an explanation. ;-) No...uher. It's the fonts! It looked like an 'o', I swear! See, we need anti-aliased fonts! *grin* Sorry, that's my bad. Ciao! -- During my service in the United States Congress, I took the initiative in creating the Internet. -- Al Gore If Al Gore invented the internet, I invented spell check. -- Dan Quayle The Doctor What: What, Doctor What http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC pgpKtpYDwgLME.pgp Description: PGP signature
Re: Why why why!!???
* may ([EMAIL PROTECTED]) [010504 08:57]: why the hell did you hack my site!!???!! i opened it today... and it was full!! of you're icons why why why!!!?? I will report you! and i Will shut you down if i have to! pleas check it out http://zipnab.yoll.net/icons/ and tell me .. Why!!?? Nobody hacked your site. That is the directory for your icons for apache. You apparently have apache running under (probably potato) Debian. Apache uses those icons for showing different file types and such when you go to view a page with no index.html and you allow Indexing. The Debian directory is so that you can use Debian FancyIndexing (I forget how to turn it on). The images are used by other things too. Please calm down, read the docs. Above all, don't threaten people. Ciao! -- When the going gets weird, the weird turn pro... -- Hunter S. Thompson The Doctor What: fill in the blank http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC pgpvy7aqlFdCL.pgp Description: PGP signature
Re: Why why why!!???
* Daniel Burrows ([EMAIL PROTECTED]) [010504 10:17]: All right, I apologize for calling it spam :) I don't understand the intent behind the initial message, then. Unless he really thinks someone broke into his site (it doesn't look like apache default page syndrome, but who knows..) That's exactly what it is: Debian Apache Default Page Syndrome for i in *everydebiansystem* do http://$i/icons/ done Examples: http://gerf.org/icons/ http://debian.org/icons/ etc. etc. Ciao! -- Little children, keep yourselves from idols -- St John, Ist century The Doctor What: Un-Humble http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC pgpFfwonp3qD5.pgp Description: PGP signature
Re: What to do about /etc/debian_version
* Bart Schuller ([EMAIL PROTECTED]) [010105 07:48]: I've seen third-party software install scripts use the file to determine which Linux distribution it's running on. Yes, I think it's important to have one central file that can show (roughly) which version of the OS is running. Being human and machine parsable. 3rd party software uses it, users like to know it, etc. However, it's going to be much more confusing as you get the ability to pull in peices from different places (via apt, package pools, etc.). Is a system that pulls in woody plus helix *still* a woody system? Or is something else? Maybe apt/dpkg are the only things that can acurrately tell us what the system is. I suspect this is a policy desicion more than anything, though. Ciao! -- No one will ever win the battle of the sexes; there's too much fraternizing with the enemy.. -- Henry Kissinger The Doctor What: What, Doctor What http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC
Re: What do you wish for in an package manager?
* Dwayne C . Litzenberger ([EMAIL PROTECTED]) [001223 22:47]: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. So my question is: What do you wish for in a package manager? Ideas: Well, I think a coherit method for managing config files and configuration of packages. An easy way to reset a package back to it's prestine settings. A tool to show which packages have been manually configured, configured through a tool, and which one. Policy management. Debian currently sidesteps this by stepping as far away from it as possible, RedHat and TurboLinux force it down your throat. A better system, imho, would be to allow it to be configurable for the PM system. Example: Decide that all daemon's should install 'off' until configured and turned 'on' manually. Ability to do *ALL* package management with source only (ala BSD) complete with diffs instead of getting the whole thing again. The ability to build any version of the binary Package from a complete source (with history (maybe RCS?)). Sort of a FAT SOURCE idea. FAT binaries. Easy methods to relocate paths. Control files that are easy to maintain and version and that can be kept with the source code, upstream, with little or no problem. The ability for the package builder to go get resources itself off the net via URIs. That's about itoh wait: GOOD DOCUMENTATION! Ciao! -- Baldrick, you wouldn't see a subtle plan if it painted itself purple and danced naked on top of a harpsichord, singing 'Subtle Plans Are Here Again.' --Edmund Blackadder II The Doctor What: Not that 'who' guy http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC
Re: Danger Will Robinson! Danger!
Alright, here's the warning so I don't see to be 'boasting' or something similar: I work for TurboLinux as the lead distribution engineer. Before most of debian-devel's technical skills, I am but a neophyte. However, I would like to offer my point of view as someone working in the industry. You have been warned. :) * Jacob Kuntz ([EMAIL PROTECTED]) [000311 17:30]: Marcus Brinkmann ([EMAIL PROTECTED]) wrote: On Sat, Mar 11, 2000 at 04:06:01PM -0500, Jacob Kuntz wrote: our biggest handicap is that we're always a year behind everyone else. being a year behind is suicide in any industry. The simple fact you are missing is that Debian is not an industry. Don't make the same mistakes as the industry. Making last minute changes and rushing in x.0 versions of critical software is just Plain Wrong. Especially the Linux kernels are often very unstable 'til x.12 or 14. i'm fully cogniscient of the fact that debian is not an industry. but it is used in the industry. i use it in the industry. i reccomend debian to all my clients and friends. debian is also representational of linux and free software. we have a responsibility to our ideals. So, our marketing guys *love* having version 10 when everyone else has 9, but this is balanced (usually sanely) by our product managers who want to keep version 9 around as long as possible for our server product. Of course, developers bounce between wanting the latest greatest and staying with the tried and true versions. We aren't through working out a long term stratagy for this, but I suspect that our workstation will be more bleeding edge (with bells and whistles) and server will plod along and occassionally hop forward to catch up. After all, if a server product has everything you need, do you really want the newest version? The problem, as I see it, is that there is no easy way to using new stuff (from unstable) in the stable tree easily. One idea I and a friend/co-worker was that for older systems, we could package the source, so it could be compiled via a tool like turbopkg or dselect. What put a damper on that is that virtually none of our rpm 3.x rpms would compile on our older rpm 2.5 systems. I believe that the debian dpkg/debhelper, etc. tools are more flexible and less prone to this breakage, so maybe Debian can run with this idea. You'd need to make sure you had complete dependency checking for source, though. Well, I'm out of ideas and comments. Ciao! -- No matter where you go, there you are. --Buckaroo Banzai (Adventures of Buckaroo Banzai) The Doctor What: A really hip dude http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC
How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
Just to make sure we are all clear here: I have cc'ed the listmaster and I am angry and insulted. On the flip side, I am trying very hard to be calm and collected and (most importantly in my mind) fair. The subject is deliberatly melodramatic. On Fri, Oct 01, 1999 at 08:47:20PM +1000, Craig Sanders wrote: [wrote lots of mean, insulting offensive things] For those tuning in late, here is the archive url for my letter to debian-devel, and Craig Sanders` response: http://www.debian.org/Lists-Archives/debian-devel-9910/msg9.html http://www.debian.org/Lists-Archives/debian-devel-9910/msg00018.html In short, a summary (admittedly from my point of view) follows: In a discussion on whether network daemons should do one of the following: a) Simply start up, grabbing any ports it needs (most do this) b) Not start up (a few do this) c) Ask about what ports to grab and whether to start up (some do this) This letter is to make it public that I think Craig has gone too far. He has hurt my feelings and has been very insulting to everyone in debian-devel. And this is not the way to get things done. Craig's opinion is direct: Things should stay the same. If someone installs a package, they are expecting it to run. Everything else is a special case requiring extra work on the part of the user. However, Craig's arguments have become increasingly hostile and insulting, building up to the message mentioned above. Being mean and insulting are not ways to get your point across. I took care in my message above to remove anything offensive towards Craig. Unfortunately Craig didn't do the same. Perhaps Craig didn't mean it that way. Perhaps he did feel persicuited or attacked. Not everyone's message was super polite. Including mine. But even so, I think he went beyond limit. I decided that I should check out some of his messages. Many are usefull, but woe to anyone who doesn't understand him or even worse doesn't understand him *and* disagrees him! Two Examples: http://www.debian.org/Lists-Archives/debian-devel-9908/msg00044.html http://www.debian.org/Lists-Archives/debian-devel-9907/msg00857.html Fustratingly, he does bring usefull information to this mailing list and have points that should be heard. Just not with the meanness and rudeness exhibited above. It is my hope that Craig Sanders reads this and thinks about what he has done and why. Till then I am Christian Holtje (aka [EMAIL PROTECTED]) -- Nobody said computers were going to be polite. The Doctor What: A Holtje Production http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Oct 01, 1999 at 08:38:00PM +0200, Josip Rodin wrote: I'd like to propose something else: until the packages provide proper debconf (or whatever) support which would configure the port and other settings for the daemon, let's keep the Provides:+Conflicts: scheme we have been using so far. I would like to second the idea that debconf handle this when it is ready. Personally, I'd like to see packages ask this question now, but the idea seems to have gotten very hostile responses. Ciao! -- Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun The Doctor What: A Holtje Production http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Sat, Oct 02, 1999 at 12:46:46PM +1000, Craig Sanders wrote: On Fri, Oct 01, 1999 at 09:06:39PM -0500, The Doctor What wrote: I took care in my message above to remove anything offensive towards Craig. Unfortunately Craig didn't do the same. garbage. you went out of your way to be offensive. to quote the opening line of your message: Excuse me. I work for TurboLinux. the implication here is that you know what you are talking about because you work for a real (i.e. commercial) linux distribution. anyone should be able to guess that that particular attitude is not going to go down well in debian-devel. it's akin to saying that proprietary software is better because the programmers get paid to write it (and, by logical extension, that free software authors are just amateur bumblers). i find posturing based on your employer to be particularly annoying - it's a blatant attempt to cash in on borrowed status. it doesn't work that way here, it's not who you work for that's important, it's what you've done. The idea was not to say that since I work for *a company* I'm an authority. My point was that I work in the real world and have a counter example. Perhaps that should have been phrased: As I work in the 'real world', at TurboLinux in fact, I consider my self as at least a counter-example. We make it an EXPLICIT Full Quote: On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote: On Wed, Sep 29, 1999 at 06:38:55AM -0400, Michael Stone wrote: The fantasy is over--WELCOME TO REAL LIFE! It turns out that some people install Linux without preexisting knowledge of how to securely administer a Unix machine. sorry, it's you who needs to wake up to the real world. Excuse me. I work for TurboLinux. We make it an EXPLICIT policy to disable all daemons, for Workstation and Server products. We also provide a tool to manage these (turboservices and turbonetcfg). I used to work for Tandem Computers, Tandem Computers had a similar policy too. While Mr. Stone is being a little extreme, this is the real world. This is a security issue. More than that it is a matter of choice. Please note that I don't say anywhere in the letter that you do not live in the real world. I also don't say that you can't understand the obvious or imploy any other methods to insult your intellegence. In fact, I try hard not to put you down at all, though I must have failed. You on the other hand show no thought for anyone else. Quotes (out of context, but I think they speak for them selves): i don't give a damn who you work for. well, bully for you. i guess that must make you so proud. now what is so fucking difficult to understand about that? you must be some kind of genius to figure that out all by yourself. i guess you aren't such a genius after all. WHY IS THE BLEEDING OBVIOUS SO FAR BEYOND YOUR COMPREHENSION? it is especially tedious when some pompous cretin just spews out trivialities based on some misunderstanding of the thread which is explicable only by you not having read it. And finally, just to make sure we're all clear on the matter no regards, craig Note that those are verbatum and all are full sentences. I did not clip short any sentences. It is my hope that Craig Sanders reads this and thinks about what he has done and why. very little of what i write is done without review and consideration of the effect of my words. i am a very deliberate writer. i presume that others are just as deliberate. if they're not, then they need to learn more caution and control over the language they use. I'll take that at face value, and ignore yet another jib at me. My last sentence was not to say that you write without review or consideration of your words. I wanted you to know I was hurt. I thought that if you were even slightly . . . empethetic, sympathetic, human . . . that you'd reconsider, or at least see that stabbing at people isn't productive. But no, I see that isn't so. I'm sorry. I generally like people, work hard to help even people who piss me off. I try to understand people. I work to try to see why conflicts arise. I try to reach a consenses. But that's where we differ, isn't it? Bye, Christian Holtje -- If only you'd listened to me, I could have saved you from all that yukkiness. --Kryten (Red Dwarf) The Doctor What: A Holtje Production http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Sat, Oct 02, 1999 at 03:53:43PM +1000, Anthony Towns wrote: On Fri, Oct 01, 1999 at 11:53:19PM -0500, The Doctor What wrote: The idea was not to say that since I work for *a company* I'm an authority. My point was that I work in the real world and have a counter example. And of course, everyone else on the list doesn't work in the real world, and just plays in their own little pointless sandpit. Feh. That *is* offensive. (And if we all do live in the real world then there's nothing special about the fact that you do too, so you wouldn't bother pointing it out, right? So since it was necessary to point it out, the rest of us must be cloistered academics, or insulated children or something, yes?) ``I work for TurboLinux, and this is the way we do it...'' is all very well. ``I work for TurboLinux. This is the way you should do it.'' is less so. I was saying that I have real world (counter) examples. Namely mine. He suggested that Michael Stone wasn't in the real world. Michael Stone was offering the same opinion of Craig Sanders. Craig obviously has real world experience, as per his web site http://siva.taz.net.au/~cas/ And running a home machine (Like azure http://azure.humbug.org.au/~aj) is real too. The fact I work at TurboLinux gives me *zero* right to say it should be so. The fact I use Debian and like Linux does give me the right to say, *I* think it should be done this way. I did not say anyone else is or is not in the real world. For the most part, I let people decide that for themselves. In any case, I fail to see how pressing `_' in dselect before any unnecessary daemons are installed could possibly be less secure than saying No, I don't want services activated by default and then installing them anyway. This isn't about increasing security per se, it's about either increasing choice (so you can install daemons even if you don't want to run them for whatever reason), or about giving you more knowledge about what's going on (so that when you install linuxconf you find out that it comes with a remote configuration thingo). Both are secure. Asking a user at install time gives the following advantages (in order of importance to me): * Ability to run concurrent 'same service' servers (more choice!) * Ability to *not* run a server on install (more choice) * A clear indication that this package uses the net * Security by default. A user can ignore it, but it isn't 'reasonable' to go any further and force this down their throat. So in that respect, we are on the same page. I agree. I just think that all packages should ask. If one wants a global switch that says: Run all daemons at install: (y/n/Ask) Fine! I'd love it! I'd be very happy. Ciao! -- Any member introducing a dog into the Society's premises shall be liable to a fine of one pound. Any animal leading a blind person shall be deemed to be a cat. -- Rule 46, Oxford Union Society, London The Doctor What: Un-Humble http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote: On Wed, Sep 29, 1999 at 06:38:55AM -0400, Michael Stone wrote: The fantasy is over--WELCOME TO REAL LIFE! It turns out that some people install Linux without preexisting knowledge of how to securely administer a Unix machine. sorry, it's you who needs to wake up to the real world. Excuse me. I work for TurboLinux. We make it an EXPLICIT policy to disable all daemons, for Workstation and Server products. We also provide a tool to manage these (turboservices and turbonetcfg). I used to work for Tandem Computers, Tandem Computers had a similar policy too. While Mr. Stone is being a little extreme, this is the real world. This is a security issue. More than that it is a matter of choice. if people don't know how to administer a Unix machine then they need to learn fast. no amount of molly-coddling by the distribution authors (i.e. us) is going to obviate that essential requirement. maintaining security on your own systems requires personal knowledge and experience, it can not be done by proxy. Since all users should know Unix anyway, let us turn off all services by default. This is not my position. I'm of the opinion that it should ask as Debian has no separate Workstation or Server set up. If it really bothers you, then maybe a global switch that sets whether daemons should just start up or ask first. When we ship a system with a bunch of stuff enabled by default, we're not only putting their machine at risk but we're also creating problems for everyone else who's system is attacked by someone using the debian machine as a jump-off point. That's bad. that's bad. it's also bullshit. enabling daemons by default is not inherently a security problem. I would beg to differ. In some environments, having an unconfigured server running for 30 seconds is too much. And don't tell me to pulling the net cable. What if it's being installed via the net? But security is not the only issue here. Choice is. Have a policy that says all daemons should ask: Should it start now, or be configured later Should it use inetd, or run stand-alone? Should it use the default port(s)? Or something else? if they don't need it then they shouldn't install the package. There is a difference between installing a package, reading the docs, seeing how it works in loop-back or an alternate port, and installing a package to run now. why run debian (with all it's useful tools like update-inetd and update-rc.d and so on) if you're going to throw away those advantages? If we ask the questions upon initial install, set the daemon the way we want it, how are we throwing away Debian's tools? We are getting what we want. If we want to only use half the tools, that's our perogative. it's damned annoying to see people trying to force their personal preferences on everyone else by making loud noises about trumped up nebulous and vague security issues. it would be nicer if such FUD were left behind in the proprietary software world. No kidding. Security isn't the only issue here, but it part of this discussion. Ciao! -- I'm not a god, I was misquoted. -- Lister (Red Dwarf) The Doctor What: Un-Humble http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Sep 25, 1999 at 01:02:44AM -0700, Joey Hess wrote: The Doctor What wrote: Why shouldn't *all* daemon packages ask these questions, and whether to even run *upon install*? Because we need to decrease the number of questions asked at install time, not increase it. According to who? I admit there a lot, and someone needs to issue bugreports againts silly, redundant questions But until debconf, then we are stuck with the current methods of configuring things. By all means make it debconf, but these questions need to be asked. Ciao! -- If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy. -Paul Evans (as quoted by Barb Dijker in Managing Support Staff, LISA '97) The Doctor What: Need I say more?http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Sep 24, 1999 at 11:13:27AM -0400, Scott K. Ellis wrote: Okay, then solve the problem of which one should actually work on the standard port? You can't use update-alternatives if the software is launched in a different manner. If you have such an advanced setup, it isn't really that hard to build it yourself, or use --force. I do not believe that any network daemon should automatically start grabbing resources without asking. By installing a package, I only consent to commiting disk space and the resoureses needed to get it actually on the disk. Anything beyond that should be asked for. Some polite packages do ask nicely whether to use inetd or to start via an /etc/init.d file. Other ones ask which port to run on or even if to run at all. Why shouldn't *all* daemon packages ask these questions, and whether to even run *upon install*? I do not like the idea of a daemon starting up with a default configuration that I have not double checked upon installation. I consider automatically starting with no choice a misfeature. And as to the idea that if I run a 'complex' system, I should dl the package and recompile is not a good one. We have not defined 'complex' and 'simple' except trivially; if you do something that isn't possible with the current tools, then it is complex. We cannot afford that definition. It would hinder us. Running multiple daemons providing the same service is reasonable and expected in a production environment and *even* in the home of an enterprising user. The real question is not why not by how. Ciao! -- We is confronted with insurmountable opportunities. -- Walt Kelly, Pogo The Doctor What: Second Baseman http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
gdm MIT-COOKIE problem
I have been trying to get gdm to work again, as it broke a little while ago. I thought it was gdm, but I found an old .deb (which worked at the time for me, 1.0.0-5) but it didn't fix the problem. (I'm using unstable, and gdm 1.0.0-9). Symptoms, gdm starts up X, and then hangs there. :0.log says that xlib is denying access, the MIT-COOKIE isn't valid. I think the message even implies that it is malformed (I'll send the log entry from home, later). Recompiling does *not* help. It seems to be a problem with the fact that (according to the change log in xlib) the new stricter MIT-COOKIE checking in xlib keeps gdm from checking in. I've tried all kinds of things, but nothing works. The most spectacular failure is when I log in as root and do an 'xauth merge /var/state/gdm/authdir/:0.auth'. That causes the X server to die and restart. Can someone point me at something to explain what is going on so I can fix this? I'm not an official developer, just someone who wants it to work! Ciao! -- Boarding this vessel is an act of war. Ergo we surrender. --Rimmer (Red Dwarf episode: Gunmen of the Apocalypse) The Doctor What: fill in the blank http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
