Re: can somebody please give me some info regarding package dependencies.

[Buddha Buck]

> Greetings!
> 
> I would like to know if an older version of a required library can be used 
> with those programs that require certain libraries to work without any 
> problems. i.e. I am currently using debian slink 2.1 with the icewm window 
> manager and I want to install sawmill but then sawmill requires certain 
> libraries to work but what i have are older versions of those libraries. Are 
> those required by sawmill or any other programs example, everybuddy, need 
> specific versions of required libraries or older versions of libraries can 
> be used?

Short answer: Package dependencies should work to ensure that you have 
the proper library versions installed.  If you can install a package, 
satisfying all dependencies, and it doesn't work due to a library 
problem, then that is a bug, and should be reported.

Long answer:

Each shared library has a "soname", which consists of a name and a 
version number.  For example, "libc6" is the soname for the current 
version of the libc standard C library.  Sonames are used to 
distinguish between incompatable library versions.  A program compiled 
with libc5 will not work with libc6, or vice versa.  But a program 
compiled against any version of libc6 should work with any other 
version of libc6.  It is possible to have multiple versions of the same 
library installed, as long as they have different sonames.

Debian chooses to include the soname of a library in the package name, 
so that programs can depend on specific sonames for libraries.  This 
arrangement allows Debian packages to emulate the semantics of the 
libraries themselves -- two packages with the same name should be 
equivilant, and packages with different hames can be co-installed.  It 
is the responsibility of the package maintainer to make sure the 
library dependencies are properly reflected in the package 
dependencies.  This way, installing the right packages so all package 
dependencies are taken care of automatically ensures that the library 
dependenceis are also met.


> 
> Any info would be greatly appreciated.
> __
> Get Your Private, Free Email at http://www.hotmail.com
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Routing table question

[Buddha Buck]

> "David H. Silber" <[EMAIL PROTECTED]> writes:
> 
> 
> I still don't understand something. Doesn't the line:
> 
> 192.168.1.0 0.0.0.0 255.255.255.0   U 0 0  0 eth0
> 
> mean "send everything addressed to IP's 192.168.1.* through default
> gateway"? But this way the kernel will be sending communications for
> 192.168.1.1 through 209.226.71.1. So I must be wrong in translating
> the line above...

It more means "send everything addressed to a host on the 
192.168.1.0/24 network to -no- gateway."

The gateway column specifies which machine to gateway through, so 
should be host addresses, not network addresses.  "0.0.0.0" does not 
mean "default", but rather "none".

Perhaps a bigger example will make it clearer...

(Abbreviated) routing table:

Destination  Gateway  Iface
192.168.1.0/24   0.0.0.0  eth0
192.168.2.0/24   192.168.1.254(eth0)
192.168.3.0/24   192.168.1.253(eth0)
209.226.71.0/24  0.0.0.0  eth1
0.0.0.0/0209.226.71.1 (eth1)

This is your setup, but I've added two more local nets that have 
gateways on the 192.168.1.0 network.

The interfaces in parenthesis are computed by the routing algorithm, 
not set by route or ifconfig.

If you send a packet to 192.168.1.34, the routing algorithm would see 
that you have a direct connection (no gateway) to 192.168.1.0/24, which 
is the network for your destination, so it would know to send through 
the eth0 interface directly to 192.168.1.34.

If you send a packet to 192.168.2.34, the routing algorithm would see 
that 192.168.1.254 is the gateway, and it's precomputed that the 
gateway is on eth0, so it would send your packet for ...2.34 to 
...1.254 on eth0.  Similarly, a packet to ...3.34 would be sent to 
...1.2553 on eth0.  Presumably, the two gateways would forward it along.

If you sent a packet to 208.4.23.5, the routing algorithm would see 
that there is no defined route to that machine, so it uses the default 
route, and sends it to 209.226.71.1 for forwarding.

Clearer?

> 
> -- 
> Arcady Genkin
> "... without money one gets nothing in this world, not even a certificate
> of eternal blessedness in the other world..." (S. Kierkegaard)
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: dselect dconfusion

[Buddha Buck]

> I)I've just updated my packages list (apt-get update.) Now I've run
> into a few dependancy problems - I've also noted that many utilities and
> pkgs have been deselected (not my doing, I think,) many of them
> required, such as adduser, login, and many more.  So I went about
> holding,  selecting, deselecting, and now I don't know where I stand.  I
> Still have many conficts/dependancy problems.  Is there anyway to start
> dselect from scratch? What I mean to ask is can I reset the selections
> to what they were before I started to tinker with them?

Not easily...  Not after you leave dselect that is.

If you get to a dependency-resolution screen, you can use "R" to reset 
your selections to what they were before you got there -- usually 
including the selection that caused the problem.  But once you get out 
of a dependency-resolution screen, it's set.

> II)Is mailx a standard mail utility?  I thought maybe pine would be
> included in the packages list, though I don't see it.  Can someone
> recommend a decent mail utility for me.  Currently I'm rebooting to win
> in order to mail you these newbie questions.

mailx is a standard mail utility, but it is -very- bare-bones.

Pine is not included because the copyright license on pine does not 
quite qualify as free software.  I believe the problem is that they 
limit distribution of modified versions.

As for decent mail agents...  I use exmh, but it has enough support 
baggage required that even though it is excellent, I wouldn't recommend 
it to a beginner.  Elm is also very good.  Mutt also has a good 
reputation.

If you use emacs or xemacs, you can deal with mail using either gnus or 
RMAIL, which are mail agents written for emacs.

Postilion and balsa seem to show promise, but neither of them are 
really finished yet.

But keep this in mind:  Choice of mail agent is a personal decision.  
Some people find that mailer A is perfect, but mailer B is unusable.  
Others think mailer B is perfect, and mailer A is unusable.  While 
"holy wars" about mailers aren't as common or as vitriolic as the 
venerable editor wars, they do happen.

> III)Thanks to those who have so quickly and courteously responded to
> my questions.   I see now why Debian's popularity is growing so
> rapidly:  fast, free, and accurate technical support : )

Danke.

> 
> Thanks again,
> 
> 
> Paul Nesbit
> 
> Algonquin College
> Computing Science / Computer Technology
> 
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Mouse

[Buddha Buck]

> I have a HP Vectra with a bus mouse.  When I run XF86Setup I cannot get the
> mouse to move.  I have read in Linux documentation that /dev/mouse should be
> linked to /dev/ca[01].  I cannot find these device drivers.  What should I
> be doing to make this happen?

I think you can't find /dev/ca[01] because it actually says 
/dev/cau[01], and that would be wrong anyway, for two reasons, one 
relevant here, and one not.

The suggestion to use /dev/cua[01] is for if you have a serial mouse, 
not a bus mouse.  Since you have a bus mouse, it is wrong for that 
reason.  It is also wrong because the /dev/cua[01] are considered a 
design mistake by the kernel developers, and they have dropped official 
support for them a -long- time ago.  It's just that not all the 
documentation that refers to them has been properly updated.

The Busmouse Howto says that Linux only supports four busmouse 
interfaces -- Inport (aka Microsoft), Logitech, PS/2, and ATI-XL.  If 
your mouse connects to a special card in your machine, it could be 
Inport, Logitech, ATI-XL, or none of the above.  If it plugs into a 
small round connector that looks like your keyboard connector, it's a 
PS/2 mouse.

If it's PS/2, you can use /dev/psaux.  You may have to compile in 
kernel support, however.


> 
> 
> Mark Kolb
> Systems Engineer
> Information Services, Network Management
> Phone: (203) 789-3791
> e-mail: [EMAIL PROTECTED]
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Help me stay away from visual C++ :)

[Buddha Buck]

> dear carl 
> 
> 
> >The more I think about it, the following is better.
> >No more buffer overflow problem.
> 
>  
> have heard lots about it in security bulletins ...
> what is a buffer over flow ? and how does it appear in code ?

A buffer is a block of memory designed to hold some data involved in 
input or output.  A buffer overflow is when you read more data into the 
buffer than it can hold.

Example:

char *
readline(FILE *input)
{
   char buffer[80];
   fscanf(input,"%[^\n]",buffer);   /* Read in everything upto a 
newline */
   return strdup(buffer);
}

This is a rather straightforward example:  It declares a fixed-width 
buffer (80 characters), then reads in an unbounded number of characters 
into it.  If it is asked to read a line longer than about 80 
characters, "buffer" will overflow.

This is a potential security problem because C doesn't do any array 
bounds checking.  fscanf will be happy to write over any memory near 
the buffer once it gets past an 80 character line.  In this case, that 
will modify such things as return addresses, saved registers, etc, 
stored on the same stack that the buffer was allocated on.  That means 
that a well-chosen long line could turn control of my program over to 
the attacker instead of the legitimate user.

Hope this helps.

> 
> cheers
> venu
> 
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: file extensions -- batch mv'ing, mp3s

[Buddha Buck]

> >> 
> >> $ for x in *;do mv -iv "$x" `echo "$x"|sed -e 's/MP3$/mp3/'`;done
> > 
> > bash$ for i in *.MP3; do mv $i ${i%.MP3}.mp3; done
> 
> mmv '*.MP3' '#1.mp3'

