PGP signers in Waterloo or Montreal?
Hi all, sorry to bother you all with this. In order to register as a debian developer I need to do one of several things; the most convenient one is to get my PGP key signed by an existing developer. If any registered developers are near Waterloo, Ontario or Montreal, Quebec I would appreciate it if you could help me out by meeting me in person to sign my key. Thanks! Avery -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: news gateways
On 14 Dec 1997 [EMAIL PROTECTED] wrote: > From: Christian Schwarz <[EMAIL PROTECTED]> > > Does this mean we shouldn't include the list addresses ([EMAIL PROTECTED]) > > in our web pages? If so, I guess I have to fix some pages... > > I don't have a problem with the list addresses being in the WWW pages. > > We should be cognizant that people do troll for mailto: URLs and spam them. > The major problem is that the WWW list archives get into search engines, > and then clueless people search for keywords and fire off questions to > anyone knowledgable that they find. [...] The problem may be simpler than this. Look at the following, from www.debian.org/contact.html (which is linked to from the bottom of every page): We have a very active user mailing list where Debian users and developers can answer your questions. You should subscribe to the mailing list before sending email to it. Subscribe by sending email to [EMAIL PROTECTED] with the word `Subscribe' in the message BODY. You can also use the form at http://www.debian.org/MailingLists/subscribe.html. Once you're subscribed, just send your question to [EMAIL PROTECTED] If you would like to contact Debian developers, send email to [EMAIL PROTECTED] Notice that: - the first paragraph about debian-user looks pretty complicated. As a new user, I would think twice about subscribing myself to a mailing list if I just had one question. - the second paragraph about debian-devel seems to be just what I need: "If you would like to contact Debian developers." They seem to be just the people to ask about my problem! (It doesn't even request that people subscribe first.) Perhaps a minor rephrasing would help. I'm not saying to take the link away, just clarify what it's for. Have fun, Avery -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
WvDial 0.1 available as a Debian package
Hi all,
I'm not an "official" Debian developer yet -- though my PGP key has been
signed now so hopefully this will accelerate the process -- but rather than
wait, I've released WvDial 0.1-1 on my own.
I'll attach the announcement (posted to comp.os.linux.announce) below. Tell
me if it works for you or if there is anything that should change. The
intention here is that WvDial 0.1 become a part of hamm as soon as possible.
I have one particular concern: wvdial replaces the /usr/bin/p{on,off}
scripts that the ppp packages provides using the "alternatives" mechanism.
However, I'm not sure that I implemented it correctly. If someone could
look at my postinst/prerm and see if it's decent, I'd really appreciate it.
Thanks! Have fun,
Avery
Introducing WvDial
==
It's amazing! It's your wildest dream come true! Dialup networking
for Linux that doesn't require chat scripts!
Okay, so maybe you're not as excited as I am, but we at Worldvisions
hope this will brighten up your day a little bit, at least. WvDial is
our attempt to make the previously rather complicated configuration of
Linux dial-up networking as simple as phone number - username -
password.
WvDial is and will remain totally free (under the GNU Library General
Public License, or LGPL), and we hope that all Linux distributions will
try to integrate it with their systems.
Features
WvDial 0.1 can:
- automatically detect your internal or external modem on any of
your serial ports, figure out its maximum baud rate, and choose
a valid initialization string.
- dial your internet provider and log in automatically, without
a login script. (This is based on the knowledge that just about
every modern ISP either starts PPP immediately and uses PAP, or
has a standard login/password prompt.)
- support any number of different dialin accounts with one simple
configuration file.
- guess at the menu system or command prompt you get from some
ISP's, and try to respond automatically. (This feature is
still rather experimental.)
- configure and run pppd automatically with PAP without the need to
change or even understand the pap-secrets file.
And best of all, it's almost completely untested!
Great! Where can I get it?
===
The WvDial 0.1 release is available both as source code and as a Debian
package. You can get either or both from our web page:
http://www.worldvisions.ca/wvdial/
Credits
===
WvDial and its supporting libraries were written by Dave Coombs and
Avery Pennarun of Worldvisions Computer Technology, Inc. as part of the
Worldvisions Weaver project.
You can contact us at:
[EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
This would be helpful for my new wvdial package as well -- from a user
interface standpoint, I would like to have a way for pppd to "call me back"
once we're properly connected.
Avery
On Mon, 15 Dec 1997, Adam P. Harris wrote:
> Maybe I should submit this as a wishlist to the bug system, but I was
> interested in getting some comments first.
>
> I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
> 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
>
> This would allow, for instance, MTA packages to ship little scripts to
> flush the mail queue when the link comes up, pop-deamons to start up,
> bind to reload, clock sync daemons to re-sync, firewall and
> masquerading rules to run, and dynamic PPP hosts to update some file
> on some server indicating their current IP.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Administration tool
On Mon, 15 Dec 1997, Brian Bassett wrote: > I recently switched to Debian from RedHat 4.2 and the one thing that I > think that Debian could really use is an administration tool. > > Thus, I've decided to try and write such a tool. I've set up a webpage > (http://www.butterfly.ml.org/debadmin/) and a mailing list (instructions > at the webpage). If you are interested in helping, feel free to subscribe > to the list and offer any advice. The current plan calls for three > interfaces (text-based curses, X, and Web/CGI). I think that the project > would be benefitted by anyone who has experience programming X or X > toolkits, or Perl CGIs. There are several Linux configuration projects going on already. It would be nice not to duplicate effort, so you might want to start a new one only if an existing system can't be extended to do what you want. See also: - The Dotfile Generator - Linuxconf - cfengine - COAS (Caldera's thingy at http://www.caldera.com) - figurine - kde/gnome have config systems I think. My web page about the "perfect" configuration system lists most things I've thought of on this subject: http://www.worldvisions.ca/~apenwarr/figurine/ideal.html (this is part of figurine, which is on indefinite hold at the moment) Have fun, Avery -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: options for menu packages
On Tue, 16 Dec 1997, Adrian Bridgett wrote: > /usr/X11R6/bin/pppload -i 2 -p 10 [...] > /usr/X11R6/bin/pppload $(tail -n +2 /etc/pppload) [...] > /usr/X11R6/bin/pppload \ > $(grep -v ^\# \ > $(if [ -r ~/.pppload ]; then \ > echo ~/.pppload; \ > else \ > echo /etc/pppload; \ > fi)) Gack! I see a couple of problems with this. First, "-i 2 -p 10" makes a bit of a silly looking configuration file. Secondly, placing any of the above commands in your "menu" entry seems wrong to me -- if the user runs pppload from the command line, he doesn't get the same settings as starting it from the menu! Best thing to do is rename /usr/X11R6/bin/pppload to, say, pppload.real and make a shell script containing the last command above with an added "$*" parameter passed to pppload.real. Actually, in the ideal case you would parse a nicely-formatted configuration file (with real words) into the desired options, so you could have lines like interval 2 and so on. You could do this with perl, awk, or if you're truly sick, even sed: cat configfile \ | sed 's/#.*$//'\ | tr '[A-Z]' '[a-z]'\ | sed s/interval/-i/g Yikes. Excuse me, now I'm even making myself crazy. Avery P.S. '#' comments should be allowed even if they aren't at the beginning of a line. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: base-files 1.6 (source all) uploaded to master
On Tue, Apr 07, 1998 at 07:18:33AM -0400, Gregory S. Stark wrote: > > Anyway, I remember a Slackware trick to set the default prompt for many > > different shells. Could not we do the same? > > Am I the only one who thinks the only correct prompts would be '$ ' and '# > '? I hope so. I know prompts are a religious issue, but they should at least tell you _something_. $ vs # tells you whether you're the superuser or not, but that's pretty dull. bash$ just provides useless information -- 99% of the time, I'm in bash; otherwise I'm in tcsh, which uses a % anyway. (I use Solaris at work and Linux at home.) I can live with having a hostname in the prompt, but I prefer to colour-code my hosts instead :) I know this one is definitely personal preference. I usually find that having my username in the prompt is pretty useless, given that I'm almost always either me or root, and I can use $/# to determine which. People with a lot of sub-accounts would like to have the username in their prompt, but I think this is uncommon (?). Having my path in the prompt is absolutely essential. I have a tendency to open tonnes of shell windows and forget where I am in each one -- displaying it in the prompt is a great help. I also like to have a newline (\n) as the first character of my prompt. This prevents it popping up at the end of an existing line, and does a good job of separating each command on the screen so I don't lose my bearings. If TERM==xterm or rxvt, I add a code that places the current hostname and directory in the window title -- that way I can remember which of my many minimized rxvt's I'm looking for. I tend to log into many computers simultaneously in the course of my work, so having the hostname/directory show up automatically in the icon is a great help. Maybe we should have a vote on popular prompt features, then try to implement them on a shell-by-shell basis :) For reference, mine looks like this: [newline] /usr/local/bin $ ^^^^ | | Yellow Bold yellow In my frame of reference, "yellow" means my laptop. I have a handy login script that chooses a colour based on hostname. I think we should stay away from colours and xterm codes in the default prompt, but just bash$ and # are pretty useless. IMHO :) Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is this a bug in libc6?
On Sat, 11 Apr 1998, Steve Greenland wrote: > > BTW, in Debian, fclose says it returns an error, and does not mention > > corrupting memory. > > ERRORS > >EBADF The argument stream is not an open stream. > > > >The fclose function may also fail and set errno for any of > >the errors specified for the routines close(2) or > >fflush(3). > > Oh, sure, that's an error it *may* report, *if* it detects it. I don't > see anything on the man page that would expect me to believe that the > implementation will detect all possible invalid streams and report an > error. I am also quite willing to believe that the particular error we > are discussing (fclose(fp);fclose(fp)) will be detected. The point here is that it's _documented_ to return EBADF if the stream pointer is not an open stream, and that's not what happens. This is difficult to enforce in practice, and is not necessary for ISO compliance -- so let's fix the man page. Has anyone submitted a bug against manpages yet? Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is this a bug in libc6?
> > The point here is that it's _documented_ to return EBADF if the stream > > pointer is not an open stream, and that's not what happens. This is > > difficult to enforce in practice, and is not necessary for ISO > > compliance -- so let's fix the man page. > > Nope, you're reading that backwards. It says that if fclose() returns EOF_ > _and _errno_ = _EBADF_, then that means that the stream is not > open. You people are being unbelievably pedantic. I know I'm not supposed to fclose() an already-closed stream, or one that failed to fopen(). If I try that, I _expect_ unpredictable behaviour! However, when I read the manpage, I found it quite unclear. If I didn't know better, I would think that double-fclose()ing a file was okay. The bug is not in libc, it's in the manpage. Fix the manpage. Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is this a bug in libc6?
On Sun, 12 Apr 1998, Hamish Moffatt wrote: > > The point here is that it's _documented_ to return EBADF if the stream > > pointer is not an open stream, and that's not what happens. This is > > difficult to enforce in practice, and is not necessary for ISO compliance -- > > so let's fix the man page. > > Is it really so difficult to handle this situation though? Using > Steve's test program on Solaris does as expected: Yes, it would be quite difficult to do efficently. There's no good way to tell that the pointer you're passing is _really_ a FILE* pointer. Once it's closed, the pointer's value is meaningless. There are various ways you could keep fclose() from crashing if you give it an invalid pointer (eg. keep a linked list of all open files, and only close the file if you find it in the list) but that wastes memory and is slow. If you try to fclose(NULL) (like when the file can't open and you close it anyway) it's easy to ignore -- just return immediately if the file pointer is NULL. But should we do that? Personally, as a programmer myself, I much prefer to work on a system that gives up consistently when I do something wrong. That's what segmentation faults are all about. It would be _easy_ to tell the kernel "don't kill tasks if they write to random memory locations." That's what DOS and Win16 did -- and you end up with random memory corruption that's virtually impossible to debug. Note that libc5 apparently didn't crash (at least, hylafax worked) when you double-fclosed a file, but that wasn't because of any feature of libc5. It was just lucky enough to avoid hitting any memory areas the wrong way. Anyone who can operate GDB should be able to track down a crash in fclose() as long as it segfaults properly. But the fclose() behaviour should be documented... the way I usually phrase it in my own API documentation is something like "a call to this function causes the pointer to become invalid, and it should not be used in subsequent function calls." Have fun, Avery P.S. I'll try Solaris at work on Tuesday. I suspect its non-crashing behaviour is just good luck on their part. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is this a bug in libc6?
On 12 Apr 1998, Gregory S. Stark wrote:
> > Yes, it would be quite difficult to do efficently. There's no good way
> > to tell that the pointer you're passing is _really_ a FILE* pointer.
> > Once it's closed, the pointer's value is meaningless.
>
> One cheap solution which will usually work is to put a magic number at the
> head of the FILE* structure and clear it when the close is done (before
> the free). This doesn't work 100% of the time but in practice would it
> would work.
Some malloc implementations (see electric fence) segfault when you even
attempt to read a dead pointer. But the real problem is something like
this:
FILE *f1, *f2;
f1 = fopen("existing_file", "r");
fclose(f1);
f2 = fopen("existing_file", "r");
fclose(f1);
fread(buffer, size, f2); /* oops!! */
It's quite possible (likely) that the second fopen() allocated the same
memory as the first, because the first fclose() released it and the second
fopen() wants a block of the same size. Thus, the second fclose(f1), which
you would like to be harmless, isn't. The magic number doesn't help here.
It would make things crash less in the general case, but that's not
necessarily desirable.
> > Personally, as a programmer myself, I much prefer to work on a system
> > that gives up consistently when I do something wrong. That's what
> > segmentation faults are all about.
>
> Well, the problem with the current setup is really that it may or may not
> crash depending on what data is in the previously allocated structure.
> It's a source of randomness which is always bad for debugging.
On the up side, libc6 seems to crash more :) I think electric fence would
make it crash consistently. That's not to say that magic numbers wouldn't
be a useful way to make it die _more_ consistently.
I think the best way to develop software is on a paranoid system; the best
way to run it is on a very relaxed system. For example, Solaris doesn't
seem to die with this bug; Linux does. If hylafax had been written on
Linux, this bug would have been found sooner and the program would have run
okay on _both_.
(Note that this isn't a snub at Solaris: I have a reverse example related
to curses/ncurses if anyone cares.)
If we could have an ultra-paranoid library for development, and an
ultra-relaxed library for an operating environment, maybe we'd be better
off. For now, I just do all my testing with electric fence.
Have fun,
Avery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bzip2 for source packages?
On Sun, Apr 19, 1998 at 05:20:39PM +0200, Sven Rudolph wrote: > IMHO the "pristine" property is more importent than the compression > ratio. If a choice between pristine gzipped and re-compressed bzip2ed > has to be made, I'd vote for the pristine way. Could someone explain to me why it's so important to keep sources "pristine" in this sense? I can understand not wanting to untar-retar the archive, but recompressing it? Who does that hurt? Avery P.S. I'm indifferent to the gzip vs. bzip2 thing. One downloads faster, the other decompresses faster. Depending on the speed of your link (or whether the files are on CD-ROM) you will have different results. That's why projects that use bzip2 _also_ include a gzipped version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why not mingetty??
On Sat, Apr 25, 1998 at 11:14:56AM -0400, Raul Miller wrote: > > That's not true, it is -- getty requires a speed, even for a virtual > > terminate, while mingetty doesn't support that. > > Does this mean that mingetty won't ignore this argument? That > should be fixed, in my opinion. It should ignore arguments? That's not exactly Principle-of-least-surprise compliant :) getty_ps uses arbitrarily different options, as does mgetty. There's not much point in making mingetty try to be the same as agetty if the others aren't. Besides, virtual terminals don't need baud rates. Plus, adding support for this means adding more useless code to mingetty, which defeats its purpose. > > As to the numbers, I just started up a getty on my box here: > > > > yodeller# ps aux | grep getty > > root 384 0.0 0.0 720 0 2 SW Feb 9 0:00 (mingetty) > > root 401 0.0 0.0 720 0 1 SW Feb 9 0:00 (mingetty) > > root 10361 0.5 1.4 868 460 3 S17:07 0:00 /sbin/getty > > 38400 tty > > This is not a completely reasonable comparison (though it does show > 0:00 time used by each getty, which is perhaps significant). It's not very useful. Virtual size is pretty pointless when comparing memory usage -- I've had programs that used "virtually" hundreds of megs without digging into swap. It's just that they allocated it without using it, or mmapped large files. Most shared libraries cause arbitrarily bloated virtual memory. RSS is the only reasonable value for comparison, and since your quoted getties are swapped out to different degrees, we can't get an accurate one. On my system: root 15982 0.4 0.8 736 344 7 S 21:47 0:00 /sbin/mingetty tty7 root 15983 0.4 1.1 860 456 2 S 21:47 0:00 /sbin/getty 9600 tty2 I just disabled my swap space and freshly restarted these tasks. RSS difference is 456 - 344 = 112k of savings. Considering my ever-increasing impression that "shared" pages don't actually work for separately-started copies of the same binary, and the simple truth that data pages can't be shared between these, I'd say a good part of that 112k is then multiplied by the number of getties you run. And as for speed... well, they both use 0:00 seconds of CPU time, but agetty takes a full second longer to start. (This is almost certainly a DTR-drop to make modems happy; since we don't deal with modems, we don't have the drop or the wait. It feels faster, and that's a big psychological benefit.) > (b) On the other hand, in my informal testing, I couldn't get mingetty > to run -- apparently, it can't do TIOCSCTTY on my system, so it bails > out. Hmm. Works for me. Of course, you do have to run it from init. TIOCSCTTY is one of the pickiest bloody system calls I've ever seen. > (d) Technically, you also need to compare console handling to console > handling, not console handling to serial handling. Incidentally, agetty's serial handling is completely atrocious anyway. For serial terminals, you should seriously use getty_ps. For modems, use mgetty. For consoles, use mingetty. See, agetty is obsolete :) Seriously, though, the very early getties (of which agetty is one, and getty_ps is another) tried to be an all-in-one completely scriptable terminal handler. This approach failed dismally with modems, and wasn't necessary for terminals. Have you ever tried to make agetty answer a phone at arbitrary baud rates with a 2400 baud modem? Yes, it can be done, I did it. Have you ever tried to do it reliably? If you did that, you have me beat. If we added a tiny enhancement to mingetty to let it set the baud rate and TERM variable, then it would be completely capable of handling serial terminals as well as the VTs. Then you just need mingetty/mgetty for complete flexibility. Meanwhile, people with serial terminals can just use agetty for those. That's not very hard. The main reason mingetty is smaller than agetty is the absence of the scripting junk, I think. > Finally, note that if we get too fancy it will be tough for people who > need to use multiple gettys on the same system (but maybe that's only > important for testing purposes). I don't think there's a need for alternatives and all that. Is there? Perhaps the sysvinit (or some other) install script could just comb through /etc/inittab and offer to replace the getty entries it recognizes with mingetty lines. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
On Sun, Apr 26, 1998 at 09:52:32AM +0300, Shaya Potter wrote: > Probably because it's allowed, doesn't the FSF distribute emacs linked or > with the ability to link out of the box against Motif? "linked or with the ability to be linked" -- perhaps that's the critical difference. I don't think FSF distributes binaries of emacs (do they?). They only release the source. Source is just data, and whether you need Motif to compile it into binary or not is your own problem. This is why I don't think the author of ncftp had any real legal problems allowing ncftp to be linked with readline (or even perhaps requiring it; I don't remember). If you don't distribute binaries of ncftp, you haven't used readline, and therefore you haven't upset the readline license. Similarly, if you don't distribute binaries of emacs-Motif or the (theoretical) kemacs, you haven't violated the emacs license. This puts Debian in a rather awkward position, since that's exactly what we want to do: distribute binaries of these programs. I still question anyway whether linking with a shared library makes a program a "derived work" but I don't feel like watching that argument again. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Licensing, was elvis package
On Sun, Apr 26, 1998 at 09:06:56AM -0400, Alex Yukhimets wrote: > Linking with Motif of GPL'd software only allowed on operating systems > which get shipped with Motif as an essential part of it (like Solaris). > Which means that linking with Motif on Linux is not allowed. (I asked RMS > directly about that and received the above response). Note that the GPL only restricts copying and redistribution. Once you have a legal copy of the source, you can do whatever you want with it "in the privacy of your own home." So you can make yourself an emacs-motif, if you own Motif, but Debian couldn't distribute it. IANAL. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
On Sun, Apr 26, 1998 at 02:46:58PM +0200, Santiago Vila wrote: > Ok, trying to be "conservative", I have changed the default prompt for > root from '[EMAIL PROTECTED]:\w\$ ' to '\h:\w\$ ' in base-files_1.9. > > I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at > least) in /etc/skel/.bashrc. Would it be against policy? > > Thanks. Why not /etc/profile? Or is that against policy? Incidentally, I've always wondered why there is no /etc/bashrc and /etc/bash_profile. They would be ideal for this. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bash prompt strings again (was Re: base-files etc.)
On Sun, Apr 26, 1998 at 03:34:01PM +0200, Santiago Vila wrote: > On Sun, 26 Apr 1998, Avery Pennarun wrote: > > On Sun, Apr 26, 1998 at 02:46:58PM +0200, Santiago Vila wrote: > > > Ok, trying to be "conservative", I have changed the default prompt for > > > root from '[EMAIL PROTECTED]:\w\$ ' to '\h:\w\$ ' in base-files_1.9. > > > > > > I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at > > > least) in /etc/skel/.bashrc. Would it be against policy? > > > > Why not /etc/profile? Or is that against policy? > > /etc/profile is read by many different shells, almost any of which > understand bash escapes, while .bash_profile is only read by bash. Right, but almost every distribution compares $SHELL to /bin/bash. It's not great, but it works. (Actually, [ -n "$BASH_VERSION" ] would be most reliable.) Do we have a policy about this? There is something about not requiring environment variables, I know. Maybe the "right thing to do" is modify bash itself to _default_ to the right prompt. bash$ is just useless, after all. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bash prompt strings again (was Re: base-files etc.)
On Sun, Apr 26, 1998 at 12:11:55PM -0400, Raul Miller wrote: > Avery Pennarun <[EMAIL PROTECTED]> wrote: > > environment variables, I know. Maybe the "right thing to do" is modify > > bash itself to _default_ to the right prompt. bash$ is just useless, > > after all. > > Excellent idea. > > Just try to keep the default prompt from getting too long. It should be the same one as would have been used in /root/.bashrc and /etc/skel/.bashrc. I think that's '\h:\w\$ ' but I could be wrong. (I don't mind this suggestion, though I would still colourize my own.) Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /tmp exploits
On Mon, Apr 20, 1998 at 01:20:10PM +0100, Ian Jackson wrote: > We should modify our libc so that opening a file in /tmp or /var/tmp - > determined by simple string comparison of the filename passed to > open(2) - fails if O_CREAT is specified without O_EXCL. > > We should do this in slink. That way almost any program with a /tmp > security hole will stop working straight away and _have_ to be fixed. And then change libc back, presumably, before making the next stable release? In that case, I think it may be a good idea. But how about this: I often extract tar files to a directory in /tmp. If /home is nfs-mounted, this can be considerably faster, and it gets cleaned up automatically sooner or later. 'tar' almost certainly doesn't open files with O_EXCL... maybe it should? Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary-CD exceeds 650 MB -- any solution?
On Tue, Apr 21, 1998 at 12:01:32AM -0700, Guy Maor wrote: > The sizes are: > 62997 contrib/binary-i386 > 326744 main/binary-i386 > 65237 non-free/binary-i386 > 31849 main/disks-i386 > 86526 contrib/source > 690239 main/source > 148075 non-free/source > > Since the official CD doesn't include non-free, there won't be a > problem for this release. All the binaries and some of the source go > on one CD, and the rest of the source on the other. The total (w/o > non-free) is 1198355, so we still fit in 2. Don't forget: 222758 hamm/binary-all 14893 contrib/binary-all 52066 non-free/binary-all And: 31849 hamm/disks-i386 If we include just the binaries from main and contrib, along with the disks-i386 directory, we seem to get 659241 kbytes. I can never quite remember whether a CD contains 640 or 650 million bytes or megabytes, but this is TIGHT on space. Shoving disks-i386 off to a different CD is probably sufficient to clear it up, though. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boot Dependancies - a weird wacky wonderful new idea
On Wed, Jun 10, 1998 at 07:57:18PM -0700, Robert Woodcock wrote: > Parallelized booting. What this means is we run multiple bootup scripts > simultaneously. It's a *lot* faster on mid-to-higher-end machines, even > with just one CPU - it'd be wickedly fast with SMP. > > "Hey wait a second that won't work!!! What if the netstd_nfs script runs > before the netbase script is done processing?" > > Well, you're right, but I have another (slightly more original) idea that > will make it work. Boot-time dependancies. Parallelized booting is a good idea (I'm almost certain that _most_ of my bootup time, and almost ALL of my shutdown time, is spent waiting for tasks to decide they're ready) but boot-time dependencies are way too much work. What's wrong with priority levels? Programs start up in alphabetical order. I wish they would die in reverse-alphabetical order (then we could have S99xdm and K99kdm, which would make the file-rc package look nicer) but priority levels do exactly what you want -- they express boot-time dependencies. We can achieve a huge degree of parallelism simply by running all boot scripts of each priority level in parallel. That is, run all scripts at level 01 (and wait to finish), then run all scripts at level 02, and so on. To see why this should be "parallel enough," look at the large number of scripts running at the default level 20. Also, the only guarantee we've ever made is that scripts are executed in priority order, so running all scripts at level 20 simultaneously shouldn't cause a problem. The hardest thing would be keeping the log messages from getting tangled up. That shouldn't really be too hard for a C/C++ program to do. I've done something almost appropriate in my wvdial package (see class WvLog and WvLogRcv). If enough people dare me, I bet I could whip something like this up (using the existing priority scheme) in an hour or two. Have fun, Avery P.S. why isn't file-rc the standard? It's _so_ much better! And why can't we kill things in reverse alphabetical order? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote: > The problem is that the Debian installation kernel tries to be all things > to all people. As there are machines that boot from SCSI drives, it was > necessary to have all the scsi controlers "built in" to the kernel, hense > its large size. > > We should recommend that everyone, once they have a standard system and > can build a kernel, should build a custom kernel for their machine as > early as possible. This is, if I recall, exactly what initrd was made for. Your bootloader (eg. lilo) loads an initial ramdisk containing all the kernel modules you might need. An init script on the ramdisk loads the right modules (however you choose to do that) and then exits; the kernel unmounts the ramdisk and remounts the "real" rootdisk. That way, you can have a kernel without _any_ disk drivers at all (even IDE) and yet boot from any disk that has a kernel driver. Works like a charm and avoids all problems with conflicting drivers. Unfortunately, I would expect it to have the same high-loading problems as bzImage since a kernel+initrd would seldom fit in the low 640k. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Base system tarball Q [XTerminal]
On Tue, Jun 16, 1998 at 11:49:25PM -0400, [EMAIL PROTECTED] wrote: > Ok I found out there is no resolv.conf (duh I know..that gets created by > a script when I configure the network...which obviously never happens) > I also found out that I hafta do a chroot . bash --login > once to get it to configure the base system (ie keymap stuff) You could copy /etc/resolv.conf and other config files out of the server's /etc directory. Most of that should be correct (though you'll have to do something special for 'nameserver 127.0.0.1' obviously). I've done an X terminal on a single 1.44 MB floppy. Almost all of the stuff on the base system is unnecessary: what you really need is a simple init system (calling ifconfig/route), libc, X, XF86Config, and rgb.txt. Most of the useful tools you can use to set up the system can be found in the "busybox" package that comes on the Debian rootdisk. Wonderful program, that one. That said, I've also made NFS-rooted X terminals and they're easily fast enough -- once X is loaded, there's no more "disk" access. Mine went from zero to XDM in about 45 seconds (over an ARCnet network, which is slower than ethernet) and needed only 4 megs of RAM to run happily. It would be great to see a Debian package that set all this up. It would also be quite nice to see busybox broken out into its own package. I may be able to help if you run into any major problems setting up the X terminal. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of dhcp-beta?
On Wed, Jun 17, 1998 at 10:55:26AM -0400, Brian White wrote: > There is a bug against dhcp-client-beta that is causing it to be removed > from Hamm. Should all "dhcp-beta" packages be removed or is omitting just > this one okay? I need to know asap. Thanks. dhcp-client-beta is seriously broken, and I won't miss it a bit. dhcpcd works much better. dhcp-beta (the DHCP server) works fine for me, however. Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Base system tarball Q [XTerminal]
On Thu, Jun 18, 1998 at 01:23:42AM -0400, [EMAIL PROTECTED] wrote: > > You could copy /etc/resolv.conf and other config files out of the > > server's etc directory. Most of that should be correct (though you'll > > have to do something special for 'nameserver 127.0.0.1' obviously). > > yes definitly...well really...I shouldn't need it...I mean... I am just > connecting to a host, once I have the IPs needed, what is the nameserver > needed for? Well, you could have a nameserver entry for "xdm-server" (or something) which is looked up while your X-terminal boots. This does seem pointless to me, but who's counting. > > I've done an X terminal on a single 1.44 MB floppy. Almost all of the stuff > > on the base system is unnecessary: what you really need is a simple init > > system (calling ifconfig/route), libc, X, XF86Config, and rgb.txt. > > wow...I never thought it would fit on 1 floppy...then again... > on my system X is only 4728 May 5 23:46 X > hmm but XF86_S3V is over 2 MB :( ohg well back to NFS root :) Ah, the joys of inordinate bloat. This was about two years ago, before libc6 and egcs started doubling the size of things. You may be able to squeeze it on anyway, if you use a compressed ramdisk. (Note that if you use a ramdisk, you need more than the minimal 4 megs -- but if you use an X server that large, you probably need more than 4 megs anyway.) > > Most of the useful tools you can use to set up the system can be found in > > the "busybox" package that comes on the Debian rootdisk. Wonderful program, > > that one. > > I will have to check that out...hmm busybox...where is that? Look for the boot-floppies package. > > That said, I've also made NFS-rooted X terminals and they're easily fast > > enough -- once X is loaded, there's no more "disk" access. Mine went > > from zero to XDM in about 45 seconds (over an ARCnet network, which is > > slower than ethernet) and needed only 4 megs of RAM to run happily. > > Nice nice...what type of systems they runnign on? 486DX/33 or 486DX/40 with XF86_S3. It was quite a while ago. Nowadays they would look pretty slow compared to a "real" computer. Also, I may have been a bit unclear above -- these really were only X terminals and accessed a _remote_ xdm server. You can run a full X session in 4 megs, but you'll have to swap like crazy (which you currently can't do on a diskless client). Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JED anyone?
On Tue, Jun 23, 1998 at 05:20:09PM +0200, Milan Zamazal wrote: > `jed' is an orphaned package. I'm considering to take its maintanence, > since I've found JED is a small and quick start editor, good for quick > editing of configuration files, etc. (I've wiped out all vis from my disk, > and ae+ed do not satisfy me fully:-). However I'm no way an experienced > JED user, so if anyone else wants to maintain it, I've nothing against it. I use jed for programming, and joe for other tasks. Jed is very nice, but it would be better still if someone could figure out its weird C++ autoindent problems (bug#15197). It's a pretty cool bug, actually. I certainly have no time to maintain the package. I say go for it! Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gothenburg -> Vancouver
On Wed, Jun 24, 1998 at 05:06:06PM +0200, Turbo Fredriksson wrote: > > Wildly off topic ... isn't "The Wave" cable modem access? > > Hmmm... You really got me there... I have been lead to beleve it's xDSL, > but I'm not sure... Anyone? It's cable modem, and it's REALLY fast (about 400kbits/sec, full time connection for somthing like $60 Canadian/month). That said, I don't know what xDSL is. Maybe that's what cable modems are :) Have fun, Avery Wishing he was in Vancouver... oh well, maybe next summer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
netselect - choosing the best FTP server automatically
Hi all, A while ago on debian-devel I proposed an algorithm that would allow APT to choose the best possible server for each user from a large list automatically. It could also be used for other tasks, eg. choosing a good SQUID neighbour or IRC server. So, I wrote a program that gathers the statistics needed for these operations. It's called netselect, and I wrote it all in one night, so please be gentle with the bug reports :) I do want to hear what you think though. Following my signature is the first part of the README. Get it from: http://www.worldvisions.ca/~apenwarr/netselect-0.1.tar.gz It's very experimental. Let me know what happens! Have fun, Avery --- netselect 0.1 = This is netselect, an ultrafast intelligent parallelizing binary-search implementation of "ping." Now stop laughing and pay attention. netselect determines several facts about all of the hosts given on the command line, much faster you would if you manually tried to use ping and traceroute. For example, if I type: netselect -v ftp.fceia.unr.edu.ar ftp.kulnet.kuleuven.ac.be \ ftp.cdrom.com ftp.debian.org ftp.de.debian.org It tells me this: ftp.fceia.unr.edu.ar 422 ms 19 hops 40% ok ( 2/ 5) ftp.kulnet.kuleuven.ac.be ms 30 hops0% ok ftp.cdrom.com 215 ms 13 hops 89% ok (17/19) ftp.debian.org 194 ms 20 hops 50% ok ( 3/ 6) ftp.de.debian.org 276 ms 15 hops 66% ok ( 6/ 9) For each host, it figures out the approximate ping time (though not as accurately as "ping" does), the number of network "hops" to reach the target, and the percentage of ping requests that got through successfully. Note that for ftp.kulnet.kuleuven.ac.be in this case, nothing got through at all. That indicates that either the host doesn't exist, or it is down. For a bigger example, I've included the file debian-ftp-mirrors, which is a partially up-to-date list of Debian Linux FTP site mirrors. Try this: netselect -vv $(cat debian-ftp-mirrors) [...etc...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Isn't cc the default compiler?
On Thu, Jun 25, 1998 at 10:24:02AM +0200, Brederlow wrote: > I compiled a lot of packages on my system and often I see that > programms don't use cc as their compiler. Thus they don't use > /etc/alternatives/cc. > > Unless somebody tells me a good reason for not using cc I will open > bugs against any Packages that just uses gcc for fun. I know that some > Packages need gcc explicitly, but that should be a realy small number. Huge numbers of packages pass gcc-specific CFLAGS and LDFLAGS. These are important, because running 'cc' without these flags can often generate pure garbage for code. (WvDial and g++, for example -- I looked at the assembly output, and was not impressed!) If you want to use 'cc', just force CC=cc on the command line. If that doesn't work, that's a bug. Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: in.tftpd: Missing a critical feature
On Thu, Jun 25, 1998 at 06:38:56PM -0500, John Goerzen wrote: > Package: netstd > Version: 3.07-1 The bug number for this report hasn't shown up in the web pages yet, so I'm removing bugs.debian.org from the cc: list in this response. You might want to forward it into the bug report. > Sun's tftpd has an option, -s. Basically, this option chroot's to the > specified directory, than set[ug]id's itself to nobody. After that, > it starts serving files. [...] > Why is this important? Well, we have a number of NCD X terminals. > These terminals try to get files with absolute pathnames like > /usr/lib/X11/ncd/configs. The tftp server should really serve this > file from an appropriate subdirectory below the tftpboot directory -- > NOT the system's /usr/lib/X11 directory. That is, the server should > actually hand the client the file > /usr/local/ncdroot/usr/lib/X11/ncd/configs in our case. I don't like Sun's chroot mode -- you can't make symlinks out of your /tftpboot into the rest of the filesystem. I did this a lot at work last term, where I would build the software for one of our embedded systems in my home directory, press reset, and it would boot the new image automatically. Instead, could we implement behaviour like this: - discard pathnames with dot-dots, of course. - if no path restriction is specified on the command line, use the given path directly. - if pathname starts with /tftpboot (or whatever's specified on the command line to limit tftpd) pass it through directly. - if pathname starts with / but not /tftpboot, append it to /tftpboot. - otherwise, append it to /tftpboot/ (ie. relative to tftpboot directory). This should cover all usages for tftp that I know of. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netselect - choosing the best FTP server automatically
On Thu, Jun 25, 1998 at 09:18:24PM -0600, Jason Gunthorpe wrote: > On Thu, 25 Jun 1998, Avery Pennarun wrote: [netselect http://www.worldvisions.ca/~apenwarr/netselect-0.1.tar.gz] > This is pretty good, but it seems to loose much meaning for me with > several equal servers, > > ftp1.us.debian.org 111 ms 16 hops 91% ok (31/34) > llug.sep.bnl.gov83 ms 15 hops 100% ok (110/110) > ftp.debian.org 80 ms 19 hops 93% ok (40/43) > ftp.cdrom.com 87 ms 13 hops 92% ok (39/42) > -- > ftp1.us.debian.org 115 ms 16 hops 93% ok (31/33) > llug.sep.bnl.gov79 ms 15 hops 85% ok (18/21) > ftp.debian.org 100 ms 19 hops 90% ok (28/31) > ftp.cdrom.com 105 ms 13 hops 90% ok (27/30) > > I'm sitting on a high speed lan conection (ie I get ~100k/s from llug) > Presumably this program pushes the network a bit hard and that is why > there is packet loss a straight ping to any of these sites will get 0% > loss. There are two big problems I've noticed with the first version (I wrote it all last night and have no more time to work on it for at least three weeks; sorry): - it stops as soon as the hop count of all sites is determined, AND the "minimum time" has elapsed. (The default minimum isn't very strict.) Requests that it sends out might not be back before it gives up! - because of random delays (and because if the TTL attempt is too low, it isn't valid for a timing check) the number of packets sent to each host varies wildly. Too-low packet counts can make this really stand out, since getting 4/5 packets is much worse than 29/30, even though only one packet was lost. I don't consider the ping time variance a big deal -- because it sends out lots of packets at once, they will get queued up a bit, but (theoretically, anyway) since each host is equally affected this effect should mostly average out. I'm not surprised by +/- 50 ms, though. If the two bugs above were fixed, I think this would be usable. After all, comparing equal hosts isn't all that useful anyway. The ones we want to filter out are the ones with really large lag times (> 500 ms) and large packet losses (> 10%). Bandwidth comparison a la bing would also be nice, but I definitely don't have time to implement that anytime soon. > My question is how can we build a single weighted score for each site? Let > the user pick one of the top two or so. But how do you weight? Assuming that the packet loss and timing statistics were made more reliable... I would say that packet loss and delay are of almost equal importance, and hop count considerably less. With bugfixes we should be able to attribute about +/- 5% of packet loss and 50ms of delay to random chance, so we need a nice binary comparison routine. Here's a random one: - gravitate, say, 3% packet loss to each site, toward the average. ie. if A has 85% connectivity and B has 95% connectivity, adjust to 88% and 92%. If the average is less than 3% away, just set both to the average. - similarly with 25ms of lag time. Given 200ms and 300ms, we get 225ms and 275ms. - Take percentage difference for each and subtract them (note that smaller lag is better, and larger connectivity is better). Hmm... - A -- B - (88-90)/90 = -2.22% (92-90)/90 = +2.22% (225-250)/250 = -10%(275-250)/250 = +10% Subtract: 7.78% Subtract: -7.78% Note that due to the way percentage difference works, we only actually need one of these. - Higher score wins. Disclaimer: IANAS. (I Am Not A Statistician :)) Anyone is invited to work on the this since I have very little time to do so. Please forward me any improvements or ideas. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Canada to remain mostly free
On Fri, Oct 02, 1998 at 10:35:54AM -0400, Greg Stark wrote: > Manley announced new crypto policies, and though the speech is low on > detail, despite being particularly long-winded, it seems Canada may > remain in the free world. Very cool. It looks like they've really listened to the industry's concerns! One thing that worries me is they weren't very strong on the export controls point... though they allow unrestricted _import_ of encryption. Golly gee, thanks. It does look pretty good for exporting though -- I guess they were deliberately careful with that in order to avoid upsetting the US. In particular, we still can't export encryption that we imported from the US :) It's good to see, though. I've never had confidence in government before. Have fun, Avery
Re: The freeze and IMMINENT 2.2.0p1!!
On Fri, Oct 09, 1998 at 09:11:10PM +0200, Michael Meskes wrote: > On Fri, Oct 09, 1998 at 03:05:17PM +0200, Martin Schulze wrote: > > No, this would hold the release for at least two more months. > > Joey, that's exaggerated by a lot. But I agree with your reasoning- I agree with Joey completely, and I don't see an exaggeration. To take a rule from my personal experience: nothing ever works the first time. It took 2.0.x more than _thirty_ patchlevels before it started working right. Linux 2.0.0 was a disaster. I think Debian 2.1 should be little more than a bugfixed version of hamm. My 2.0 CD's have some serious install bugs, including a completely broken cd_autoup script and bad X11 (xbase won't configure until you install an Xserver, but it installs before all Xservers, which then won't work because they try to to configure X without a working xbase...) In response to someone else's comment about being the "first out with Linux 2.2" -- I don't think we want to be. Red Hat was the first out with glibc, and look at all the nastiness they went through. Let Debian be the slow, stable one, and learn from everyone else's mistakes. Linux kernel 2.2 should be dropped into the new unstable distribution the moment it's available, and we should plan to use it in Debian 2.2 -- but let's integration-test it heavily before we drop it on the unsuspecting public. (That said, any Debian 2.1 user can run APT and install kernel 2.2 easily from unstable.) Slink is a badly-needed cleanup release. Don't hold it back for any package. Have fun, Avery
Re: The freeze and IMMINENT 2.2.0p1!!
On Sun, Oct 11, 1998 at 02:34:28PM -0400, Michael Stone wrote: > > > Quoting Avery Pennarun ([EMAIL PROTECTED]): > > > > Slink is a badly-needed cleanup release. Don't hold it back for any > > > > package. > > I still think that calling slink "a badly needed cleanup" implies that > hamm is horribly broken. I agree that it would be good for debian to > release more frequently, but that's not the same as saying that hamm > doesn't work. "Horribly broken" is probably not the term I would use for hamm. Red Hat 5.0 was horribly broken. Slackware has always been horribly broken. But hamm was so close to perfect -- it almost installs wonderfully, except for a few critical things that mess up as I mentioned in my previous mail. In particular, the X packages install in the wrong order and thus don't work without twiddling. The kernels don't boot on some systems because they have too many drivers. APT isn't the default. Multi-CD support doesn't work (or perhaps it does work, but it's non-obvious if it does). If we avoid delaying releases, Debian 2.2 could be out by April. That gives lots of time to integration-test the Linux 2.2 kernel, and it means slink will be rock-solid for users while they wait. People who really need kernel 2.2 can install it from the new unstable. After all, that's where it belongs -- 2.2.0 is bound to be unstable for a while. Linux 2.2 will break things that we don't expect. I know -- I'm running the 2.1 kernels already, and I've had to hack around a bit of funny behaviour from setserial, ipchains, and a few other packages. That's just me. Other people will have other problems. Not serious ones, but quite a few of them, and if we rush the release of slink we'll miss some. If we don't rush it out, Joey's estimate of a 2-month delay is very reasonable. I don't want to see a two month delay. Have fun, Avery
Re: Bug#27697: auto-include-dependency failure case
On Mon, Oct 12, 1998 at 06:47:14PM -0600, Jason Gunthorpe wrote: > What I have been doing of late is generating the .d file when the .o file > is built. Nothing depends on the .d file but if it exists it is included. > This makes the .o file depend on all included files and the .c file > automatically. Also the .d file depends on nothing so there is no rebuild > rule for it. Hmm, what a good idea. I hadn't thought of doing it that way. > make in it's tracks. The only remaining problem is erasing header-files > requires a make clean :< I hate that. I've considered just adding a "%.h:" blank rule, but I don't like the looks of that... > In my make files I actually use the GNU C specific option to generate a .d > file as it compiles from .cc to .o, it runs -REALLY- fast compared to the > technique automake uses. I don't know what automake does, but I've found that gcc -MM for each file is really slow... it takes about 1/2 the time of actually compiling the file! In wvdial 1.10, I redesigned my own rules.mk dependencies to be much faster: it still uses gcc -MM, but only once per directory. It gets a list of all headers included from any of the files in the current directory (recursively) then processes each header only once using a rather funky awk script. All dependencies end up in a single .depend file, but I can do a whole directory full of files in about the same time as it takes to create a single .d file the old way. You might want to look at the wvdial source (it's in slink) to see what I've done... note that I've fixed a few minor buglets in the awk script since wvdial 1.10, so if you want to use my script, let me know and I'll fire you off the latest version. Have fun, Avery
Re: latest sysklogd broken?
On Fri, Oct 16, 1998 at 12:12:52AM +0200, Martin Schulze wrote: > > > What do you mean by "break"? If you restart syslogd you have to > > > restart some other programs as well (squid, teergrube, inn, named come > > > to my mind.) > > > > Can you explain this? This doesn't sound very "normal" to me. > > Sure. Many programs open the socket to syslogd and never re-open > it. Thus whenever you restart the syslogd (contrary to SIGHUP' it). > These files will log into nowhereland, i.e. the console. This sounds like a fixable libc bug. For the Unix domain socket, it should easily be able to notice when send() fails -- and it should re-open the log socket in that case. I don't think any programs bypass libc to do their syslog calls... You should submit a bug against libc6, I think... Have fun, Avery
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 06:48:24PM +0200, Martin Schulze wrote: > Enrique Zanardi wrote: > > Are we going to include "apt" in the base system? Its package > > ordering feature (and a few others) obsoletes the other methods, but > > currently apt doesn't work with mountable media. A "multi-cdrom-apt" > > method should be added quick. > > NO! It does not _obsolete_ other methods. It add new methods. I would > begin to hate somebody if it would replace e.g. the ftp method. Apt and > apt-get are some more alternatives. They don't replace existing tools. Most of the older methods should be removed. I installed hamm using the CD-ROM method (seemed logical enough) and it tediously went through _all_ the packages on the CD in randomly-ordered dpkg -iGROEB fashion. APT functionality really does obsolete that. Choice is good, but when the choice is between "slow and inferior" and "faster and better" there really isn't much point. APT isn't a tradeoff, merely an improvement. That said, multi-CD support in APT would make me an extremely happy camper... Have fun, Avery
Re: Slink not installable from CDs
On Thu, Oct 15, 1998 at 11:39:28AM -0700, David Welton wrote: > On Thu, Oct 15, 1998 at 08:31:59PM +0200, Santiago Vila wrote: > > > > "What would you like to see on the first CD"? > > Why don't we look at what the most popular downloads have been? Some > Perl/Python type person ought to be able to parse them nicely, include > information about relative sizes of things, and then output something > based on that. I don't have time for this, so feel free to can the > idea of no one is interested in doing it. I can whip up something like that if someone can feed me the FTP statistics. Have fun, Avery
Re: Slink not installable from CDs
On Fri, Oct 16, 1998 at 06:18:09AM +0200, Martin Schulze wrote: > > How do we determine what's important, and what's optional ? > > Some people already mentioned that we need to distinguish between > certain packgages. > > I propose: [...] I think we should play a simple game of numbers, and I think FTP statistics are a good place to get those numbers :) Simply start with the most popular package, and pull in all of its dependencies. Then continue with the next-most-popular package that isn't already included, and pull in its dependencies. And so on... stop when the next package+dependencies won't fit any more on the first CD. I'd rather not make any discrimination based on which section/priority the package maintainer thought the package should be in. "extra" contains some rather useful packages (like sendmail) while "optional" contains many less-popular niche packages. Hmm, but I guess we'll also want to force 'base' in there whether it's popular or not :) I can't promise anything, but I _think_ I should have time to write a script like this next weekend... if someone doesn't beat me to it. It should be a pretty easy job of parsing the Packages and FTP statistics. The dependencies will be the hardest part, but still a much easier job than the APT and gdselect people have had... Since this script will only really be useful to CD-makers, this project would be mostly independent of dpkg-multicd or whatever. Have fun, Avery
Re: 1FA: problem still in hamm disks
On Sat, Oct 17, 1998 at 09:49:54AM -0400, Michael Stone wrote: > Quoting Tom Lees ([EMAIL PROTECTED]): > > While I'm at it, *PLEASE* drop the dependency of lilo on mbr. I don't want > > a new mbr eg if I want to install LILO to use on a floppy ONLY (I use > > GRUB on my HD). Change it to Recommends. mbr being a high priority and/or > > essential (can't remember if it is) should be enough. > > Can someone explain what the point of mbr is? Why not just install lilo > directly to the mbr? (I always go back and do this for security reasons > anyway: I've disabled floppy boot in the bios, why do I want an mbr > that re-enables it?) Wow! Maybe I'm an idiot, but I just _now_ (after literally years of wondering) realized where that silly 1FA: message was coming from. I had thought it was some kind of weird debugging feature of some BIOSes! 1FA looks like a hexadecimal number. I know MBR has to be small, but can we at least put in some commas, eg. "1,F,A:" ? Furthermore, I think it should be made abundantly clear, somewhere obvious, that you have to set the active partition when you install Debian. I've always been a pure-LILO user, and LILO ignores the active setting. Not understanding mbr, I've always gone through on my Debian systems and changed lilo to use /dev/hda instead of /dev/hda1, because otherwise my system wouldn't boot automatically to Linux. I know it's my own sheer incompetence, but I would have appreciated a warning message about this somewhere. Have fun, Avery
Re: Netscape packages and lesstif
On Sun, Oct 18, 1998 at 06:34:40AM -0400, Gregory S. Stark wrote: > The dmotif netscape packages seem to depend on lesstif, does this mean you can > run them with just lesstif? Or is that in addition to requiring real Motif > libraries? I'm surprised (but happily so) since i thought lesstif aimed only > at source-level compatibility not binary level. I hear they're moving toward binary compatibility. I don't know if it works or not. Sorry to not answer your main question. Have fun, Avery
Re: make mutt the `standard' mail reader
On Mon, Jan 18, 1999 at 05:38:32PM +0200, Antti-Juhani Kaijanaho wrote: > On Sun, Jan 17, 1999 at 08:57:07PM -0500, Avery Pennarun wrote: > > The "de-facto standard Internet tab size" has always been 8 characters. > > Always? The 1982 standard for ARPANET¹ email (RFC 822) explicitly > states in Section 3.4.2 that there is no nework-wide standard tab size > and so the use of HTAB is discouraged. That's what makes it a "de-facto" standard. Unfortunately, no standards, even de-facto ones, are universally implemented because there are people who (often rightly) believe that they're junk. Yay for ^H versus DEL :) Have fun, Avery
Re: Bug#27050 (fdutils): A cause for security concern?
On Tue, Jan 19, 1999 at 04:43:37PM -0500, Ben Collins wrote: > On Tue, Jan 19, 1999 at 02:29:44PM -0700, Anthony Fok wrote: > > As the Slink deep freeze and release are impending, I would like to ask > > your advice: Should I follow the suggestion given by the bug reporter > > Thomas Roessler? If so, should I fix this bug before Slink is out? I > > am kind of busy with school now and would like to put it off till the > > holiday, but if all of you experienced developers feel that it is > > urgent, I will try to fix it before Slink is released. > > I would suggest making it sgid to group floppy, them make it mode 2754. > There doesn't seem to be a need to have it suid root since /dev/fd? is > writable by group floppy. I don't think you can mount filesystems unless you're root. > 1) Only people in group floppy will be able to execute it, That's a useful feature, though. You could make it owned by root.floppy, mode 1754. (There is no real need to make it setgid floppy in any case.) When the docs for a setuid program warn you "not to trust its security" then be afraid, be very afraid. It shouldn't be automatically setuid in Debian until _some_ security-conscious person has audited it carefully. Have fun, Avery
Re: Bug#27050 (fdutils): A cause for security concern?
On Tue, Jan 19, 1999 at 08:56:11PM -0600, John Hasler wrote: > Avery Pennarun wrote: > > When the docs for a setuid program warn you "not to trust its security" > > then be afraid, be very afraid. It shouldn't be automatically setuid in > > Debian until _some_ security-conscious person has audited it carefully. > > Would you say the same of daemons that run as root? Coming from you, that sounds like a trick question. Okay, I volunteer to be tricked: yes, daemons should not run as root (especially network servers) unless they've been looked over by some security-competent person, and only if they actually NEED to run as root! I don't know its current status, but I submitted a bug against socks4-server a while ago because it was running as root for no reason at all -- it works fine when running as "nobody." Setuid programs are actually more dangerous than daemons, though -- the non-root user has more complete control over their execution environment, so there are more types of security holes. For example, you can change the PATH environment variable and shell strings (eg. IFS, HOME, etc) so using the system() and execvp() system calls is generally dangerous in a setuid program, but often not so bad in a daemon. Have fun, Avery
Re: the Great X Reorganization, package splits, and renaming
On Fri, Jan 22, 1999 at 03:18:51PM +0100, Santiago Vila wrote: > > Still, it is advisable to install the renamed versions of these packages > > as soon as is convenient, in the event that their contents do change in > > the future. > > This would just postpone the problem until there is a real difference > between the old packages and the new ones, but would not make the > problem to disappear. It would be just a clock bomb. Imagine the following > scenario: > > --Oh, I upgraded from Debian 2.1 to Debian 2.2 and now my font packages > do not work. > > --Did you read the release notes for the X packages in Debian 2.1. Because it's such a widespread problem, we can assume that Debian 2.2's version of APT will support package renaming in some way. That means we can actually put off solving this problem until Debian 2.2, and even longer if the X fonts don't change. To put it another way: - Upgrading from old-Debian to 2.1 doesn't replace the font packages, but that doesn't cause an immediate problem; - If Debian 2.2 doesn't have new or rearranged fonts, there is still no problem; - If Debian 2.2 _does_ rearrange the font packages, it should implement some package renaming scheme at _that_ time, assuming APT or dselect has been improved with a nice renaming scheme. Why make things ugly before there's an actual reason to do so? Have fun, Avery
Re: the Great X Reorganization, package splits, and renaming
On Sat, Jan 23, 1999 at 12:03:55PM -0500, Raul Miller wrote: > Avery Pennarun <[EMAIL PROTECTED]> wrote: > > Because it's such a widespread problem, we can assume that Debian 2.2's > > version of APT will support package renaming in some way. That means we can > > actually put off solving this problem until Debian 2.2, and even longer if > > the X fonts don't change. > > This means that we're willing to hold off on upgrades to all font packages > until the relevant apt support for package renaming is ready. Sure, why not? Nothing in them has changed. > I just hope the rest of the world agrees that this is wise. Uh... yeah, me too. > [What's wrong with using the "empty package" mechanism, and waiting for > apt to give us a way of making defunct empty packages delete themselves?] I didn't think there was any plan to add "auto-delete defunct empty package" support to APT; on the other hand, I've seen lots of package renaming proposals. Besides, if the empty packages are unnecessary, why should we have them crowding things? Have fun, Avery
Re: Debian logo & its license
On Sat, Jan 23, 1999 at 07:48:00PM -0600, Stephen Crowley wrote: > On Sat, Jan 23, 1999 at 04:21:37PM -0800, Chris Waters wrote: > > Debian is a free project to distribute a free OS. It should have a free > > logo. FREE THE LOGO!! FREE THE LOGO!! :-) > > And what if some anti-debian people get ahold of the logo and use it for > evil purposes? What if someone gets hold of the Linux kernel and uses it to guide nuclear missiles? (Well, at least they have to share their changes with us :)) Seriously, slander is slander, and it's rude, and people will know it when they see it. Furthermore, if people want to parody Debian (including the logo) they'll do so regardless of the logo license, and Debian doesn't have enough money to sue them about it. Besides, did anyone bother to register a trademark? A license that says "this logo should only be used when referring specifically to Debian" is plenty and probably still unenforceable. Have fun, Avery
Re: filters: Licence problems
My answer to exercise 1: since you have quoted text, rule (2) says you must not comply with rule (6), but rule (3) says you must comply with all even rules (including, presumably, 6). This seems to imply that no message containing quotations would be allowed. I'm not sure if that's only true when you start with one or more implicit assumption, but then again, I'm not sure if you complied with rule (6) anyway. So I guess it sounds like a pretty decent set of arbitrary rules. I second the motion, and hereby propose that we apply them to debian-devel as well. We can call them the "Debian Grumpy Pooper Guidelines (DGPG)." Have fun, Avery On Sun, Jan 24, 1999 at 10:04:45PM +0100, Marcus Brinkmann wrote: > On Sun, Jan 24, 1999 at 01:50:21PM -0500, Raul Miller wrote: > > David Welton <[EMAIL PROTECTED]> wrote: > > > If you are indeed serious... technically, you are right, of course, > > > but I think people are really going to think we are just a bunch of > > > grumpy party-poopers if we seriously start to get anal about obviously > > > silly licenses like this..:-> > > > > Perhaps we need a new list: debian-grumpy-party-poopers? > > > > [With a nice long legal document indicating what's appropriate > > traffic for the list, of course.] > > (0) Every mail has to follow rule (0), (1), (2) and (3). > (1) Any mail which starts with one or more implicit assumption has to follow > rules (4) to (7). > (2) Mails with quoted text must not fulfill rule (6) but (8). > (3) Mails which carries a valid FQDN must comply with all even rules. > > (4) Do NOT apologize for what you said, thought, wrote or assumed. > (5) Do NOT try to make people happy. > (6) Do NOT rant, flame, lie, hypocry or whine. > (7) The number of letters divided by the number of words must be less than > the number of columns divided by the number of lines. > (8) End your message with a signature which uses figlet to summarize your > final position. > (9) This rule is obsolete and should not be used in any way. > > (42) If you have come so far, you have the right to get the answer of the > universe. Have a deep breath and start all over again, this time reading > more carefully. > > Exercise 1: Examine if this mail could be sent to > debian-grumpty-party-poppers. > Exercise 2: Write three DIN A4 pages about the breakdown of the society by > overdoses of microwaves. > > Marcus > > -- > "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ > Marcus Brinkmann http://www.debian.orgmaster.debian.org > [EMAIL PROTECTED]for public PGP Key > http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >
Re: the Great X Reorganization, package splits, and renaming
On Mon, Jan 25, 1999 at 02:18:56PM +0100, Santiago Vila wrote: > On Mon, 25 Jan 1999, Branden Robinson wrote: > > > You have yet to explain what will BREAK if people continue to use the old > > font packages. Not in the future, RIGHT NOW. > > Oh, you have yet to explain why a clock bomb is *not* a bad thing. > "Surely, it will exploit, but not now" ;-) But it won't. I agree with Branden on this point. What's the problem, other than that you think someday it will explode? I think it won't. Who wins? My guess is that by the time potato is released, some kind soul will have implemented package renaming in dpkg. In that case, all future releases of Debian will have the problem solved. In slink, there's no problem other than your supposed "time bomb," the existence of which is arguable at best. > I propose a solution (which is the only *viable* solution, since we can't > guarantee that dpkg will be changed), and you say it's uglier than the > hell. It is ugly. Twiddling with dpkg in the xbase package (tell dpkg to select all xfonts packages corresponding to the installed xfnt packages) kind of appeals to me, but I'll respect Branden if he doesn't want to try it, particularly while slink is in deep freeze. (Specifically: we could do it sort of like the "menu" package does, postponing the activity until after dpkg releases its lock. It won't fix things immediately, but the changes will show up next time through dselect.) > > It would compound the error to reverse the name change. Yup. Very sorry for posting a "me too" message, but I thought it might be needed. (I suspect that the infamous Debian "silent majority" effect is kicking in again.) Have fun, Avery
Re: New logo strategy
On Mon, Jan 25, 1999 at 09:11:47PM -0600, Steve Greenland wrote: > On 25-Jan-99, 19:06 (CST), Wichert Akkerman <[EMAIL PROTECTED]> wrote: > > I agree with James Treacy's observation that we will probably need two > > logos: one logo with a liberal license that people can just freely, and > > another, more restricted logo for things like official CD's and so. > > To phrase this in another way: we will have a logo that everyone can > > slap onto their webpage, t-shirts, posters, etc., and a logo that can be > > used for `official' products, like CD's made using our own iso-images. > > Sorry, I think this is a bad idea: > > 1. We have to agree on *two* logos :-). It's actually a good idea, and solves quite a few problems with the licensing issues. The "liberal" logo is something cool-looking that says "Debian" in some way, that everyone can plaster all over CD's, books, web pages, and so on. The "restricted" logo is more like a certification -- think "Intel Inside" and "Yes! It works with Netware" here. Visions of little swirlies. It would only be allowed to appear on official merchandise that is certified to really be Debian, like official CD's. This one is probably black and white, and quite simple, and says something like "Certified Debian." Notice how Novell's logo is quite different from the "Yes!" logo, and how "Intel Inside" is very different from Intel's logo. And guys, when worrying about licensing issues, remember that unless we get these things trademarked, anyone who produces a rather similar looking certification graphic will be free to use it wherever they want. You can only use copyright law to sublicense the _exact_ image file and derived works, NOT similar-looking art. (But if it uses the word "Debian" it's probably covered under other trademarks. IANAL.) Have fun, Avery
Re: Getting Slink compatible with Linux-2.2.0
On Tue, Jan 26, 1999 at 04:40:35PM -0700, Jason Gunthorpe wrote: > On Tue, 26 Jan 1999, Gergely Madarasz wrote: > > > > But is that specific problem Debian/slink related..? That is, does it work > > > correctly with potato? > > > > No, it does not work correctly with potato either. It seems to be a > > general incompatibility with 2.2 > > 2.2 did something bizzar to how the packet filter code needs to work, > nothing that used that mechanism will work anymore. Anyone made sure that > libpcap works? libpcap works, insofar as tcpdump works. bootpc and older DHCP daemons broke not because the packet filter code changed (it did, but it's backwards compatible), but because 2.2 kernels act differently than 2.0 kernels with _normal_ TCP/IP sockets when interfaces have their IP address set to zero. Fun experiment on 2.0 kernels: [configure your ethernet or PPP link] ifconfig dummy0 0.0.0.0 up ping www.debian.org Won't work (dummy0 interferes with eth0 and ppp0, regardless of your routing table!), because 2.0 had a really weird hack for 0.0.0.0 addresses in order to make DHCP and bootp work. This hack has been removed, and the code is now more strict (if an address 0.0.0.0 is set on an interface, that interface has IPv4 entirely disabled). The fix is to change bootpc and DHCP daemons to use RAW sockets and generate their own IP headers, since they need oddball headers anyway. I believe the DHCP daemons have already been fixed. Have fun, Avery
Re: Intent to package xfntbase, xfnt75, etc.
On Wed, Jan 27, 1999 at 08:43:30PM -0500, Branden Robinson wrote:
> > * "There should be some better way".
> >
> > Fine. Which one?
>
> Is there a way to have a dpkg --set-selections call lurk in the background
> until the current dpkg process ends, like update-menus does now? That
> would be a far cleaner solution.
Sure, why not do it in exactly the way update-menus does? I think it just
looks for a lock file in some directory or another.
> while (dpkg running)
> wait
Good...
> for oldpackage in xfntbase xfnt75 xfnt100 ... xslib xslibg; do
> case $oldpackage in
> xfntbase) newpackage=xfonts-base ;;
> ...
> xslibg) newpackage=xlib6g-static ;;
> esac
> echo "$newpackage install" | dpkg --set-selections
> done
Be careful! This way, you're forcing all of the above packages to be
installed, which you could just as easily have done with a dependency by
the dummy xbase.
oldpackages="$(dpkg --get-selections
| egrep '^(xfntbase|xfnt75|...)'
| awk '{print $1}')"
for oldpackage in $oldpackages; do
[ "$oldpackage" = "xfntbase" ] && echo "xfonts-base install"
...
done | dpkg --set-selections
Every invocation of dpkg is horribly slow, so we should try to limit it to
one call each of get-selections and set-selections. The above should do the
job, but it's untested so there are probably syntax or logical errors.
> The second half is easy. Waiting for dpkg to finish is what I don't know
> how to do. There is also the issue of guaranteeing that apt(?) is invoked
> to realize the state of the new selections.
Hmm, I don't think that's necessary; apt only seems to cache _available_
packages, not user selections, I think.
Besides, if dselect/apt don't notice the preference changes immediately,
it's still okay -- just the "new" packages won't be installed until next
time dselect/apt are run. Big deal. As we know, the old packages aren't
hurting anything anyway.
Now, on with the flamewar! Don't let me stand in your way.
Have fun,
Avery
Re: Getting Slink compatible with Linux-2.2.0
On Wed, Jan 27, 1999 at 08:13:30PM -0600, Marcelo E. Magallon wrote: > >> Steve McIntyre <[EMAIL PROTECTED]> writes: > > > Don't think so small. Some of us run quite big machines on Debian; my > > workstation/server at work has ~300MB of swap configured from ~25GB of > > disk. >128 MB of swap is _not_ very big... > > I'm NOT thinking small. I'm thinking efficiency. You are talking 6 > full orders of magnitude in terms of access time. If you have the > money to pay for 25 GB of hard disk, I'm sure you have the money to > afford a motherboard that can take over 1 GB of RAM. Even if 1 GB of > RAM is way more expensive than 25 GB of HD, it's not 6 orders of > magnitude more expensive. Six orders of magnitude?? In the unlikely event that my 100 MHz SDRAM can really handle 32 bits (4 bytes) per cycle, then it can transfer 400 megabytes per second. It's not REALLY that fast, but I'll give it the benefit of the doubt. Meanwhile, a relatively lame IDE hard drive can sustain about 6 megs/sec. So if you swap to that drive, then our 400 megs/sec main memory is about 66 times faster (between 1 and 2 orders of magnitude, speaking in powers of 10). That's a bunch faster, but not as much as you claim. Plus, almost all the memory that ends up in swap doesn't get accessed very much. The more memory you have, the more true this becomes. I regularly take my 64-meg Linux system about 50 megs into swap (yay for StarOffice), and it still flies along nicely. This works because of two things: first, Linux's swapping code has been getting a LOT better (probably better than anyone else's) in the recent past; lately, instead of churning constantly, the drive sits idle a lot, even when I'm heavily into swap. Secondly, most programs only have a relatively small portion of memory that they access *A LOT*. The rest is low-bandwidth stuff that's kept in memory for simplicity more than anything. For example, netscape has a big cache of graphics and scripts, and StarOffice keeps lots of mostly-unused shared libraries and gigantic documents all in memory. That means that on tiny-memory systems (say, 8 megs or less) swapping will still thrash because even the often-used parts don't all fit in memory at once. As memory gets larger, though, swapping becomes less painful. Try it sometime. It actually isn't so bad. (And at about $0.04 CDN per megabyte on a hard drive versus $2.19 in real memory, swap space is an AWFUL LOT cheaper.) Now, the inefficient programmers that burped out StarOffice and Netscape in the first place are still pretty hard to explain. Have fun, Avery
Re: Call for mascot! :-) -- flying pigs
On Thu, Jan 28, 1999 at 01:35:24PM -0800, Steve Lamb wrote: > >> >I mean, how often do you see an Octopus flying across the sky? > > >> I can honestly say that I'm more likely to see an octopus fly across > >> the sky than a dragon. > > >I don't think so - Octopi can't fly! (Unless they flap their arms (legs?) > >really hard, and then they'd run out of energy and die from falling :) > > Octopi are real, dragons are mytical. I am more apt to see something > real flying through the air, no matter how improbable, than something > mythical, which I cannot ever see at all. For that matter, how about a flying pig? Then at least outsiders will get the joke. You know, a slightly lean, brightly smiling, winged angel-pig with what might or might not be a curly tail. Hey, he could have a cape, like Super Pig. Think about it, you'll learn to love it. The key here is "cute." People don't want an ugly chicken-like creature that is clearly ready to attack at the slightest provocation. Octopi and ants may also be good, if they have wings. Have fun, Avery
