Re: coming soon
3. /etc/rc[0-6].d will move to /etc/rc.d/rc[0-6].d to match the practice on other Linux systems. Symbolic links will provide compatibility with the old locations. Is this really necessary ? Real SysV's do things the way we have done. I can make symbolic links in /etc/rc.d that point back out to where the directories are instead of moving the directories. I was of the impression that real SysV worked the other way, but I can satisfy everyone. I agree with Ian. Pleas don't do this. Adding alternative paths to the same directories will only add clutter and cause confusion. BTW, I just checked and Solaris uses the same directory structure we already have. Of course, I don't know if that's good or bad. :-) David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses-1.9.8a ELF release
David Engel writes (Re: ncurses-1.9.8a ELF release): [ and earlier: ] The runtime package installs the shared libraries as lib*.so.3.0.new and then renames them to lib*.so.3.0 in the postinst script. This is fine for not disturbing running programs when the package is being upgraded, but there is no provision for deleting the files when the package is removed. Again, I'd like to hear Ian Jackson's thoughts on adding special installation support for shared libraries to dpkg. Ian Jackson, are you there? I'd *really* like to hear your opinions on this. Yes, I'm here. Sorry, I haven't been reading this mail for a few days and I'm noow catching up on a 400-message backlog. OK, I know what that's like. As far as I can see we have three kinds of shared library: 1. Packages like X or mkfs or what have you, where it doesn't matter if the library link is missing momentarily, or even if it's absent while the package is in a broken state according to dpkg. 2. Packages like the libc or ncurses, where we can't leave it broken even for an instant without risking an unrecoverable system. 3. The shared library is part of the same package as the executables and is version-specific - it's just there to save disk space and memory, and furthermore this is a critical package which we can't leave broken. AFAIK only dpkg falls into category 3. Lots of things fall into category 1, but they can do without special handling. Right. Category 2 is mainly what I'm interested in. Category 1 needs the link to be updated *with both libraries present*, am I right ? No, I don't think so. For these, it should be sufficient to just do it in the postinst script. Could you take a good look at maintainer-script-args.txt in project/standards, and consider what extra functionality you'd like me to include in dpkg ? I've been looking at it off and on for the last few days now and I still don't know if I can do what I want to do. Let me try presenting the problem differently and you tell me if and how it can be done. Let's say I have a package named foo-n with a shared library in it named libfoo.so.x.y that, at least for the time being, must always be available by that name, even while dpkg is moving things around. Now, at some point in the future, I know that libfoo.so.x.y whill no longer be needed for any number of reasons. What I'd like to be able to do after dpkg is done upgrading foo-n with foo-m, removing foo-n completely or replacing foo-n with bar-p, is have libfoo.x.y deleted, if and only if, no remaining package claims to own libfoo.x.y. Can this be done, and if so, how? David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
xkeycaps-2.29-1 (new package)
This is Jamie Zawinski's useful xkeycaps utility, based on the new X11R6 ELF libs. Date: 16 Dec 95 11:06 UT Source: xkeycaps Binary: xkeycaps Version: 2.29-1 Description: xkeycaps: Graphical front-end to xmodmap. Priority: Low Changes: * New package. Files: -rw-rw-r-- 1 rob rob156247 Dec 16 06:05 xkeycaps-2.29-1.tar.gz -rw-r--r-- 1 root root93393 Dec 16 06:00 xkeycaps-2.29-1.deb 7b78b5f4e1a44bb62c5aa84810ad8487 xkeycaps-2.29-1.tar.gz d2a87634dc508cd003447fbd7f123326 xkeycaps-2.29-1.deb -- Robert Leslie [EMAIL PROTECTED]
Re: PCMCIA support in boot kernel? [a bloody fight]
] I'll try to add PCMCIA support to the follow-up release of 1.3.47. 47 ] is already stable and I'd rather not de-stabilize it. It will be ] released tonight or tomorrow. ] ] Any volunteers to check it as I have no way to test it. [ ... ] i'll check it, if you compile it. i must shamefully admit that i threw in the towel in the PCMCIA vs. Debian fight on my IBM 701 last night; i installed RedHat (which was flawless and easy, btw.). it was a long (two day) and bloody (at least for me) fight, and it was making me very frustrated. i just couldn't get any other transportation net than floppy net -- which for many reasons are very cumbersome for me -- up and running. depmod on the PCMCIA modules failed when i got the binary release of the PCMCIA modules from Slackware (for kernel 1.2.13, the same as i was running); it complained about missing symbols and version mismatch (1.2.13 does not match kernel version 1.2.13 or something strange like that) and 8390.o was included as a module while the Debian kernel has it compiled in? well, i'm new to Debian/dynamically-loadable-kernel-modules/ PCMCIA, so bear with me. well, next try was SLIP over the serial line. i got about one text line over the serial line before it locked up completely; even a 'stty -a /dev/ttyS0' hung. i didn't even try SLIP as kermit/getty wouldn't work. it's a shame, really. i'd much rather run Debian than RedHat as i like to support GNU/FSF, and the systems really have about the same potential in becoming great; both have package systems worth a damn. bye, -- Bjørn Stabell mailto::[EMAIL PROTECTED] http://www.cc.uit.no/~bjoerns/ fax:+4777644100
Re: coming soon
David Engel writes: 3. /etc/rc[0-6].d will move to /etc/rc.d/rc[0-6].d to match the practice on other Linux systems. Symbolic links will provide compatibility with the old locations. Is this really necessary ? Real SysV's do things the way we have done. I can make symbolic links in /etc/rc.d that point back out to where the directories are instead of moving the directories. I was of the impression that real SysV worked the other way, but I can satisfy everyone. I agree with Ian. Pleas don't do this. Adding alternative paths to the same directories will only add clutter and cause confusion. BTW, I just checked and Solaris uses the same directory structure we already have. Of course, I don't know if that's good or bad. :-) All the other Linux distributions are going to /etc/rc.d/* because that's what comes with the svinit package. It works very well; in practice I've found that it's one of the things that I like better about my Red Hat system than my Debian system. Also, as Linux is continually documented, the standard practice will get documented, and that will be one more way that Debian is different from other Linux systems, which I think is not a good idea. Furthermore, one of the reasons that I recommend Debian is the fact that one of the goals of the packaging system is to eventually be able to install packages other than .deb. In particular, this one change would make it nearly painless to add .rpm packages, once they add their dependency system (in a few months). It would *also* make it possible to install .deb packages on a Red Hat system. So I suggest that alternative paths one way or another will be useful. I think that using the same directory structure as other Linux distributions is the best way to do it, but if you can't hack that, then make the /etc/rc.d directory and make the appropriate links in it to /etc/rc?.c and /etc/init.d michaelkjohnson
Bug#2036: Printer stuck #2.
1. I didn't have lp installed since the installation parameter screen
for this said line printer, not just printer.
Having been a computer operator in times past I KNOW my little HP Deskjet 500
is NO line printer.
2. I ran: insmod lp
the result:
Module:#pages: Used by:
lp 2
Address Symbol Defined by
0082c060 _lp_table [lp]
In fact, I used insmod, rmmod, lsmod, ksyms all a couple of times each or
more, and looked at the man pages, too.
I am happy to report that the '500 now responds to its OWN Reset button
and does the Power On Reset.
I must regretfully add that that is all of the progress made.
3. lsmod /dev/lp0
returns: bash: /dev/lp0: No such device
and I was logged in as root, too.
Using lp1 or lp2 is no help.
4. Additionally, I had forgotten to mention that the Print Screen button on this
key board works with MS-DOS, but NEVER with Debian yet. (A real pain for a
Linux novice trying to work around this bug by copying various help and data
screens down by HAND! Especially during installation.)
That Print Screen button still doesn't work.
Thanks for all the help. It's going to take a LOT of it to get Debian up to
a Plug -n- Play appliance standard. This printer problem is just one of many.
{([|])}-{([|])}-{([|])}-{([|])}-{([|])}-{([|])}-{([|])}-{([|])}-{([|])}-{([|])}
The above reflects the observations of myself only, unless stated otherwise.
Eddie Maddox, Amateur Lobbyist Great spirits have always encountered
[EMAIL PROTECTED] violent opposition from mediocre minds.
P.O. Box 75321
St Paul MN 55175-0321 Albert Einstein
USA
Re: coming soon
On Sat, 16 Dec 1995, Michael K. Johnson wrote: David Engel writes: 3. /etc/rc[0-6].d will move to /etc/rc.d/rc[0-6].d to match the practice on other Linux systems. Symbolic links will provide compatibility with the old locations. Is this really necessary ? Real SysV's do things the way we have done. I can make symbolic links in /etc/rc.d that point back out to where the directories are instead of moving the directories. I was of the impression that real SysV worked the other way, but I can satisfy everyone. I agree with Ian. Pleas don't do this. Adding alternative paths to the same directories will only add clutter and cause confusion. BTW, I just checked and Solaris uses the same directory structure we already have. Of course, I don't know if that's good or bad. :-) All the other Linux distributions are going to /etc/rc.d/* because that's what comes with the svinit package. Huh? sysvinit comes with etc/rc.d/rc.* files as well as the etc/rc[0-6].d/ structure. It works very well; in practice I've found that it's one of the things that I like better about my Red Hat system than my Debian system. Red Hat uses this rc[0-6].d structure below /etc/rc.d/ Debian (and I also just checked SysV) has /etc/rc[0-6].d/ Slackware has /etc/rc.d/rc.* _files_ What do you refer to as works very well, and what is the standard? OTOH -- some uncluttering of the /etc dir may not bad. But consider this as a me too in company with Ian and David. mfg Rolf Rossius
Re: coming soon
Bruce Perens writes: From: Ian Jackson [EMAIL PROTECTED] 1. The initrunlevel file is moving to /etc from /var/log. /var/run, surely ? /var/run is possibly in a mounted filesystem. Init breaks if it can't find this file. I've been thinking about using a named pipe so that it will work with a read-only root. You can't change run-levels if you can't write this file. Isn't it just as likely that /var/log will be on a mounted filesystem? (In fact /var is a separate filesystem on mine.) -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: coming soon
I can make symbolic links in /etc/rc.d that point back out to where the directories are instead of moving the directories. I was of the impression that real SysV worked the other way, but I can satisfy everyone. I agree with Ian. Pleas don't do this. Adding alternative paths to the same directories will only add clutter and cause confusion. BTW, I just checked and Solaris uses the same directory structure we already have. Ditto Unixware. ttfn/rjk
Re: coming soon
Bruce Perens writes: From: Ian Jackson [EMAIL PROTECTED] 1. The initrunlevel file is moving to /etc from /var/log. /var/run, surely ? /var/run is possibly in a mounted filesystem. Init breaks if it can't find this file. I've been thinking about using a named pipe so that it will work with a read-only root. You can't change run-levels if you can't write this file. Isn't it just as likely that /var/log will be on a mounted filesystem? (In fact /var is a separate filesystem on mine.) In fact, isn't /etc guaranteed to be on the root filesystem? I don't see how a system can boot without it. Why move initrunlevel at all? I think other distributions will leave it in /etc. Jeff
Re: coming soon
I was talking about moving initrunlvl to /etc, not /var/log . Regarding the location of the rc[0-6].d directories, slackware, redhat, caldera, etc. all put them in /etc/rc.d/rc[0-6].d . I don't have to change their locations, but it seems to make more sense for us to be Linux-compatible than SysV-compatible. Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios Q: How many Microsoft engineers does it take to screw in a light bulb? A: None. They just define darkness as an industry standard.
Re: coming soon
From: Jeff Noxon [EMAIL PROTECTED] In fact, isn't /etc guaranteed to be on the root filesystem? I don't see how a system can boot without it. Why move initrunlevel at all? I think other distributions will leave it in /etc. Debian does not currently have it in /etc . I am going to move it there. Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios Q: How many Microsoft engineers does it take to screw in a light bulb? A: None. They just define darkness as an industry standard.
Re: Debian sysvinit and more..
I no longer maintain sysvinit--Bruce Perens does now. You'll want to talk with him. (A few sysvinit-related discussions started last week; it would be good for you to participate in them. Are you on the debian-devel mailing list? If not, ask [EMAIL PROTECTED] to add you.) Could someone mail the latest copy of the Guidelines to Miquel? (As an aside, are they available anywhere on ftp.debian.org? I don't think they are yet; or, at least, I haven't moved anything into the archive.) In short: We'd love to have you involved in the Debian Project. I know we were looking for a maintainer for inn a few weeks ago. I'm not sure if we found one. Ian? Thanks, Ian Murdock. On Sat, 9 Dec 1995, Miquel van Smoorenburg wrote: Hi, I am considering a new release of my sysvinit (the last official one was 2.50, though debian and Slackware use 2.57). I've converted my system to Debian a couple of weeks ago and we also install it on customers machines. (We used to have our own distribution, but it the maintenance was too much work). Now since I use and support Debian, I'd like to make it as debianized as possible. However, you are the maintainer of debian-sysvinit. What would be wise? I have already converted all paths to the debian/FSSTND ones, and I will include the Debian /etc directory stucture instead of the old examples. But should I already include the debian.* files or should the package maintainer do that, so that my package stays generic and there is a well defined base. The same goes for minicom, actually. Other questions. :) Since we install Debian on our own systems and on servers for customers, we need a stable server distribution. I've made Debian packages for sendmail-8.7.1 and INN-1.4UNOFF3 that run pretty well. (And sendmail can be autoconfigured). I am also considering making a package for apache since we also install that on most systems, and a new UUCP package since I hate to have all uucp commands in /usr/sbin while even the FSSTND recommends /usr/lib/uucp (which is also a nice place to put the uucp maintenance and reports scripts we use). Could you point me to documentation or a URL where I can find info on how to contribute this back into Debian (if people are interested ofcourse). Thanks, Mike. -- + Miquel van Smoorenburg + Cistron Internet Services + Living is a | | [EMAIL PROTECTED] (SP5) | Independent Dutch ISP | horizontal | + [EMAIL PROTECTED] + http://www.cistron.nl/+ fall+
Re: Debian sysvinit and more..
Yes, Miquel, we'd love to have you on the project. I think it would be fine for you to maintain init and package the debian.* files in your main source distribution. Bruce Here is the new draft packaging guidelines written by Ian Jackson. This is Info file guidelines.info, produced by Makeinfo-1.63 from the input file guidelines.texi. File: guidelines.info, Node: Top, Next: Additional Information, Prev: (dir), Up: (dir) Debian GNU/Linux Packaging Guidelines * (This file was last updated on 6th November 1995. Please check the directory `project/standards' at any Debian GNU/Linux archive for a potentially more up to date copy.) This file documents the steps that must be taken in the preparation of a Debian GNU/Linux package. All submissions to be included in the distribution proper and all packages to be considered for `contrib' or `non-free' availability *must* conform to the guidelines and standards described in this document or they cannot be included or made available at the archive with the distribution. Please read the Guidelines carefully. If you have comments or questions, please contact [EMAIL PROTECTED]'. If you are planning on going further than just contributing a package (i.e., if you plan to maintain it for an extended period of time or if you are generally interested in becoming more involved in the Project), you should join the `debian-devel' mailing list. For more details, read `info/mailing-lists.txt', available at any Debian GNU/Linux archive. * Menu: * Additional Information:: * Package Copyright:: A few words about the importance of understanding the package copyright. * Package Content:: Requirements for the package content. * Source Package:: Creating the source package. * Binary Package:: Creating the binary package. * Control Files:: The binary package control files. File: guidelines.info, Node: Additional Information, Next: Package Copyright, Prev: Top, Up: Top Additional Information ** These Guidelines are intended to be fairly general. More specific information is available about certain aspects of building packages, such as how to use the features of Init under Debian GNU/Linux. This information can be found in the directory `project/standards' at any Debian GNU/Linux archive. At the time of this writing, the following documents are available: `README.etc-skel' A description of `/etc/skel' and `/usr/doc/examples'. `descriptions.txt' How to write an extended (and more useful) `DESCRIPTION' field. `README.init' How to use the features of Init under Debian GNU/Linux in packages. `mailers.txt' How to properly configure packages to use the Debian GNU/Linux mail system. `maintainer-script-args.txt' All the ways that the package maintainer scripts inside a package can be called by dpkg. `dpkg-upgrades+errors.txt' What order things happen in during a package upgrade. `virtual-dependencies.txt' How to use virtual dependencies in packages. `virtual-package-names-list.text' The list of virtual package names currently in use, together with the procedure for getting new virtual package names allocated. `dependency-ordering.txt' How to properly order package names in the `DEPENDS' field. There are a number of documents that describe more technical details of dpkg's operation, that will probably only be of minority interest. Please read them if you're doing anything complicated. `auto-deconfiguration.txt' How dpkg can sometimes automatically deconfigure packages in order to do bulk installations smoothly. `dpkg-essential-flag.txt' How to tell dpkg a package is essential and should not be removed. (This is for the use of base system packages only.) `dpkg-disappear-replace.txt' What happens when a package appears to have been completely replaced. In the future, we hope also to make available: `copyright.txt' How to choose a good copyright notice to attach to new programs. `version-ordering.txt' The algorithm with which packages' version numbers are compared. Also, you should download the sample files and the sample package (GNU Hello) available in `standards/samples'. You may use any of this material as a starting point for new packages. The following sample files, incidentally, are available: * debian.README * debian.control * debian.postinst * debian.postrm * debian.rules File: guidelines.info, Node: Package Copyright, Next: Package Content, Prev: Additional Information, Up: Top Package Copyright * Please study the copyright of your submission *carefully* and *understand it* before proceeding! If you have doubts or questions, please ask! In order to understand how we classify and distribute certain packages, it
bind package, maintainer wanted ...
Hi, I'm searching for a new maintainer for the bind package. I don't use it myself so I'm probably not the right person to maintain it. Peter -- Peter TobiasEMail: Fachhochschule Ostfriesland [EMAIL PROTECTED] Fachbereich Elektrotechnik und Informatik [EMAIL PROTECTED] Constantiaplatz 4, 26723 Emden, Germany
bind package, new maintainer!
Hi, the new maintainer for the bind package is Robert Leslie [EMAIL PROTECTED]. Thanks, Peter -- Peter TobiasEMail: Fachhochschule Ostfriesland [EMAIL PROTECTED] Fachbereich Elektrotechnik und Informatik [EMAIL PROTECTED] Constantiaplatz 4, 26723 Emden, Germany
Bug#2036: Printer stuck #2.
Try /dev/lp0, /dev/lp1, and /dev/lp2 . I don't think the print screen button works, but you can print any of the virtual screens (the ones that you access by pressing Alt-F1 through Alt-F12) with the command (as root) cat /dev/vcs0 /dev/lp0 . Change the vcs and lp numbers as appropriate. Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios Q: How many Microsoft engineers does it take to screw in a light bulb? A: None. They just define darkness as an industry standard.
efax-07a-3
This release fixes the bugs from #2033.
If you are using efax-07a, please install this and let me know what you think
about, esp. the interaction between preinst and postinst. This is required to
save changes that a user could have made to /usr/bin/fax from efax-07a-{0,1}
before the sourcing of /etc/efax.rc was introduced.
NB: This is an ELF release.
Date: 16 Dec 95 23:21 UT
Source: efax
Binary: efax
Version: 07a-3
Description:
efax: Programs to send and receive fax messages.
Priority: Low
Changes:
* efax-07a-3 release
* efax.rc: (no real change) FAXINDIR, FAXOUTDIR, FAXLOGDIR use
/var/spool/* and not /usr/spool/* as this looks better (bug#2033)
* debian.rules: creates directories recvq, sendq and log in
/var/spool/fax with mode 2775 and group dialout (bug#2033)
* debian.postinst, debian.control: suggests /etc/efax.rc for
local changes instead of /usr/bin/fax (bug#2033)
* debian.postinst, debian.preinst: save existing fax script and
deal with it; /usr/bin/fax is no longer a conffile (bug#2033)
Files:
-rw-r--r-- 1 root root91636 Dec 16 18:20 efax-07a-3.tar.gz
-rw-r--r-- 1 root root10284 Dec 16 18:20 efax-07a-3.diff.gz
-rw-r--r-- 1 root root75860 Dec 16 18:21 efax-07a-3.deb
623c7b41432a92ab6b9cdb47132459f0 efax-07a-3.tar.gz
b46747075d9e59d81addb35281dae251 efax-07a-3.diff.gz
870cd42b3fccc9a007edeceb6a4b2d64 efax-07a-3.deb
--
Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd
0.93 - 1.1 upgrade procedure?
I rendered by system nonfunctional today. It wasn't entirely unexpected, but it was disappointing. I downloaded a snapshot of the development tree packages, and ran dselect [I]nstall on them. (Ian J. -- FYI, this was with dpkg-1.0.5, subsequent to the problems I've emailed you about). The result was a system which booted OK but hung on login. I'm guessing that this comes from the readline vs. bash problem which was discussed here recently. I had been running a hybrid system with the variously-revisioned elf development packages announced on 11 Nov. Those packages are now lost from my system, and I've now dropped back to a 0.93R6 system. What's the current recommended procedure for installing elf and ncurses development upgrades to a 0.93R6 system?
Re: coming soon
On Sat, 16 Dec 1995, Michael K. Johnson wrote: All the other Linux distributions are going to /etc/rc.d/* because that's what comes with the svinit package. It works very well; in practice I've found that it's one of the things that I like better about my Red Hat system than my Debian system. Last time I looked at the source to sysvint, both the /etc/rc?.d and /etc/rc.d setups were represented. I also feel obligated to mention that I gave my copy of the Caldera Preview II to one of my co-workers to run on his machine the moment I read in the manual that they used the in-between configuration for sysvinit. It's a shame, too, because I could actually use some of the NetWare administration tools. I mean, if you want BSD, use simpleinit or something. If you want the ease of use of the system V stuff, do it right. Mike. -- I'm a dinosaur. Somebody's digging my bones.
Bug#2037: bibtex not searching $TEXINPUTS
Package: bibtex Version: 0.99c-3 Bibtex isn't searching $TEXINPUTS for .bst files if $BSTINPUTS is empty. It goes directly to the system default .bst input directory (which is /usr/lib/texmf/bibtex/bst/). Debian 0.93R6 Kernel 1.2.13 Libc 4.6.27