Nice, but mmv isn't a standard Unix command.  mv, echo, sed, and 
sh/bash are.


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: file extensions -- batch mv'ing, mp3s

[Buddha Buck]

> 
> To change .MP3 to .mp3 in a given directory, I do this (anyone know an
> easier/more efficient way?):
> 
> $ for x in *;do mv -iv "$x" `echo "$x"|sed -e 's/MP3$/mp3/'`;done
>

I usually do something like this:

bash$ for i in *.MP3; do mv $i ${i%.MP3}.mp3; done

I don't know if ${var%pattern} is a bashism or not.

The ${var%pattern} returns the value of $var, with the shortest suffix 
matching the pattern (a filename glob) deleted.  Using %% instead of % 
removes the longest suffix, and # and ## remove the shortest and 
longest prefixes.

I think it's shorter, clearer, and more efficient.

Any better ways?

 
-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: infomagic

[Buddha Buck]

> 
> On 23-Jul-99 Kenneth Scharf wrote:
> > 
> > Check out www.infomagic.com.
> > 
> > The reason they no longer put Debian on their linux toolkit cd's (they
> > say) is that at 4 cd's it is now too large.  So they now have a
> > SEPARATE debian 4 cd set.  The latest (2.1r0x) will be out in August at
> > $15 (plus postage).  You can subscribe for updates at $10 a pop. 
> > Hopefully, the August release will be followed very shortly by the 2.2
> > release? (In a few months anyway).  This is an OFFICIAL Debian release.
> >  Their web page still shows the 'ol blue eyes' logo on the CD.  Someone
> > should tell them about the new logo?
> 
> I thought InfoMagic CD's were not reliable.

If InfoMagic CD's were not reliable, it's because they were cutting 
their CDs (to shoehorn Debian into their toolkit CDs), and not taking 
the same quality control as we do when developing our official CD 
images.

If InfoMagic is now shipping Official Debian CDs, then they are using 
our CD images, so they should be just as reliable as anyone else.  And 
according to Kenneth, that is exactly what htey are doing.


> 
> --
> Andrew
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Buddha's Dselect' way

[Buddha Buck]

> I get light from Buddha's 're:Why so much hate'
> ,really.
> Clearity in summarizing this debate , as he says 
> 'no newer in this matter from years.'
> Obviously i can only take act of his strong-
> experience in  Debian problems.
> But this , in my opinion, doesn't justify 
> keeping Deselect as it is, without trying to improve it
> concretely.

Well...

dselect is part of the dpkg package.  Recently:

  Ian Jackson, author of dpkg/dselect, has announced that he will start 
doing more development work on dpkg and dselect soon.

  Wichert Akkerman and Ben Collins (et alia) have announced a design 
and technical specification fo DPKGv2, which will presumably replace 
dpkg and dselect.

  Jason Gunthorpe, et alia, have been working on apt, which promises to 
eventually be a replacement for dselect.  Right now, the command-line 
utilities, support library, and a gtk-based front-end (gnome-apt) are 
working, and looking good.  Using apt as a backend to dselect makes 
dselect -significantly- better than it was before.

  In addition, there are various language-specific interfaces to dpkg 
(dpkg-perl, dpkg-awk, dpkg-python) which can be used to write a 
front-end to replace dselect.

So we aren't ignoring the problem, rather there are several projects 
underway to fix it.  But it's hard going.

> pay attention: 
> if we think about it,
> Dselect is the 1st program a newbie uses from the 
> installation of the Distribution, in absolute.
> I think this is too hard for everyone.
> bye , alex.
>  
-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: exmh installation

[Buddha Buck]

> OK this is a new user question... but I checked the man pages, the docs and
> the Web pages on this issue and came up dry.
> 
> According to the manual/web pages on exmh, once I have all the proper
> software installed (I do) I can run
>   wish -f exmh.install
> 
> according to the README.exmh I am to type
>   wish exmh.install
> 
> The exmh file is a script file (see www.beedub.com/exmh/)
> 
> however I can't find the script in the package or on the drive. Would
> someone point me in the right direction here?

Are you using the Debian exmh package, or installing exmh directly from 
www.beedub.com?

On my system (using the Debian exmh package), /usr/bin/exmh is the wish 
script itself, and it is set up so that all I have to do to run it is 
just type:

   exmh

and it automatically runs it as a wish script.

Also, if it is a Debian package, you can check the file 
/var/lib/dpkg/info/.list, and get a listing of all files 
"owned" by .

> 
> /* Mike Lieberman[EMAIL PROTECTED] */
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Good HTML editor for debian Linux?

[Buddha Buck]

Steve Lamb said:
> 
> On Wed, 21 Jul 1999 11:24:46 -0700, Chris Beaumont wrote:
> 
> >Is there anything Linux-friendly with anything approaching the feature
> >set of the program that I am used to, BBEdit on the Power Macintosh...
> 
> No.  

What is there that BBEdit can do that Emacs can't?



-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: "S" file permissions

[Buddha Buck]

> (Sorry for the non-Debian-specific question.)
> 
> Can someone explain what this execute bit means?
> 
> IOW, what is the difference between "s" (suid) and "S" (?)?
> 
> I've tried irc and one guy said it was something to do with an old SysV
> standard.  Someone else said it's "super-suid" or suid without eXecute (but
> how can you have suid without executing?).



It's "suid/sgid without execute".

The permissions on a file are controlled by 12 bits, grouped roughly 
into four groups of three:

  suid, sgid, sticky
  read, write, execute for user
  read, write, execute for group
  read, write, execute for other

suid means that when the file is executed, it inherits the user ID 
associated with the file.  sgid means that when the file is executed, 
it inherits the group associated with the file.  The sticky bit on 
files doesn't mean much anymore, but on directories, it affects how 
file permissions are interpreted in the directory.

When you do an "ls -l", it modifies the display for the execute bits 
for the user/group/other to show the suid/sgid/sticky bit.  For 
instance, the listing

-rwSr-sr-x   1 bobstudent   1024  Feb 22 1998  oddfile

would mean that bob could not run oddfile (no user execute bit set), 
but all other students (group execute bit set) and all other users 
(other execute bit set) could run oddfile.  When "tom", of group 
"staff" ran oddfile, it would run as if it were "bob" of group 
"student" (because suid and sgid bits are set).

Similarly,

-rwxr-Sr-x   1 bobstudent   1024  Feb 22 1998  oddfile2

would allow bob and non-students to run oddfile2, and if tom were 
running it, it would run as "tom" in group "student".

> Can anyone enlighten me?
> 
> (It's not in the info or man pages.)

Check the info listing for "ls".  It says there what s, S, t, and T all 
mean.

> 
> TIA.
> 
> 
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: why so much hate?

[Buddha Buck]

Jason Carley saieth:

> Sure there is room here for opinion. Mine however, as a new user
> of debian, is that dselect can be improved. It is not a slight on
> the fabric of debian merely an observation. Having just ben through
> the process of installation, I feel I can comment with some recency.

There is a lot of room for opinion.  Many people feel there are serious 
problems with dselects interface.  People thought that when I was first 
getting involved with Debian about 4 years ago.  And most developers 
accept that those problems and criticisms have merit.

This discussion unfortunately goes around in circles -- A new user, 
such as yourself, starts using Debian, and raises valid complaints 
about dselect's performance -- unaware that the issue is -very- old 
(bug #1037, titled "dselect user interface (was Re: debian 0.95pl5 
installation)" was filed 24 June 1995, and is still open), has been 
discussed to death, and informing us of them isn't going to help.  Old 
timers reply by effectively saying "Deal with it", or even claiming 
that it's good that it's so complicated.  The new users (more than one 
now) claim that this is the wrong attitude to have, and that the 
problems shouldn't be ignored, etc.  After a while, it boils down to 
"Shut up and code".

The trouble is that no one has gone out and corrected those problems.  
And very likely, for a variety of reasons, no one ever will.  The new 
users who have "shut up and coded" have looked at the code for dselect, 
and have decided not to bother dealing with it.  The old timers would 
prefer to deal with something new (like apt or DPKGv2) rather than deal 
with dselect.  The code is some of the oldest for the project, and has 
not had any major user interface changes in most of that time.  It has 
a reputation of being very fragile -- it will break if modified -- and 
hard to work with.  So most people realise that until something better 
comes around, we are stuck with it.

"Shut up and code", followed by inactivity, isn't the only result of 
the never-ending "dselect interface" debates.  Some people have chosen 
instead to work on dselect replacements -- replacements that don't 
suffer from the maintainability problems that dselect has.  The main 
interface being worked on right now is apt.  Currently, gnome-apt is a 
decent, working packaging interface.  In my opinion, it does not quite 
replace dselect (mainly because I can't easily tell which packages are 
new), but when it is done, it'll be a very good system.  Apt is also 
used as a back-end interface for dselect -- and here, it is superb.  
the "apt" dselect method is a vast improvement in speed, flexibility, 
and reliability over the older dselect methods.
 
> I am sure you are very experienced with debian and can thus use
> almost all of its tools better than I can.  But there are areas
> where dselect can be difficult to follow and somewhat dangerous
> to use if you are not totally familiar with it. I guess it is an
> appropriate proving ground, a test if you will.  But is that
> really the point of a package management application?

No, it isn't appropriate for a package management system to be a 
"test", to make sure that only skilled or dedicated people install and 
use the system.  That isn't its intent, however good it may be at it.

And yes, there are dangerous, poorly documented areas of dselect.  I 
still remember the first time I installed Debian -- there were several 
packages I wanted to get rid of after the default install, so I went 
into the "select" option, cleared all my selections, chose the few 
packages I wanted to remove, fought my way past the dependency screen, 
and proceeded to [R]emove almost my entire system.  Shortly thereafter, 
I installed Debian for the second time ;-).

