Bug#1931: less" doesn'
On 7 Dec 1995, Mark Nudelman wrote:
> Bill,
> Thanks for sending the info on the two fixes you made in less-290.
>
> I don't quite understand the purpose of the first one. You said:
> >In screen.c, it's presumed that dumb terminals have termcap
> >capabilities. This isn't necessarily true. I added the
> >#ifdef DEBIAN block below to stop a segfault.
>
> Your change causes less to exit immediately when it finds an unknown
> type of terminal, rather than trying to run using minimal ("dumb")
> capabilities. I'm not sure what you mean by "it's presumed that dumb
> terminals have termcap capabilities." The ability to handle the termcap
> functions (tgetflag, etc.) is a feature of the system, not of the terminal.
> It may be that your system's implementation of termcap is failing because
> I'm simulating a tgetent() call by simply strcpy'ing a string into termbuf.
> This would be unfortunate. I guess a better solution, if this is the case, is
> to not call any termcap functions if tgetent fails, and simply hardcode
> some default capabilities. I will look into this.
Here's what happens with the change not compiled in.
Script started on Thu Dec 7 20:03:52 1995
# TERM=crap
# gdb ./less
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.14 (i486-debian-linux), Copyright 1995 Free Software Foundation, Inc...
(gdb) break get_term
Breakpoint 1 at 0x21cc: file screen.c, line 688.
(gdb) r screen.c
Starting program: /home/A/debian/packages/work/less-290/less-290/./less screen.c
Breakpoint 1, get_term () at screen.c:688
688 if ((term = getenv("TERM")) == NULL)
(gdb) n
690 if (tgetent(termbuf, term) <= 0)
(gdb)
698 strcpy(termbuf, "dumb:hc:");
(gdb)
701 hard = tgetflag("hc");
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x600532ed in end ()
(gdb) The program is running. Quit anyway (and kill it)? (y or n) y
#
Script done on Thu Dec 7 20:04:56 1995
I'm not a curses jock, but it appears to me that tgetent() sets
up termbuf as a local variable which termcap doesn't know about,
and then tgetflag() is looking for "hc" in the entry for TERM=crap.
I'm not sure what the required operation for tgetent() is when
it's asked to get a capability for a terminal which isn't present
in /etc/termcap. Perhaps this is a bug in GNU libtermcap. A segfault
in the library call seems a bit harsh, but I don't know if it's
allowed. My man page for ncurses (not GNU curses) says that tgetflag
returns ERR on failure.
Re: fixed: ange-ftp doesn't set TERM=dumb in inner shell
On Thu, 7 Dec 1995, Austin Donnelly wrote: > Could the emacs maintainer (Ian M) include this in the next emacs > release, please ? (I think that version 19.30 is out). Yes, I'll do that. I'll be getting to 19.30 this weekend. > Alternatively, does Ian M want to give the emacs and emacs-el > packages to me ? Actually, thank you for offering, but Emacs is one package that I'd like to keep. I'll be posting the packages that I still maintain but which I would like to give to a new maintainer tomorrow. (There are still a few.)
Re: ncurses build options...
On Thu, 7 Dec 1995, Michael Alan Dorman wrote: > On Thu, 7 Dec 1995, Ian Jackson wrote: > > That all sounds reasonable. I take it that the terminfo manipulation > > programs and the manpages are small enough that having them installed > > on every system is not a problem (ncurses-runtime will be an essential > > package). > > Actually, they're going into a different package. > > > Also, we need to decide on the package naming conventions for shared > > library packages. >[...] > > The runtime package needs to contain the shared library major version > > number in its name, and we need to be prepared to install several > > versions. > > 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? I don't see how this addresses the need for shared libraries to be in an essential packages. If multiple versions may be installed, and older versions might be superseded by newer versions, which essential package will contain the shared libraries? Does dpkg support a virtual package being declared essential? Perhaps if a package declared essential also has a Provides line, the virtual package so named should be considered essential, and dpkg should refuse to remove the last package providing that virtual package. All ncurses shared libs packages could then privede ncurses-shlibs or somesuch, and be dechared essential. (perhaps dpkg already works this way??).
Re: re:-O2 or -O3 ?
> >Does anyone disagree with Brian White ? If not I'll change the > >guidelines back to recommending -O2. > > Brian's right. Stick with -O2. But some verbage in the guidelines about -O3 and tradeoffs with -O2 would probably be a good idea.
Re: j1-7-5
> > Ray, until we get a properly > > packaged, shared version of ncurses, you should probably not link with > > libncurses.so when building libreadline.so. This will allow the > > static version of ncurses to be used for now. > > I'll have to look into this. Who is taking over ncurses? Ray, I hope you've been following the discussion on ncurses. It contains just about everything I promised to send you. > Now that ELF is becoming the standard, bash will probably depend on > a dynamic libreadline RSN. > I'm not fully confident that I know how to make upgrading libreadline > safe. > > I've placed a work in progress version of libdb at > ftp.wi.leidenuniv.nl/pub/linux/devel-ray. > Can you check if this version > 1. is safe, i.e. if there were a base-like package using it, that it >would not break while updating What I did with libc5 was to install the library as libfoo.so.fullversion.new and then rename it and run ldconfig in the postinst script. Ian Jackson, what do you think of adding support for the "installing with a different name and then renaming" step to dpkg. Dpkg could be told which files to do this with by putting a "libfiles" file in the DEBIAN directory. This would be more convenient and consistent (i.e. reliable) than having every developer doing it manually. > 2. does the right thing with regards to the .so link. > 3. is split up correctly in a development and a runtime version. I'll take a look at it. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses build options...
> > Also, we need to decide on the package naming conventions for shared > > library packages. > > Well, tell me if this seems to make sense: > > ncurses-base-1.9.7a-1.deb will contain a minimum set of terminfo files. > It depends on nothing. > > 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. This should be ncurses21-* (or ncurses2.1-*). As was already noted, the major version for the current ncurses is really 2.1. FYI, with ELF shared libraries, the major version if effectively defined by the soname when the library is built. > ncurses-dev-1.9.7a-1.deb wll contain the shared libs, header files and man > pages for library routines. It will depend on ncurses2. This should be in lock step with ncurses21. It should also depend on libc5-dev. > ncurses-bin-1.9.7a-1.deb will contain the terminfo database manipulation > files. It will depend on ncurses2. It should also depend on libc5. > > The runtime package needs to contain the shared library major version > > number in its name, and we need to be prepared to install several > > versions. > > 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? If we support multiple shared library versions, we should allow users to install the -dev package for any of them. Of course, they should only be allowed to have one of them installed at any one time. I chose to put the major versions in the package names for my Tcl/Tk packages (tcl74-deb and tk40-dev) for two reasons. First, it makes it much more obvious for users which -dev package goes with which runtime package. Second, the ftp administrator will be less likely to accidentally delete the -dev packages for older, but still supported, versions if they have different package names from the new ones. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: GCC/binutils shared library search changes?
> 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? Yes, ld (part of binutils) was changed. This was done to allow better control of which libraries were linked in. > If this is going to be a permanent change then I can probably hack the > Imakefiles to make extra lib*.so symlinks. Yes, this is permanent. You could also create them in the debian.rules file. BTW, the generic, Linux X libs were built with -rpath. Please do not do this for Debian. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
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
GCC/binutils shared library search changes?
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: total 0 lrwxrwxrwx 1 sde1000 sde100017 Dec 7 18:50 libFS.a -> ../lib/FS/libFS.a lrwxrwxrwx 1 sde1000 sde100019 Dec 7 18:28 libICE.a -> ../lib/ICE/libICE.a lrwxrwxrwx 1 sde1000 sde100024 Dec 7 18:28 libICE.so.6.0 -> ../lib/ICE/libICE.so.6.0 lrwxrwxrwx 1 sde1000 sde100021 Dec 7 18:57 libPEX5.a -> ../lib/PEX5/libPEX5.a lrwxrwxrwx 1 sde1000 sde100026 Dec 7 18:57 libPEX5.so.6.0 -> ../lib/PEX5/libPEX5.so.6.0 lrwxrwxrwx 1 sde1000 sde100017 Dec 7 18:28 libSM.a -> ../lib/SM/libSM.a lrwxrwxrwx 1 sde1000 sde100022 Dec 7 18:28 libSM.so.6.0 -> ../lib/SM/libSM.so.6.0 lrwxrwxrwx 1 sde1000 sde100019 Dec 7 18:26 libX11.a -> ../lib/X11/libX11.a lrwxrwxrwx 1 sde1000 sde100024 Dec 7 18:26 libX11.so.6.0 -> ../lib/X11/libX11.so.6.0 etc. If this is going to be a permanent change then I can probably hack the Imakefiles to make extra lib*.so symlinks. Steve Early [EMAIL PROTECTED]
Bug#1931: less" doesn'
Bill,
Thanks for sending the info on the two fixes you made in less-290.
I don't quite understand the purpose of the first one. You said:
>In screen.c, it's presumed that dumb terminals have termcap
>capabilities. This isn't necessarily true. I added the
>#ifdef DEBIAN block below to stop a segfault.
Your change causes less to exit immediately when it finds an unknown
type of terminal, rather than trying to run using minimal ("dumb")
capabilities. I'm not sure what you mean by "it's presumed that dumb
terminals have termcap capabilities." The ability to handle the termcap
functions (tgetflag, etc.) is a feature of the system, not of the terminal.
It may be that your system's implementation of termcap is failing because
I'm simulating a tgetent() call by simply strcpy'ing a string into termbuf.
This would be unfortunate. I guess a better solution, if this is the case, is
to not call any termcap functions if tgetent fails, and simply hardcode
some default capabilities. I will look into this.
I understand your other fix, to workaround the kernel bug having to do
with /proc files (actually, both fixes, yours and the one from Raul Miller).
I will try to incorporate these into my next release (although it bothers
me to have to put cruft in my code to workaround kernel bugs).
Thanks again, and let me know if you find any other problems.
--Mark
Re: ncurses build options...
On Thu, 7 Dec 1995, roro wrote: > 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. OK. Easy enough to take care of. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: -O2 or -O3 ?
> > Does anyone disagree with Brian White ? If not I'll change the > > guidelines back to recommending -O2. > > I don't disagree with Brian but am not sure he's adequately proven his > point. He's only told us about what he found when compiling afio. > > Wouldn't it be wise to compare -O2 to -O3 on several (larger) packages > before the guidelines are modified? I think function inlining is something that should be done only for performance-critical applications. The average debian package doesn't fit into that category. If you -O3 everything, you'll get bigger executables, you'll need more memory to run them in, and you'll need bigger hard drives to store them on. I wouldn't be surprised at all if they actually ran *slower* because more memory was being eaten up by useless inlining. People with 4MB and 8MB machines have the most to lose here. Let's save -O3 for packages that can benefit from it, like X servers and math applications. Jeff
Re: ncurses build options...
On Thu, 7 Dec 1995, Ian Jackson wrote: > > ncurses-term-1.9.7a-1.deb will contain the monolithic set of terminfo > > files. It depends on the lockstep revision of ncurses-base (since we > > might move a few more things out of term and into base as they seem > > appropriate -- getting out of sync might cause surprise disappearance of > > important files). > If we decide to move a terminal out of ncurses-term into ncurses-base > then people who have both installed and upgrade ncurses-term before > ncurses-base will miss one of them for a bit. Is this important ? If you mean "during the time it takes them to do the other upgrade" when you say "for a bit", then I think you're right. I would like to confirm some dpkg behavior, though: Take ncurses-base-1 and ncurses-term-1. The decision is made to move Wyse50 terminals from term to base. New versions (xxx-2) are released. User installs base-2, then term-2. This would leave the user without Wyse50, unless dpkg moved the wyse50 from term.list to base.list. Does it do this (you said something earlier today that made it sound like it does)? Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: ncurses build options...
> > ncurses-developer: > > static, debugging and profiling libraries (all in /usr/lib) > > Do we really need/want debugging and profiling libraries? No other > packages currently provide these. I think the debug libraries, at least, are very useful to have. This is a package for developers, after all. :) Jeff
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
Towards support for S/Key
A common source of security problems is often that each service uses its own protocol and code for authentication (ftpd, telnetd, rlogind, login, popd, ...). Besides the inconsistent user interface, this also introduces many oportunities for security holes. This holds in particular for public domain software, for which there is no centralised code management. As we are integrating all these packages into one high quality distribution, I think that this point is worth our attention. Separating authentication code into one library, would offer the following benefits: - consistent interface for all utilities - more security (at least if the library itself is also properly protected) - it becomes much more easy to plug in alternative authentication methods, e.g. S/Key. BTW: a similar thing has been done with the readline library (I'm not sure about this, but at least I have noticed that ftp has command line editing). On the other hand, I don't think that this modularity is easily achieved, as it interferes with many packages. Perhaps more debian-knowledgeable people can add their comments? -- Patrick Weemeeuw, network manager K.U.Leuven, KULeuvenNet, currently at the Dept. of Computer Science Celestijnenlaan 200 A, B-3001 Leuven, Belgium Tel: +32 16 327635 Fax: +32 16 327996 E-mail: [EMAIL PROTECTED] PGP key: ftp://ftp.kulnet.kuleuven.ac.be/pub/people/patrick/pgpkey.asc
Re: ncurses build options...
Michael Alan Dorman writes ("Re: ncurses build options..."):
> ncurses-term-1.9.7a-1.deb will contain the monolithic set of terminfo
> files. It depends on the lockstep revision of ncurses-base (since we
> might move a few more things out of term and into base as they seem
> appropriate -- getting out of sync might cause surprise disappearance of
> important files).
I don't think this is necessary, and even if it were a straightforward
dependency wouldn't help.
If we decide to move a terminal out of ncurses-term into ncurses-base
then people who have both installed and upgrade ncurses-term before
ncurses-base will miss one of them for a bit. Is this important ?
> 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?
Someone else will have to answer this.
Ian.
Re: re:-O2 or -O3 ?
>> Note that "-O2" is the highest form of optimization that does not trade >> off space for speed. Since Linux is sometimes run on machines with very >> tight memory/disk constraints, then trading off significant space (>20%) >> for insignificant speed (<10%) is, IMO, not worth it. Measuring speed >> improvement is, unfortunately, much more difficult than measuring program >> size. > >Does anyone disagree with Brian White ? If not I'll change the >guidelines back to recommending -O2. Brian's right. Stick with -O2. Behan Webster -- ,---. Behan Webster | The opinions expressed above are mine and | [EMAIL PROTECTED] | in no way reflect those of BNR or [EMAIL PROTECTED] | (613) 765-5502 `---'
Re: -O2 or -O3 ?
>> Does anyone disagree with Brian White ? If not I'll change the >> guidelines back to recommending -O2. > >I don't disagree with Brian but am not sure he's adequately proven his >point. He's only told us about what he found when compiling afio. I didn't find it. I was just commenting on, and providing explanation for, somebody else's results. >Wouldn't it be wise to compare -O2 to -O3 on several (larger) packages >before the guidelines are modified? My point was that I don't think "-O3" should be a rule because, in general, I believe it will make packages larger without significant increase in speed. There may be packages where the speed increase is enough to justify using it. There may be cases where individual files should be compiled with "-O3" and not the rest. In the end, it is up to the maintainer to make the judgement call. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#1984: dpkg won't install cdtool
On Thu, 7 Dec 1995, Ian Jackson wrote: > That sounds like the same bug. > I'm worried about it, but I don't have enough to go on. I'll see if I can re-create it. I'll mention that I _may_ have done the first installation of cdtool with 1.0.6, but then you warned people away from it and I grabbed 1.0.7, which is what I was using when I could not install it. I upgraded and installed other programs with no trouble during this same time period. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: ncurses build options...
On Thu, 7 Dec 1995, Ian Jackson wrote: > That all sounds reasonable. I take it that the terminfo manipulation > programs and the manpages are small enough that having them installed > on every system is not a problem (ncurses-runtime will be an essential > package). Actually, they're going into a different package. > Also, we need to decide on the package naming conventions for shared > library packages. Well, tell me if this seems to make sense: ncurses-base-1.9.7a-1.deb will contain a minimum set of terminfo files. It depends on nothing. 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. ncurses-dev-1.9.7a-1.deb wll contain the shared libs, header files and man pages for library routines. It will depend on ncurses2. ncurses-bin-1.9.7a-1.deb will contain the terminfo database manipulation files. It will depend on ncurses2. ncurses-term-1.9.7a-1.deb will contain the monolithic set of terminfo files. It depends on the lockstep revision of ncurses-base (since we might move a few more things out of term and into base as they seem appropriate -- getting out of sync might cause surprise disappearance of important files). > I think that `developer', while nice and explanatory, is rather long > to appear in package listings and the like, so I'd favour using `-dev' > instead. Done. > The runtime package needs to contain the shared library major version > number in its name, and we need to be prepared to install several > versions. 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? Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Bug#1984: dpkg won't install cdtool
Michael Alan Dorman writes ("Re: Bug#1984: dpkg won't install cdtool"):
> I'll see if I can re-create it. I'll mention that I _may_ have done the
> first installation of cdtool with 1.0.6, but then you warned people away
> from it and I grabbed 1.0.7, which is what I was using when I could not
> install it.
If you were bitten by the stupid bug in 1.0.6 you'll have noticed,
since it will have prevented dselect from installing anything - but
you said (or Raul said) that you weren't using dselect anyway.
> I upgraded and installed other programs with no trouble during this same
> time period.
That's somewhat encouraging.
I can't think of anything that could cause dpkg to think a file was on
the disk when it wasn't except some other program somewhere having
actually removed it.
Very old versions of dpkg have problems in this area, so if you
installed several `overlapping' packages a long time ago you might
find effects like this.
Ian.
Re: -O2 or -O3 ?
On Thu, 7 Dec 95 19:36 GMT, Ian Jackson <[EMAIL PROTECTED]> said: > Does anyone disagree with Brian White ? If not I'll change the > guidelines back to recommending -O2. I don't disagree with Brian but am not sure he's adequately proven his point. He's only told us about what he found when compiling afio. Wouldn't it be wise to compare -O2 to -O3 on several (larger) packages before the guidelines are modified? --Mike
Bug#1205: compiling strace
Wichert Akkerman writes ("Bug#1205: compiling strace"):
> Compiling strace with newer kernel sources is not so difficult as the
> bug reports from Ray Dassen suggest. Starting with the strace source
> as found on sunsite's devel/strace
>
> diff --recursive strace-3.0/syscall.c strace-new/syscall.c
> 35a36,41
> > #ifdef LINUX
> > #define __KERNEL__
> > #include
> > #undef __KERNEL__
> > #endif
> >
> diff --recursive strace-3.0/system.c strace-new/system.c
> 40a41
> > #include
>
> I've compiled it here with sources for kernel 1.3.0. Newer kernels should
> also work.
Would you like to be the strace maintainer ?
There is another thing that needs changing in strace - or at least, it
needs changing for me, because I have a /proc-paranoia patch
installed.
/proc//mem isn't useable other than by root on my system, and
though there is alternative code in strace it isn't enabled on Linux.
I'd like to see strace use the alternative code if /proc//mem
fails.
Ian.
Re: right place for wtmp?
brian white writes on debian-user: > [someone wrote:] > >Btw, uucp coming with debian has /usr/spool/uucp compiled in, shouldn't > >this be /var/spool/uucp? > > /usr/spool is a symlink to /var/spool. Nevertheless, UUCP should look in /var. Should we report this as a bug ? Ian.
Re: ncurses build options...
Michael Alan Dorman writes ("ncurses build options..."):
> OK, here's what I think I've come up with:
> [snip]
That all sounds reasonable. I take it that the terminfo manipulation
programs and the manpages are small enough that having them installed
on every system is not a problem (ncurses-runtime will be an essential
package).
Also, we need to decide on the package naming conventions for shared
library packages.
I think that `developer', while nice and explanatory, is rather long
to appear in package listings and the like, so I'd favour using `-dev'
instead.
The runtime package needs to contain the shared library major version
number in its name, and we need to be prepared to install several
versions.
Ian.
Bug#1984: dpkg won't install cdtool
Michael Alan Dorman writes ("Re: Bug#1984: dpkg won't install cdtool"):
> I had cdtool-1.0-3 installed. I did a 'dpkg --install cdtool-1.0-4'.
> Tried to run one of the cdtool programs --- it wasn't there.
> Reinstalled. Still wasn't there. Grabbed a copy of -3 and installed
> that. _Still_ wasn't there. I started comparing against the file list
> --- the /usr/doc/copyright/cdtool file was there. I did a 'dpkg --purge
> cdtool'. Then ran the installation again. Everything worked.
That sounds like the same bug.
I'm worried about it, but I don't have enough to go on.
Ian.
Re: re:-O2 or -O3 ?
brian white writes ("Re: re:-O2 or -O3 ? "):
> Note that "-O2" is the highest form of optimization that does not trade
> off space for speed. Since Linux is sometimes run on machines with very
> tight memory/disk constraints, then trading off significant space (>20%)
> for insignificant speed (<10%) is, IMO, not worth it. Measuring speed
> improvement is, unfortunately, much more difficult than measuring program
> size.
Does anyone disagree with Brian White ? If not I'll change the
guidelines back to recommending -O2.
Ian.
Re: ncurses build options...
On Thu, 7 Dec 1995, David Engel wrote: > This will be necessary -- the ncurses developers have already changed > the shared library version number once since they introduced shared > library support and have indicated they won't hesitate to do so again. I wondered at the fact that soname was .2.1. > ncurses-base: base terminal definitions That's no problem. It'll be a tiny package, but no big deal. > ncursesNN-lib: shared library only, multiple major versions allowed > ncurses-progs: programs and manual pages And make ncurses-progs dependent upon the appropriate ncursesNN. > Do we really need/want debugging and profiling libraries? No other > packages currently provide these. Fair enough. For my purposes it just means the builds will be faster. > No. The header files should go in /usr/include with > /usr/include/ncurses being a symlink to /usr/include for backwards > compatibility. Remember, ncurses is replacing curses and should be > installed as curses. Please look at the interim version that I did. OK. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: ncurses build options...
> OK, here's what I think I've come up with: > > ncurses-runtime: > shared libraries (in /lib) > looks for files first in /etc/terminfo then /usr/lib/terminfo > has linux as compiled in fall-back. > terminfo manipulation programs > man pages for the programs > small terminfo database in /etc/terminfo > includes ansi, dumb, linux, sun, vt52, vt100, vt102, > vt220, xterm How do you plan to support multiple major versions simultaneously? This will be necessary -- the ncurses developers have already changed the shared library version number once since they introduced shared library support and have indicated they won't hesitate to do so again. One suggestion is to break this down into even smaller packages like this: ncurses-base: base terminal definitions ncursesNN-lib: shared library only, multiple major versions allowed ncurses-progs: programs and manual pages > ncurses-developer: > static, debugging and profiling libraries (all in /usr/lib) Do we really need/want debugging and profiling libraries? No other packages currently provide these. > header files (in /usr/include/ncurses) No. The header files should go in /usr/include with /usr/include/ncurses being a symlink to /usr/include for backwards compatibility. Remember, ncurses is replacing curses and should be installed as curses. Please look at the interim version that I did. > examples and documentation (including man pages > > ncurese-terminals: > all of the terminals not in ncurses-runtime, installed in > /usr/lib/terminfo OK. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Bug#1987: No information on how to get started
Looking at the Debian directory at my local mirror, I do not find any information on how to install Debian onto a system. There is no informantion in any of the README* files in the main directory, and only a passing reference in the FAQ (where there is some talk about rootdisks and bootdisks, but not where to find them, how to make them, what to do with them, ...). -- Thomas Kvnig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram.
Re: dselect user interface (was Re: Bug#1959: binutils desc should says its necessary for gcc)
>That's right. I need someone to design a completely different user >interface for the package selection function in dselect. The current >list interface will survive and just have "- wizard mode" tacked onto >the menu item. Most people will use "- normal mode" or whatever we >decide to call it. I think that the list of packages should be split up some way in order to reduce the feeling of overload one can get when looking at a list of hundreds. The current organization into sections is probably a good place to start, though cross-section dependencies may make this hard. Sections like devel are also quite crowded, so possibly there should be some other criterion (e.g. distinguishing between devel/ packages which are `standard' and those which are merely `recommended' and so on.) There should probably be a *really* dumbed down version which just asks `do you want to install the development tools' and such questions. But I think there may need to be a level between this and the current dselect as well. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: Unidentified subject!
> > I don't know that the patch even exists anymore. However, a quick and > > dirty hack is only a two line change in read_entry.c. > > Actually, ncurses source is clear and commented enough that I don't even > think this counts as q-n-d just because it's quite obvious what's going on. The reason I called it q-n-d is because the old patch was more complete and allowed the second directory to be specified as an option to the configure script. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
ncurses build options...
OK, here's what I think I've come up with: ncurses-runtime: shared libraries (in /lib) looks for files first in /etc/terminfo then /usr/lib/terminfo has linux as compiled in fall-back. terminfo manipulation programs man pages for the programs small terminfo database in /etc/terminfo includes ansi, dumb, linux, sun, vt52, vt100, vt102, vt220, xterm ncurses-developer: static, debugging and profiling libraries (all in /usr/lib) header files (in /usr/include/ncurses) examples and documentation (including man pages ncurese-terminals: all of the terminals not in ncurses-runtime, installed in /usr/lib/terminfo I think this satisfies all the suggestions that have been made. Let me know if you see anything wrong. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Unidentified subject!
On Thu, 7 Dec 1995, David Engel wrote: > > So far I have been unable to find a copy of the patch that lets you fall > > back to another directory. However, support is already in there to allow > I don't know that the patch even exists anymore. However, a quick and > dirty hack is only a two line change in read_entry.c. Actually, ncurses source is clear and commented enough that I don't even think this counts as q-n-d just because it's quite obvious what's going on. This is the first time in ages I've looked at someone else's source code and not been driven barking mad. So Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: Bug#1978: man: default pager should be less
In article <[EMAIL PROTECTED]> you wrote: : >Something ought to be done though, since more(1) can't be made to go : >backwards through manpages. This is rather a serious deficiency. : HP-UX's more(1) doesn't allow you to go back at all. Ever. :) Until HP-UX 10.X, at which point it has very less-ish behaviour. Check the man page, or just hit 'b' by accident thinking you're in less, and be amazed. It's the little things that make you so happy sometimes... :-) Bdale
Re: Bug#1978: man: default pager should be less
In article <[EMAIL PROTECTED]> you write:
>Austin Donnelly writes ("Bug#1978: man: default pager should be less"):
>> On Wed, 6 Dec 1995, Bill Mitchell wrote:
>> > less(1) isn't necessarily installed. more(1) is.
>>
>> Good point.
>
>Something ought to be done though, since more(1) can't be made to go
>backwards through manpages. This is rather a serious deficiency.
HP-UX's more(1) doesn't allow you to go back at all. Ever. :)
Austin
Bug#1986: stdio broken? Strange behaviour of fgets() and scanf()
> Maybe that's it. Maybe 'fgets' is interfering with how scanf works. > Does it still fail if you remove the 'fgets' from the for loop? Yes, it still fails. I tried removing the #define from the start of the string to be matched, though, and it no longer fails. OTOH, the original program (which is too long to reproduce here) which reads a file largely consisting of #define SYMBOL VALUE lines also fails, reading to the end of the file and then carrying on reading nothing. Steve Early [EMAIL PROTECTED]
Re: Building ncurses...a couple of questions...
> > You can handle it by creating both /etc/terminfo and /usr/lib/terminfo > > as directories, and configuring ncurses to search them in order. Then we > > can put the linux and ansi terminfo entries in the /etc one, and everything > > else in the /usr/lib one. > > So far I have been unable to find a copy of the patch that lets you fall > back to another directory. However, support is already in there to allow I don't know that the patch even exists anymore. However, a quick and dirty hack is only a two line change in read_entry.c. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: re:-O2 or -O3 ?
>> I'm surprised that [-O3] make a 20% increase in code size, especially for >> the probably negligible performance improvement. >> >> [...] >> The bottom line is, unless your function is _very_ short (a few lines, >> max, with no loops) in probably should _not_ be inline. It sounds >> like the GCC "heuristic" does just this, but it probably isn't as good >> as a human could decide (with the "inline" directive). >> >> I vote against using "-O3" and to stick with "-O2". > >We're building a distribution, so it makes sense to trade off >computation at build time against computation at run time. I agree with that. The trade off I am against, in general, is significant program size for insignificant program speed. >I thought that the different -O levels in GCC were different values >of that tradeoff; if so, then we should be using the highest >available. True, but there is more... Using the highest will make it run faster (usually), but also makes the program size larger. If inline functions make a program 20% larger and only produces a 5% increase in speed, is it worth it? >If the different -O levels have some other general scheme I'd like >to be enlightened as to what it is. >From the GCC info page (v2.7.1)... '-O' '-O1' With `-O', the compiler tries to reduce code size and execution time. `-O2' Optimize even more. GNU CC performs nearly all supported optimizations that do not involve a space-speed tradeoff. The compiler does not perform loop unrolling or function inlining when you specify `-O2'. As compared to `-O', this option increases both compilation time and the performance of the generated code. `-O3' Optimize yet more. `-O3' turns on all optimizations specified by `-O2' and also turns on the `inline-functions' option. Note that "-O2" is the highest form of optimization that does not trade off space for speed. Since Linux is sometimes run on machines with very tight memory/disk constraints, then trading off significant space (>20%) for insignificant speed (<10%) is, IMO, not worth it. Measuring speed improvement is, unfortunately, much more difficult than measuring program size. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#1986: stdio broken? Strange behaviour of fgets() and scanf()
On Thu, 7 Dec 1995, brian (b.c.) white wrote:
> > for (ksnum=0; 1; c=fgets(buf,sizeof(buf),stdin)) {
>
> The third thing in the "for" structure only gets executed at end of
> the loop. 'c' thus has an undefined value on the first iteration
> which just happened to be NULL for you (hence the "(nil)" output).
> GCC should have warned about this if you use "-Wall".
Whoops. Yes, that much is just me being an idiot. The bit about return
values from scanf still stands, though.
> Personally, I don't trust 'scanf' like this. It always seems to get
> confused regarding end-of-line and so never scans where I want it to.
> I always use 'fgets' followed by 'sscanf'. This, however, is not the
> basis of your problem. Why you never get '-1' returned, I don't know.
The fgets() in the 'for' line seems to be to flush the remaining few
characters of the line before using scanf on the next line. Not quite how
I would have written it, but it's always worked up until this version of
libc.
Steve Early
[EMAIL PROTECTED]
Re: Building ncurses...a couple of questions...
On Thu, 7 Dec 1995, J.H.M.Dassen wrote: > I don't see the necessity of this. Take bash for instance: it uses > readline, which uses ncurses. Taking this to its logical absurdity, we get: "Let's just require that everything be on one big hard drive so it's all in the root partition so we don't have to worry about any of this." > I'd like to see a /lib/ncurses.so which uses definitions on the root > fs, in /etc. I looked at the FSSTND on the web, and it doesn't seem to forbid this, or even imply that it's "wrong". Anyone else want to venture an opinion? Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: Building ncurses...a couple of questions...
> The answer, I think, is that anything depending on ncurses that is > expected to work without /usr will have to statically linked --- but that > should be the only change, since the static libs will also have fallback > terminal definitions compiled in. I don't see the necessity of this. Take bash for instance: it uses readline, which uses ncurses. I'd like to see a /lib/ncurses.so which uses definitions on the root fs, in /etc. Why is this not possible? Ray -- LOGIC The principle governing human intellection. Its nature may be deduced from examining the two following propositions, both of which are held by human beings to be true and often by the same people: 'I can't so you mustn't', and 'I can but you mustn't.' - The Hipcrime Vocab by Chad C. Mulligan
Bug#1984: dpkg won't install cdtool
On Thu, 7 Dec 1995, Ian Jackson wrote:
> Michael Alan Dorman writes ("Bug#1984: dpkg won't install cdtool"):
> > Try doing a --purge first. I was having a similar problem and that
> > solved it.
> > I just assumed it was my system, but apparently not.
> ??? I'm very puzzled.
Sorry, looking back over Raul's message, I'm not sure I was seeing the
same thing he was. My problem was:
I had cdtool-1.0-3 installed. I did a 'dpkg --install cdtool-1.0-4'.
Tried to run one of the cdtool programs --- it wasn't there.
Reinstalled. Still wasn't there. Grabbed a copy of -3 and installed
that. _Still_ wasn't there. I started comparing against the file list
--- the /usr/doc/copyright/cdtool file was there. I did a 'dpkg --purge
cdtool'. Then ran the installation again. Everything worked.
I've not tried to reproduce it.
Mike.
--
"I'm a dinosaur. Somebody's digging my bones."
Bug#1205: compiling strace
Hello! Compiling strace with newer kernel sources is not so difficult as the bug reports from Ray Dassen suggest. Starting with the strace source as found on sunsite's devel/strace diff --recursive strace-3.0/syscall.c strace-new/syscall.c 35a36,41 > #ifdef LINUX > #define __KERNEL__ > #include > #undef __KERNEL__ > #endif > diff --recursive strace-3.0/system.c strace-new/system.c 40a41 > #include I've compiled it here with sources for kernel 1.3.0. Newer kernels should also work. Greetings, Wichert.
Re: Building ncurses...a couple of questions...
On Wed, 6 Dec 1995, Raul Miller wrote: > I wasn't thinking about anything specific... I was just worrying about > potential configurations with no /usr partition. > I probably shouldn't have even mailed the original message. No, I think it's a valid question to bring up---I was just confused about how you phrased it. The answer, I think, is that anything depending on ncurses that is expected to work without /usr will have to statically linked --- but that should be the only change, since the static libs will also have fallback terminal definitions compiled in. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
fixed: ange-ftp doesn't set TERM=dumb in inner shell
I send off a bug report against emacs to the emacs maintainers, and
got a patch back.
Here's my report, and the patch, delimited by =-=-=-=-= lines
Austin
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: [EMAIL PROTECTED] (Austin Donnelly)
Newsgroups: gnu.emacs.bug
Subject: ange-ftp doesn't set TERM=dumb in inner shell
Date: 6 Dec 1995 07:39:47 -0500
Lines: 71
Message-ID: <[EMAIL PROTECTED]>
In GNU Emacs 19.29.1 (i486-debian-linuxaout, X toolkit) of Wed Sep 20
1995 on imagine configured using --prefix=/usr --with-pop=yes
--with-x=yes --with-x-toolkit=lucid i486-debian-linuxaout
The standard Debian /usr/bin/ftp has readline support, which is very
nice. However, this means that it outputs control codes to make full
use of the terminal.
The problem is that ange-ftp can't parse the ftp output when it has
all these control sequences in it.
/usr/bin/ftp will keep quiet if TERM is set to "dumb", but as things
stand, it believes TERM to be "xterm", so it outputs "turn keypad on"
and "turn keypad off" codes when giving prompts.
This means that emacs running (with -nw) out of an xterm, or running
in X fully can't do ange-ftp. Starting emacs by typing:
bash$ TERM=dumb emacs &
solves the problem. However, this isn't a long-term solution.
I think the best solution would be to start the ftp client in an
environment where TERM=dumb.
I include the error messages from ange-ftp for completeness below:
(Note that both these buffers contain ESC control characters. I have
also provided uuencoded copies of them in case they get mangled in transit).
--- buffer: *ftp [EMAIL PROTECTED] -
[?1h=open src.doc.ic.ac.uk
ftp> [?1l>Connected to phoenix.doc.ic.ac.uk.
220 sunsite.doc.ic.ac.uk FTP server (Version wu-2.4(23) Sun Jul 9 23:09:29 BST
1995) ready.
Remote system type is UNIX.
Using binary mode to transfer files.
[?1h=ftp>
begin 644 ftp-buffer
M&UL_,6@;/6]P96X@"YD;V,N:6,N86,N=6LN"C(R,"!S=6YS:71E+F1O
M8RYI8RYA8RYU:R!&5%`@2X*4F5M;W1E('-Y7!E(&ES([EMAIL PROTECTED]"E5S:6YG(&)I;F%R>2!M;V1E('1O('1R86YS9F5R
5(&9I;&[EMAIL PROTECTED];6S\Q:!L]9G1P/B`*
`
end
-- buffer: *Messages* --
Loading ange-ftp...
Loading ange-ftp...done
Opening FTP connection to src.doc.ic.ac.uk...
FTP Error: OPEN request failed: [?1l>Connected to phoenix.doc.ic.ac.uk.
begin 644 message-buffer
M3&]A9&EN9R!A;F=E+69T<"[EMAIL PROTECTED],;V%D:6YG(&%N9V4M9G1P+BXN9&]N90I/
M<&5N:6YG($944"!C;VYN96-T:6]N('1O('-R8RYD;V,N:6,N86,N=6LN+BX*
M1E10($5R
To: [EMAIL PROTECTED]
Subject: Re: ange-ftp doesn't set TERM=dumb in inner shell
Thanks. Does this fix it?
cd ~/e19/lisp/
diff -c /rms/e19/lisp/ange-ftp.el.\~1\~ /rms/e19/lisp/ange-ftp.el
*** /rms/e19/lisp/ange-ftp.el.~1~ Thu Nov 16 17:27:14 1995
--- /rms/e19/lisp/ange-ftp.el Wed Dec 6 18:28:40 1995
***
*** 1778,1784
;; It would be nice to make process-connection-type nil,
;; but that doesn't work: ftp never responds.
;; Can anyone find a fix for that?
! (let ((process-connection-type t))
(if use-gateway
(if ange-ftp-gateway-program-interactive
(setq proc (ange-ftp-gwp-start host user name args))
--- 1778,1787
;; It would be nice to make process-connection-type nil,
;; but that doesn't work: ftp never responds.
;; Can anyone find a fix for that?
! (let ((process-connection-type t)
! (process-environment process-environment))
! ;; This tells GNU ftp not to output any fancy escape sequences.
! (setenv "TERM" "dumb")
(if use-gateway
(if ange-ftp-gateway-program-interactive
(setq proc (ange-ftp-gwp-start host user name args))
Diff exited abnormally with code 1 at Wed Dec 6 18:48:56
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The diff in fact works fine.
Could the emacs maintainer (Ian M) include this in the next emacs
release, please ? (I think that version 19.30 is out).
Alternatively, does Ian M want to give the emacs and emacs-el
packages to me ?
Austin
Re: upload directory
Date: Tue, 5 Dec 95 23:03 PST From: [EMAIL PROTECTED] (Bruce Perens) Please do not start uploading to ftp.debian.org again until Ian Murdock says it's OK. He's probably going to want to copy the files over from ftp.pixar.com and so on before he's ready for new uploads. Yes. I spent a few hours moving files out of Incoming last night, and I didn't even get to the files on ftp.pixar.com. Hopefully, I'll have everything moved by tonight, and we'll be back to normal (well, at least until everyone leaves for the holidays... :). I'll give the okay when I'm finished. Thanks.
Bug#1969: w3-el recommends things that don't exist
What happened to netpbm. I just picked a copy from GNU. Why isn't pbmplus free? Thanx, Simon P.S. Yea, Teleport.com is still silly and my senmail is still crazy, Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Bug#1962: kernel needs sbpcd.h editing in some cases
To do a complete & correct kernel configuration for all possible systems requires either M$ or SCO. Even Novell could not do it :-). Once X is up, even minimally, and sources are installed, we can add a make xconfig to allow some flexibility. To do much more, I'll have to ask you-all for help or patience. I'll get to it some day. Really. Simon P.S. Yea, Teleport.com is still silly and my senmail is still crazy, Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
