Bug#1527: binary in source package
Package: miscutils Version: 1.3-5 [EMAIL PROTECTED]:tty3:~/zz/miscutils-1.3$ ls -ltr total 462 -rw-r--r-- 1 roro users 388 Mar 21 1995 arch.c ... -rw-r--r-- 1 roro users 26 Jun 20 01:29 debian.conffiles -rw-r--r-- 1 roro users4989 Jun 20 01:29 passwd.c -rwxr-xr-x 1 roro users 12292 Jul 11 06:43 bdflush* -rw-r--r-- 1 roro users2632 Aug 5 04:46 Makefile -rw-r--r-- 1 roro users 422 Aug 5 05:14 debian.control -rw-r--r-- 1 roro users 24452 Sep 30 06:22 login.c -rw-r--r-- 1 roro users2421 Oct 1 22:22 mkboot.sh -rw-r--r-- 1 roro users1584 Oct 2 02:46 installkernel.sh -rwxr-xr-x 1 roro users2282 Oct 2 03:07 debian.rules* -rwxr-xr-x 1 roro users2282 Oct 2 03:07 debian.rules.bak* [EMAIL PROTECTED]:tty3:~/zz/miscutils-1.3$ I don't think the binary bdflush should be provided by the source-package. bdflush.c compiles to update. Please remove bdflush by hand. mfg Rolf Rossius
Bug#1528: change 0.2-5 to 0.2-6 not consistent
Package: ed Version: 0.2-6 [EMAIL PROTECTED]:tty3:~/zz/ed-0.2$ tail -4 debian.README Changes for ed-0.2-6 Priority: High Changes: install ed as /bin/ed instead of /usr/bin/ed [EMAIL PROTECTED]:tty3:~/zz/ed-0.2$ tail -2 debian.postinst ln -s /usr/bin/ed /usr/bin/red [EMAIL PROTECTED]:tty3:~/zz/ed-0.2$ tail -2 debian.postrm rm -f /usr/bin/red debian.postinst and maybe debian.postrm should be corrected wrt the location Bof ed/red. mfg Rolf Rossius
Re: Building ncurses...a couple of questions...
Please keep in mind: ncurses 1.9.7a searches the terminfo entries in - $HOME/.terminfo or, if set in $TERMINFO and then in - /etc/terminfo (this is the debian-special for /usr/lib/terminfo) The first could provide a scheme for startup (/usr not mounted) without hacking the sources further. mfg Rolf Rossius
Re: ncurses build options...
On Thu, 7 Dec 1995, Michael Alan Dorman wrote: > ncurses2-1.9.7a-1.deb will be the shared library package. It is ncurses2 > because the major portion of the soname is 2. It will depend on libc5 and > ncurses-base. > Done. Is it necessary or appropriate to have ncurses-dev be > ncurses2-dev? Correct me if I'm wrong, but we don't plan to support > people compiling with multiple versions, so it should be sufficient to > make sure that ncurses-dev merely has the correct dependencies, right? Contrary to libc5, where the soname is libc.so.5, an therefore libc.so.5.0.0 until libc.so.5.2.16 are interchangeble (or was supposed to be) ncurses has the soname libncurses.so.2.x. ncurses2 has no meaning if the ABI between libncurses.so.2.0 and libncurses.so.2.1 has changed. There are no major/minor numbers in ELF, only soname. The real ncurses2.0 will maybe called curses. ncurses1.9.8 will be released really soon now and contains: dist.mk == # If a new ncurses has an incompatible application binary interface than # previous one, the ABI version should be changed. VERSION = 1.9.8 SHARED_ABI = 2.2 mfg Rolf Rossius
Re: GCC/binutils shared library search changes?
On Fri, 8 Dec 1995, Stephen Early wrote: > Was either GCC or binutils (whichever is appropriate) changed between > gcc-2.7.0-2 and gcc-2.7.2-1 or binutils-2.5.2l.20-2 and binutils-2.6-1 so > that it won't find ELF shared libraries with names like libX11.so.6.0, > only libraries with names like libX11.so? > > I ask because X has suddenly started statically linking the core binaries > when I do a complete build. It compiles the shared libraries first, and > puts symbolic links in a temorary 'usrlib' directory. This directory > looks like this: > If this is going to be a permanent change then I can probably hack the > Imakefiles to make extra lib*.so symlinks. The search for libxxx.so.x.y.z done in older binutils was taken out again three month ago and is not in the binutils-2.6-1. Yes, it will bite a lot of people, but it is ok. I will strongly opt againts the automatic search, if someone want to try to insert this again. Maybe I should have spoken erlier to all developer and package-maintainer. It seems to be a need for a mechanism to provide the information from the release-notes. Here is a snippet from release.binutils-2.6.0.2: = Most of the modifications in binutils 2.5.2l.20 are in here except for the support of lib.so.x.y.z since it may not work under all ELF systems. You have to make a right symlink to lib.so.x.y.z from lib.so when you install lib and if there is none for the existing shared library , i.e., # ln -sf lib.so.x.y.z lib.so = mfg Rolf Rossius
Re: ncurses available on ftp.pixar.com
On Sat, 9 Dec 1995, Michael Alan Dorman wrote: > Since ftp.debian.org seems to still be having problems with people > downloading new files, I'm putting a copy of ncurses-1.9.8a in > ftp://ftp.debian.org/pub/bruce/Incoming, since a handful of people have ^^ You mean ftp.pixar.com > contacted me since yesterday to ask if I could send them copies directly. > I think ncurses wins an award for "most packages from one source archive." Granted. Minor doc-bug in ncurses-1.9.8a/debian.README: ncurses21 should read ncurses3.0 I hope ncurses3.0 will be a stabile ABI, since a lot of packages depends on it. mfg Rolf Rossius
Re: ncurses available on ftp.pixar.com
Another problem: ncurses-base-1.9.8a-1.deb should have a debian.preinst to kill the link etc/terminfo -> ../usr/lib/terminfo provided by base-0.93.6. Or it is intended that these fall into /usr/lib/terminfo? And how to elegantly get rid of the huge /usr/lib/terminfo database w/o installing and purging? mfg Rolf Rossius
Re: ncurses available on ftp.pixar.com
On Sat, 9 Dec 1995, Bill Mitchell wrote: > > On Sun, 10 Dec 1995, roro wrote: > > > And how to elegantly get rid of the huge /usr/lib/terminfo database > > w/o installing and purging? > > Good point. This sounds like a serious user-upgrade issue. This looks > like a dpkg-guru question. > On second thought -- not really. The old ncurses-developer, and ncurses-runtime are not automatically superceded. I could remove developer. dpkg stopped me on removing runtime, because dependencies to dialog and miscutils. I compliled a new miscutils and kicked dialog. Then I removed ncurses-runtime. Now /use/lib/terminfo is no more. Looks pretty cool. OTOH, I should go to bed ... mfg Rolf Rossius
Re: More ncurses...
There is somehow a glitch we have to solve in the pre/post-inst/rm scripts for ncurses and potentially for readline. My bash is now (and should be in the future, maybe even with shared readline): [EMAIL PROTECTED]:tty1:/lib# ldd /bin/bash libncurses.so.3.0 => /lib/libncurses.so.3.0 libc.so.5 => /lib/libc.so.5.2.18 and don't like to be invoked without libncurses.so.3.0 handy. Is it really ok to move libncurses.so.3.0 to libncurses.so.3.0.new in pre --- why is this TRT? Upgrading libc 5.2.16-1 -> 5.2.16-2 -> 5.2.16-3 -> 5.2.18-0 seems to work, but ncurses 3.0-1.9.8a-2 -> 3.0-1.9.8a-3 -> 3.0-1.9.8a-3 left me with /lib/libncurses.3.0.new but without /lib/libncurses.3.0. This has to be avoided at all costs! mfg Rolf Rossius [EMAIL PROTECTED]:tty3:/fs7/debian/binary/base# dpkg -i ncurses3.0-1.9.8a-3.deb (Reading database ... 7711 files and directories currently installed.) Preparing to replace ncurses3.0 (using ncurses3.0-1.9.8a-3.deb) ... sh: can't load library 'libncurses.so.3.0' dpkg: error processing ncurses3.0-1.9.8a-3.deb (--install): subprocess pre-installation script returned error exit status 16 sh: can't load library 'libncurses.so.3.0' dpkg: error while cleaning up: subprocess post-installation script returned error exit status 16 Errors were encountered while processing: ncurses3.0-1.9.8a-3.deb
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
Useless use of "-lfoo" (fwd)
After Ian Lance Taylor from cygnus has confirmed that GNU ld for ELF will continue to behave that way, I'd like to pass this to the maintainer of debian packages. The latest packages I've compiled and seen some superfluous "-lfoo" are: man-2.3.10-6: manpath (-lgdbm) zsoelim (-lgdbm) git-4.3.7-5: gitview (-lreadline) gitcmp (-lreadline -lncurses) gitkeys (-lreadline -lncurses) gitmatch(-lreadline -lncurses) gitwipe (-lreadline -lncurses) perl-5.002-3: a2p (-lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lbsd) mfg Rolf Rossius -- Forwarded message -- Date: Tue, 19 Dec 1995 03:53:35 +0100 (MET) From: roro <[EMAIL PROTECTED]> To: David Engel <[EMAIL PROTECTED]> Subject: Useless use of "-lfoo" A peculiarity of the link editor for ELF (in contrast to aout) will not harm, but sometimes do unwanted things for the resulting binary. I have noticed this in the package git and suspect there are others. The configuration and build process for a packages often collects the names of the needed libraries and add "-lfoo -lbar -lbaz" to the link flags for *all* binaries. Even if no functions or objects from libbar (a shared lib) are required for a binary, the soname of libbar "libbar.so.x" is noted in the bin and this file is necessary at runtime. ELF: [EMAIL PROTECTED]:tty6:~/tmp$ gcc t.c [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libc.so.5 => /lib/libc.so.5.2.18 [EMAIL PROTECTED]:tty6:~/tmp$ gcc t.c -lm [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libm.so.5 => /lib/libm.so.5.0.5 libc.so.5 => /lib/libc.so.5.2.18 For the "aout" format, an additional "-lm" makes no difference (assuming libm is not needed by t.c): [EMAIL PROTECTED]:tty6:~/tmp$ gcc -b i486-linuxaout t.c [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libc.so.4 (DLL Jump 4.7pl5) => /lib/libc.so.4.7.5 [EMAIL PROTECTED]:tty6:~/tmp$ gcc -b i486-linuxaout t.c -lm [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libc.so.4 (DLL Jump 4.7pl5) => /lib/libc.so.4.7.5 I don't know whether it is *that* important. But should the debian package maintainer not be better aware of this fact, be encouraged to adjust the link flags and maybe report to upstream maintainer? What do you think? mfg Rolf Rossius
Bug#4095: depmod doesn't create a proper modules.dep
Package: modules
Version: 2.0.0-7
Depmod fails to create the right side in the dependency file
modules.dep. I suggest a modification to a previous applied
fix to Bug#3781 in 2.0.0-6: Close the file *after* the last
usage.
mfg
Rolf Rossius
--- modules_2.0.0/depmod/load_obj.c.2.0.0-7 Sat Aug 10 16:14:29 1996
+++ modules_2.0.0/depmod/load_obj.c Sat Aug 10 16:14:35 1996
@@ -278,20 +278,20 @@
/* Make sure each file is closed */
/* Michael Meskes 7/29/96 <[EMAIL PROTECTED]> */
if (feof(fp) || ferror(fp)) {
fclose(fp);
return 1;
}
- fclose(fp);
if (N_MAGIC((*aouthdr)) == OMAGIC)
errstr = load_aout(fp, aouthdr, syms, mod);
else if ((header.e_ident[0] == 0x7f) &&
(strncmp((const char *)&header.e_ident[1], "ELF",3) == 0) &&
(header.e_type == ET_REL))
errstr = load_elf(fp, &header, syms, mod);
+ fclose(fp);
#endif /* USE_BFD */
if (errstr != (char *)0)
return 1;
return 0;
}
#endif
