Re: Shared libraries and symbols
It's OK with me if the guidelines specify that shared libraries be stripped. Thanks Bruce
Bug#4392: xfishtank coredumps at 16bpps
Ok. I will try to get it to run with 16bpp. Everybody seemed just to run
8bpp. Perhaps I am not current.
On Wed, 4 Sep 1996, James A. Robinson wrote:
jimr
jimr Its not compiled for 16bpp.
jimr
jimrCould such programs then have a note telling us about that in the
jimrdescription? It looks bad when one downloads software and gets a core
jimrdump trying to run it. I think many people are running 16bpp, and
jimrmany more will be running it as 2meg become the default -- is this a
jimrmajor problem with most fancy X programs (games and stuff)? Do they
jimrneed to be compiled for different depths?
jimr
jimr
jimrJim
jimr
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{}Snail Mail: FTS Box 466, 135 N.Oakland Ave, Pasadena, CA 91182{}
{}FISH Internet System Administrator at Fuller Theological Seminary {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
Bug#4392: xfishtank coredumps at 16bpps
Its not compiled for 16bpp. Could such programs then have a note telling us about that in the description? It looks bad when one downloads software and gets a core dump trying to run it. I think many people are running 16bpp, and many more will be running it as 2meg become the default -- is this a major problem with most fancy X programs (games and stuff)? Do they need to be compiled for different depths? Jim
Ae and new package format.
After getting pgp up and running, I only had to try dpkg-buildpackage about 4 times before I got it right. (That's actually very easy) At each step of the way the errors were informative enough to get me down the road. I got several errors about the failure of getpwd to return a path. Diff -u appears to choke on files that do not end in proper newlines. For the changelog this required the addition of a bare newline at the end of the file. I also had to move my pgp keys into /root/.pgp so I could sign the proper files. I think, from what I have seen in the documentation that I could have built this as dwarf (rather than root) but the setup for getting root privilage wasn't clear, so copying the keys was the quick fix. So far, I really like the new source format. Thank you Ian for all the fine work and documentation effort! I really like the way that dpkg-buildpackage (or more likely dpkg-source) packs up the original tree in a tar.gz file and then gets rid of the tree. Nice space saving, specialy since it uses the tar.gz file whenever it needs to reference anything in the original source. I am still a little foggy about how pre-depends are handled (or if they are even necessary any longer) and the issues of depends in general, but I have more complex packages that will surely teach me these points ;-) As soon as master gets back within my reach, I will upload the new ae package to incoming. Although there is some discussion about announcing new Debian packages, it isn't clear if our announcement policy has changed in general. Do I need to announce the upload to master anywhere besides here? Do I even need to do that here? It might me nicer if the announcements were generated when the package was moved from Incoming to it's host tree. That way they would be less pre-mature. Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Bug#4404: fsp postinst mildly broken
package: fsp version: 2.71-3 [If I just hit return, it spews; if I actually hit n, it seems to do the right thing fix is probably to change the $input = y to something like $input = y so they don't vanish... Setting up fsp (2.71-3) ... If you want, I can configure FSP so that the daemon runs on UDP port 21, as user ftp, providing access to the files stored in /home/ftp. Some manual configuration of the daemon, and customization of the FTP directory, may be required for the daemon to function as desired. Note that setting up fspd is _not_ required to access FSP archives. You only need to do this if you want to set up your own FSP archive. If in doubt, say no for now, and read the documentation. Do you want me to do this? (y/n) [n] /var/lib/dpkg/info/fsp.postinst: [: too many arguments /var/lib/dpkg/info/fsp.postinst: [: too many arguments Please answer `Y' or `N'. Do you want me to do this? (y/n) [n] n Making sure that the fsp daemon is disabled ... Done.
Re: Ae and new package format.
From: Dale Scheetz [EMAIL PROTECTED] I got several errors about the failure of getpwd to return a path. One of the directories above the current directory is not readable? Bruce
Wouldn't it be nice to have app-defaults files be conffiles?
I know one can have a big file containing customization for all the X apps, but I'd like to be able to modify the app-defaults/xxx file for the xxx app. without having it being overwritten when a new release of xxx is available? Is this a bad idea? YA. -- Yves Arrouye Email: [EMAIL PROTECTED] 7, avenue Leon BolleeWeb: http://www.fdn.fr/~yarrouye/ 75013 Paris Work: +33 45 95 64 59 France Home: +33 53 61 09 55
Re: BSD lpr vs. LPRng
On Aug 28, 11:56pm, Bdale Garbee wrote: } Subject: Re: BSD lpr vs. LPRng } In article [EMAIL PROTECTED] you wrote: } : } : The only incompatibility is that you might have to add a :bk: entry to } : the printcap in order to print to a BSD-lpd-based network printer. } } I care a lot about compatibility with other BSD'ish lpd-based systems. I } could live with this easily. Especially if LPRng's postinst does that for us ;-). But does it mean the BSD lpr should be obsoleted? BTW, has anybody heard about a free lp spooler? Yves. -- Yves Arrouye Email: [EMAIL PROTECTED] 7, avenue Leon BolleeWeb: http://www.fdn.fr/~yarrouye/ 75013 Paris Work: +33 45 95 64 59 France Home: +33 53 61 09 55
Bug#4407: aout-svgalib library not detected by ldconfig
Package: aout-svgalib Version: 1.28-6 This package installs its libraries in /usr/i486-linuxaout/lib But all the other aout libraries seem to be in /usr/lib/i486-linuxaout/lib Unfortunately /usr/i486-linuxaout/lib is not present by default in /etc/ld.so.conf, and so the libraries cannot been found. As a fix I added it to ld.so.conf and reran ldconfig -v. I am using the standard buzz-fixed distribution. Thanks Gordon
Bug#4408: buzz-fixed installation disk broken
Package: boot1440-1 Version: buzz-fixed I need to use the custom boot disks (custom no 1) to start my installation process. However, the modules.tgz file is broken (unexpected EOF during the detar process). I looked at the other boot disks, but all the modules.tgz files seem to be in the same position. What it means is that you do not get any of the ethernet modules with the installation process. The fix for me was complicated; I obtained an image*.deb file, used pkzip on another machine to split it up so that I could get it onto floppies, ran win95 and used pkunzip on the destination machine to extract the .deb file, switched to debian, and used dpkg to extract the modules.tgz file. Then I could get my ethernet card running and continue the installation by ftp. This was using the buzz-fixed installation disks, and as I said custom boot no 1. Thanks Gordon
Bug#4409: Problems with the post-install
Package: kernel-image Version: 2.0.5-1 The post-install seems to look for /vmlinuz, and since I don't have one of those it dies off rather quickly! All my kernels are in the /boot directory, as this is a partition on my IDE drive, and / is on a SCSI drive (which would be difficult to boot from). Surely this is not an unusual setup? This used to be the standard method a few years ago (I have been using linux for many years, and debian for a year or so). As a fix, why not first look in /, and then in /boot? I am using the buzz-fixed distribution. Thanks Gordon
Bug#4411: at should not use Pre-Depends
Package: at Version: 2.9b-1 at is not an essential base package, so it should not use Pre-Depends. Ian.
Re: Ae and new package format.
On Wed, 4 Sep 1996, Bruce Perens wrote: From: Dale Scheetz [EMAIL PROTECTED] I got several errors about the failure of getpwd to return a path. One of the directories above the current directory is not readable? By root? Pwd works ok. I'll keep an eye out. Next time I see these errors, I'll capture a log and investigate it more closely. Thanks, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Bug#4413: setserial should not use Pre-Depends
Package: setserial Version: 2.10-8 setserial should not be an essential base package, so it should not use Pre-Depends. Ian.
Bug#2037: bibtex not searching $TEXINPUTS
[EMAIL PROTECTED]'s mail: Bibtex has nothing to do with TEXINPUTS. As you can see here from the file /usr/lib/texmf/web2c/texmf.cnf, bibtex is supposed to listen to its own variables: [...] Then the kpathsea doku is wrong and the bug should be reassigned to kpathsea (I think it should be reassigned to kpathsea anyhow). From /usr/info/kpathsea.info.gz: TeX environment variables = Kpathsea defines a sequence of environment variables to search for each file type it supports. This makes it easy for different programs to check the same environment variables, in the same order. The following table lists the environment variables searched for each file type in the order they are searched (and a brief description of the file type). That is, only if the first variable is unset is the second variable checked, and so on. If none are set, various other things are checked; *note Path sources::.. [...] `.bst' (BibTeX style file) `BSTINPUTS', `TEXINPUTS' Regards Herbert.
Bug#4413: setserial should not use Pre-Depends
Package: setserial Version: 2.10-8 setserial should not be an essential base package, so it should not use Pre-Depends. Ian. I have just checked out the bugs web site, and notice that I have quite a few outstanding reports on setserial. I will try and update it, but a lot of changes seem to have been made to the administration of the packages. Is there a new guide to the format of the .deb files and their submission? Thanks, Gordon
dpkg and dependencies
Ian Jackson and I have had several exchanges by private email having to do with the dependencies in dpkg, following my bug reports: #4262 (dpkg-source requires cpio) and #4263 (dpkg-source requires patch). We have now come to an impasse. Ian suggested if I were to bring this to debian-devel perhaps someone there will set you straight. Here are the arguments: I cpio is only required by dpkg-source, and not to install packages. I I've added it to Suggests and mentioned it in the Description. This I will be in 1.3.10. (ditto for patch.) S Now I'm confused. I would have thought that since a command within the S dpkg package requires cpio in order to operate, that the whole dpkg package S would be said to Depend on cpio. I No. S This is not my reading of the programmer's manual, which says: S Suggests: S This is used to declare that one package may be more useful with one S or more others. Using this field tells the packaging system and the S user that the listed packages are be [sic] related to this one and can S perhaps enhance its usefulness, but that installing this one without S them is perfectly reasonable. I The manual is correct. I believe dpkg is in accordance with it now. S It is unreasonable to install software (dpkg-source) which won't S function at all without additional files. I So are you suggesting that I should split dpkg up into half a dozen I packages ? Since debian-changelog-mode.el won't work without Emacs I I have to make dpkg depend on Emacs ? Since you can't use I dpkg --print-architecture to determine the build architecture unless I you have GCC and libc installed I should make dpkg depend on those ? I Since dpkg's NFS installation method won't work without NFS loaded I into the kernel I should refuse to allow dpkg to install properly if I you don't have that configured in ? S Yes. S In any case, what is the mechanism to warn the user that only 1 S (or perhaps 0, 2, or some other number) of components of a package S he's got installed ought to be expected to work? I Suggests, plus the Description, and the manuals for the package I components if this is thought necessary. S I find this logic absurd. If it is reasonable to install software that S won't work, then what is the reason? Just to remind oneself of its S existence? S Debian users should be told during the initial installation they will S have 2 choices: S -- realize that some, most, or perhaps all of the software they just Sthought they installed won't work at all, and that they'll need to read Severy doc and every man page and every info page associated with the Spackage in order to identify the components that won't work, or S -- follow religiously every suggestion made by every package. S I doubt this is the common understanding of the word suggests, except S perhaps in the world of organized crime. S The package dependency mechanism does little good if there is not a common S understanding and use of it. OK, will someone please set me staight? Susan Kleinmann
Bug#3762: etc/rc.boot/0setserial usually hangs machine
I have read your bug report regarding setserial... are you still having problems? As far as I know, no other person is having similar problems setserial... If you are still having problems, could you get back to me within the next few days, otherwise I will consider the bug report closed. Thanks in advance, Gordon
Bug#4332: Vulnerability in the Xt library (fwd)
Owen Dunn: I'm currently trying to clear some of Steve Early's backlog of X package bugs; this'll be among them (though it may be a while longer before the packages get converted to the new source format.) Thanks. One suggestion: this particular bug is a quite serious one (uid 0 exploit for FreeBSD has been posted to bugtraq; it probably wouldn't be too hard for someone to adapt it for Linux). So I think the fix should go in the stable tree as well, before converting to the new format... Marek
When to use pre-depends?
Is the essentialness of a package a sufficient condition for using pre-depends? Guy
Bug#4414: rxvt cut loses empty lines
Package: rxvt Version: 2.14 Doing cut and paste from rxvt to anything will discard empty lines. The lines get lost in the cut. Guy
Re: dpkg and dependencies
On Thu, 5 Sep 1996, Susan G. Kleinmann wrote: Ian Jackson and I have had several exchanges by private email having to do with the dependencies in dpkg, following my bug reports: #4262 (dpkg-source requires cpio) and #4263 (dpkg-source requires patch). We have now come to an impasse. Ian suggested if I were to bring this to debian-devel perhaps someone there will set you straight. Here are the arguments: I cpio is only required by dpkg-source, and not to install packages. So? Dpkg-source is a program that will not function without the proper version of cpio, or patch, or diff. This program, by your own definition depends on these other programs/packages. Since it is a delivered functionality of dpkg, it seems only logical that the package should reflect this dependance. S It is unreasonable to install software (dpkg-source) which won't S function at all without additional files. I So are you suggesting that I should split dpkg up into half a dozen I packages ? Since debian-changelog-mode.el won't work without Emacs I I have to make dpkg depend on Emacs ? Since you can't use I dpkg --print-architecture to determine the build architecture unless I you have GCC and libc installed I should make dpkg depend on those ? I Since dpkg's NFS installation method won't work without NFS loaded I into the kernel I should refuse to allow dpkg to install properly if I you don't have that configured in ? S Yes. Well, maybe not a half dozen ;-) However, dpkg and dpkg-dev sounds like a good start. Put all the installation programs, dpkg, dselect, etc, into dpkg and all the development tools like dpkg-source into dpkg-dev. This should make it clearer to you that dpkg-dev does, in fact, depend on the packages in question. WRT the emacs piece, this is not a program, but a thing (script?) that emacs can run to look at dpkg files and as such represents enhanced functionality, so at the most, it might need to appear in the suggests list. On the other hand, if one of the programs providing functionality in the package actually needs this file to operate, then yes, emacs should be in the dependancy list. Luck, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: Do we ever retire packages?
'Michael Meskes wrote:' [EMAIL PROTECTED] writes: I have argued before that a2ps and a2gs are effectively replaced by genscript, and that we should remove them. I think a similar case could be made for xosview as we now have procmeter. Opinions? Remove them. Move them to project/obsolete or some such. -- Christopher J. Fearnley|Linux/Internet Consulting [EMAIL PROTECTED], [EMAIL PROTECTED] |UNIX SIG Leader at PACS http://www.netaxs.com/~cjf |(Philadelphia Area Computer Society) ftp://ftp.netaxs.com/people/cjf|Design Science Revolutionary Dare to be Naive -- Bucky Fuller |Explorer in Universe
Bug#4415: gwm doesn't install documentation
Package: gwm Version: 1.8c-3 gwm's source tree has a comprehensive doc/ directory, but it's not installed. It should be in /usr/doc/gwm, or if trying to keep the package size down, in a gwm-doc package which gwm Suggests:. -- Shields, CrossLink.