But until someone writes something better, or fixes dselect, it's what 
we have.



-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: problem with .xsession

[Buddha Buck]

> 
> Hi guys,
> 
> I recently made the switch from fvwm to enlightenment as my default window 
> manager.
> 
> Currently, my .xsession file looks like this and works fine:
> 
>   enlightenment

Yep, that should work fine -- but is a bit bland.  I can see why you 
would want to spiff it up some.

> 
> But when I tried to add other progs at startup using the new .xsession file:
> 
>   enlightenment &
>   swisswatch &
>   xload &
>   xbiff &
> 

Yep, that should work lousily.  I can see why you don't like this 
version ;-).



> it wouldn't work. My .xsession-errors file is as follows:
> 
>   Imlib Init
>   X connection to :0.0 broken (explicit kill or server shutdown).
>   Xlib: connection to ":0.0" refused by server
>   Xlib: Client is not authorized to connect to Server
>   Error: Can't open display: :0
>   Xlib: connection to ":0.0" refused by server
>   Xlib: Client is not authorized to connect to Server
>   Error: Can't open display: :0
> 
> Am I going about this the wrong way, is there a better way to do it?

You are -almost- going about it the right way.

The .xsession file is not treated as a configuration file by X, it's 
treated as a program to run.  Traditionally, it's a shell script, but 
technically it could be any program.  This is why the .xsession file 
has to be executable, for instance.

When the .xsession file exits, that signals X that your session is 
over, and it can/should exit as well.

So what is going on here?

In the original case, when you said

enlightenment

you were saying, in effect "Run enlighenment in the forground, and wait 
for it to finish.  Then exit."  Since .xsession didn't finish until 
after E finished, all was well.

However, in the refined case, when you said

enlightenment &
xload &

you were saying "Run E in the background, and DON'T wait for it to 
finish; then run xload in the background, and DON'T wait for it to 
finish; then exit".  Since .xsession didn't wait on anything to finish, 
it quickly started E, xload, swissclock, and xbiff, then quit.  That 
caused X to quit.

The easiest way to fix this is to simply have the last program in your 
.xession file run in the forground

enlightenment &
xload

Then, when xload exits, X will exit.  When I do it this way, I find 
that I exit my window manager, and xload will still be running, but I 
have to way to kill it!  So what I would recommend would be:

xload &
exec enlightenment

The exec says "replace .xsession with enlightenment, rather than 
running it separately".  It saves one process and probably a miniscule 
amount of memory, so it's not necessary, but it's tidy.


> 
> Thanks alot in advance
> 


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Unidentified subject!

[Buddha Buck]

> Would someone please explain in words of less than two syllables 
> just what steps are required to use "dselect" ?? . I have followed 
> the instructions in the manual at least 20 times so far but it seems 
> there must be something more than "+ " and "-" involved in
> selecting packages to install / uninstall that is probably trivial to
> an expert but totally incomprehensible to a beginner :(

Well...  I pronounce "dselect" with 3 syllables, so it's going to be 
real hard ;-).  I'll try to keep it simple...

Actually, that's about it for selecting packages to install and 
uninstall.  I've been using dselect for 4 years, and I don't know many 
more tricks.

One mistake I made -once- was deciding I didn't want a package, 
unselecting all packages, selecting that one package (selecting the one 
I wanted to uninstall), and then choosing "remove" from the main menu.  
One system re-install later, I had the idea.  Keep selected the 
packages you want on the system, deselect the packages you want removed.

Since the "apt" method automatically removes deselected packages when 
you use "install", perhaps that option shoulc be thought of as "make it 
so".

What I usually do (as an expert, I've been using dselect for nearly 4 
years) is:

I select "update" from the main menu, to make sure I have the most 
recent package listings.

I go to "select", and take a look at what is new, selecting any that 
sound interesting using the "+" key.  I also sometimes decide against 
keeping certain packages, so I deselect them with "-".

