Location for libelf?
Ok, I've fiddled around, and have reached the stage where I can upload libelf to master. The one question I have is: should it go into contrib, or devel? Currently, the library is considered to be in alpha stages - it's definitely usable, but there you are. I seem to recall that alpha stuff should go into contrib; but recent discussion on this list appears to contradict that. Anybody want to come down one way or the other? Cheers (and thanks).
Bug#4060: Update: 4060 - Kernel decompression failure.
From: Christopher R. Hertel [EMAIL PROTECTED] I've heard reports from OS/2 users that similar problems have been seen with some installations of that OS. Again, the solution was to disable cache. Linux 1.2.8 loads and runs fine from the hard disk. The others who had to turn off cache in order to install Debian found that they could re-enable cache once they had installed the system. My hypothesis at this time is that this is a problem in SysLinux. I've uploaded a disk we can use to investigate this. Please download ftp://ftp.pixar.com/pub/bruce/LILO_BOOTDISK.gz and see if it will boot on your system. It won't do much once you've booted it because it does not have the hard disk driver linked in (this is the _all_module_ boot floppy for 1.2 in an early incarnation). But it should boot the kernel and load the compressed root filesystem all from one floppy. If it works, please copy the kernel from this disk onto your SysLinux boot floppy (both are MS-DOS filesystems), and veriify that that does not boot. If that's the case, we will have Peter Anvin (author of SysLinux) work on the problem with you. Thanks Bruce -- Clinton isn't perfect, but I like him a lot more than Dole. Please register to vote, and vote for Democrats. Bruce Perens AB6YM [EMAIL PROTECTED]http://www.hams.com/
Re: Shadow problems
Bruce Perens writes: Bruce Let's plan on having shadow be part of the base for 1.2 . We Bruce should thus have the default login be aware of it, etc. Let's not forget about xdm, please. -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
Bug#4188: ldd never gives non-zero exit status
Package: ldso Version: 1.7.14-4 -chiark:~ ldd /bin/ls libc.so.5 = /lib/libc.so.5.2.18 -chiark:~ echo $? 0 -chiark:~ ldd /bin/true ldd: /bin/true is not a.out or ELF -chiark:~ echo $? 0 -chiark:~ ldd /dev/null ldd: can't read header from /dev/null -chiark:~ echo $? 0 -chiark:~ ldd /spong ldd: can't open /spong (No such file or directory) -chiark:~ echo $? 0 -chiark:~ ldd usage: ldd [-vVdr] prog ... -chiark:~ echo $? 0 -chiark:~
Re: Shadow problems
Miquel van Smoorenburg writes: Well the login we're using now is from util-linux, and unless you can get the shadow patches into the upstream source (which wouldn't be a bad idea) it would be easier to use the login from the shadow package I think. You can use the Replaces: header for that. The same goes for newgrp. In fact I think you can drop newgrp since it isn't needed under Linux, we have BSD groups support. But then I think we shoudl keep newgrp just for compatibility. vipw and vigr should be rewritten so that they can edit the passwd+shadow. I've got a vipw that merges passwd+shadow, lets you edit the merge, and then splits it again. It also adheres to the shadow password locking convention. If you want it drop me a line. Yes. Of course I'm interested. Could you either send it to me via email or place it in my directory on yar or upload it to my ftp site (feivel.informatik.rwth-aachen.de) and drop me a line please? Also, you'll have to replace adduser ofcourse. This will be easy; shadow comes with a command line utility useradd that just needs a simple perl wrapper around it that emulates adduser functionality. For the first step it seems to be easier to add a call to useradd to the adduser script we're using already. Bruce (I think it was Bruce) mentioned that we want shadow passwords as a standard feature for 1.2; so I think just making sure all conflicting packages get upgraded to work with shadow and letting shadow conflict with the older packages would do the job. That should be a Breaks: not a Conflicts: entry. But since we don't have Breaks: ... Which reminds me: RedHat is going to integrate PAM into their next release. Perhaps now is a good time to look if we should consider using that too, or if we think that shadow is good enough for now. If we can get PAM, too, I'm all for integrating it. What has to be done? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Re: Shadow problems
David Frey writes: M 1) Should we change the login package to be shadow aware? Or should shadow M come with its own login (that works with and without shadow password files)? M Or should we use the shadow login as standard? I'd prefer if we would be shadow's login, since it is far more cleverer than standard login (the same goes for su btw). I talked to Guy (login maintainer) about this problem a while ago and treid to persuade him to use ths shadow login as standard (it works without the shadow file, too). But he prefers to keep the old one. Should we create a second login package? Also should we try to package the shadow su, too (and divert teh shellutils one)? I'm going to changes jobs next month and I'd really like to finish my work on this problem until then. I don't know if I will have the time in my new job. Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Re: Bug#4096: abuse is still a.out
On Sat, 10 Aug 1996, Andreas Jellinghaus wrote: Package: abuse Version: 1.10-4 abuse is still a.out [EMAIL PROTECTED]:~$ file /usr/games/lib/abuse-1.10/abuse.x11R6 /usr/games/lib/abuse-1.10/abuse.x11R6: setgid Linux/i386 demand-paged executable (ZMAGIC), stripped This is due to the fact that we don't have the source code for abuse. I've asked the makers if they'll make an ELF version, but I haven't seen one. Until then there isn't much I can do - I'll leave the bug open however, as I do agree an ELF version would be much better. -- Run.exe First Law of the Universe: No law applies to ALL of the Universe [EMAIL PROTECTED] http://www.ntplx.net/~runexe/ Finger me for PGP key
Re: Shadow problems
Bruce Perens writes: Let's plan on having shadow be part of the base for 1.2 . We should thus have the default login be aware of it, etc. But the question remains, which login? The standard one patched, or the shadow one, or both and the user decides? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Bug#4189: dselect highlights too many lines when TERM=linux
Package: dpkg Version: 1.3.5 Wishing to see the colored version of dselect, I tried this from a color xterm: # export TERM=linux # dselect I didn't see any colors, which was disappointing but hardly fatal. However, when I used the arrow keys to scroll up or down, dselect highlighted _all_ the menu options I scrolled over, not just one. Susan Kleinmann
Re: Shadow problems
Cc: debian-devel@lists.debian.org (Debian Development) Bruce Perens writes: Let's plan on having shadow be part of the base for 1.2 . We should thus have the default login be aware of it, etc. But the question remains, which login? The standard one patched, or the shadow one, or both and the user decides? Quick question (which may show some of my ignorance of the current linux shadow stuff): Will inclusion of the 'shadow' package as default interfere with the use of NIS passwd/group entries? Our installation is fairly dependent on NIS. -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta
New source format and related issues...
Well, I think, if I can get it to work, that the new source format will be fine. _IF_ I can get it to work. I've looked at the docs, I've examined hello and dpkg, and I'll be damned if I can find any information that would allow me to actually reproduce the files that were uploaded to master, and assuming that dpkg was in fact build with the utilties it includes, this is annoying. My first problem stems from the simple fact that the new process of building a package isn't terribly well documented in the programmers manual---it devotes a whole sentence to saying Look at dpkg-source(1). Since I missed that sentence, I was baffled for a while. This was compounded by the fact that, since the 'source' target is still listed in the .PHONY target, when you do 'debian/rules source', you get Nothing to do for target source, rather than Don't know how to make source, or even better, Source is an obsolete target, please use dpkg-source. Anyways, I finally figured out that I had to invoke dpkg-source. So I tried dpkg-source, and here's what I get: dpkg-source: building hello in hello_1.3.orig.tar.gz tar: Cowardly refusing to create an empty archive Try `tar --help' for more information. dpkg-source: failure: tar gave error exit status 2 Since I had both appropriate hello-1.3 and hello-1.3.orig directories, I figured maybe I was doing something wrong in invoking dpkg-source, so I looked around a little more and found dpkg-buildpackage. After figuring out that it needs to be run from within the debian source directory, I ran it, and lo and behold, it has the same problem with dpkg-source that I do. So, I've got the tools, but I can't get them to work, and furthermore, most of them aren't even mentioned in the draft programmers manual that goes to great lengths to document the files and requirements and so forth, without ever really discussing the the tools, or how to use them. I'd really like to know what I'm doing wrong, so I can move ahead on this. Also, on the subject of our available examples: I think the debian/rules file in the hello source package makes at least 1 poor decisions in how certain things should be implemented---and given that prospective maintainers are often pointed in its direction, I think we should take care of these before immortalizing them. For instance, Bruce seems to have originated a much more sensible construct for seeing to the creation of the directories from which the package is built. Instead of just throwing 'install -d' commands in the body of the 'binary' target, a list of target directories is constructed and a target created that will iterate over that list, creating directories as it goes. The binary target is then made dependent upon that target. This is 1000% easier when you're working with a complex package that needs a lot of directories. It would also be nice if we could produce some simple tools that would help take care of some of the small administrative headaches automatically---say, a tool that would look through the debian directory and install all appropriate files into the DEBIAN directory, running them through any appropriate filters. Another useful tool would go through the temporary directory structure and assign permissions and ownerships. Certains parts of the tree (*/bin, */man, you get the idea) would have defaults associated with them (0755, for */bin, 0644, for */man, root.root owning everything, etc). The package maintainer would then need only supply the program with a list of the exceptions (along with correct perms and ownership), and the rules file then could just execute _that_ command with su -c, since nothing else would need that access (well, the clean command might). Now I know that there are always situations in which this just wouldn't work, and that's fine---there's nothing that stops a rules file from overriding parts of this when necessary. The important thing is that tools like this would make the creation of 90%+ package that much more automated, and most likely that much more free of the little bugs that clutter up the bug system. Mike. -- Don't let me make you unhappy by failing to be contrary enough
Re: Shadow problems
Please work out with Guy Maor (loginutils maintainer) which login to make standard. I think I will have the set-up script start the system with shadow enabled, and let the user take it out if they must by removing /etc/shadow . Thanks Bruce -- Clinton isn't perfect, but I like him a lot more than Dole. Please register to vote, and vote for Democrats. Bruce Perens AB6YM [EMAIL PROTECTED]http://www.hams.com/
Bug#4156: rpncalc has unexecutable unwriteable /usr/man, /usr/man/man1
In message [EMAIL PROTECTED], Ian Jackson writes: Package: rpncalc Version: 1.1-1 Directories must be 755 root.root. Fixed in rpncalc-1.1-2
how to test for SLIP devices
Hi, I would like the diald preinst script to check if the kernel has SLIP devices (either compiled in or in as a module). I think it should be enough to check for the string `slip' in /proc/modules and the string `sl?:' in /proc/net/dev. Is this correct? Thanks, -giuseppe PS: please cc me in your replies as I'm temporarily off the devel list.
Re: Shadow problems
The shadow feature does not preclude use of NIS passwd and group maps. Only users that have * as their password field will get their passwords from /etc/shadow or /etc/gshadow (file names may vary). If our NIS package replaces passwd, etc., with NIS-master-server-aware versions, that package would have to be updated. I think this is one reason that people are experimenting with shared libraries for validation. Thanks Bruce -- Clinton isn't perfect, but I like him a lot more than Dole. Please register to vote, and vote for Democrats. Bruce Perens AB6YM [EMAIL PROTECTED]http://www.hams.com/
Re: how to test for SLIP devices
Look for sl0 in /proc/net/dev . I think that's a definitive test. Thanks Bruce -- Clinton isn't perfect, but I like him a lot more than Dole. Please register to vote, and vote for Democrats. Bruce Perens AB6YM [EMAIL PROTECTED]http://www.hams.com/
Bug#4159: xcoral dies
**On 15 Aug, In article Bug#4159: xcoral dies , ** SGK (Susan G. Kleinmann) writes: SGKRaul Miller said: Package: xcoral Version: 2.5-1 Today, I decided to try xcoral. The first operation I tried, upon starting it, was New. This was sufficient to kill the program, with the error message: X Error of failed request: BadValue (integer parameter out of range for oper SGKation) Major opcode of failed request: 12 (X_ConfigureWindow) Value in failed request: 0x0 Serial number of failed request: 924 Current serial number in output stream: 930 It may be relevant that I'm using 9wm. SGK SGKTo check whether 9wm might be relevant, I just tried xcoral under fvwm. SGKIt seemed to work fine for me. Yes, I have never seen this error message with fvwm... I will reassign this bug... -- Christophe Le Bars - Email : [EMAIL PROTECTED], [EMAIL PROTECTED] 01001DEBIAN0LINUX0110ESPERANTO00101011ML1010010GNU0111 10111010010100011 Utilisez Linux Debian! 10010101001110010
