Re: Debian Bug#20445 disagree
On Sat, Apr 11, 1998 at 09:10:21PM -0400, Raul Miller wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > > From a logical point of view, I think project/experimental is the best > > choice. Why don't we include selected directories from there on the official > > CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)? > > Project/experimental is not part of hamm. > > If Extra really isn't enough of a distinction (how much more of a > distinction (I still don't see why, given the definition), maybe > there should be a hamm/experimental. I really think that's a good idea. pgph6kGMqTE2c.pgp Description: PGP signature
Re: Anyone want to make a Debian XDM login screen?
On Mon, Apr 13, 1998 at 01:44:22AM -0500, Branden Robinson wrote: > One presumes that will stop very soon now. Both GTK+ and the GIMP are > very, very close to a 1.0 release. For the GTK+, one can assume that the > library interface will be stable for a while. > > Like I said, this is probably a 2.1 thing. > > 2.1 should be one hell of a release. I should (knock wood) have a lot of X > issues ironed out by then; we'll have APT; we'll be moved to FHS; Mozilla, > GTK+, GIMP, and GNOME will have been hacked on enough to make outsiders > drool just by looking at them; etc. Who knows, kernel 2.2 may even be out > by then. Quite a bit of change for a "minor" version increment. Perhaps then 2.1 will not in fact be 2.1 but rather 3.0? If it's that much of an improvement and kernel 2.2.x is actually stable.. pgpn4WGXwWzay.pgp Description: PGP signature
Re: kernel-headers-2.0.32 vs. kernel-headers-2.0.33
On Mon, Apr 13, 1998 at 12:28:15AM -0500, Manoj Srivastava wrote: > > Congratulations! You have just introduced a subtle bug on your > system. It may work, and possibly never cause a problem, but > there is a bomb ticking away, waiting to explode ;-) Which bug is that? If it's really that big of a deal I was considering rebuilding glibc anyway with egcs and adding to it the dependancy of either egcc or gcc. This would satisfy both issues? > There is a reason there is a versioned dependency for > libc6-dev. The reasons are explained in a libc6-dev FAQ. I have also > posted it in a related document. > > I think I have changed my mind. I think libc6 should really > get a package all its own, called libc6-kernel-headers. I do not know > whether I can push it into 2.0, but I shall try. Please do. I had not realized I had created a problem by doing this. I shall correct it directly. > All this silly snipping of links and upgrading to incompatible > headers may cease then. mmm, no. As long as things like OSS/Linux demand that your kernel headers in /usr/include/linux be the same as those of your current kernel before their pathetic install script will actually install, people will likely do what I did, oblivious to the potential consiquences. A question which comes to my curious mind... is there a way a program running as root can ask the kernel things like "do you support modules and module versioning?" or is the above script which hung my machine without so much as an oops from 2.1.82 till 2.1.89 the only way an installer can check these things? (it reads autoconf.h) (BTW, I am -GLAD- I yanked the CS4232 card and put the ES1688 in--no more ISA PnP and I can now compile OSS/Free which never worked with the CS4232) pgppjmHSynyMe.pgp Description: PGP signature
Re: kernel-headers-2.0.32 vs. kernel-headers-2.0.33
On Sun, Apr 12, 1998 at 11:38:18PM -0700, George Bonser wrote: > > Also, I now see what you ment by your "ticking time-bomb" comment. If you > change the symlinks, user programs are no longer in sync with glibc. This > can, as Linus pointed out in your quoted text, cause "interesting" > failures though I might prefer the term "spectacular results". Thus far I have been lucky---OSS is the only thing which EVER crashed my system. Well, no, egcc did when I tried to compile 2.1.92, but that was due to a pair of (known at the time of the compile attempt) bugs.. pgpNw7y4GKv10.pgp Description: PGP signature
Re: kernel-headers-2.0.32 vs. kernel-headers-2.0.33
On Mon, Apr 13, 1998 at 12:23:41AM -0700, George Bonser wrote: > > Please do not use force unless you understand what you are > > doing, and also understand that others may not be able to help > > recover a hosed system. > > Agreed, and thank you for the information. I now understand how the kernel > headers used for glibc have been "decoupled" from the kernel include > headers. Indeed that's two of us. Thanks Manoj pgp0qnsyyXldx.pgp Description: PGP signature
Re: kernel-headers-2.0.32 vs. kernel-headers-2.0.33
On Mon, Apr 13, 1998 at 12:56:49PM +0200, Richard Braakman wrote: > > A question which comes to my curious mind... is there a way a program > > running as root can ask the kernel things like "do you support modules and > > module versioning?" or is the above script which hung my machine without > > so much as an oops from 2.1.82 till 2.1.89 the only way an installer can > > check these things? (it reads autoconf.h) > > The preinst from the ftape-modules packages contains a few checks like that: [..] Interesting methods you used. Now, why doesn't OSS do it this way? heh pgpWzltSTkR3w.pgp Description: PGP signature
Re: Are we shipping 2.0 with ipmasq in the default kernel?
On Tue, Apr 14, 1998 at 07:27:03AM -0400, Alex Yukhimets wrote: > Well, script is sure nice, but when I installed the whole distribution from > scratch yesterday, it was some pain: I requested ipmasq package to be > installed (among other 800 or so things :) and when it asked me how to > configure itself, I had no idea how to answer the questions it asked - like > the IP of external interface- how do I know, it is a ppp dialup! So, I left > the answers blank. As a result, after reboot my system had ALL the networking > forbidden. Purging the package helped, but I had to spend quite a few minutes > figuring out what's going on. Find the IP Masq HOWTO and make use of same. It'll save you LOTS of pain. pgpERjqUfDTm9.pgp Description: PGP signature
Re: Are we shipping 2.0 with ipmasq in the default kernel?
On Tue, Apr 14, 1998 at 10:28:34AM -0400, Alex Yukhimets wrote: > > Find the IP Masq HOWTO and make use of same. It'll save you LOTS of pain. > > Hi. Hi back => > The thing is that I had a prefectly working IPmasq setup, with rules > changed in ip-up and ip-down. hmm, now there's an idea. Since I don't use diald or similar, I just set the rules static. The biggest reason for my use of iqmasq is rc5, so.. > I just wanted to give a try of ipmasq _package_. > And configuration script does _not_ take into account the possibility of > external interface with dynamic IP. OK, if this package is not for people with > dial-up then description should mention that and at least postinst should > finally ask whether to activate the rules based on the entered IPs. Yes, it should take that into account I think. I'm tempted to go snag it and see what I can do to the package to make it nicer (unless the maintainer wishes to do it..) pgpXzR7nfBZIL.pgp Description: PGP signature
Re: Spamming people
On Tue, Apr 14, 1998 at 08:19:29PM -0700, boobileedoo wrote: > please get someone to spam [EMAIL PROTECTED] > and [EMAIL PROTECTED] plus get some one to spam > [EMAIL PROTECTED] thanx Why? Isn't spamming supposed to be wrong? What makes it wrong for people to spam is if it's not wrong for us to spam them? pgpi9HMf1ILXE.pgp Description: PGP signature
Re: A little ircii /dcc tweak I'd like to see the default...
On Sat, Apr 18, 1998 at 07:29:19PM -0700, Robert Woodcock wrote: > I'd like to see this patch become the default: > > --- ircii-4.4/source/dcc.c~ Thu Dec 25 17:36:09 1997 > +++ ircii-4.4/source/dcc.cSat Apr 18 19:22:43 1998 [patch body removed] > > Yes, what that does is check your /dcc commands to see if they have /etc > or /passwd in them, and if they do, print a message "Send request > rejected". Ick, no. If an admin is not running shadow passwds, that's their fault. Don't cripple the user needing help with a file in /etc. [..] > My thoughts on this are that large systems without shadow passwords with > shell accounts with ircii installed are: > > 1. very few and far between. > > 2. probably not running debian. > > 3. have hundreds of other security holes because of #2, making this one >irrelevant. > > 4. have admins who usually wouldn't get debianized source anyway, or if >they did, they'd be clueful enough to "fix" it. > > I'd love to hear people's opinions on this. Quite true on all counts. I see no need for the patch. pgpMdyzi94EaS.pgp Description: PGP signature
Re: Problems with pgp signed mails
On Sun, Apr 19, 1998 at 03:29:18PM +0200, Martin Schulze wrote: > > There's nothing wrong with your mail, my mutt just doesn't recognize > it as pgp signed. I have adjusted my preprocessor. /usr/doc/mutt-i/pgp-Notes.txt.gz has more info on how to fix this with procmail. > > -BEGIN PGP SIGNATURE- > > Version: 2.6.3ia > > Charset: noconv > > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > > I wonder why the others have a different title. The proper way to do PGP messages is still in a stat of flux. pgp0avNLnXMrQ.pgp Description: PGP signature
Re: Problems with pgp signed mails
On Sun, Apr 19, 1998 at 06:39:25PM +0200, Martin Schulze wrote: > > > There's nothing wrong with your mail, my mutt just doesn't recognize > > > it as pgp signed. I have adjusted my preprocessor. > > > > /usr/doc/mutt-i/pgp-Notes.txt.gz has more info on how to fix this with > > procmail. > > Ha! That's the reason why I'm complaining... Although I didn't > know it was documented there. Complaining because it is or is not documented how to make mutt see messages which are not designated as PGP? => It beats the way pine did it with filters, that expecting headers and stuff. Specially since procmail can add them so easily. procmail owns. pgpCQU76XaC0X.pgp Description: PGP signature
Re: A little ircii /dcc tweak I'd like to see the default...
On Sun, Apr 19, 1998 at 10:10:00AM -0700, Robert Woodcock wrote: > [...] > >> Yes, what that does is check your /dcc commands to see if they have > >> /etc or /passwd in them, and if they do, print a message "Send request > >> rejected". > > > > Ick, no. If an admin is not running shadow passwds, that's their fault. > > Don't cripple the user needing help with a file in /etc. > > Hmmm, I guess I didn't make that very clear. I was not advocating putting > that code *in* the ircii sources, I was advocating taking it *out*. You're right, I misread the patch.. hehe Epic doesn't seem to do this to me, I've sent people files from /etc before. Not passwd certainly, but. > (As for copying it to /tmp first, yeah, that *will* work, but why should > we put users through the pain for no reason at all? In fact, I was able > to defeat it by symlinking ~/argh to /etc and /dcc'ing ~/argh/whatever.) There's really no point in having a check, patch away! pgp4ztZnbNbWq.pgp Description: PGP signature
Re: elvis package
On Wed, Apr 22, 1998 at 06:27:03PM -0400, Raul Miller wrote: > > I'm pretty sure that a program must be either entirely GPLed, > > or contain no GPLed parts. > > More precisely, the non-gpled parts must not have terms which prevent > compliance with the gpled parts. Uhh, the GPL does not state that the software must simply be free, it states that it must be free in a form that is compatible with the GPL. The GPL has what some consider to be a "virus". It is free, but militantly so. This is good sometimes, but bad others. It would have been bad for Netscape, which is why they opted to use their own. What people do not realize is that an author can release code to be used under more than once license, ie under GPL or MPL as you choose, as long as you follow one of them. I would be much happier with the GPL if it was a bit more compatible with other free licenses, but it does serve its purpose for some things. For example, M$ can't run off with a derivative of Linux and sell it (both as idea and product) as their own. pgp1BlRlrCH0l.pgp Description: PGP signature
Re: Intent to package moxa radius
> >>Anyway, could you explain to me how this advertising clause is so > harmful? > > > > See http://www.gnu.org/philosophy/bsd.html. > > Ok, this helps. I am still at a loss why we mention BSD as one of the "free" > licenses in DFSG, and have no mention of this problem there. I'll try to > contact Moxa about this problem, but I doubt a successful outcome, since I > think they really want to get some publicity out of making their software > free > one way or another. > > Am I correct that this clause doesn't make software really non-free (DFSG > definition) ? Or am I missing something obvious in DFSG? If you ask RMS, MANY licenses are not "free enough", including BSD, Artistic, and others. DFSG is not free enough for him, yet you can do more with one of the other licenses. Interesting how that works out. RMS is pushing an ideal more than anything. pgpiobXkCzdBn.pgp Description: PGP signature
Re: Intent to package moxa radius
On Thu, Apr 23, 1998 at 12:06:33AM -0400, James A.Treacy wrote: > > If you ask RMS, MANY licenses are not "free enough", including BSD, > > Artistic, and others. DFSG is not free enough for him, yet you can do > > more with one of the other licenses. Interesting how that works out. > > > > RMS is pushing an ideal more than anything. > > > Please don't get into an argument about what license is more free. > It all depends on what you are trying to achieve. When I release code, > I find that the GPL preserves the rights that are important to me. Someone > who wants to use it in commercial software will complain that the GPL isn't > free enough because he can't use it. Many would say that the GPL is > more free than, for example, the BSD license because it guarantees that > modified versions remain free. It does that, but sometimes that is not always a good thing. Take for example the libreadline library. It is GPL, not LGPL. In order to link this library which is somewhat standard (IMO at least) your software must be GPL. An example of this is ncftp which was using it--that's a nono, even though it is a simple shared library. In this instance, the GPL actually hurt ncftp. The program ncftp is freeware with source (think beer) so really anyone can use it, even if they can't hack it to pieces. But it is not compatible with the GPL under which libreadline is released and therefore cannot have libreadline dynamically linked. This is a limitation on the GPL I think, and the reason I think so is that while ncftp is not OpenSource/DFSG-free, Artistic for example would be. However if ncftp were Artistic, it would still be incompatible with the GPL license on libreadline. As would BSD and a number of other licenses which are OpenSource/DFSG-free. In fact, the GPL is incompatible with every other free license I know of, possibly in some places even its cousin, the LGPL. So really, one must ask: who is incompatible with whom here? I do personally consider this a limitation in the GPL--whether caused by oversight or by idealism I can't say for certain (reading the writings of RMS, I would say the latter) > If you are going to argue, please explain where you are coming from so > you can get past the word 'free' and actually discuss something instead > of having everyone talk past each other. I'm certain RMS is not going to like my suggestion, but perhaps if the GPL were to instead of saying that other parts must be GPL, etc that other parts must fit under the DFSG? I think most do not find this too limiting, but I would like to hear others' opinions.. > Different people prefer different licenses. Why don't we all agree to > that and go drink some beers and work on 'free' software. sounds like a plan pgpVauOy1BdaV.pgp Description: PGP signature
Re: Intent to package moxa radius
On Thu, Apr 23, 1998 at 05:04:19PM -0500, Manoj Srivastava wrote: > Rev> It does that, but sometimes that is not always a good thing. > Rev> Take for example the libreadline library. It is GPL, not LGPL. > Rev> In order to link this library which is somewhat standard (IMO at > Rev> least) your software must be GPL. An example of this is ncftp > Rev> which was using it--that's a nono, even though it is a simple > Rev> shared library. In this instance, the GPL actually hurt ncftp. > > On the contrary. This is an excellent point you made. ncftp > is now under GPL!! Yay! libreadline not being under LGPL worked! > Hurrah! Um, 2.x is GPL. 3.x is not, afaik. > So, it is indeed a good thing. Maybe more software would > become DFSG free if we were a little more pushy about it, like RMS > has been being. > > I think it is about time we hardened our stance in favour of > the GPL. Manoj, you're crazy, you realize that?I happened to like 3 better than 2 personally.Ah well, one of my favorite programs is now free for the modding---someone wanna do slang version now? => pgptxes6Fdfl1.pgp Description: PGP signature
Re: Intent to package moxa radius
On Fri, Apr 24, 1998 at 02:22:39PM +0100, Jules Bean wrote: > >>On the contrary. This is an excellent point you made. ncftp > >> is now under GPL!! Yay! libreadline not being under LGPL worked! > >> Hurrah! > > > > Um, 2.x is GPL. 3.x is not, afaik. > > Certainly the version of 3 in hamm is not linked against readline, which > would suggest not. > > In fact, it makes 3 in the hamm almost useless, IMHO - what is the use of > ncftp without history and completions? They're the main reason I use it... 3 was yanked from hamm (hardly usable) and 2 was put in main. I think it uses an epoch, which should make it install even though versionwise it's older. > >>I think it is about time we hardened our stance in favour of > >> the GPL. > > > > Manoj, you're crazy, you realize that?I happened to like 3 > > better than 2 personally.Ah well, one of my favorite programs > > is now free for the modding---someone wanna do slang version now? => > > The GPL's not that good. Here's an example from the Mac-side. Internet > Config is a free program which centralises the users internet preferences > (mail-servers, email address, .sig, etc.). Because it's free, it is used by > lots of commercial and pseudo-commercial (Netscape) apps.. and this is a > good thing. I must agree with Manoj that it has its purposes. I won't pretend to like that libreadline is not LGPL--but I am told there is another lib which is not under the GPL and is essentially a workalike. I don't have this library, nor do I know what it's called, but I'm looking for it. => > If it had been GPLed, they wouldn't be able to distribute it. Which would > be a bad thing. Unless you really believe that commercial software has > absolutely no value or place... > > Indeed, this line of reasoning is what caused the LGPL to be introduced, > surely? Quite probably. But the author of libreadline didn't choose to do this. pgp0E2irZTgUf.pgp Description: PGP signature
Re: Intent to package moxa radius
On Sat, Apr 25, 1998 at 04:27:20AM +1000, Martin Mitchell wrote: > > 3 was yanked from hamm (hardly usable) and 2 was put in main. I think it > > uses an epoch, which should make it install even though versionwise it's > > older. > > Hm.. I'm the ncftp maintainer and the version in hamm/non-free should > definitely be removed. I'll file a bug right away. I think it was removed. At least, if it wasn't, it was replaced on my system by the 2.x from main. pgpTFkbvYfJYS.pgp Description: PGP signature
Re: ncftp status? (was re: Intent to package moxa radius)
On Fri, Apr 24, 1998 at 10:21:04PM +0100, Jules Bean wrote: > I don't see any version of ncftp 2 in frozen? > > Someone said it was GPL (and hence free) now? And someone else said it had > gone into hamm/main, but I don't seem to have it in my packages file... It's there. In main, I believe section net. pgpZ9V9qzBd1n.pgp Description: PGP signature
Re: consistency check
On Sat, Apr 25, 1998 at 06:11:25PM +1000, Anthony Towns wrote: > If you're running a hamm (Debian 2.0, frozen) you might like to look at > cruft (cruft_0.9.4_i386.deb, still sitting in Incoming; try > ftp1.us.debian.org:/pub/debian/Incoming > or your favourite Incoming mirror) which does something like this. Just snagged it. > In particular, it checks that all the files listed as alternatives, as > diversions and in the dpkg database itself are all present and accounted > for, and produces a list of things that weren't listed but are still on > your system, and things that were listed, but aren't. It also takes into > account symlinks (if you've got a symlink from /usr/tmp to /var/tmp, it'll > complain if /var/tmp doesn't exist, for example), user home directories > (it'll make sure that everything in /home/aj is owned by aj, for example), > and a couple of other things. VERY interesting results. I highly suggest throwing the output to a pager if you do anything at all with it. It did complain about every single file it didn't know was going to be there. /usr/src/* for example (about 4 kernels worth of files); everything on my fat partition (which will be gone as soon as I discover the best use of the space currently taken up by it) was also displayed. It noted all the things left over from local installs (or attempts at same) and that'll help me clean things up a bit---this is good. Pointed out a policy issue too.. xfstt in slink (I run hamm, but snagged that package greedily when I heard about it) puts fonts in /var/ttfonts. Would those not be better found in /var/lib/xfstt/fonts with a symlink just in case? It pointed out some problems I don't know how to fix properly, though: missing: alternatives /etc/alternatives/editor.1 missing: diversions /usr/bin/addr.bind /usr/bin/dig.bind /usr/lib/nslookup.help.bind /usr/man/man1/addr.1.gz.bind /usr/man/man1/dig.1.gz.bind /usr/man/man8/nslookup.8.gz.bind missing: dpkg /etc/im/im_palette.pal /sbin/ldconfig.new /usr/bin/perl.dist missing: alternatives /usr/X11R6/bin/rclock /usr/X11R6/bin/rxvt /usr/man/man1/nvi.1.gz missing: link_dests : unexplained: / : The dangling links others have commented about. There are missing files which are my fault. All in all, there's still a few problems with hamm I think. > It's still a work in progress -- in particular there are bunches of files > that are created when packages are installed but dpkg is never told about > (/etc/passwd is one example), which cruft doesn't cope with too well at the > moment -- but it's a start, at least. Hey, don't be too hard on yourself, it's helped me recover massive diskspace and maybe the above will help fix some problems with my system and with hamm in general. > > e.g. every package that has a checkscript gets this checkscript executed. > > this way some kernel packages could check, that the user doesn't install > > the wrong include files by hand, because he thinks, debian > > is wrong, and he is right instead (asm,scsi,linux, you know the > > problem...) > > This is an interesting idea; one that cruft doesn't even attempt to > address. > > In this particular case there are a few things. First, if the user *does* > do this, dpkg will warn them anyway (and I'd presume this would show up > under dpkg --audit). The only advantage in doing it this way is that the > libc6-checkscript could provide some explanation as to why this is a > problem, which dpkg probably couldn't. > > I'm not entirely sure this is an appropriate sort of thing to nag the > user about; we've already got the FSSTND which tells people not to touch > stuff that we put there, and I'm of the opinion that if the sysadmin > chooses to violate this then that's their choice, and I'm somewhat > disinclined to nag them about it. > > I could certainly include something like this in cruft (after doing all > it does currently, it could happily just call all the scripts in > /usr/lib/cruft/checkscript/ or somewhere similar) and present any results, > but I'm not entirely convinced that this would be a particularly useful > thing to do. Are there other examples of things where a script would be > useful to check that an install hasn't gone weird? I think you should institute support for checkscripts and I think it should be suggested everyone use them in their packages. If packages were better equipped to clean up after themselves... It's possible that if you ran the checkscripts FIRST they would actually be able to clean up the small things and then cruft could see what in addition it thought needed fixing. Yathink? > > i am always not sure, wether my system is OK. :) sometimes it might be > > useful to do a new installation (no update) only because then much of the > > old unneeded rubbish is gone. > >
Re: X and Window Mangers
On Tue, Apr 28, 1998 at 05:36:03PM +0200, Yann Dirson wrote: > > The long-term plan is: > > > > 1) ship an empty /etc/X11/window-managers with xbase > > 2) mark it as a conffile > > 3) separate twm into its own package > > 4) write /usr/sbin/register-window-manager > > I don't think shipping an empty file, and marking it as a conffile, > would be interesting. If this file is going to be modified only by > the registering interface, then this should not be necessary. marking it as a conffile is good for things like cruft.. Unless we make cruft use checkscripts more and have programs supply explain and checkscripts... pgpAcvM3zQD2q.pgp Description: PGP signature
Re: netstd tools in the base system (was Re: What to do with /bin/perl symlink?)
On Tue, Apr 28, 1998 at 07:00:48PM -0600, Jason Gunthorpe wrote: > > What if the person does not want to use dselect? Many people (not me) > > prefer > > to download packages themselves, and dpkg -i them. Now that ftp is > > removed, > > they would either have to download netstd using something other than linux, > > or > > use dselect to download netstd. Given some people's dislike of dselect, > > this > > will be a major complaint. > > Some people can't use dselect's ftp method, firewalls and so on. Unless the firewall doesn't allow ANY ftp at all, the ftp method supports passive mode. pgpekApV0GiCB.pgp Description: PGP signature
Re: xfsft deb package
On Thu, Apr 30, 1998 at 01:49:06AM +0200, Remco Blaakmeer wrote: > If it is a patch to xfs that uses the freetype libs, I'd think it could be > incorporated into the xfs that is in the xbase package, but I wouldn't > care if it was implemented as a separate font server. Could you contact > Branden Robinson <[EMAIL PROTECTED]> (the XFree86 maintainer) about this? Why is xfs in xbase at all? It's not required to use X. I would suggest just pulling it out to its own package. pgpLi9IzBNDnF.pgp Description: PGP signature
Re: as much business as you can handle
You know, I think I would not mind seeing someone respond to these spams with something that might get the point across that we don't want their garbage. I really think the lists should reject mail from those not subscribed. pgpCNszjWPc1S.pgp Description: PGP signature
Re: xfsft deb package
On Wed, Apr 29, 1998 at 10:14:18PM -0500, Branden Robinson wrote: > > Why is xfs in xbase at all? It's not required to use X. I would suggest > > just pulling it out to its own package. > > I eventually plan to do this. See the X Strike Force page. > http://master.debian.org/~branden/xsf.html I like, go for it! pgpG8U7Tgmw0t.pgp Description: PGP signature
Re: on forming a new Linux Distribution
On Wed, Apr 29, 1998 at 08:05:00PM -0700, Bruce Perens wrote: > I've been giving serious thought for a while to forming a new Linux > distribution. My reason is to fulfill some goals that currently are > not addressed by Debian or the commercial distributions. Certainly no distribution can meet the needs of everybody. Debian seems to be the best distribution on technical merit, but it seems to be missing some things from the easy-to-use standpoint. I was thinking about building an unofficial set of installation scripts and the like for Debian to make it easier on a new user but still show some of the power in Linux in general.. My plan was to make a console-only thing that could really install to a < 100 meg partition (I'm aiming high and trying to get it in 40 or less) and have it be compatible with Debian enough that you could later show dpkg the main Debian mirrors and have it act like it was a normal installation, if perhaps a little nonstandard as to what was installed and what wasn't, and it should be able to integrate itself with no fuss. Thought even that some of the Debian maintainers might be interested in some of the resulting scripts if they were very useful at all. > I've posted my first message on this topic to debian-devel, as I think > a lot of you have similar goals to the ones below, and those who do have > earned the right to be in on the project from the start. I don't currently > have a mailing list for this project - I guess I'll have to start one. I'm not a programmer. I just know what's easy to work with and what's not. I can build a package but am currently doing much of it by hand since I don't yet understand the workings of debhelper. I'll RTFM later and maybe learn how to use it. => You want rpm though. =p I personally think rpm is nasty when you consider that a friend of mine (a newbie) tried to install bitchx today and found that she didn't have libcurses.so.4. Yeah, that she didn't have the FILE. No clues where to get it. No hint as to the package. For libcurses that's a no brainer, but what about some of the less known libs? dpkg would have told her what package and what version she needed. Using apt she could quite easily just run apt-get install and it would. Some packages like pine and qmail are worth the fact that to make them useful they must be in source packages. We ALL (all of us who thought pine was an important package at all) agreed on that. And you wouldn't get me away from qmail--so don't try. => The older version of ncftp is now GPL, but what of the new version? Would you say there's no need to use that because it was not OpenSource? Not everything is OpenSource and not everything needs to be, really. When OpenSource versions of similar programs appear, that's fine. But until they do, you'll be crippling yourself by not using what's there. Some of them are quite free despite not being quite free enough. With the exception of rpm in place of dpkg, there is very little you want to do with this planned dist that Debian doesn't already in terms of techincal forms.. Debian is not the most user-friendly dist, but that could chanage with a few custom scripts and possibly a few rebuilt packages using different conffiles. pgpSUZk3CVsa0.pgp Description: PGP signature
Re: on forming a new Linux Distribution
On Thu, Apr 30, 1998 at 02:33:54AM -0500, Ean Schuessler wrote: [..] > Bruce could have followed the great Freeware tradition of building > concensus by putting togethor a team of Debianites dedicated to > creating a newbie-friendly wrapper for the technically excellent > Debian distribution. [..] If there are a group of people interested in doing this still, I am very much interested in seeing this done and contributing what I can to the project. The demo I would want to create for such a thing to show how much Linux can do without even touching X (mostly for the HD space issue) would probably not fit Official status very well because I would almost certainly include pine-src and qmail-src packages in the defaults-to-be-installed area simply because it's a demo designed to be as easy as possible. NO editor is as easy (read: mindless) as pico and pine is a user favorite. And the most config qmail requires after package installation is control/me, which I'd have a script edit for you.. =p > Free Software is all about diversity. Any development effort that > wants to grow to a significant size needs to understand that. The best > way to make a friendly Linux distribution (be it Debian or any other > name you should chose) is not to eliminate all the people who are > deeply interested in the technical component of the work. The people > who want to make something for the new users should cooperate with the > die hard hackers to create a system that perserves both sets of needs. > Either extreme is lopsided. I agree. Debian is a great dist on technical merit, even though it doesn't have some of the niceties needed for a home-user who wants to try Linux on their machine and is willing to learn--but can't really afford a lot of time to figure out how to handle the common tasks we take for granted. > At a fundamental level I question the proposition that Debian is not > concerned with usability. Beyond that I question the fact that RedHat > is so much more usable than Debian. It may install easier, but is it > easier to run? You spend a few hours installing your system, you spend > years running it. See Crystal's horror story once she got everything installed. rpm is a file-based dependancy, not a package based. She knew she needed a file, not where to get it. This is the kind of thing dpkg does well IMO.. > In the interest of diversity and competition I support the idea of a > Debian faction or even an alternate distribution that is focused on > the user. I cannot endorse the extreme (ditch dpkg, go work for > RedHat) that Bruce has gone to. User-friendly SCREAMS dpkg to me. Not really Debian, but dpkg. rpm is not nice to new users, though it is more flexable with installing combinations of tarballs and packages. Still, with as many packages as Debian has, this is a non-issue really. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: on forming a new Linux Distribution
On Thu, Apr 30, 1998 at 10:06:00AM -0400, Steve Dunham wrote: > > It might be smart to fork rpm (call it something else) and re-do the > > header fields to be more sensible, then use APT to provide understanding > > This would be bad. Especially since RPM is a cross platform standard: > people are using rpm to install packages on Solaris machines and many > other commercial Unix platforms. .deb files are perhaps more so.. While dpkg doesn't exist for everything, the file format of .deb is just an ar file with a few tarballs inside. pgp52mvuuyXA5.pgp Description: PGP signature
Re: on forming a new Linux Distribution
On Thu, Apr 30, 1998 at 04:35:24PM +0200, Martin Schulze wrote: > [1] The KDE team produces a lot of them like kppp, kisdn, kheise etc. > I don't believe that these is the answer as long as Qt is non-free > but it's a way in the right direction. My personal hesitation with Qt has been overcome finally knowing that Troll Tech wouldn't pull an Open Group stunt on us, but you are right in that it would be nicer if the license were OpenSource. Would it be possible for a sort of dual license to be considered OpenSource? Something that allowed free creation of OpenSource software (commercial or not) but proprietary software required commercial licensing for it? This sounds SO CLOSE to what the license does now, the only real difference is focusing on whether or not the developer can make a profit doing what they do (RedHat for example whose development has always been GPL even though they make $$ doing it..) The GPL even has that restriction, though it's more limited to RMS' vision of the Perfect License and not all software that is Free. I think it's possible at least the Qt people might actually agree, considering. And they would suddenly have a LOT more Qt users out there (which would mean more Qt developers) if things like KDE didn't have to go in to contrib. pgp0btd8Fz1oC.pgp Description: PGP signature
Re: on forming a new Linux Distribution
On Thu, Apr 30, 1998 at 10:44:21AM -0400, Stephen Carpenter wrote: [Debian for the clueless users] > > If there are a group of people interested in doing this still, I am very > > much interested in seeing this done and contributing what I can to the > > project. > > I find this idea interesting and would like to see it... Then I suppose if you're not the only one, something might get done with it.. => Anyone else interested is free to email me and we can see about actually getting a mailing list for the job and start DOING something about it. It's one thing to say "oh that'd be nice" but another all around to get off our tails and make it happen. Some of what I can imagine doing already is not suited for Debian's official CD really, but I suppose that would be the kind of thing to want and see what the Debian developers and users think. One thing I would like see (if there are any mildly compitent programmers interested) is more tools like apt that are able to be used in console or X. > > editor is as easy (read: mindless) as pico and pine is a user favorite. And > > the most > > config qmail requires after package installation is control/me, which I'd > > have a script edit for you.. =p > > I dunno...I think ee and ae are both pretty damned easy and mindless :)(ae is > sooo mindless I have noticed it is putting CR in my text documents) I found pico to have more features than ae, and I know that's not true. ae was just harder to use. > > I agree. Debian is a great dist on technical merit, even though it doesn't > > have some of the niceties needed for a home-user who wants to try Linux on > > their machine and is willing to learn--but can't really afford a lot of time > > to figure out how to handle the common tasks we take for granted. > > This is very true... I know a number of people who just want to"Point and > click > and have it work" Most of them would settle for a DOS-looking configuration, but you can only do so much with dialog and most people DON'T write even that much. Most of the enhancements to usability I can think of would be fine with sh scripts and whiptail (or dialog which I despise--it should be an alternatives thing with whiptail having higher priority IMO) and in places that's not suitable perl scripts would be fine. There's not MUCH we would actually NEED programming done for---but I can think of a small number of Make Linux Easier For Everyone programming tasks (better XF86Setup!) > > See Crystal's horror story once she got everything installed. rpm is a > > file-based dependancy, not a package based. She knew she needed a file, not > > where to get it. This is the kind of thing dpkg does well IMO.. > > I have used both Debian and RedHat and I agree... dpkg is MUCH easierto > use than RPM isand it works much better...at this point in the short > few months I have used debian I have installed and uninstalled and > generally used dpkg hundreds of times... [ Side note to self: I can't believe joe just formatted that paragraph with the >'s in the right spot, it's never done that before... ] Oh yeah, rpm is the one thing Redhat should have ignored. dpkg is really a better program, though it may not have been quite what they wanted at the time. > on my past RedHat systems I alwasy had a lengthy read of the man page... > it took forever to get it to work! The thing is thisRedHat is a GREAT > 1st systemby that I mean the firsttime you ever install linux...as > much as I love debian and think it is greatly superiour in many ways... I > still recommend RedHat for the first time. > > This is just because it installs a nice useable system so nice and easy... > and has graphical admin toolsthe learning curve to linux is sharp > (unless you are comming from another Unix) but RedHat makes the first few > days/weeks easier > > remember: "There are only 2 kinds of system admins, those who have screwed > their computer up while logged on as root, and those who havn't YET" after > they are at the level of having done that..(I have personally done that Whelp, if I get my way (and I'm stubborn) you'd also be able to show them a Debian CD and they would at least have the OPTION of having an installation that was easy for the kind of system they would need at home. > um... > lets see...at least 3-5 times) ..that is when I suggest debian :) RedHat > is a very good system to get started on...but hard to grow with Debian on > the other hand makes a great 4th system (yes 4th...I messed it up once > after I switched too..probably will again someday) I was the one who sat down one day and finally dove in, using a multiboot with OS/2 and WFW (I won't run 95, WFW is the most stable Windoze ever) on my system. I just Partition Magic'd myself a new pair of partitions and installed Debian. Life as I know it changed that cold December night.. => Installation was a snap. I knew basic shell commands from working on a SunOS (and later the buggiest Slowaris yo
Re: on forming a new Linux Distributionx
On Thu, Apr 30, 1998 at 11:32:00AM -0700, Bruce Perens wrote: > > For what it's worth, GIF support is doable with free software, just not > > compressed gifs. [gif supports a variety of compression mechanisms, > > including "none".] > > The patent expires in August. You think nobody is going to try and snatch it then? pgptaxyq7OQ2X.pgp Description: PGP signature
Re: Intent to package pine-src
On Thu, Apr 30, 1998 at 05:19:00PM +0200, Santiago Vila wrote: > Ian, why do you still think that qmail-src should not exist? > Are you the only one? > > [ I intent to package pine-src ]. I use qmail-src and I would use pine-src. You are right that at least in hamm this is the best way to do it. In apt, maybe. (apt does have the ability to use more than .deb format but that's not here yet is it?) pgp8c7Yu3ik4o.pgp Description: PGP signature
Re: Intent to package pine-src
On Thu, Apr 30, 1998 at 01:57:28PM -0400, Dale Scheetz wrote: > I agree with Ian. The .deb file format is expressly for the distribution > of configured executables (binaries for short). Using this format for > source distribution is simply asking for trouble. > > Maybe we need a tarball that contains .dsc, .changes, .diff, and > .orig.tar.gz all rolled up in one .src file, known to all the necessary > programs, but to me this isn't necessary. You know, for awhile I was using pine 3.96L-2. It was in hamm and it worked. Then hamm was frozen and it went away. A lot of people thought then that there was no more pine in Debian---you watched the resulting thread, everybody here did. Now, by this time I knew about the source for pine 3.96L-7. I knew about it because I was getting the source to build in maildir support for pine 3.96-2, but I found later that it was already added. I would NEVER have known there was a source package if I didn't need to build it. And I would NEVER found qmail without qmail-src. Until such time as apt will handle .dsc files and source packages, the .deb packages are the closest thing we have to readily accessable distribution. Do you always go picking through source dirs looking for new programs? I don't. And I'm sure a lot of other people don't either. At least for now, packages like pine-src and qmail-src are a GOOD thing. > For almost two years now we have distributed source packages as a > collection of checksum authenticated files with a pgp signed changes file > containing them. These four files: .dsc, .changes, .diff, and .orig.tar.gz > comprise the Debian Source Format, as described in the significant > documentation. > > We do it this way for both DFSG Free as well as for contrib and non-free > software, so why make an exeption in this case? Because these are different circumstances. I would consider removing the qmail-src package---something done as a service to those who want to sue qmail but would otherwise go and get the tarball and never know it could be installed RIGHT. > Retrieval of source from archives is usually done "by hand" but any such > bulk retrieval should be easy to manage with a script. I take the lack of > a script to indicate the current relative lack of need. Anyone is welcome > to prove me wrong by writing such a script ;-) Why would anyone write the script, someone else was kind enough to put it in a .deb so there was no need. A .deb that shows up in dselect and Packages files. pgp6X8Rp4lrrf.pgp Description: PGP signature
Re: Intent to package pine-src
On Thu, Apr 30, 1998 at 02:16:12PM -0400, Stephen Carpenter wrote: > hmm would it satisfy things to make a binary dist of the original files > and of the debainized files...and litterally have it unpack the "real" > pine and then run patch on it with a diff made agains t the debianized > binaries? (I dunno that patch will do binaries...but you get the idea > anyway...) The postinst for the .deb will compile the source, install the .deb, and clean up after itself if you so desire for a -src package... > yes yes...that idea is sick and twisted..and probably not ok either but... > it was an idea...and besides...I kind of enjoy being sick and twisted > ocasionally There's an AWFUL LOT to patch... pgpQ5bknOUV52.pgp Description: PGP signature
Re: Intent to package pine-src
On Thu, Apr 30, 1998 at 05:09:18PM -0300, Igor Grobman wrote: > Here is an idea. Why don't we make an installer package for these > source-only packages. It would work the same way as netscape installer, > except it would compile the binary as well as retrieve the source tarball > from the net (or require user to have a tarball). I believe that will > remove the objections of those who think .deb is wrong format for source > packages, but will still mean that pine.deb is visible in the > distribution. That's essentially what pine-src is, though it includes the .orig.tar.gz file. There's nothing that says it HAS to really. It could be done that it was just the .diff and .dsc files and you just get the original source from UW. I would not mind this with qmail either so long as both have in the description where to get the files you need. (and what the file should be called when you try to install it) pgplsI5W6Retd.pgp Description: PGP signature
Re: Why is dosemu in contrib?
On Thu, Apr 30, 1998 at 09:57:11AM -0700, David Welton wrote: > > > dpkg -s dosemu says: > > > > > Package: dosemu > > > Status: install ok installed > > > Priority: extra > > > Section: contrib > > > Installed-Size: 1799 > > > Maintainer: Herbert Xu <[EMAIL PROTECTED]> > > > Version: 0.66.7-10 > > > Depends: libc6, slang0.99.38, xlib6g (>= 3.3-5) > > > ... > > Does it possibly depend on having a working copy of DOS around? That > would put it in contrib. Includes the FreeDOS kernel. pgpx5OMHToEhP.pgp Description: PGP signature
Re: Why is dosemu in contrib?
On Thu, Apr 30, 1998 at 10:08:59AM -0700, David Welton wrote: > On Thu, Apr 30, 1998 at 01:05:19PM -0400, Stephen Carpenter wrote: > > > That might not put it in contrib isn't there a "Free" version > > of DOS that someoen other than Micro$loth made? i fsomething like > > that works with DOSemu... > > Caldera makes one, but it's not Open Source. FreeDOS, what is included with dosemu, is OpenSource. pgpa9sQJRqIxR.pgp Description: PGP signature
Re: on forming a new Linux Distributionx
On Thu, Apr 30, 1998 at 06:55:43PM -0400, Raul Miller wrote: > > You think nobody is going to try and snatch it then? > > Er.. how do you snatch an expired patent? Reregistration? pgpDXJWQhU0vz.pgp Description: PGP signature
Re: monochrome cards
On Thu, Apr 30, 1998 at 11:32:18PM -0400, Raul Miller wrote: > > That said, I can't see anyone using a MCA card as his primary > > interface. > > I can see this, or serial console, being used for a server. Or an old 386 that you use as a router... > Also, don't forget the sorts of interfaces blind people use... You mean, whatever satisfies the requirement of "video device"? heh. Been there, done that. => pgpH1wmsb2AtI.pgp Description: PGP signature
Re: Intent to do a non-maintainer release of shadow-980403.
On Thu, Apr 30, 1998 at 06:47:02PM -0700, Joel Klecker wrote: > A week or so ago I sent a report[1] regarding the latest upstream version > of the shadow password utils, in that report I detailed which bugs were > fixed, and I offered to do a non-maintainer release. > > I have yet to receive any response, I assume this is because the maintainer > (Guy Maor) is busy, so if there are no objections, I will go ahead and do a > non-maintainer release. > > I intend to upload to frozen, as there is little new functionality, and > many bug fixes, including at least one critical. Please do. The fixes [snipped] look VERY important for hamm IMO. pgp03g9QwcxM9.pgp Description: PGP signature
Re: on forming a new Linux Distribution
On Fri, May 01, 1998 at 04:19:42PM +1000, John Boggon wrote: > Can someone tell me why a new distribution has to be started up just > because the current one isn't newbie friendly or easy to install ? There isn't really. > Why not concentrate on an installation system or front end for dpkg / APT > along with a system management GUI package that can help an inexperienced > sysadmin or user maintain his/her system ? This work could be done > independently of Debian and be designed to sit over the top of it. > Wouldn't this achieve Bruce's aims ? Why re-invent the wheel ? Not quite that, but similar is what a few of us have been talking about and I have had in mind for some time now.. Debian's a good dist. Why duplicate the effort? And, we could not duplicate the shortcuts that the developers have already if we are working on newbie stuff. Then it would end up like redhat, either you can have it really simple or not at all. Debian has a lot of shortcuts for people who know their way around the system. Those are just as important as the the configuration scripts for the most absolute novice in the world. Moreso really because most will eventually grow out of the novice scripts and tools and into the standard shortcuts found in Debian now. pgpobOAzTnJYP.pgp Description: PGP signature
Re: Intent to package pine-src
On Fri, May 01, 1998 at 12:32:26PM +0200, Santiago Vila wrote: > > The postinst for the .deb will compile the source, install the .deb, and > > clean up after itself if you so desire for a -src package... > > Well, I don't plan to do that. I think it would be too much for a -src > package. > > I will simply add a README saying how to unpack the source and build it. > The main point is to make it available from dselect. All other concerns > are secondary. There is already a generic PACKAGE-build script. It's used in qmail-src and the other -src package which qmail depends on, the one that provides tcpserver, what's that called...? Anyway, it uses it. => pgpppnVjvzx3k.pgp Description: PGP signature
Re: source packages and censorship
On Fri, May 01, 1998 at 11:33:55AM -0400, Daniel Martin at cush wrote: > I think someone already proposed this idea, and it was immediately > ignored, so I'm going to suggest it again: I didn't ignore it. > What about a pine-installer package? > > This would be similar to the netscape3 and netscape4 packages of old - > the user would be asked in the preinst to put the pine .orig.tar.gz, > the .diff.gz and the .dsc files into /tmp (or $TMPDIR); if those files > weren't there the preinst would bomb out, aborting installation. (the > documentation displayed in dselect would have to mention this too). Just be sure to tell the user where to get these things. netscape4 didn't tell you what version/filename to get or even where from. Granted, ftp*.netscape.com is a no-brainer, but. => pgpNNBIVoOrST.pgp Description: PGP signature
Re: Intent to package pine-src
On Fri, May 01, 1998 at 08:43:20PM +1000, Craig Sanders wrote: > the qmail-src package works very nicely (i tried it out on a 'spare' > machine recently - qmail's quite nice...if it wasn't for the license > and attitude problems i'd be quite tempted to switch to it) and the > build-qmail script could probably be very easily modified to be a > build-pine script. The license says no binary dist.. No problem, I can compile source. => And if the package saves me the trouble by compiling for me, all the better! (I use qmail-src) pgpFcKKMqPqgH.pgp Description: PGP signature
Re: Conflicts between developers and policy
On Fri, May 01, 1998 at 04:12:59PM -0500, Manoj Srivastava wrote: > Hi, Hi back! => > This, I like. Me too. It makes sense. pgpokv7P7zBx2.pgp Description: PGP signature
Re: A few questions
On Fri, May 01, 1998 at 09:08:12AM -0400, [EMAIL PROTECTED] wrote: > I've seen the term mentioned here many times, I've looked in the docs but > can't find the meaning (so it must be slang). What is a tarball? A .tar.gz file => > On the thread of .deb vs .rpm From Maximum RPM I see that rpm will > actually build the package from original sources ie: apply patches to the > source, then build from your makefile the binaries, and make the .rpm > package file. I get the idea that dpkg should do the same, right? (Or is > it not quite as automated?) Sorry but Redhat's book is better written than > dpkg documentation. Maybe that's why Bruce wanted to use rpm? Generally, if you know how it works, Debian has a better way. Let's take my favorite source-only package, the qmail package whose qmail-src is said to be redundant (and kinda is) but how else would you KNOW there WAS a qmail package? So, lets go build it. I go to my favorite mirror (hi johnnie) and go to /debian/hamm/non-free/source/mail and I do this: > ls qm* qmail_1.01-5.diff.gz qmail_1.01-5.dsc qmail_1.01.orig.tar.gz Well, seems qmail is out of date---there's a qmail-src 1.01-7, but that's probably in slink, so I go to /debian/dists/slink/non-free/source/mail and look... > ls qm* qmail_1.01-7.diff.gz qmail_1.01-7.dsc Well now I see one of those "Problems with the source package system". THat .orig.tar.gz file should at LEAST be symlinked to slink! but it's not. We'll deal, though. You would get the .orig.tar.gz file and the two 1.01-7 files and you'd drop them in a directory, like /usr/src/qmail-src for example. now you go in to the directory and you type: /usr/src/qmail-src# dpkg-source -x qmail_1.01-7.dsc it'll run and then you go in to the directory it created for you and build the .deb file... /usr/src/qmail-src/qmail-1.01# dpkg-buildpackage -B -uc It goes on compiling for awhile.. When it finishes, go up a level and /usr/src/qmail-src# dpkg -i qmail_1.01-7_i386.deb Enjoy your new qmail! Whelp, apt could do this for you and then even clean up after itself. It COULD. But the point is, it DOESN'T. Until it does, I don't mind redownloading the .orig.tar.gz file in a new qmail-src .deb just so I know there is a new version. There is no Packages.gz for the source directories. > Other than one is free and the other is not quite... what are the tradeoffs > between Qt and Gtk? (I'm slightly leaning toward Gtk right now). Qt is perhaps a bit nicer-looking IMO. Other than that, not much => pgphURwt7hEk8.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 12:15:32PM +0100, Mark Baker wrote: > > - targetted towards desktop use only, no server apps, just a few games > > > > - minimal size - optimized for installation via 28.8k modem via FTP, > >which will be the primary distribution mechanism (not CD). > > These don't seem consistent to me. If people are the wrong side of a dialup > link, they need to have a local MTA (actually most people ought to have that > even if they're not, although the configuration is significantly simpler if > they're on a permanent fast network connection and so don't need local > mailboxes) and a local news server. You need MTA. You just do. But you don't need a complex MTA. If you consider sendmail the standard to judge by, most everything is smaller, simpler, or better for personal systems. My personal choice for an MTA is qmail. The savings in configuration and maintenance (or lack of needing to do either) far outweighs the time required to wait and watch it compile. You DON'T need a news server. slrn is a good thing here! You don't need ftpd and telnetd. You probably do need an http server for documentation, but then again dhttpd is small and does the job nicely. The only other servers that I can fathom a home user wanting are xservers.. hehe > Other than that, it sounds good---not for me, and probably not for the > majority of Debian's existing users, of course, but for people who want a > simple desktop OS that's easier to use than Windows. Well, I wouldn't want the games, but essentially the small dist that is easy to use would be a REALLY NICE THING. And really there is almost NO work duplicated because all you need to make of your own is any custom packages you want, a new base-files, and of course installation floppies. I'm collecting names of those who have either emailled me or mentioned interest in seeing Debian a little easier on the novice user (but without getting annoying to the experienced user!) and will be in the next day or two trying to see if maybe we can get some projects organized to make Debian and Linux in general a little more friendly. The net result is that the above games dist and my mini-show-off-the-power-of-linux dist will be possible. Just build base-files and floppies. The rest is already in debian. I don't think many people mind a few unofficial debian dists that meet needs Debian doesn't quite fill. Of course, with such a diverse group, I'm probably wrong, but I'll take my chances this time. => pgpquEiGNbCVZ.pgp Description: PGP signature
Re: Intent to package: uedit
On Sat, May 02, 1998 at 09:12:41AM -0400, Raul Miller wrote: > > Yeah, that's right, an editor that opens /dev/mem. > > If you do an objdump (-Slx) on the binary, you'll see that it's trying > to treat the screen as a region of memory. This program is starting to scare me. It disables console switching, puts your keyboard in raw mode, is suid root (an EDITOR is suid?), manipulates /dev/mem itself (can we say "corruption"?) and has no source! I don't know that there is any method for doing this, but if the person who intends to package this thing was serious, I protest this thing getting in to the Debian ftp mirror, non-free or not. I think this program is dangerous and is a blatant security and stability compromise. Debian has a policy to try and fix these kinds of problems within 48 hours if possible. This one should be fixed now, before the thing gets uploaded to master. pgpYfeZoHUmLP.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 10:11:48AM -0400, Raul Miller wrote: > > You need MTA. You just do. But you don't need a complex MTA. If you > > consider sendmail the standard to judge by, most everything is smaller, > > simpler, or better for personal systems. My personal choice for an MTA is > > qmail. The savings in configuration and maintenance (or lack of needing to > > do either) far outweighs the time required to wait and watch it compile. > > To be fair: if you install qmail you also have to have gcc, bintools, > make, libc*-dev, and maybe more. [Also, on a slow system without much > disk it can take several hours to compile -- not that I think this is > a likely consumer configuration for next year.] You're right, I would not want to compile this on a 386. However, his target is gamers and my target is windoze desktop users. His target has mor HD space to spare than mine for certain, but I think I can get the base devel stuff in mine. I'm shooting for < 100 megs total with installation media being 40 megs or less. I can get basic devel in that, and neither of us are worrying about slow machines. I will admit though that I would want to try and see if I could get the author to let me package the binaries for this task. > > You don't need ftpd and telnetd. You probably do need an http server for > > documentation, but then again dhttpd is small and does the job nicely. > > Much better than a server would be a browser which supports cgi for > local browsing. [Warning: this concept would need to be fleshed out > before it could be implemented. Issues are: mime type issues for > non-executables, mime-type issues from the result of a "cgi", handling > of forms data without an http server, nph-, and maybe a wee bit more.] Not sure I wana mess with the innards of lynx. When I learn how to do it right, I would like to build a debian/ directory for lynx-ssl and find a free-world maintainer for the package, but. I'd LOVE to package it. But, I'm not in the free world. pgpzp92QysGcY.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 01:37:28AM +1000, Hamish Moffatt wrote: > > You need MTA. You just do. But you don't need a complex MTA. If you > > consider sendmail the standard to judge by, most everything is smaller, > > simpler, or better for personal systems. My personal choice for an MTA is > > qmail. The savings in configuration and maintenance (or lack of needing to > > do either) far outweighs the time required to wait and watch it compile. > > qmail has weird licensing and completely-DFSG was part of Jim's goals. > I think smail or exim would do fine. smail is reasonably straightforward, > although requires some pretty hideous tricks to do some fairly simple > things (like different alias files per domain). exim and smail are both > easy to set up with the provided configuration programs though > (which seem pretty much identical in my limited experience). smail is NASTY to configure over dialup links. And getting worse it seems. I couldn't do it. sendmail is clearly not suited for the task. exim might be, but I haven't used it and if its configuration program is identical to smail's I would not be able to. There is no simple way to set up local mail to be delivered locally and other mail to go out over dialup connection when you connect. qmail was the only one I tried that would do this without lots of configuration. You could even set control/me in ip-up.d/, or just use your ISP's domain. > > You DON'T need a news server. slrn is a good thing here! > > Any newsreader, for that matter -- rtin, for example. Any news reader which can use the nntp server of your ISP, but then these are dialup 28.8 people. That's why I said slrn. Frankly slrn is much easier to use than most others and slrn has the also easy to use slrnpull program which will pull news for you without making you wait while it gets every little message. slrnpull is the only small news gatherer that will actually keep the spool small. slrnpull will (with appropriate scorefile) kill spam and not create groups you don't pull for crossposts. leafnode doesn't do this, but leafnode has also a server (something I wish slrnpull did) slrnpull should probably be seperated from slrn simply because there's nothing in it that REQUIRES slrn other than that it puts things in /var/spool/slrnpull (can be changed) and if you don't LIKE slrn you can still have slrnpull, etc. pgp7E94RssOiR.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 11:36:28AM -0700, John Labovitz wrote:
> > The whole exim package is about 500k, which only takes 5 minutes or so
> > to download via modem - so I'd probably stick with that (unless
> > something better comes along). MTA choices are easy, because there is
> > very little user-visible stuff involved.
>
> have you looked at ssmtp? i just took a quick look at the source, and
> it seems that it's *extremely* simple -- sounds like a good one for a
> send-only MTA.
Looking at your results of looking at it...
> config options excerpted from the INSTALL file:
>
> root: The person who gets root's mail (also daemons', etc).
> This userid (on the mailhub) get all mail sent to
> local adressees with userids less than 10. In other
> words, she gets mail the system mails to root, daemon,
> etc.
ooh! I did -NOT- know it did this. Not thinking it had this was my one
complaint about the package. Can you specify your own MDA (ie procmail) for
this?
> mailhub: The place where the mail goes. This is looked up with
> gethostbyname, and so must resolve to an IP address. MX
> records don't count, as several vendors' machines that we
> run ssmtp on (notably suns) don't fully support them.
> They'd be nice, though...
That's fine for your dialup ISP.
> rewriteDomain: The place to say the mail came from. This is for
> hostname-hiding, and only applies if the programs is
> compiled with REWRITE_DOMAIN defined. We don't usually have
> to do so (our main mailhubs run zmailer: our clients run all
> sorts of junk).
Again, fine for a dialup ISP...
> hostname: the Fully Qualified Domain Name of the machine, in case
> you have set hostname to the short form.
Ugh. Depending on what it needs this for, it could be not good that it
wants this. Then again, since this thing would probably only run when you
were on the net, it would be no major pain to just configure it in ip-up.d.
> it would be way cool if the configuration of the above could be
> somehow linked in with a ppp dialup script -- ie, i have two ISPs, and
> two associated mailhub/hostname settings. the right one should be set
> when i connect to a given ISP.
>
> i believe there's already a debian package of ssmtp.
Yes there is, and it would be easy to have two setups I would think, though
it might need some tweaking of the pon script to do it. Essentially take
the current script which is:
#!/bin/sh
/usr/sbin/pppd call ${1:-provider}
and make it:
#!/bin/sh
export MYISP=${1:-provider}
/usr/sbin/pppd call $MYISP
This would have $MYISP available to ip-up.d scripts. That would be the name
of the provider if you had more than one, or just "provider" for the generic
one (a symlink on my system)
pgp3gHjvVhBKb.pgp
Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 11:43:22AM -0700, Jim Pick wrote: > > have you looked at ssmtp? i just took a quick look at the source, and > > it seems that it's *extremely* simple -- sounds like a good one for a > > send-only MTA. > > I haven't looked at it. It's only 15k! That would be a really good > choice if it actually does the job. :-) You betcha it would! Of course, getting mail is another matter. For this, I think fetchmail fills the bill. Sure it's not microscopic like ssmtp, but it works. It DOES require either inbound smtp available or a delivery agent of some sort. Of course, the thought here for ssmtp is "send it to root".. hehehe pgp61KXeUsYa5.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 03:22:18PM -0400, Raul Miller wrote: > This might work for some people -- people with constant net connections > or who don't mind waiting for demand-dialed ppp every time they want > to send a message. Yeah, the lack of a queue bothered me, but at the same time most MUA's have postpone to send later features. Pine is the only one I know that does background sending and then it's an option most users never see, unfortunately. > Also, remember that by default cron sends error messages to "root", > which would be root on whatever machine you configure ssmtp to > hand messages over to. read back a few messages... ssmtp has special handling for mail to root (and daemons). pgpcerA9tcl3g.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 08:22:31PM +0100, Mark Baker wrote: > > have you looked at ssmtp? i just took a quick look at the source, and > > it seems that it's *extremely* simple -- sounds like a good one for a > > send-only MTA. > > But this is aimed at dialup users! You don't want a send-only MTA, as dialup > users presumably want to store their mail locally. Their mail isn't gonna get delivered by smtp unless maybe fetchmail delivers it by smtp. pgptf3apPN8Uh.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 08:24:30PM +0100, Mark Baker wrote: > > > You DON'T need a news server. slrn is a good thing here! > > > > Any newsreader, for that matter -- rtin, for example. > > No, that's useless on dialup links, which I understand is a large part of > the market Jim wants to aim for. You need either an offline reader like > slrn, or a simple news-server (and I'd recommend leafnode for this). Nah, leafnode does NOT deal with spam well (read: at all). slrnpull is better at that. Probably why it should be split out of the slrn package. pgptxgFFfSHXn.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 06:52:47PM -0400, Raul Miller wrote: > > > root: The person who gets root's mail (also daemons', etc). > > > This userid (on the mailhub) get all mail sent to > > > local adressees with userids less than 10. In other > > > words, she gets mail the system mails to root, daemon, > > > etc. > > ooh! I did -NOT- know it did this. Not thinking it had this was my one > > complaint about the package. Can you specify your own MDA (ie procmail) for > > this? > > I'd forgotten about this bit of configuration, but: yes you can specify > procmail as your delivery agent -- as long as the machine which receives > mail supports procmail. ssmtp does not support mail reception, nor does > it support local mail delivery. one word: fetchmail. pgpgYtkeKaOxr.pgp Description: PGP signature
Re: Coming to closure on ae...
On Sat, May 02, 1998 at 11:42:39PM +0200, Oliver Elphick wrote: > >There doesn't seem to be a "reliable" method for determining whether or > >not you are in an xterm. Any method so far suggested has "natural" > >configuration situations that break the method. > > When you start an xterm, TERM is set to xterm; why not test for that? Test $DISPLAY, it's the Right Way to test for X. pgp4a4c5Tbig9.pgp Description: PGP signature
Re: ppp: how to tell the connection speed?
On Sat, May 02, 1998 at 12:13:35PM -0600, Marcelo E. Magallon wrote: > > BTW has anyone else run across a modem that reports 'CARRIER' instead of > > 'CONNECT'? > > My very first modem did that. But we are talking 1988 (whoa! it's been > long) here and that was an El Cheapo 2400 I think most Rockwell chipsets can do that. Part of a 4-5 line report of the connection info. Quite verbose actually. pgpf9yzhic3Jj.pgp Description: PGP signature
Re: Coming to closure on ae...
On Sat, May 02, 1998 at 08:24:50PM -0400, Raul Miller wrote: > > Test $DISPLAY, it's the Right Way to test for X. > > But not the right way to test for xterm. If $DISPLAY is set you're either in an xterm, rxvt, or kvt. As far as ae would care, these are one and the same. pgpBM27t6J25C.pgp Description: PGP signature
Re: ppp: how to tell the connection speed?
On Sat, May 02, 1998 at 09:10:08PM -0500, [EMAIL PROTECTED] wrote: > Rev. Joseph Carter writes: > > I think most Rockwell chipsets can do that. Part of a 4-5 line report of > > the connection info. Quite verbose actually. > > But somewhere in there they always say 'CONNECT'. The one I'm dealing with > apparently doesn't. I'm trying to find out if this is common enough that > pppconfig needs to provide for it. Yes, it's common enough. pgpNYigfJlqD0.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 07:33:03PM -0400, Raul Miller wrote: > > one word: fetchmail. > > fetchmail doesn't do local mail delivery, but relies on an smtp server. > ssmtp is not an smtp server. one more word: procmail [from man page] -m, --mDa (Keyword: mda) You can force mail to be passed to an MDA directly (rather than forwarded to port 25) with the -mda or -m option. If fetchmail is run ning as root, it sets its userid to that of the target user while delivering mail through an MDA. Some possible MDAs are "/usr/sbin/sendmail -oem", "/usr/lib/sendmail -oem", "/usr/bin/formail", and "/usr/bin/deliver". There's also a fetchmailrc keyword for this. I suggest procmail over deliver because for one procmail is in the simplest setup identical to deliver and it can use MH and Maildir folders (that is, whenever the next procmail gets uploaded with the Maildir patches) and it can also do spam filtering if you write a .rc's for it. Procmail does not require a .procmailrc unless you wanna do something fancy with it. pgpYuX5OQxUAz.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 07:42:08PM -0500, Manoj Srivastava wrote: > Rev> smail is NASTY to configure over dialup links. And getting worse > Rev> it seems. I couldn't do it. sendmail is clearly not suited for > Rev> the task. > > Just don't tell that to my machine. > > manoj > who is happy with sendmail and does have a dialup connection and diald How did you get sendmail to cooperate with dialup? And sendmail is still not suited to being easy to configure. sendmailconfig is "not that bad" but it's also "not that good" if the intent is for a person who doesn't know anything beyond that their smtp server is mail.ispdomain.com about it. ssmtp is the right solution it looks like, probably along with fetchmail and either procmail (this would IMO be preferred) or deliver.. pgpkfJ1ir2Zqm.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 09:49:31PM -0400, Raul Miller wrote: > Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > > You can configure fetchmail to run through procmail. > > Er, the fetchmail FAQ implies that if you use -mda procmail you can lose > mail to resource exhaustion. You lose .forward and aliases. Of course, procmail can do both real easy. pgp4gM09mIHFG.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 11:27:29AM +1000, Craig Sanders wrote: > > smail is NASTY to configure over dialup links. And getting worse it seems. > > I couldn't do it. sendmail is clearly not suited for the task. > ^^^ > > why? > > sendmail configuration is a no-brainer with debian's sendmailconfig > script. I didn't understand it and I'm not quite clueless. Once johnnie explained what was meant by all but the most basic questions well, THEN it didn't work because my system was dialup. Before I knew it, he was telling me to edit sendmail.mc by hand and add a Cj line. ...and a procmail line... ..and a couple others... The script didn't deal with the fact that I didn't have a static IP/name. > it can handle probably 99% of cases likely to be needed by most > users...all the user has to do is answer a few questions (which have > sensible defaults). > > configuring sendmail only becomes difficult when you need to do weird or > complicated things. procmail is a weird and complicated thing? dynamic IPs are a weird and complicated thing? If you have to edit these files by hand, the script doesn't deal with all cases. pgp9x4gMNX1kU.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 08:39:25PM -0700, Joey Hess wrote: > > slrnpull should probably be seperated from slrn simply because there's > > nothing in it that REQUIRES slrn other than that it puts things in > > /var/spool/slrnpull (can be changed) and if you don't LIKE slrn you can > > still have slrnpull, etc. > > What news servers besides slrn support reading news directly from the news > spool w/o a news server? tin, nn, pine (if you call that a news reader), trn pgpLAzYWGvs4W.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 08:34:28PM -0700, Joey Hess wrote: > > I haven't looked at it. It's only 15k! That would be a really good > > choice if it actually does the job. :-) > > One large problem with ssmtp is that it has no queueing. If you try to send > mail offline, it gets lost. Does ssmtp return an error if you try to send when there's nobody there to receive? If so, a send queue can be added as a wrapper, and it could probably be added to the program easy enough. pgp64euFDZxcD.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 12:54:20AM -0400, [EMAIL PROTECTED] wrote: > I think I'm confused too thought that is not such an unusual state latesly... > Fetchmail IS POP (or IMAP and somthing else but definately NOT smtp) for > __getting__ the mail. It IS also smtp for handing the mail to the machine > that it is running on (though I guess that with the --mda procmail switch > it probably uses pipes instead of port 25). exactly. > Again, though I will willingly admit to not knowing lots of stuff but what > ISPs _receive_ mail from a user without using smtp to do it (other than the > completely proprietary systems such as AOL, Juno, etc.)? None. Your mail program either has support for your ISP's smtp server directly (pine and netscape) or it doesn't and you use something like ssmtp which does little more than put the mail on your ISP's mailhub. (it will deliver root and daemon mail to some user of your choice) The problem we've hit now is that ssmtp doesn't queue mail. Well, if it can't send the message and resturns an error code, we can use it fine as it is with a perl wrapper to fake a queue. However, if it doesn't, we'll have to modify the program, something that would be a good idea anyway. If the utility you want doesn't exist, modify or build a wrapper around something that does similar. smmtp is small, which is what we want. IMAP is a bi-directional protocol, BTW. pgp6Xe8zafWZ6.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 10:41:10AM +0200, Hugo Haas wrote: > > > root: The person who gets root's mail (also daemons', etc). > > > This userid (on the mailhub) get all mail sent to > > > local adressees with userids less than 10. In other > > > words, she gets mail the system mails to root, daemon, > > > etc. > > > > ooh! I did -NOT- know it did this. Not thinking it had this was my one > > complaint about the package. Can you specify your own MDA (ie procmail) for > > this? > > I'm afraid that you can't do that (well, the first s in ssmtp stands > for simple...). Someone else said you could pipe root's mail to some MDA like procmail or deliver.. If you can't, it would not be a nasty problem to modify the program's source for the task. I think I even know enough C for the job! hehe > > Ugh. Depending on what it needs this for, it could be not good that it > > wants this. Then again, since this thing would probably only run when you > > were on the net, it would be no major pain to just configure it in ip-up.d. > > It is used to write header stuff, to generate the From: line if > RewriteDomain is not specified. > > It is also used to send a HELO command, but this could/should be changed. mmm, okay, then we WOULD want that set in ip-up.d The other issue remaining with the program is that it doesn't do mail queues, and that's one I'm not sure how to handle. I'm sure perl could store messages in a queue and try and send them on demand, even using locks so it'd be re-entrant.. I've written perl that could do this. => This process is simple: The send wrapper: Generate a unique file name (pid.timestamp?) drop a lockfile for the above dump stdin to above locked file send file contents to ssmtp did ssmtp return an error? No: Delete the file and lock Yes: Delete the lock only and exit The runq clone: For each file in queue directory which isn't locked: Lock the file send the file contents to ssmtp did ssmtp return an error? No: Delete the file and lock Yes: Delete the lock only pgpdFiTzMpCBy.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 07:38:57PM -0500, Manoj Srivastava wrote: > Rev> The script didn't deal with the fact that I didn't have a static > Rev> IP/name. > > Hmm. I don't quite understand that -- I think I just had my > machine set up as 127.0.0.2 or something (I could also have used > 192.168.1.10 or something). I had /etc/hosts set up with that -- and > said order hosts,bind in /etc/host.conf. I almost understand that. I think. => Yeah, I could have done it that way -IF- I understood all of that then, but I didn't. And I don't think I would expect most newbies to understand it outta the crib---er, I mean outta windoze either. (I came from OS/2 personally) > I had sendmail working for me as far back as I remember (like > linux 0.98.XX) -- and I just got a static IP address late last year. > > Rev> procmail is a weird and complicated thing? dynamic IPs are a > Rev> weird and complicated thing? > > Nope. I would never cal procmail complicated. Underpowered, > yes, complicated, no. underpowered mailagent maintainer perl slices and dices > I fail to understand the problems you had, but in my case, I > have never had a problem with sendmail. The biggest problems I had with sendmail seem to stem from being a new user. Which is why I say, sendmail does not seem to be a good solution for a first linux system--especially if coming from Windoze.. pgpFakNvZqMRk.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 07:10:45PM -0500, Manoj Srivastava wrote: > Rev> How did you get sendmail to cooperate with dialup? > > What do you mean by cooperate? I send mail using sendmail > whenever I want to. On up-up, I do a sendmail -q. I download messages > using fetchmail. As to my sendmail config, I append my own config > file /etc/mail/sendmail.mc below. Just edit out the HACK stuff, that > is mostly anti-spam and local hacks. I'll save this message for use in my next sendmail configuration. Unfortunately this thing is "standard" which means it won't go away and I'll need to configure it somewhere sooner or later... => > Rev> And sendmail is still not suited to being easy to configure. > > Fortunately, I do not find that to be the case. I have added > several local HACKs and uploaded them into /usr/lib/sendmail.cf/hacks; > and that was that. I found it quite easy to modify the guts of > sendmail behaviour that way. I don't know how this works... > I do know it is fashinable to slander pore ole sendmail ;-) What, just because sendmail.cf looks like line noise? => > Rev> sendmailconfig is "not that bad" but it's also "not that good" if > Rev> the intent is for a person who doesn't know anything beyond that > Rev> their smtp server is mail.ispdomain.com about it. > > Oh, well, I guess like UNIX, sendmail is not for people who > are not willing to scale the learning curve. And I do not personally > think that the sendmail learning curve is that bad (I think it is > easier than learning vi or ed ;-) I don't like vi either.. => It's hard to use and the commands were designed for a plain ASCII terminal with very bare screen manipulation codes.. hehehe Oh wait, it IS.. nevermind... > Rev> ssmtp is the right solution it looks like, probably along with > Rev> fetchmail and either procmail (this would IMO be preferred) or > Rev> deliver.. > > You mileage has evidently varied from mine. Apparently so.. => pgppkpwSoSlcz.pgp Description: PGP signature
Re: MDA's was: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 11:45:24PM +0400, Amos Shapira wrote: > |Sendmail configuration is tough but it is also the best documented MTA > |bar none! The O'Reliey book alone on sendmail is 2 1/5" thick. Probably > |close to everything that has ever been done with mail has been done with > |sendmail (and possibly some things that can only be done with sendmail -- > |and NO I don't know of any examples personally). > > The only reason I still keep sendmail on my home machine is that I > didn't get any answer about how to implement a "fallback MX" in Qmail. > The point is a little mute now that I have an FR line at home but > still maybe this is your example. Didya ask the qmail list? pgpzmsUPgduvL.pgp Description: PGP signature
Re: fetchmail/procmail was: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 11:40:45PM -0400, [EMAIL PROTECTED] wrote: > We are probably wasting everyone's time now by not looking to see just what > fetchmail/procmail interface actually is... > > As I understand it, the fetchmail/procmail interface is a kludge. No, actually it's a pipe.. => > Fetchmail > is intended and designed to work with smtp for delivery. Procmail OTOH > doesn't know anything about smtp. What sort of error code is procmail > going to give to fetchmail and how is fetchmail to receive this code? If procmail gives errors the message is not deleted from the POP server. I've tested this (without meaning to) myself.. pgpFTToTyQX2t.pgp Description: PGP signature
Re: not knowing where to send this.....
On Mon, May 04, 1998 at 01:52:25AM -0400, Raul Miller wrote: > > I expect that everyone who has sent email to debian-devel this > > weekend will have been unsubscribed. > > [Er... probably not everyone: the "too many bounces" mechanism > probably won't knock off people who posted just a few times.] Just the big mouths like me... => pgpsZe2MMJWsR.pgp Description: PGP signature
Re: bug #21739 - xfstt -- comments?
On Mon, May 04, 1998 at 11:28:20AM -0400, Stephen Carpenter wrote: > I have been working on the xfstt package to take it over. Until a few > days ago there was only one bug of "Wishlist" priority filed against > it which is now ready to close as soon as I am able to upload > files (ie am finished registering as a debian package maintainer et al) > It now makes a pid file in var run like a "good little deamon" and can > be started > and stoped form a scipt in /etc/init.d > however this new bug has been reported...and I am looking for comments > about how to fix this one. Cool.. I haven't even looked at the source to this thing so I don't know if it can be done, but Mozilla can't tell any TTfonts are fixed width.. I didn't file a bug report because I don't know that it's something that is Mozilla, xfstt, both, or if it could be fixed.. > The new bug states the xfstt keeping the true type fonts in /var/ttfonts > is > a violation of both the FHS and the FSSTND > I agree with this...now that I think about it...this IS a violation > (unfortunatly...bad news...I lost my printed copy of the FHS and the > FSSTND > I will be printing up new copies soon tho) > any thoughts on wher ethe true type fonts should go? > what would be a good directory for them? I'd agree with the upstream author and use /usr/lib/X11R6/fonts/ttf probably. pgpoflFEojoov.pgp Description: PGP signature
Re: Linuxconf
On Tue, Jun 02, 1998 at 05:24:10PM +1000, Craig Sanders wrote: > > > if a program edits it too, it should do it in a way which does > > > not interfere at all with that human's right to put whatever s/he > > > desires in the file. if it can not guarantee that 100% then it > > > should not edit the file. > > > > With the exception of sendmail.cf, linuxconf does this. > > so i can make any arbitrary change to any config file which linuxconf can > work with, and linuxconf will: > > - not freak out because of some weirdness i did > - not freak out because of some perfectly sensible thing i did > - not lose any information (not a single byte), including comments and > the order/location of comments in the file Yes. And if it does lose info (again, sendmail is currently the exception) it's a bug to be fixed, not a design limit to live with. > if that is the case, then i withdraw my objection against linuxconf > editing config files directly. It was my second objection---the first was the X requiremet (which I find out wasn't the case either) > RE: sendmail.cf > > IMO, linuxconf should manage sendmail.mc rather than sendmail.cf. That would be more reasonable, however not all that sendmail can do is supported with the m4 rules and such. Not at the moment at least. Sendmail is their selling point because of how complex it is, how little m4 helps and how much they can do with it. The motivation for the project is that sendmail if easy to configure could sell linux and the opensource paradigm to a few people. This is good. The solution of course is to extend the m4 stuff to support all the things linuxconf does, but that's not so easy. Also, note that slackware didn't at last look have m4 sendmailconfig. Another example of where slackware is doing more harm than good these days by not adopting things the rest of the world has... =p But that's another argument. pgpZxWGLg02Dj.pgp Description: PGP signature
Re: Linuxconf
On Tue, Jun 02, 1998 at 11:14:45AM +0100, Jules Bean wrote: > > The solution of course is to extend the m4 stuff to support all the things > > linuxconf does, but that's not so easy. Also, note that slackware didn't at > > last look have m4 sendmailconfig. Another example of where slackware is > > doing more harm than good these days by not adopting things the rest of the > > world has... =p > > This sounds foolish to me. > > The solution is to switch to a better designed mailer (exim springs to > mind) with easier to manage configuration. Nah. The biggest reason to use sendmail is that it's standard and all. I'm not likely to give up qmail anytime soon, but you could in theory have the sendmail module not there and replace it with an exim module in Linuxconf if you wanted. I doubt with qmail's non-free state this will happen, but if it happens with exim I might be tempted to try it. Fact is that I couldn't figure out with smailconfig how to set up my dynamic ip system and exim used very close to the same config program. The first one that did exactly what I wanted was qmail. Granted there's fair to good chance that I could go back now and get exim to do what I want--I've learned a few (thousand) things about smtp daemons on *nix boxen since then. But as easy as Linuxconf made sendmail, I know I could configure that. Only problem is that sendmail has still only two modes: slow but queued and fast but not queued. qmail and I think exim both support queues of all messages and delivery is essentially instant. With qmail in fact, you can't stop messages from being queued---save a disk crash you won't lost mail accepted by the system. sendmail still can't promise that, though it's gotten better. pgp1L6hSJFpZ9.pgp Description: PGP signature
Re: Linuxconf
On Tue, Jun 02, 1998 at 03:59:22PM +0100, Jules Bean wrote: > > yes, that's a perfect solution.for those who choose to use exim. it > > does absolutely nothing at all for those who prefer to use sendmail. > > True. But I was answering the suggestion (chopped, unfortunately, which > was foolish of me) that a user-friendly front-end to sendmail would solve > one of Linux's (and Debian's in particular) PR problems. I was simply > pointing out that if simple mail configuration *in particular* is a goal, > then sendmail may not be the best MTA. I certainly would support efforts > for a sendmail.cf configuration utility. You misunderstood then. With all the toys in sendmail, it could be a PR boost, IF people could configure these toys easily. sendmailconfig doesn't do too well with that at the moment. pgpXpmPd5AWk4.pgp Description: PGP signature
Re: Tools the Parse config files (was Re: Linuxconf)
On Tue, Jun 02, 1998 at 12:46:02PM -0500, Manoj Srivastava wrote: > Shaya> Also, linuxconf shouldn't be used to configure a user's > Shaya> personal information, such as .bashrc, .pinerc, those should > Shaya> be left to either the program itself like in pine, or to a > Shaya> package like the dotfile generator for a program like bash or > Shaya> procmail. > > Why not use linuxconf? I am not contradicting you, just asking > for clarification. Mostly because Linuxconf is not designed for the task. Perhaps it could be made to work with a module based on the dotfile generator, but that's not how it works NOW.. pgpjgpC9K9E3Q.pgp Description: PGP signature
Re: Linuxconf
On Tue, Jun 02, 1998 at 12:32:53PM -0500, Manoj Srivastava wrote: > Jules> The solution is to switch to a better designed mailer (exim > Jules> springs to mind) with easier to manage configuration. > > This seems to imply that linuxconfig should drop support for > sendmail (which still is an industry standard smtp daemon) in favour > of simpler to configure replacements. I guess we can live with that. > > Of course, switching MTA's involves other decision parameter > than a simplistic pointy clickey configuration, but I shall not go > into that. Linuxconf does use modules for everything. It would be as simple as NOT using the sendmail module and instead using an exim module. Not a big issue here. pgpO78AiuSOlG.pgp Description: PGP signature
Re: Tools the Parse config files (was Re: Linuxconf)
On Wed, Jun 03, 1998 at 07:43:22AM +0300, Shaya Potter wrote: > > Shaya> Also, linuxconf shouldn't be used to configure a user's > > Shaya> personal information, such as .bashrc, .pinerc, those should > > Shaya> be left to either the program itself like in pine, or to a > > Shaya> package like the dotfile generator for a program like bash or > > Shaya> procmail. > > > > Why not use linuxconf? I am not contradicting you, just asking > > for clarification. > > I don't feel Linuxconf is suited for that. It's just my gut feeling, it > could probably be extended to do it, but it seems to me like it would be > good if there was a seperation b/w the program the configures the system, > and the program that configures the user. Not technicall reasons, just looks. This doesn't mean that user config can't be done with the same kinda interface. liblinuxconf, anyone? pgpR29FrDyoCP.pgp Description: PGP signature
Re: Debian Re-organization proposals (was: Re: so what?)
On Wed, Jun 03, 1998 at 12:59:50PM -0500, Stephen Carpenter wrote: > > No, because democracy is inefficient in our case. > > I would go a step further and say democracy is always inefficient, in > fact it is "inefficiant by design" Indeed, there is a reason why in the US a republic was formed by our founding fathers and not a democracy. How things have shifted I don't know, but they feared anything resembling a democracy (cf. The Federalist Papers) for the same reasons why our government is as it is today. A republic would be a better choice. I am however just one voice and one choice, so I kinda don't suspect these opinions to change the course of Debian. I do think however that now is a bad time to discuss it in detail. Right now hamm is more important because the uses are more important than our squabbles over political structure. pgpmXv08ByFD6.pgp Description: PGP signature
Re: Zip disk install set?
On Sun, Jun 07, 1998 at 03:43:13PM -0700, Karl M. Hegbloom wrote: > I'd like to see a Zip disk install set. What should go on it? [..] > pine This can't be on the base disk because it's non-free. If you want, you can make a zip disk with anything you want on it, make it bootable even... Or, you can make a floppy to boot it, which seems to be a better idea if like me, you can't figure out how to get your scsi card to boot scsi id 6. If lilo were on the disk, you could actually use it anywhere. pgpD59uwJH5j7.pgp Description: PGP signature
Re: so what? Re: Debian development modem
On Mon, Jun 08, 1998 at 01:22:26PM +0100, Ian Jackson wrote: > We must decouple our development tracks much more. I propose that we > resolve never again to plan a release with is not fully backward > compatible with the current stable version. Agreed! Those of us who have been talking about possible suggestions for changing the way releases are handled all seem to agree that changes should be phased in. > We should abandon the idea of `release goals'. Instead, if someone > thinks a thing definitely needs doing by the time of a release, they > do it. If it doesn't get done then we release anyway. I don't see anything MAJOR in the plans for 2.1 that could not be done this way. It seems though like a good plan. > So, in detail: > > Every three months (fixed date) we copy the current `unstable' into > `frozen'. At this point `stable', `frozen' and `unstable' should all > stay interoperable both in source and binary form. This still doesn't address the problem of packages that really aren't ready to be released. That's kinda why we were suggesting unstable be a pool for packages in development. If they're ready for release, move them to frozen. That way nobody's package is being "left out" of a dist because of a bug, but rather being moved into a release after a fair amount of time if the package is ready in the author's opinions. (I was suggesting the bug system be used as part of that since the authors have control over the priority of the bugs against their packages) > Bugfixes must be applied to frozen, and important ones to stable too. > After one or two months of beta frozen should be stable enough to > release. Is this not how things are done wrt frozen and to stable now? > If it's not fine with you then let's not hold up the releases - > instead, go and fix those packages. This is the biggest reason for Guy and co's suggestion about making unstable a pool in which packages start and move out of--so no package can hold up a release. If the author believes the current version of a package is not yet stable enough for release, the last stable version would be used. This requires that we don't break backward compatibility, but for all the other reasons we had before we should keep things as compatible as possible anyway. pgpmQtuKUCwK0.pgp Description: PGP signature
Re: ircII is now free.
On Tue, Jun 09, 1998 at 02:05:45AM +0200, Martin Schulze wrote: On the subject of ircII, thanks David, your effort is GREATLY appreciated. > > > RedHat for one doesn't care for this, so I think it's one of the > > > examples of what Debian is doing for Free Software with its > > > clear and visible ideological organization. > > > > Well, except for the fact that they are pumping 1000's of dollars into > > Gnome development instead of taking the easy way out and paying > > troll-tech... > > ... and receiving much complaints by the KDE people ... as > recently shown at Linux Kongress in Cologne... I don't see how the KDE people have much right to complain. 1. It's RedHat's money. 2. If they really have a problem with not getting money from Redhat, they could start porting their Qt stuff to gtk and helping the project to make gtk-- better. I still think that KDE has all the right in the world to exist and under the GPL license too (though it's apparent now that the KDE people need to specify along with the GPL that they allow the linking of Qt in order for them to be on the most solid legal footing) pgprN19M5VLLA.pgp Description: PGP signature
Re: apt and hamm
On Sun, Jun 14, 1998 at 12:59:49AM -0600, Bdale Garbee wrote: > In article <[EMAIL PROTECTED]> you wrote: > > : My personal opinion is that Apt is *already* the way to go. > > Absolutely. 100% of the people I've suggested apt to (which is now almost > everyone in my circle of Debian friends) has switched to it for good. I have > had several people tell me that the apt method for dselect makes a positive, > fundamental change in their perception of Debian. Indeed, it made a change in my perception as to the complexity and pitfalls of the dselect program. Poor handling of complex dependancies, no handling of multiple mirrors. Apt doesn't purge packages right yet though, and if a download screws up, you can occasionally have a screwed up font caused by garbage echoed to the screen.. This has happened I think only with the ftp access method, but it still does happen. It's still got quirks, but you couldn't pay me to go back to plain ftp method. Well, if you paid me a lot maybe. > I wouldn't dream of not installing apt as part of the installation of any > new systems I help with... > > Not putting it in hamm won't hurt me or my friends, but I think it will help > to perpetuate the perception that Debian is hard to install. Having said > this, > I really really want hamm to get released as close to *NOW* as possible. > Thus, > if this needs to wait for the first point release, so be it. Oh certainly. It's indispensable IMO. pgpzrkW7NM22b.pgp Description: PGP signature
Re: Stop vi discussion
On Mon, Jun 15, 1998 at 09:38:16AM +0200, I mangled and reordered what Andreas Jellinghaus wrote: > you may flame me, but you have to write the flame with joe. You asked for it... ~$ echo $EDITOR joe ~$ [if not emacs or vi or ae,] > what then ? > joe. How dare you come up with such a logical solution to the problem! And how can you be so unfair as to include my favorite editor but not everyone else's? heh. Actually, there is one problem that I've had with a couple of programs including joe.. Upon exit, occasionally the keyboard input will not be echoed bach to you. It'll still be accepted, it just won't display. I use screen, but it's not limited to screen that I've noticed. It also happens for me in X and in regular VT. Output from bash, mutt, and joe all works fine. Going in to joe and exiting again doesn't fix it. It's fixed by stty sane, which indicates that it's just something getting set and not reset. I can't say I know what causes it, but I've filed a bug against joe about it. If anyone else has had the problem, it would definately need to be fixed for it to go in to base. Also, joe vs. ae sizes according to dpkg may be an issue: Installed-Size: 334 Installed-Size: 83 pgpvMHofMpp8u.pgp Description: PGP signature
Re: libc6_2.0.7 release notes...
On Wed, Jun 24, 1998 at 09:48:36PM +0100, Philip Hands wrote: > > Dale> Epochs are not, were never, intended to be used for this > > Dale> purpose. They are only for dealing with upstream renumbering > > Dale> that would cause conflicts. > > > > I thought this was all about the upstream releasing > > pre-releases with versions that would not order right for Debian? If > > that is indeed the case, then this is precisely what epochs were > > designed for. > > I like the way that the ``clever'' hack of sticking R on the end of libc6's > version, confused the hell out of APT. Due to a bug in apt, not a bug in the logic. => > Well, it made _me_ laugh :-) > > I wonder if an epoch would have caused the same problem... I've watched this discussion. I have formed the opinion that using an epoch in this case was not the right way to do it. The r will serve for the moment, and future versions should be handled better I hope. I hope. pgpTtCi0BozJA.pgp Description: PGP signature
Re: libc6_2.0.7 release notes...
On Thu, Jun 25, 1998 at 10:29:43AM -0400, Dale Scheetz wrote: > Brandon Mitchell has come up with a better scheme than my "numbering" > alternative. Consider the following: > > 2.0.8pre1 2.0.8-0pre1 > 2.0.8pre2 2.0.8-0pre2 > 2.0.8 2.0.8-1 > > This has several advantages over my previous scheme. It preserves the > upstream version information in "human readable form". It takes advantage > of the fact that dpkg will create a source upload for -0 and -1 sequences. > It naturally maintains the dpkg sequence ordering of the version numbers. > It doesn't need to use epochs. It has one disadvantage I can see. The -0pre looks like it's something it's not, but I believe people will figure it out, especially if the desc contained real version info. pgpx7E6JFcyEU.pgp Description: PGP signature