Sometimes, this causes a dependency problem, and the dependency 
resolution screen comes up.  Here, I use +, -, _, or = to resolve the 
dependency problem ("=" means "hold", or "don't do anything with this 
package", and prevents upgrading, removal, or installation).  
Sometimes, I decide against my original action (say, installing a 
package would pull in another version of emacs as a side-effect, and I 
don't want that to happen (two installed emacsen is enough)), so I'll 
use "R" to say "revert back to previous state".  Sometimes, I'll decide 
I can live (for now) with the dependency problem, so I'll use "Q" to 
say "Quit the dependency screen, accepting any problems".

When I am done selecting, deselecting, etc, I hit enter to return to 
the main menu.  If there are any dependency problems, I'll (re)enter 
the dependency resolution screen, and deal with it as above.

My cursor has conveniently moved to "install" automatically, so I just 
have to hit return again.  I answer all questions, and the install 
happens.  Easy-like.

Some tips for the select screen:

The "/" key will allow you to do a substring search on the package 
names.  For instance, "/gnome" will search for any package with "gnome" 
in the name.  The "\" will continue the previous search.  This will 
wrap, so repeatedly hitting "\" will rotate through all packages 
matching the search.

The "o" and "O" keys cycle through sort options.  I don't know which 
does which, so I usually hit "o" and "O" until I find the sort option I 
like.  The default (new, updated, obsolete/local, installed, 
uninstalled) is convenient, so I usually don't bother with these.

That's about all I do.  There is a help screen ("?"), which lists these 
commands and more, so that might be more help.

Are you having any particular difficulty?

LAter,
  Buddha


> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: GMT ntp servers

[Buddha Buck]

> Does anyone know the ip's of some ntp servers that are on gmt?  I'm trying to
> get my computer time correctly set to gmt so it will display the correct time.

By spec, ntp servers try to sync to UTC, not GMT.  Since the difference 
is probably not important, that means -any- ntp server -should- work 
fine.

When I set my system time occasionally, I tend to use 
tock.usno.navy.mil.  I -know- they report UTC.

> thanks,
> 
> chris
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Debian goes big business?

[Buddha Buck]

Ben Pfaff said:
> Laurent Martelli <[EMAIL PROTECTED]> writes:
> 
>What about non-developper users ? Shouldn't they have a word to say,
>even if they can't or do not have the time to contribute with code ? 
> 
> They should have `a word to say', and they do--they can subscribe to
> Debian lists and give their feedback and advice, which developers are
> free to follow or ignore.  But they do not, and should not, IMO, have
> the privilege of voting or otherwise setting policy.  Users are not
> developers and shouldn't presume to be.

Until they go through the procedure of registerring as a developer.  
Then they can presume all they want.

On that note:  Are there any developers in the Buffalo, NY area who 
would be willing to meet with me to exchange key signatures?

> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Xdm serving network from my machine!

[Buddha Buck]

Greetings,

  I run Debian "unstable" connected to a dorm network at my school.  
Recently, people have started experimenting with Win95-based X servers, 
which apparantly broadcast messages across the network looking for 
XDMCP servers willing to use their display.  I found about this by 
reading a school-based newsgroup where someone mentioned getting a XDM 
login screen from my machine.

  At the very least, I consider this a security problem.  I don't want 
to have to run x via startx, but I -really- don't want to offer login 
screens to everybody on the local net.  If that is how xdm is 
configured by default, I'll definately file a bug on it.

  How can I configure xdm so that it will -only- serve local servers?

Later,
  Buddha

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Date in mail headers

[Buddha Buck]

t servers out there (and minds ;-)... I'm not going
> to, neither now nor in future to comply in making my software 7-bits just for
> those servers, they'll just have to break, until the administrators find it 
> with
> in their time to comply to evolution.  These servers are out-dated by 50
> years.  :-)

Not really.  The current -standard- for email transmission is RFC821 
(also about 15 years old), and that explicitly states that SMTP is 
7-bits only.  ESTMP, MIME, and other standards-track protocols are 
designed to try to work around that problem, but not all sites use 
ESTMP yet, etc.

> 
> 
> Just me
>  
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Minimizing Mail Packages?

[Buddha Buck]

> Hello All,
> 
> Connected intermittantly to internet using PPP to an ISP who uses POP3
> for mail.  I am attempting to minimize the number of packages needed
> to run mail.  It seems there are many mail packages but not a great
> deal of information on there interrelationships.

Basic interrelationships:

There are three different type of mail packages: Mail Transport Agents 
(MTA), Mail Delivery Agents (MDA), and Mail User Agents (MUA).

The job of the MTA is to move email from one machine to another.  
Sendmail, exim, zmailer, qmail, smail are all standard MTAs.  I also 
consider fetchmail (and fetchpop) as an MTA, although I believe this 
view to be non-standard.  You usually only have one MTA running on a 
system, except for fetchmail.

The job of the MDA is to place the mail where the user can find it, 
once the MTA system gets it to the machine where it gets delivered.  
Deliver and procmail are both used as MDAs.  Many MTA's include basic 
MDAs, and some MUAs also come with MDAs.  mh, an MUA, ships with 
slocal, an MDA that can filter and sort mail.

The job of the MUA is to allow the user to read, file, compose, and 
send mail.  Usually, the MUA takes mail from where the MDA leaves it 
and stores it elsewhere.

> Am running on X the following Debian mail-related packages : exim,
> fetchmail, mh and exmh with subsidiary packages of metamail and 
> mime-support.  I know one needs both mh and exmh to do mail 
> processing if exmh is used. Also POP3 support is needed for mail to 
> and from the ISP.

POP3 is needed to get mail FROM the ISP.  POP3 is not a protocol for 
sending mail, just receiving it.  You need to use some other MTA to 
send mail.  If you setup works, it probably is because exim is doing 
that job.

With the exception of qmail instead of exim, your mail packages are 
identical to mine.  I also have procmail installed, but I haven't 
converted my slocal setup to procmail yet, so I'm not actually -using- 
procmail.  I use fetchmail for all incoming mail, and qmail for all 
outgoing mail.

> 
> Are exim and fetchmail also required? Can one one just use mh
> and exmh by themselves to do all mail composing and handling as well as
> receiving and sending mail via POP3 to the ISP?

I believe that mh and exmh can be configured to get mail via POP3, but 
I haven't bothered to figure out how.  I don't believe that mh has the 
capability to send mail without an MTA.

Why do you want to minimize the number of packages you install?

If you truely want to minimize the number of packages, you could remove 
-all- the packages you listed (with the possible exception of the two 
MIME packages), and use Netscape Mail.  It will handle receiving mail 
via POP3, sending it via SMTP, etc.  I wouldn't recommend it, though (I 
don't like Netscape as an all-in-one package, especially when there are 
alternatives).

> 
> I tried mutt and think it's great for subsidiary usage.
> 
> Victor
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: naming convention question

[Buddha Buck]

> I wrote:
> > But why is it good to choose names that don't reflect *anything*?
> 
> Scott K. Ellis writes:
> > They do, they are the codename for the version,...
> 
> What secrets are being protected by this code?

None.  Codes don't exist just to make things secret.  Code names can 
and do exist for other reasons as well.  Codes serve to prevent 
problems that occur when the "proper" name is used instead.  Commercial 
codes aren't secret, but cut down on the time it takes to transmit 
information.  Similarly, code names for software in development help 
keep different versions and products separate in the developers minds.

In this case, code names are used to prevent problems which we've run 
into in the past, with people grabbing the wrong distributions, with 
thrashing mirrors, and so on.

> 
> > ...similar to the codenames that Microsoft...
> 
> Oh.  Well, if *Microsoft* does it, it *must* be a good idea.
> 
> Obscure code names are ok in closed development where the only people who
> need to know the names deal with them all day every day and so will learn
> them quickly.  In open development, they are confusing.

To a large degree, there are only 2 or 4 names most Debian users need 
be aware of: stable and unstable, and possibly contrib and non-free.  
Two of these are symbolic links to the code-named versions.  These -do 
not change- name, although they change in contents.

Unstable was deliberately named that to -discourage- people from using 
it.  When J. Random Linuxer comes to the Debian FTP site, we want him 
to look at stable or possibly Debian-1.3.1.  If they are scared that 
"unstable" will crash their system (and at times, it will crash your 
system, if you aren't careful), and avoid it, then Debian won't end up 
looking bad for having systems that will crash your system.

Yes, we want people to use unstable (be it buzz, rex, bo, hamm, or 
whatever the next code name is), because that way we can catch bugs 
before they end up in a released version.  But we also want those that 
do to know what they are getting into -- that there are risks in using 
potentially buggy software.  By choosing names that don't imply 
versioning or quality of release, that are intentionally meaningless, 
we effectively require people to go to an effort to use it, and that 
keeps people who aren't paying attention safe.

I am not a Debian developer -- I have not submitted any packaged for 
the Debian system -- but I do know how fast info like the new codenames 
becomes known.  Some names, like hamm, were the topic of discussion 
when they were chosen (as mentioned elsewhere, "woody" was thought of, 
but rejected).

To a certain degree, Debian is a more open development system than the 
Linux Kernel.  No single person is responsible for what goes into the 
system -- that is divided up amongst nearly 200 developers -- whereas 
with the kernel, Linus himself says yea or nay to every patch 
submitted.  Out works-in-progress are open to all to look at or use, 
for good or worse.
> 
> > The sequence (buzz, rex, bo, hamm) follows names of characters in the
> > Pixar animated movie, "Toy Story".
> 
> Cartoon character names are somehow supposed to be mnemonics for Debian
> releases?

No, they are supposed to be names of Debian releases.  Names don't 
necessarily mean anything about the object named.  That you are named 
"John" tells me very little about you.

So far, the only name I've seen you suggest was "unreleased-1.3" and 
"unreleased-2.0" for what is currently called "bo" and "hamm".  Can you 
come up with better names than bo and hamm that meets all of the 
following criteria:

1) the name cannot be changed once decided, since this will cause
   unwanted thrashing of mirror sites.  this means:

   1a) It can't refer to release status, since a change in release 
status
   would cause a change in the appropriate name.
   1b) It can't refer to a date, since dates tend to be too variable in
   Debian anyway.

2) the name must not encourage people to use it directly, since we have
   run into problems in the past of people publishing releases that
   weren't ready for release, because the name made people think it
   was ready (the Debian-1.0 fiasco).  This means that the name
   most definitely can't refer to 


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: naming convention question

[Buddha Buck]

John Hasler writes:
> Buddha Buck writes:
> > It was seen that one reason for this was that someone looking at the FTP
> > site, seeing a directory with a numbered version would think that that
> > version was ready for release.  A policy decision was made to name
> > releases while in development, and only number them when released.
> 
> "unreleased-1.3" and "unreleased-2.0" would be more useful and less
> confusing.

Maybe, but it makes life hard on mirror sites.

Before we went to the current scheme, there was a time when the main 
directories were "stable" (i.e., released, ready to go, and in theory, 
unchanging), and "unstable" (i.e., a moving target, a future release, 
not yet fully ready).  When "unstable" got renamed "stable", all hell 
broke loose at mirror sites.

Mirror software can't tell the difference between a renamed directory 
and a new directory with new files in it.  So when "unstable" vanished 
and "stable" changed drastically, the mirror sites dutifully downloaded 
all the new stuff under stable (which was already under unstable, but 
the mirror sites couldn't tell), and then deleted the files it already 
had under unstable.  This tied up a tremendous amount of network 
bandwidth, and everybody involved complained bitterly (and for good 
reason).

Now we use symbolic links to manage the release names (stable currently 
points to bo, and unstable points to hamm).  When we release hamm, 
stable will change to point to hamm, and the mirror sites only have to 
deal with one or two small symbolic link changes, not downloading the 
entire distribution again.

Symbolic links are crucial for managing the distribution.  A month ago 
or so, we had three distributions on ftp.debian.org: rex, bo , and 
hamm.  Since hamm is bigger than bo, and bo was the first distribution 
to require 2 CD's to distribute, without symbolic links between the 
three distributions the whole mirror site would be over 1.5GB in size.  
By using symbolic links, we can usually eliminate a major chunk of that 
-- when a new distribution is created, it is initially populated with 
symbolic links to the old distribution (which makes the new 
distribution quick to mirror, and small in size), and as the packages 
are upgraded, the new distribution fills up.  If we renamed the base 
directories (as we would when "unreleased-1.3" became "Debian-1.3"), a 
lot of symbolic links would break.

Thus there are two good reasons why the distribution _name_ (be it rex 
or bo or unreleased-1.3) shouldn't change.  Because of that, it is good 
to choose names that don't reflect the release status of the 
distribution.


[EMAIL PROTECTED] said:
> One question though: Why's hamm called hamm/hamm/ on the ftp archives?
> What for? 

In addition to the main distributions (rex, hamm, bo) Debian has also 
packaged programs which don't meet our free software guidelines.  Those 
are placed in the "non-free" and "contrib" directories, which is 
outside of rex or bo.

When bo was nearing release, while rex was "stable", some people 
complained that some of the non-free and contrib packages had 
dependencies on things in unstable.  This was threatening to force 
people into using unstable when they wanted to remain in stable.  So 
with hamm, it was decided to move non-free and contrib under hamm (in 
hamm/non-free and hamm/contrib) so that non-free packages that depended 
on hamm main packages could be kept separate from non-free packages 
that were safe to use with bo.  what would have been the hamm main 
distribution became hamm/hamm.  Offhand, I don't know why it wasn't 
hamm/main.


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: naming convention question

[Buddha Buck]

John Hasler writes:
> Buddha Buck writes:
> > It was seen that one reason for this was that someone looking at the FTP
> > site, seeing a directory with a numbered version would think that that
> > version was ready for release.  A policy decision was made to name
> > releases while in development, and only number them when released.
> 
> "unreleased-1.3" and "unreleased-2.0" would be more useful and less
> confusing.

Maybe, but it makes life hard on mirror sites.

Before we went to the current scheme, there was a time when the main 
directories were "stable" (i.e., released, ready to go, and in theory, 
unchanging), and "unstable" (i.e., a moving target, a future release, 
not yet fully ready).  When "unstable" got renamed "stable", all hell 
broke loose at mirror sites.

Mirror software can't tell the difference between a renamed directory 
and a new directory with new files in it.  So when "unstable" vanished 
and "stable" changed drastically, the mirror sites dutifully downloaded 
all the new stuff under stable (which was already under unstable, but 
the mirror sites couldn't tell), and then deleted the files it already 
had under unstable.  This tied up a tremendous amount of network 
bandwidth, and everybody involved complained bitterly (and for good 
reason).

Now we use symbolic links to manage the release names (stable currently 
points to bo, and unstable points to hamm).  When we release hamm, 
stable will change to point to hamm, and the mirror sites only have to 
deal with one or two small symbolic link changes, not downloading the 
entire distribution again.

Symbolic links are crucial for managing the distribution.  A month ago 
or so, we had three distributions on ftp.debian.org: rex, bo , and 
hamm.  Since hamm is bigger than bo, and bo was the first distribution 
to require 2 CD's to distribute, without symbolic links between the 
three distributions the whole mirror site would be over 1.5GB in size.  
By using symbolic links, we can usually eliminate a major chunk of that 
-- when a new distribution is created, it is initially populated with 
symbolic links to the old distribution (which makes the new 
distribution quick to mirror, and small in size), and as the packages 
are upgraded, the new distribution fills up.  If we renamed the base 
directories (as we would when "unreleased-1.3" became "Debian-1.3"), a 
lot of symbolic links would break.

Thus there are two good reasons why the distribution _name_ (be it rex 
or bo or unreleased-1.3) shouldn't change.  Because of that, it is good 
to choose names that don't reflect the release status of the 
distribution.


[EMAIL PROTECTED] said:
> One question though: Why's hamm called hamm/hamm/ on the ftp archives?
> What for? 

In addition to the main distributions (rex, hamm, bo) Debian has also 
packaged programs which don't meet our free software guidelines.  Those 
are placed in the "non-free" and "contrib" directories, which is 
outside of rex or bo.

When bo was nearing release, while rex was "stable", some people 
complained that some of the non-free and contrib packages had 
dependencies on things in unstable.  This was threatening to force 
people into using unstable when they wanted to remain in stable.  So 
with hamm, it was decided to move non-free and contrib under hamm (in 
hamm/non-free and hamm/contrib) so that non-free packages that depended 
on hamm main packages could be kept separate from non-free packages 
that were safe to use with bo.  what would have been the hamm main 
distribution became hamm/hamm.  Offhand, I don't know why it wasn't 
hamm/main.


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: naming convention question

[Buddha Buck]

> What is bo? hamm?  Could someone explain these naming conventions to me,
> please.
> 

Bo is a code name for the Debian 1.3 release.  Hamm is a code name for 
the Debian 2.0 release, currently in development.

Some time ago, Debian ran into a problem when a not-quite-ready 
development version of the distribution was downloaded and sold on CD.  
It was seen that one reason for this was that someone looking at the 
FTP site, seeing a directory with a numbered version would think that 
that version was ready for release.  A policy decision was made to name 
releases while in development, and only number them when released.

The current naming schema we are using is the names of characters from 
the Pixar computer animated feature film "Toy Story".

> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: make-kpkg problem

[Buddha Buck]

> 
> I extracted kernel-source-2.0.30_2.0.30-7.deb so that I can home-brew a
> kernel.  There is a problem in that when I do a "make-kpkg clean" it
> actually does a "make mrproper" and amongst other things I lose my
> include/asm link.  A "make clean" works as expected.

What include/asm link?

If you are talking about a link from /usr/include/asm to 
/usr/src/linux/include/asm-i386 and from /usr/include/linux to 
/usr/src/linux/include/linux, etc, then the solution is simple:  Those 
links should never have been made in the first place.  The README that 
comes with the kernel sources is in error.

The issue is discussed in the libc5-dev or libc6-dev packages' 
FAQ.Debian file in the /usr/doc hierarchy.  If you have the libc5 or 
libc6 development packages installed, check the FAQ.  Even Linus 
himself now says that while those links were a good idea at one point, 
they no longer are, and with libc6, they are -decidedly- the wrong 
thing to do.

For libc6, the API to the library and the API to the kernel were 
intentionally divided, so that the library could provide support for 
services the kernel doesn't yet have -- but will -- without breaking 
programs that need to use those services (example:  libc6 has support 
for more than 32 signals.  The kernel interface allows only 32 signals. 
 When the kernel allows more than 32 signals, all you have to do is 
update your libc6, not recompile every program in existence because a 
very common, fundamental, data structure changed).  Making those links 
could cause programs compiled under libc6 fail, because they are using 
the wrong interfaces.

If that wasn't the include/asm link you were referring to, I apologize 
for subjecting you to this rant.


If you made those links, you might want to re-install the libc 
development package so the proper
> 
> Is this intended?  I have looked at the code but cannot spot the reason
> for this behaviour.  Using kernel-package_3.35.
> 
> The docs say nothing about "make-kpkg dep".  What is the correct
> procedure here?
> 
> Lindsay
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Lindsay Allen   <[EMAIL PROTECTED]>  Perth, Western Australia
> voice +61 8 9316 2486modem +61 8 9364-9832  32S, 116E
> http:  http://rolf.ece.curtin.edu.au/~lindsay   debian linux
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Certification

[Buddha Buck]

> 
> There are many models that could be used to set up the certification;
> it could even be an application that could be downloaded.  As for
> studying for it -- one approach would be to select questions from a
> large database of possible questions.  The database of possible
> questions could be public, if the size of the database makes simple
> memorization impractical.  I believe this is the approach here in the
> US for written pilots' tests.

I know that US Amateur Radio License written exams are done precisely 
that way, a large public pool of questions (with answers, to ensure 
fairness in the grading) out of which the individual tests are 
generated.  And there are Amateur Radio licensing books available that 
do little more than go over the question pool explaining the correct 
answers -- no theory, just review of the questions and answers.

If it was worth a job, I could easily write an application that would 
generate, administer, and correct such a "certification" test.  Then, 
by drilling at it, I could easily pass any such test in month.  Two 
months if the test is in Italian (a language I don't speak).  I might 
have no comprehension of the material, but I could get certified.  And 
given the presence of the Amateur Radio licensing books I described, I 
don't think I'm alone.

If any certification happens, I think there needs to be a "practical" 
part of the certification process -- have them install Linux on two 
"identical" systems (with one SCSI terminator missing, just for fun), 
networked via Ethernet, one acting as a router to the Internet at 
large, etc.  Nothing too complicated, but touching on all the areas a 
"certified professional" should know how to deal with.  I also think it 
should be coordinated by someone with a known name, like Linux 
International or SSC.  (LI would be a good choice, because any 
certification fees would go towards Linux development).
> 
> Of course, however the thing would be done -- it would be sure to
> infuriate someone.  What is important to include, what is a valid
> question, why didn't I pass when I'm a linux god -- I'm not sure that
> a sane person would get into building it.  In an earlier incarnation,
> I was testing coordinator for the public school system in the Northern
> Mariana islands, and I assure you that such issues can take a lot of
> thought and time.

I can agree with this, whole heartedly.
> 
> Maybe somebody should hack together something and release it as a toy
> to see if enough people are really interested.  I whipped up a little
> kludge of tutorial/test program in C last semester; after doing that,
> I think that perl or tcl/tk would be a better approach, since it's
> mostly text manipulation.  

I threw together a quick drill program for myself (so I could pass a 
final exam) in perl about a year ago.  It isn't hard, and Perl is a 
good choice for it.

> 
> For the forseeable future, having certification in solaris or whatever
> will be a bigger job getter, but I wish we had a certification to
> advertise our love of free software.
> 
> steve

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: xinitrc vs. xsession (was Re: Window Managers)

[Buddha Buck]

> On Thu, 3 Jul 1997, Gary L. Dolan wrote:
> 
> > I hate to think that my version of 1.2 (now 1.3) is idiosyncratic, but the
> > global xsession and the global xinitrc files are identical. I have attempted
> > in my own halting way to parse my way thru the file(s), and the result 
> > appears to me to be that some resource files do not get read. I would be
> > pleased if someone would correct my impression if I am wrong.
> 
> 
> My second point is (possibly a bug). Shouldn't /etc/Xsession have $startup
> defined as .xsession and /etc/X11/xinit/xinitrc have $startup defined as
> ..xinitrc? At the moment, both files have $startup defined as .xsession. Is
> this a bug?

On my system (using XFree86 3.3-3, except for xbase, which is 3.3-2), 
/etc/X11/xinit/xinitrc is a symbolic link to /etc/X11/Xsession, which 
is how you described it.  So the global xsession and the global xinitrc 
are in fact the same file.

My $HOME on my system only has a .xsession, but on other accounts, I 
routinely have .xinitrc a symlink to .xsession, so I only have to deal 
with one startup file.

Perhaps it should be better documented that .xsession and 
/etc/X11/Xsession are the Debian way to do it.  When I was figuring 
this out months ago, it was a tedious matter of chasing through man 
pages to find the config files that specified the start-up scripts, 
which were symlinks to the real scripts, etc, all to find out that I 
was looking for .xsession.


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: choosing a linux distribution

[Buddha Buck]

Matt,

I apologize if you seem to have been hit recently by the Debian 
Advocacy Brigade, but I -do- want to add one thing myself.

Craig Sanders said:
> 
> RE: your web page at http://mkracht.aye.net/~matt/linuxdist/
> 
> > Debian
> > 
> >Web: http://www.debian.org/ 
> >FTP: ftp://ftp.debian.org/ 
> 
> You've got this part correct, at least.
>

[and then goes on to state some problems he had with your review
 of Debian]

I think your page could be improved -- and made significantly more fair 
in the process -- if you included with each distribution listed the 
version number of the distribution you were reviewing, and where you 
got the distribution.  As Craig mentions, there have been some 
notoriously bad Debian CD's made by some companies (He mentions 
Infomagic, and other companies have also been mentioned on the Debian 
mailing lists.  I choose to not name names).

Many of the problems you cited with Debian (6 disk install, difficult 
CD-ROM install, older versions of programs) exist with Debian 1.2, but 
are fixed with Debian 1.3.  Debian 1.3 ships from at least one company 
in a Debian-approved 2 CD set that is bootable -- for a no-floppy 
install.  The time between 1.2 and 1.3 allowed for many programs to be 
upgraded and tested before 1.3's release.  Other problems (like 
dselect's user interface) are being worked on.

It is unfortunate that your apparent review of Debian 1.2 became known 
to the Debian community so shortly after the release of Debian 1.3, 
especially without being identified as Debian 1.2.  For many of us, the 
Debian you reviewed isn't the Debian we use on a daily basis.  As Craig 
mentioned, newer versions of most of the packages are available in 1.3, 
or from the "unstable" distribution on all of the Debian distribution 
mirror cites.  The latter is updated on a regular basis.

A 2-disk Debian CD set made from the "Official" Debian 1.3.0 ISO9660 
disk images is available for $4.95 from Linux Systems Labs (see 
http://www.lsl.com).  Offhand, I don't know of any other Debian vendors 
offering 1.3.0 from the official disk images.  I would encourage you to 
pick up a copy and re-evaluate Debian.  If you still don't like Debian, 
you are entitled to your opinion.

In the mean time, please update your web page to state what versions of 
Slackware, Red Hat, and Debian you are reviewing.
 



-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Xfree33

[Buddha Buck]

> > Hi,
> > I recently upgraded my Xfree setup to 3.3 from unstable. But now I seem
> > to have some problems.
> >Only the user that runs the xserver (startx) can run apps on it
> > any attempt to run an app by another user is refused. eg below;
> >
> ># xhost
> >
> >Xlib: connection to ":0.0" refused by server
> >Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> >xhost:  unable to open display ":0.0"
> ># 
> 
> Isnt this a "feature"? Did you try "xhost +"? My root-user also must not
> open windows on my (user-)screen. "xhost +" disables this.

xhost + allows more than that.

xhost + allows any user on any machine connected via a network to do 
anything to your X screen.  Including record every key stroke (you 
don't type in passwords, do you), pop up windows, etc.

At least "xhost +machinename" allows only any user on a given machine 
to do that.

Take a look at the man page for xauth, for a safe way to do that.  
Basically, when the system is running, it creates a small "magic 
cookie" that only it knows, that only you can read.  When some program 
tries to connect to the server, it asks for that magic cookie.  If the 
program can't provide it, the program can't talk to your server.  If 
you want other people (like root, or yourself logged into another 
machine, or your friend next to you) to be able to talk to your screen, 
you can provide them with a copy of the cookie.  It is much secure than 
opening up your machine to every user in the world!


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Xemacs vs. Emacs

[Buddha Buck]

> Hello,
> 
> I remember seeing some messages in this list not long ago saying that
> the maintainers of these two packages had agreed on a format that would
> allow both to coexist in the same machine. What's the status of this?

It works.  The XEmacs19 package and Emacs package from unstable (what 
will be Debian 2.0) coexist perfectly fine.  Until this morning I did 
have both of them installed.

If you want to try XEmacs, I'd suggest grabbing that installation

However, XEmacs19 as it currently stands in unstable doesn't work with 
the XFree86 3.3 binaries also in unstable.  So if you use dselect to 
install it via FTP, make certain that you do -not- upgrade your X 
packages.  XEmacs19 works fine with XFree86 3.2.  I'll probably 
reinstall XEmacs19 when the onflict between it and X is resolved.

> 
> I'd like to try Xemacs but I don't want to give up my old friend Emacs!

XEmacs is just like Emacs, but a bit prettier, with a few new features, 
and only slightly slower.
> 
> -- 
> Pedro I. Sanchez
> 
> 
-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Release Date for Debian 1.3.1

[Buddha Buck]

Dale Scheetz said:
> On Sun, 15 Jun 1997, Lawrence Chim wrote:
> 
> > What do you expect in Debian 1.3.1?
>
> The major push for 1.3.1 is to fix problems with the XFree86 packages.
> They are currently in the process of being upgraded from 3.2 to 3.3. The
> first round of testing showed up some minor problems that are being fixed
> as we speak. 

Is the "upgrading to XFree86 3.3 makes Xemacs 19.15 dump core" problem 
one of the minor problems?  The two things I've been hearing people ask 
for the most in 1.3.1 is Xemacs 19.15 and XFree86 3.3.  If these two 
remain incompatable, a lot of people are going to be unhappy.

Unfortunately, I've not the expertise or free disk space to try to 
solve either problem.

> 
> Luck,
> 
> Dwarf
> -- 
> _-_-_-_-_-_-  _-_-_-_-_-_-_-
> 
> aka   Dale Scheetz   Phone:   1 (904) 656-9769
>   Flexible Software  11000 McCrackin Road
>   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308
> 
> _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Making kernel using "make install"

[Buddha Buck]

> 
> On Fri, 17 Jan 1997, Victor Torrico wrote:
> 
> > When making a kernel 2.0.27 I do the following:
> > 
> > make mrproper
> > make config
> > make dep
> > make clean
> > make zImage
> > make modules
> > make modules_install
> > make install
> > 
> > The "make install" is not documented in the "/usr/src/linux" directory
> > as far as I know but when it is used it seems to put everything from the
> > new kernel where it belongs properly in the "/boot" directory and lets
> > you update lilo as well. I just tried doing this for the hell of it and
> > it seems to work very well. 
> 
> Ah-hah!  Finally, what seems to be a simple sequence of commands for
> building a new kernel.  But what must I do to ensure that my old kernel
> will continue to work (with its modules), especially if lilo wants to
> complain that the new kernel is too large?  I assume that certain files
> and directories ought to be backed up or renamed or something, but some
> pointers to "safe" kernel testing would be very helpful!

What I do when I want to upgrade my kernel (which I will be doing later 
today... 2.0.28 is out) is something like this (assuming that 
linux-2.0.28.tar.gz is already in /var/tmp, but it could be anywhere, 
really):

tar xzvf linux-2.0.28.tar.gz
cd linux
cp /usr/src/linux/.config .
make-kpkg -revision custom.1.0 kernel_image kernel_source
cd ..
# rm -rf linux linux-2.0.28.tar.gz
dpkg --install kernel-image-2.0.28_custom.1.0_i386.deb
dpkg --install kernel-source-2.0.28_custom.1.0_i386.deb
dpkg --remove kernel-source-2.0.27_custom.1.0_i386.deb
dpkg --remove kernel-image-2.0.26_custom.1.0_i386.deb

and that's it.  My /etc/lilo.conf has entries for /vmlinux and 
/vmlinux.old, which are symbolic links that the post-install script for 
the kernel-image package maintain properly (and reruns lilo as well).  I 
keep one set of installed kernel sources and two installed kernel 
images.  All you need for this is to install the kernel-package package, 
and it should work.

Read the docs in /usr/doc/kernel-package for more information.

> 
>   --Pete
> ___
> Peter J. Templin, Jr.   Client Services Analyst
> Computer & Communication Services   tel: (717) 524-1590
> Bucknell University       [EMAIL PROTECTED]
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: Can any one recommend a mailreader...

[Buddha Buck]

> EXMH is a powerful X-based reader that meats all of your criterion (except 
> perhaps filename completion as I am not quite sure exactly what you are 
> talking about here).

While I use Exmh, and I would highly recommend it myself, as far as I 
can tell, it meets none of the asked for criteria.

It is Tcl/tk based, not curses, so it requires X.  While it can handle 
multiple folders and can do automatic sorting, it is best (IMHO) used 
with slocal or procmail to handle the sorting for you.  Even with its 
native sorting, you have to edit an external file to handle the sorting 
for you.  It doesn't need filename completion because it is all 
point-and-click with file selectors and folder lists, etc.  

My suggestion would be a combination of procmail (to handle sorting) and 
elm.  It doesn't do all you want or all that exmh does, but I'm happy 
with it when I'm away from my home machine.

> 
> > other than pine. I would like a simple curses based
> > reader that easily allows one to configure the mail to read
> > automatically into separate folders depending on
> > the address it came from, allows filename completion
> > when reading files in or when going to different folders,etc.
> > 
> > Preferably any configuration should be built into the interface
> > itself, i.e. it would be nice to avoid editing a configuration 
> > file directly. 
> > -Walter
> > 
> > The system I intend to run it on is the university system running
> > slackware.
> -- 
> John Goerzen  | Running Debian GNU/Linux (www.debian.org)
> Custom Programming| 
> [EMAIL PROTECTED] | 
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Debian and Windows95

[Buddha Buck]

Greetings,

Currently, I am running primarily Debian Linux (unstable), but I have a 
160MB bootable MS-DOS partition that I am using for one or two MS-DOS 
programs that don't have Linux counterparts (such as AutoCad).

My DOS setup does have some problems, however.  Because I've paid much more 
attention to the Linux-side of my system, I haven't upgraded the DOS 
side when I got new hardware.  MS-DOS can't talk to my SCSI CD-ROM 
drive, nor my sound card, nor my SCSI ZIP drive, etc.  

I was thinking of upgrading my MS-DOS setup to a Windows95 setup, but I 
have some concerns.  To me, maintaining the working Linux setup is 
-most- important.  If I can't do that, then I will forgo Win95.

All of the Linux+Win95 documentation I have talks about adding Linux to 
a working Win95 setup.  I'm interested in doing the reverse.  I have 
heard that Win95 likes to play around with the MBR and partition tables 
to make sure that it is the only or primary OS on the system.  How can I 
make certain that I don't lose anything critical when installing it?

Has anyone else done this?  What can I expect?

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: Please do not use Qt (fwd)

[Buddha Buck]

e)?  Not a problem with the GPL, since you can modify 
GPLed programs at your will.  On the otherhand, since the Windows Qt 
libraries are proprietary without source, this seems to be evidence 
that the authors of Qt do -not- want you to be able to port it to new 
platforms.  This is in direct violation of the letter and spirit of the 
GPL.
> 
> How does it come that you are talking about stuff you do not understand.
> 
> I personally would appreciate something like alladins license for
> ghostscript beeing applied for Qt.
> 
> But Qt is still a very new, but promising project.
>
 
-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: How to choose safe configuration at boot time?

[Buddha Buck]

> On Wed, 20 Nov 1996, Buddha M Buck wrote:
> 
> > (that'll teach me to use a 11-character root password). 
> 
> Unless you changed your system, only the first 8 have any significance.
> (Part of the shadow password suite allows extended length passwords.)

Yes, I know that "bigpassw" is equivilant to "bigpassword", but I still 
-think- of my password as "bigpassword".

If the shadow suite changes this behavior, I might consider switching 
to it.

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: cannot compile 2.1.5 due to /usr/include/linux being in libc5-dev

[Buddha Buck]

> On Sun, 27 Oct 1996, Philippe Troin wrote:
> 
> 
> Almost every kernel that have looked in (including 2.0.x) looks in
> /usr/include.

This is wrong.
> 
> Anytime a file needs an include file it it referenced lise this:
> 
> #include 
> 
> This is /usr/include/linux/whatever.h.  It is assumed by Linus,
> et. al., that /usr/include/linux, /usr/include/asm, and
> /usr/include/asm-i386 will all be symlinks to the actual kernel
> source.

I just checked the source tree for 2.0.21, and what it does is sets a 
variable HPATH in the makefile to be ${TOPDIR}/include, where ${TOPDIR} 
is the current working directory from which make was run.  It then adds 
-I${HPATH} to the CC variable, so that if I had my Linux source tree in 
/var/tmp/linux (which I do), it would search /var/tmp/linux/include/linu
x for whatever.h before even looking in /usr/include/linux.  It is my 
understanding that the kernel sources are designed to be as independant 
of the system header files as possible, and tries to make no 
assumptions about what, or where, the standard system headers are.


>  The only solution for me has been to move the offender out of
> the way and temporarily create the expected symlinks while I compile
> the kernel and then put everything back when I am done.  I have put
> this in a script since I try to keep up with the 2.1.x kernels and
> have to compile somewhat frequently, but this is still kind of a
> pain.  Maybe someone else can tink of some better solution/compromise.

I haven't gone to 2.1 yet (the horror stories of device drivers 
crashing because of the memory management reorganization scare me), so 
I don't know if things have changed in this regard.

> 
> Erv

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: Opinions on Linux Journal article

[Buddha Buck]

[Note:  I'm moving this from debian-changes to debian-user]

> '[EMAIL PROTECTED] wrote:'
> >
> >Hello,
> >
> >i was wondering what were the reactions of list members to 
> >this article.
> 
> I thought it was well done.  It showed our strengths and weaknesses.

Which article?  Which issue?

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: Can't do setuid

[Buddha Buck]

> I need the ability to run my dialing script as root since the script
> makes hostname, domainname, and /etc/resolv changes.  
> 
> It appears that Debian Linux does not have setuid capability.  Is this a
> feature that I can turn on through a configuration file?

No.  There is no way to turn on the ability to have setuid scripts.

There are severe potential security problems associated with setuid 
scripts.  As such, the capability is explicitly -not- allowed in the 
Linux kernel.

Setuid program, however, are a very useful tool.  Su, for instance, 
-must- be setuid root to do its job.  It isn't a script, however.

There are several ways to do the same job.  One of the most common is 
to write a small setuid C program that calls the script for you.

> 
> Do all Linux distributions (Slackware, Redhat, etc) have this
> restriction?  Which distributions allow suid?

No linux distribution allows it.  It is inherent in the kernel.
> 
> Where does the restriction take place (the kernel or an executable
> file)?

The kernel.

> 
> Suid programs work on Sun Unix, but it don't seem to work here:
> 
>-rws--x--x   1 root users1413 Oct  8 14:18 dial-att
> 
>> dial-att
>Can't do setuid
> 
> At present I have to su to root in order to dial.  This is an
> inconvenience and will not work for other user accounts.  I am aware of
> the programs available that perform the equivalent of setuid but the
> issue here is why isn't the setuid function implemented (apparantly)?



> 
> Jim
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: The *"'($^"'( list... and Xdm login

[Buddha Buck]

> a simple question about xdm : 
> 
>   my root password is ... say "toto". when i try to login
>   with password "totoxxx", it works. The xdm login
>   only compares characters from the begining, to the end of
>   the password. is it normal ??? 

It shouldn't be that way for your root password as "toto", but let's 
say your root password was "wizardoz".  Then "wizardos_is_a_fraud" 
would work, because anything past 8 letters is ignored.

In fact, the scenario that you describe -couldn't- happen, unless login 
on xdm was severely broken (try using "dorothy" as a password instead 
of "toto",  if you can get in, then you know it's broken :-( ).  What 
login (and xdm, etc) do is take the passwork you type, hash the first 8 
characters with a one-way hash function, and compare that with the 
stored, previously hashed password.  The original password is lost -- 
it exists in the memory of passwd, login, xdm, and so on the bare 
minimum they need to do their job, then it is destroyed, to prevent 
snoopers.  Since all xdm has to play with is a previously hashed value, 
it -can't- tell that the password "toto" is only 4 characters long.  It 
can only tell that "totoxxx" hashes to the same value as "toto".  Given 
the way that the hash function is designed, I think (but I am not 
certain) that that is mathematically impossible (but at the least, it 
it highly improbable).

I just tried it on my system, and I was able to su to root by using the 
password "scarecro" instead of the complete "scarecrow" (and, no, that 
isn't the root password on my system, but mine is longer than 8 
characters), so the 8 character limit is still live on Debian systems.

Theoretically, we should be able to "pay no attention to the crypt() 
behind the login", but maintaining compatability with other systems 
forces us to use the same crypt() Unix has been using for decades.  
This limits us to only 8 significant characters.  How many utilities 
would have to be changed to implement the following password logic:

  If the stored hash is 13 characters long, use crypt().  
  If it is 32 characters long, use md5sum().  
  Otherwise, fail.

This would allow us to retain backwards compatability while potentially 
increasing the security of the system by allowing arbitrarily long 
passwords.

> 
> thanks,
> 
> Richard
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]

Re: where's man ??

[Buddha Buck]

> 
> I just installed Debian 1.1 and I logged on as root. First thing I notice,
> there are no editors installed. Not one. You would think this would be a
> "required" thing... 

If you just installed the 5 floppy disk base installation, there is a 
lot that is missing.  Only one editor (ae) is installed, very minimal 
(if any) documentation is there, and so on.  You need to install the 
-rest- of the system (from CD, other floppies (don't know how well that 
will work, given that some packages are bigger than a single floppy), 
or over the network.  I believe the minimums needed to do an FTP-based 
install over ethernet is on the base disks, although Bruce Perens would 
know for sure.

> 
> another thing... 'man' doesn't seem to exist! Logged in as root, typing
> 'man man' gives "command not found" -- and it's not in /usr/bin.
> 
> what gives?? 

The man pages and man program have to be installed in addition to the 
base packages.  They are in the doc section of the distribution, in the 
packages manpages and man, respectively.

> 
> Thanks, Chris.
> 
> ===
> Chris R. Martin   email: [EMAIL PROTECTED]
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Two Packages Missing

[Buddha Buck]

> Guy Maor: 
>
>  > pbmplus was replaced by netpbm.
> 
> Hmm. Perhaps some kind soul can make a debian package?!
> 

Someone did...

bash$  dpkg -s netpbm 
Package: netpbm
Status: install ok installed
Priority: optional
Section: non-free
Maintainer: Jim Robinson <[EMAIL PROTECTED]>
Version: 1994.03.01p1-5
Description: netpbm -- graphics conversion tools.
 Netpbm is a toolkit for conversion of images between a variety of
 different formats, as well as to allow a few basic image operations.
 It is based on the pbmplus distribution.

bash$ 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: hardware needed for real terminals..or consoles

[Buddha Buck]

> one thing I hope to do when I get acquainted(future,hopefully near )is 
> to open consoles so mt family has, in effect simultaneous access to the 
> computer so I can make upgrades nto one computer rather than buy and 
> maintain several since hardware tends not to be cheap, I'm trying to 
> think(and save up) ahead of time when that day comes what is needed
> for each terminal?
> 
A serial port.  A serial null-modem cable.  A terminal.  A free plug 
;-).

Seriously, that is about all you need, hardware wise.  Out of them, the 
hardest to come by would be the serial ports and the terminals.  I 
don't know where to go to get dedicated terminals, but usually some are 
available in the used market.  The serial ports are a potential 
problem.  Standard PC hardware limits you to two or four serial ports, 
unless something special is done.  There are plenty of solutions, most 
providing 4 or 8 extra serial ports.  If this is all you need, then 
that would be fine.

The cabling is simple, and you might even be able to buy pre-made null 
modem cables.

However, this solution, while fairly traditional, does have certain 
limitations.  The terminals will be limited to text.  X will be 
impossible.  If this is acceptable to you, then this is probably the 
least expensive option.  If you want X-like capabilities, then you need 
to go a more complicated route, a route that most likely involves 
ethernet.  I'll let others deal with that problem.



-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: mailing list

[Buddha Buck]

> 
> The problem it's I can't put everything on my online
> account and they (administrator) don't have procmail
> or mh...

That's one reason why I use MH on my home machine...  Nobody but me 
cares that I have 100MB of archived mail.  I can do any sort of 
filtering I want, and so forth.  That's one of the nice things about 
running Linux... you are free to use sophisticated tools your ISP won't 
let you.

> That's good for the reputation
> of the mail list but mush of the time, it's because
> we try to answer directly to the user without checking
> what other people already answered. (I do it myself
> more of the time). Results: many answers mainly
> identicals to a same problems.

Yes, and this happens also on newsgroups.  If anything, it is -worse- 
on newsgroups, since people are more likely to follow-up without 
checking or before propagation delays allow them to even seee the other 
followups.  Newsgroups also have larger propagation, and attract spam, 
flames, irrelavancies, meaningless crossposts, and so forth.  Can you 
imagine if a comp.os.linux.advocacy/comp.os.windows.advocacy 
crossposting got into ...debian.users?

The only real solution would be to moderate it, which would overwork 
some poor volunteer and probably change the flavor of the list.

> 
> More of that, a news group is more organized. Thread
> are follow up and it's easy to jump over some who
> don't interested yourself. This will help people to
> got an answer more easily and more quickly, and to
> free a bit the traffic on this mail list (Debian-users).

This is a mis-conception.  Newsgroups are only -slightly- more 
organized than mailing lists, in that newsgroups add an additional 
header: "References", which allows newsreaders to tie articles together 
into threads a bit easier.  A mail program should also be able to do 
some degree of threading.  Granted, most mail programs don't, but then, 
neither does rn, one of the classic news programs out there.

> About the CGI-news thread... I remember to see one in
> a HOWTO contributions page... But where? Sorry, I was
> looking and don't find it. 

And that is part of the problem...  The Kernel Hacker's Guide is like 
that, but I don't read it as much as I wanted to when I first saw it.  
Where was that?  I don't know, it's in my Netscape bookmarks.  But I 
don't leave Netscape up all the time, it's a memory hog.  My mail 
reader, however, isn't.  I also don't have to be online, nor do I have 
to go to it, and so forth.

> 
> Thanks and sorry for this long reply,
> Fab.


-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Loading X Windows

[Buddha Buck]

> 
> > Is it possible to start an X session from the shell?
> 
> yes.  type "startx" at the command line, as any user, and the machine is
> transformed.  you can end with alt-ctl-backspace.
> 
> > Also, does X allow multiple sessions at once?
> 
> what do you mean by this.  you can have multiple windows open.  type
> "xterm &" to launch an extra xterm, for example.  Or you can log in from
> another x-capable machine and open windows.
> 
Or, if you are desparate and foolish enough (and have a lot of memory), 
you -can- run multiple X servers on different virtual consoles.  I've 
done this in the past.  I don't recommend it.

I have also seen multiple simultaneous X servers running on a MkLinux 
machine.  Unfortunately, the current version of MkLinux for PowerPC ony 
supports one console (not even serial support yet), so it made the 
machine a bit unusable and forced a reboot.

--
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: X Windows

[Buddha Buck]

> OK, so, I used xdm to start X and things work fine. When I exit fvwm2 I
> get a login prompt. Now, I want to shut down the server.
> 
> A. I can find no xdm process either with ps a or top. Is it hiding?

I don't think it should be...  On my system, it shows up as 
/usr/bin/X11/xdm.  

Try "ps -a | grep -i xdm | grep -v grep" and see what it gives you.  

There is also a hot key on newer kernels (which I conveniently forgot, 
sorry) that will dump a listing of the kernel process table to the 
console.

IF you start xdm with "/etc/init.d/xdm start", you should be able to stop it 
with "/etc/init.d/xdm stop".  In fact, that might work even if you didn't (I 
haven't tried)
-- 
 Buddha Buck  [EMAIL PROTECTED]
"She was infatuated with their male prostitutes, whose members were
like those of donkeys and whose seed came in floods like that of
stallions."  -- Ezekiel 23:20

Re: Checking if the network is up

[Buddha Buck]

> Hi,
> I am trying to write a script to use popclient to download the mail from
> the office's server. This will run on a portable. I want the script to
> check whether the network is up before attempting to retrieve any mail,
> as I am likely to use the notebook in other places and won't be hooked
> to the network.
> 
> The question is:
> 
> Is there any way of checking whether the network is responding so that I
> only run popclient when it is?

Yes, there are probably a number of ways.

You could check the output of netstat -r for a default route (something 
like 
"[ `netstat -rn | grep '^0\.0\.0\.0' | wc --lines`  = 0 ] || 
popclient...", although there is probably an easier way to do that)

I have set it up so that on my system, bringing up my PPP connection 
automatically creates a "/var/lock/ip-is-up", and bringing it down 
deletes that file.  Since I only have a single net connection, this 
works.  For multiple net connetions, some modification might have to be 
done.

There are probably others, but I don't know them offhand.

One final note:  I don't use a lap-top, but my computer is also not 
connected to the internet fulltime.  However, I run two popclients 
every 5 minutes via a cron entry.  I've decided that I don't need to 
have then even check for the net connection first.  Since popclient 
aborts very quickly when it can't establish a connection, I don't even 
notice that i have them running.  Will this not work for you, too?

> 
> Thanks.
> Luis.
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"She was infatuated with their male prostitutes, whose members were
like those of donkeys and whose seed came in floods like that of
stallions."  -- Ezekiel 23:20

Re: more mirror questions

[Buddha Buck]

> I just did some quick checking on the timestamp of the same file at 1/2
> dozen sites... the target being "debian-manual.txt";
> 
> Mar 6 15:46 -> ftp.tower.net.au  (GMT +8 hrs)
> Mar 6 23:46 -> ftp.debian.org
> Mar 6 23:46 -> ftp.ion.com.au(GMT +10 hrs)
> Mar 6 22:46 -> ftp.lh.umu.se
> Mar 7 06:46 -> ftp.caldera.com
> Mar 6 18:46 -> tsx-11.mit.edu
> 
> So if one does not do a "mirror -T site" first then you stand the distinct
> possibility of re-fetching or losing all your current files if you do not
> check first. I can't really afford the overhead of of "mirror -n site" then
> a "mirror -T site" then the actual mirror run itself.. and that would cause
> 3 lots of global "ls -ltR" execs on the remote site, quite expensive. Anyone
> have some ideas or suggestions about streamlining this process ?

It would be nice if mirror had a remote_tiimezone key that could be 
set.  That would allow the mirror sites to all have the same real time 
on the files (as opposed to the difference between ftp.ion.com.au and 
ftp.tower.net.au above).


-- 
 Buddha Buck  [EMAIL PROTECTED]
"She was infatuated with their male prostitutes, whose members were
like those of donkeys and whose seed came in floods like that of
stallions."  -- Ezekiel 23:20

Re: xconsole

[Buddha Buck]

> [EMAIL PROTECTED] wrote:
> 
> 
> There is also an error on booting from syslogd about not being
> able to find /dev/xconsole. What is /dev/xconsole for?

/dev/xconsole is a named pipe that syslogd uses to communicate to 
xconsole.


-- 
 Buddha Buck  [EMAIL PROTECTED]
"She was infatuated with their male prostitutes, whose members were
like those of donkeys and whose seed came in floods like that of
stallions."  -- Ezekiel 23:20