Re: more trouble with 1.1 upgrade
On Sun, 19 May 1996, Scott Barker wrote: > I got a message from dpkg when installing cron: > > dpkg - warning, overriding problem because --force enabled: > trying to overwrite `/usr/bin/savelog', which is also in package debian-utils savelog has moved to debian-utils so that it may be in a base system. (cron is not a base package). Unfortunately a new version of cron has not been released yet. I guess I'll usurp cron and release a new version with savelog missing so there won't be a problem. Guy
changelogs for debian packages
Either I'm blind, or the changelogs for debian packages are not part of the packages. It would be nice if they were, so that when an upgrade takes place, the user could see what has changed from one version to the next without having to download the source and unpack it to find out. -- Scott Barker Linux Consultant [EMAIL PROTECTED] http://www.cuug.ab.ca:8001/~barkers/ (under construction) [ I try to reply to all e-mail within 5 days. If you don't ] [ get a response by then, I probably didn't get your e-mail ] [ (we have a sometimes sporadic connection to the internet) ] "The marvels - of film, radio, and television - are marvels of one-way communication, which is not communication at all." - Milton Mayer
Re: Imake problems.
> > I have tried to use imake on several packages recently. If I try xmkmf I > get something like: > > imake -DUseInstalled -I/usr/X11R6/lib/X11/config > Imakefile.c:3: Imake.tmpl: No such file or directory > imake: Exit code 33. Stop. > > Anyone know what's missing? > > I'm running xbase-3.1.2-9 which seems to be responsible for imake and > xmkmf. rulcmc:/usr/X11R6/lib/X11/config$ dpkg -S Imake.tmpl xdevel: /usr/X11R6/lib/X11/config/Imake.tmpl rulcmc:/usr/X11R6/lib/X11/config$ dpkg -l xdevel ii xdevel 3.1.2-4XFree86 3.1.2 developer's toolkit So, it's xdevel you're after. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian Linux!
Re: Root login is waiting
> > I have a problem with root login again. All other logins are fine, > but root login is waiting after I typed the password. Even > su isn't working anymore. I updtated some packages, including > a few from Incoming this morning, after reboot, this behaviour > is present. Sound familiar, a solution? Not really a solution, but: I (don't tell anyone else) have on my "joost" homedirectory a subdir that's only readable to "joost". in that dir I've got a shell that's setuid root: if for some reason root cannot login, I usually am able to execute that shell. Not really the solution you're after on a secure system, though! -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian Linux!
Re: mailing list as digest?
Matthew> To the point: unfortunately, the volume is very large. I'd much Matthew> prefer to get this mailing list in digest format. Does anyone know Matthew> if this is possible with the list server that debian.org uses? No Matthew> mention is made on their web pages, the place I signed up from. You can use either "procmail" or "mailagent" to filter your incoming mail into different folders. Very, very convenient. Both packages are in the mail directory of the Debian distribution. -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Where are the new packages put?
I'd like to know if new packages (like dpkg 2.0, xtel, etc) go: I can't easily find them on the ftp.ibp.fr mirror, for example. Is there a list of newly released packages with their location in the Debian archives>? Thanks, YA.
Re: perl and setgid scripts
...in fact apropos my previous comments about perl, I note that the description reads as follows: Larry Wall's Practical Extracting and Report Language. An interpreted scripting language, known among some as "Unix's Swiss Army Chainsaw". Perl is optimized for scanning arbitrary text files and system administration. It has built-in extended regular expression matching and replacement, a dataflow mechanism to improve security with setuid scripts and is extendible via modules that can interface to C libraries. It's not clear what point there is in advertising the taint feature if you're not going to implement set[ug]id scripts... Darren? - Richard -- http://www.elmail.co.uk/staff/richard/ GCS d- s+:- a-- C++ ULVS+++$ P+++ L++ E++ W(++,--) N(++,+) o? K w--- O? M- V? PS(+,+++) PE Y+ PGP+ t- 5++ X+@ R tv--- b++> DI+ D+ G e++ h r% y++
Re: Root login is waiting
On Mon, 20 May 1996, Erick Branderhorst wrote: > I have a problem with root login again. All other logins are fine, > but root login is waiting after I typed the password. Even > su isn't working anymore. I updtated some packages, including > a few from Incoming this morning, after reboot, this behaviour > is present. Sound familiar, a solution? this happened to me eactly (accept on a solaris machine - but i have a debian machine also) setting quotas incorrectly is what stuffed me up .. so i booted the machine up off the installation boot disk and hacked out the quotas .. dont think this is eaxctly your problem though .. try deinstalling all the packages you installed between the time it worked to when it didnt :) \\ ONE SENSE Of BEAUTY On white plum-petals that were pure and sweet, The Nightingale now wipes its muddy feet. \\ The Australian Internet Company ISP Par Exceliance
Re: kernel headers
Manoj Srivastava said: > The kernel headers package are for those people who are > not satisfied with the headers in libc5-dev, (or don't have > libc5-dev, in which case I wonder why they want the headers at all, > since compilation (I think) depends on having libc5-dev), and also > don't want to pull in the rest of the kernel sources. I guess I wasn't clear enough -- I was actually wondering why kernel headers were included anywhere *except* with the kernel source. I can see some logic in having a kernel-headers package for those who don't want all the kernel source, but I totally fail to see why any kernel headers are included in the libc packages. Kernel headers are dependant upon the kernel source, not on the C libraries. It just doesn't make sense to me. -- Scott Barker Linux Consultant [EMAIL PROTECTED] http://www.cuug.ab.ca:8001/~barkers/ (under construction) [ I try to reply to all e-mail within 5 days. If you don't ] [ get a response by then, I probably didn't get your e-mail ] [ (we have a sometimes sporadic connection to the internet) ] "Money can be lost...beauty normally fades with the years...health may fail or some disease can strike...friends usually vanish, perhaps die. Only memories remain for as long as you live. so, live that your memories will make you glad rather than sad." - George Dubow
Re: changelogs for debian packages
On Mon, 20 May 1996, Scott Barker wrote: > Either I'm blind, or the changelogs for debian packages are not part of the > packages. It would be nice if they were, so that when an upgrade takes place, > the user could see what has changed from one version to the next without > having to download the source and unpack it to find out. I think this goes for both changes in the original program distribution, _and_ changes to the debian packaging (last digit of the debian number). I've been just letting dselect update everything and I never know what's changing! ...RickM...
Re: kernel headers
Hi, >>"Scott" == Scott Barker <[EMAIL PROTECTED]> writes: Scott> Is there a good reason that the kernel headers have been Scott> separated from the kernel source? I think it is a very Bad Scott> Thing to separate the headers from the kernel. The kernel is Scott> the heart of the whole system, and I don't think it's wise to Scott> split it up. The kernel-source package is a superset of the kernel-headers package, so the headers have not been "separated" from the rest of the source. The kernel headers package are for those people who are not satisfied with the headers in libc5-dev, (or don't have libc5-dev, in which case I wonder why they want the headers at all, since compilation (I think) depends on having libc5-dev), and also don't want to pull in the rest of the kernel sources. If this is not in the description, It should be, and I'll add it into the next version of the kernel-packages package (to be uploaded later today). manoj -- Everyone has a purpose in life. Perhaps yours is watching television. -- David Letterman %% Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 <[EMAIL PROTECTED]> http://www.pilgrim.umass.edu/%7Esrivasta/>
Re: regular (aka bsd) compress distribution?
From: Yves Arrouye <[EMAIL PROTECTED]> > Is it impossible to distribute a real compress program? I know there > may be problems with an LZW patent, but I don't know how they relate > to the distribution of a compress program for say personal use. > If this is possible I'll make a package for it. I'd be happy to see someone make a "compress" package and distribute it _from_their_own_site_ . If you can do that, please go ahead. We'll put a note in the main archive that you distribute it so that people can find it. We (the core of Debian developers) just don't want to deal with a law suit arising from an infringement of the Unisys patent when "gzip" works so well that it has obsoleted "compress". That's why we won't put "compress" in the official Debian archive. Thanks Bruce Perens Debian Project Leader
Re: Root login is waiting
On Tue, 21 May 1996, Fundamental wrote: > On Mon, 20 May 1996, Erick Branderhorst wrote: > > > I have a problem with root login again. All other logins are fine, > > but root login is waiting after I typed the password. Even > > su isn't working anymore. I updtated some packages, including > > a few from Incoming this morning, after reboot, this behaviour > > is present. Sound familiar, a solution? > > > this happened to me eactly (accept on a solaris machine - but i have a > debian machine also) > > setting quotas incorrectly is what stuffed me up .. so i booted the > machine up off the installation boot disk and hacked out the quotas .. (clip) There was a discussion before on linux-kernel about this---it seems like the xconsole (and maybe other) pipes fill up and since root logins are tracked by the system logs, the login hangs due to the 'filled pipes' (call a plumber?) If quota is set to verbose, it displays that [-] [\] [|] [/] rotating bar... perhaps this clogs it faster... I don't think this is generally curable :( perhaps fiddling with the code that logs root logins to the logs might help... or course a security hole could be created if one was not careful. You can try to make your login less noisy... > > \\ > > ONE SENSE Of BEAUTY > On white plum-petals that were pure and sweet, > The Nightingale now wipes its muddy feet. > \\ > The Australian Internet Company ISP Par Exceliance [EMAIL PROTECTED] "Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come." -- Matt Groening
Re: kernel headers
Hi, >>"Scott" == Scott Barker <[EMAIL PROTECTED]> writes: Scott> I guess I wasn't clear enough -- I was actually wondering why Scott> kernel headers were included anywhere *except* with the kernel Scott> source. I can see some logic in having a kernel-headers package Scott> for those who don't want all the kernel source, but I totally Scott> fail to see why any kernel headers are included in the libc Scott> packages. Kernel headers are dependant upon the kernel source, Scott> not on the C libraries. It just doesn't make sense to me. The headers were included in libc5-dev after a rash of very buggy alpha kernel releases (1.3.7* or something like that) that proceeded to break compilations, etc. Kernel versions are changed far more rapidly than libc is, and there are higer chances that people install a custom kernel than they install custom libc. Add to that the fact that few programs really need the more volatile elements of the header files (that is, things that really change from kernel version to kernel version), [before you reject this, consider: programs compiled on one kernel version usually work on other kernels]. So, it makes sense that a set of headers be provided from a known good kernel version, and that is sufficient for compiling most programs, (it also makes the compile time environments for programs on debian machines a well known one, easing the process of dealing with problem reports), the few programs that really depend on cutting edge kernel data structures may just use -I/usr/src/linux/include (provided that kernel-headers or kernel-source exists on the system). libc5-deb is uploaded frequently enough that it never lags too far behind the latest released kernel. I hope I was clear enough to answer your question. manoj -- "I take Him shopping with me. I say, 'OK, Jesus, help me find a bargain'" --Tammy Faye Bakker Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 <[EMAIL PROTECTED]> http://www.pilgrim.umass.edu/%7Esrivasta/>
Re: My experiences of the installation
On Mon, 20 May 1996, Esa Turtiainen wrote: > to get my favorite Emacs keys to work. Isn't there any easier method > to get all the meta characters to work? ^] should be still added to > get easily the Telnet quit character. But really, they should all be > there. Agreed, the Meta keys for Emacs should be in the keymap files distributed with Debian... They just aren't right now. What you can do, though, is copy your keymap file to another one and then modify that to your liking and have it loaded by default at boot. Not very hard. > HOWTO/Finnish suggest > > LC_CTYPE=finnish.iso88591 > > All the perl programs give a three-line warning after that. Debian doesn't have the locale support files. So basically perl is complaining that it can't find the files that describe finish.iso88591. I hope to fix that by making a 'locale' package at some point in the future. Some other Howto's or mini-Howto's have interesting things to say about keymaps and 8-bit character set support... You might want to browse in /usr/doc/HOWTO some more (assuming you installed the howto package). > 8-bit modes > --- > > There are good hints in HOWTO/Finnish how to make less, emacs, etc. > to work with 8-bit characters. Too elaborous. > > Xterm seems to filter all the alt-commands to some 8-bit characters. > No Emacs-editing is possible. Rxvt seems to work, though. For xterm, try adding the following to your /etc/X11/Xresources file (or equivalent): XTerm*eightBitInput:false XTerm*eightBitOutput: true > I accidentally loaded NAS and it made something that did not > work at all. Then try purging it (using the '_' key in dselect). > One important thing is to remember > > depmod -a > > after installation (make modules_install). Debian does not do this > in every boot like the system I used to have. The default behavior is to run 'depmod -a' every time you boot into a kernel with new version. If you don't like, go edit /etc/init.d/modules. By uncommenting three lines you can have 'depmod -a' run every time you boot. > I think that the system should find sbpcd using driver name like > eth0 but it can not (BUG?). Huh? eth0? That's for network cards. > It is a good idea to add the following lines to /etc/fstab > (they could be there already): > > /dev/fd0 /floppy autonoauto 0 0 > /dev/sbpcd/cdrom iso9660 noauto,ro 0 0 > > Some notes: isofs do not work as type (BUG?). /dev/cdrom would be > nicer to use but umount do not accept it. I does not undestand that > /dev/cdrom is a link to /dev/sbpcd (BUG). umount is perfectly happy with my symlinked /dev/cdrom... Try putting /dev/cdrom instead of /dev/sbpcd in the fstab file and see if it makes your umount happier. > I have not bothered to install this before, seems usable. > If it is running, you can not start X using startx, because > /dev/mouse is used already. If X is running, you can start > gpm. You can configure gpm to send a copy of the mouse events to a fifo /dev/gpmdata. Then you point the X server to the fifo instead of the mouse device. Look at the gpm -R option in the man page... Never tried it myself, but you might want to give it a try. You'll probably need to create the fifo yourself. > I tried not to install vi, first. However, the default configuration > of many utilities require it. I found: > > - crontab -e > - CVS > > So, I ended up to install it. > > At least crontab starts to work, if you set environment variable > EDITOR. Maybe it should be in default /etc/profile (set to what? > hopefully not ae). Ae is there because it's user-friendly for total newbies. Other Unix users know enough to set EDITOR and then they never have to deal with ae. > BTW. I used the followin one-liner 'dlocate' to find out to what > package a file belongs: > > grep $1 /var/lib/dpkg/info/*.list Try dpkg -S instead. > Despite the help message, dpkg -L and dpkg --list are not the > same. You're right, but you need to look at the help message some more. dpkg -L|--listfiles ... dpkg -l|--list [ ...] > locate > -- > > Do not work. It tries to run as nobody but because nobody do not > have shell defined, su fails (why? it should work). I added > -s /bin/sh to > > /etc/cron.daily/find This is a known bug with the nobody passwd entry. Just set nobody's shell to /bin/sh. > Init files > -- > > I am little missing some menu-based interface to init-files. /etc/init.d > should have just files that are linked to different rc.* files. Now there > are additionally some files that are really support files for inittab. > > If you make modifications to files in rc.[1-6], it is unlikely that > you make them in all 6. This makes levels 2-5 really unusable. Files? You meant symlinks, right? The rc.[1-6] directories should only have symlinks. Unusable? The point of having four different multi-user runlevels is so p
Re: Imake problems.
On Mon, 20 May 1996, Dale Scheetz wrote: > I find the fracturing of packages into runtime and development sometimes > doesn't make any sense. In this case, why is imake and xmkmf supplied in > xbase, but the configuration files they need to run properly in the xdevel > package. Shouldn't they all be in the same place? It would certainly make > using and finding them more straight forward. Agreed. IMHO imake and xmkmf should be together with their config files... i.e in the xdevel package. 1. They're only used when compiling x binaries. 2. Getting a 'xmkmf: file not found' will probably get users thinking "I need an x development package". Getting a failed xmkmf run will most probably get the users thinking 'bug!'. Maybe you'd care to file this as a bug against xbase? Christian
Re: Root login is waiting
> On Mon, 20 May 1996 15:20:34 +0200 (METDST), > [EMAIL PROTECTED] (J.H.M.Dassen) said: Ray> Can you check if you have a /dev/xconsole? Maybe syslog tries to Ray> write to it. I don't have a /dev/xconsole, and Debian complains about it on boot-up. How do I make one? (I know about mknod, but I don't know the parameters.) (Please excuse me if /dev/MAKEDEV can be used for this, just tell me and I'll find the place.) kai -- Life is hard and then you die.
Re: dselect complaints
> I was going to come down on Mr. Gribble for his post, but that work has > already been done Let's all stop coming down on each other - even the ones who speak out of turn should themselves be corrected gently. Project staff must maintain their cordial dialogue. It's essential for the project to succeed. We've been doing really well at that for a long time, it's just starting to break down now. So please watch for it and self-correct. Thanks Bruce
Re: dselect complaints
On Sun, 19 May 1996, William S. Gribble wrote: > Ian Jackson wrote: > > I'm not interested in hearing any more complaints or even extensive > > suggestions for improvement, unless the person complaining is > > volunteering to do the work on a new interface. > > If you don't want feedback about the tools, might I suggest that you (junk clipped) As someone who has suggested a rewriting of dselect, let me vote for Ian on this one. Dselect is hard for new users, but I like it overall... It is extremely functional. I was going to come down on Mr. Gribble for his post, but that work has already been done, so I'm as of now downloading the source to dselect and I'm going to head-butt it until I understand it or it defeats me. (inside tip: bet heavily on dselect ;) [EMAIL PROTECTED] "Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come." -- Matt Groening
Re: kernel headers
On 20 May 1996, Manoj Srivastava wrote: (clip) > The kernel-source package is a superset of the kernel-headers > package, so the headers have not been "separated" from the rest of > the source. (clip) > manoj > -- > Everyone has a purpose in life. Perhaps yours is watching television. > -- David Letterman %% > Manoj Srivastava Systems Research Programmer, Project Pilgrim, > Phone: (413) 545-3918A143B Lederle Graduate Research Center, > Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 > <[EMAIL PROTECTED]> http://www.pilgrim.umass.edu/%7Esrivasta/> I have heard discussion on this list before about why debian does this; I don't want to argue why;; But will it break anything major if I don't follow this guideline, and esp. is there a temporary way to set things up 'the old way'? Most of what I compile right now wants kernel headers so it can be compatible with the current kernel (ie kernel utilities and patches.) For example I have kernel utilities which use #include and I keep catching them raiding the /usr/include directory. [EMAIL PROTECTED] "The C Programming Language -- A language which combines the flexibility of assembly language with the power of assembly language."
Re: Bug#3072: No more logs since cron.weekly rotation
On Mon, 20 May 1996, Lukas Nellen wrote: > > "G" == Guy Maor <[EMAIL PROTECTED]> writes: > > > G> The bug is in syslogd - the last line of the /etc/cron.weekly/sysklogd > G> script reads "/etc/init.d/sysklogd reload". Presumably this > G> UNDOCUMENTED reload command has the same effect as sending a SIGHUP to > G> syslogd. Except it doesn't. > > This is related to another bug reported (can't find the number right > now) in that start-stop-daemon cannot read the pid of syslogd from the > pid file. This manifests itself also during shutdown - the K-links for > syslogd fail to kill syslogd. Something seems to be wrong with the way > that syslogd writes its pid file. Very wrong? Yes and no. The problem was that syslogd wrote its pid file as syslog.pid (no 'd'). It's been fixed in sysklogd-1.3-3. Christian
Re: regular (aka bsd) compress distribution?
On Mon, 20 May 1996, Stephen Early wrote: > On Mon, 20 May 1996, Yves Arrouye wrote: > > > Is it impossible to distribute a real compress program? I know there > > may be problems with an LZW patent, but I don't know how they relate > > to the distribution of a compress program for say personal use. > > If this is possible I'll make a package for it. > > If we do have a compress package, it must go in non-free. Would still be better than nothing. And making a compress package shouldn't be hard... it doesn't even need to provide an 'uncompress'! Any takers? Christian
