Bug#1800: missing terminfo keydefs
package: ncurses-runtime version: 1.9.4-0 I'm no ncurses or terminfo expert, but I've been trying to get ae working with terminfo in anticipation of the junking of termcap, and I've run into some missing key definition problems for TERM=linux. I've looked at the terminfo source in an earlier version (1.8.7) which I happen to have available, and find keydefs apparently missing from data/linux. The apparent missing defs I noticed are for kf20-kf29 (Shifted F1-F10, or f11-f20), kil1 (insert key) and kdel1 (delete key). I haven't checked files other than data/linux. At a minimum, data/linux and data/xterm should be defined to the keys available on the usual PK keyboards, I'd expect. It's very possible that I'm missing something here but, in my ignorance, that's what it looks like to me. [EMAIL PROTECTED] (Bill Mitchell)
Re: ELF conversion
David Engel writes ("Re: ELF conversion"):
> > > > Yuk. Why can't we use a sensible location, such as /usr/lib/a.out/*
> > > > (and /usr/bin/a.out/* if we need it) ? See what the FSSTND has to say
> > > > about things that think they need a directory right under /usr.
> > >
> > > Because $prefix/i486-linuxaout is the standard directory where the GNU
> > > development tools expect to find a.out files on an ELF system.
> >
> > Then the GNU development tools are broken, surely ?
>
> I don't think so. With ELF now being the default, a.out is considered
> a cross-environment. Why should the GNU tools handle it any differently
> from other cross-environments?
They shouldn't. In this case IMO all the other cross-environments'
installations are broken too. Last time I looked there was a comment
in the FSSTND that applications shouldn't use directories directly
under /usr, and here we have the GNU compiler set using /usr/ for
many !
> > > I
> > > don't know if the FSSTND has even addressed this yet, but I'm
> > > confident they would sanction it, at least as a short term solution
> > > during the transition.
> >
> > The transition to a.out is not a short term thing. I still have
> > libraries on my system that date from my initial installation 3 years
> > ago; I do not want to have to live with a horrible /usr/i486-linuxaout
> > directory for what may turn out to be the best part of a decade !
> >
> > I think that making assertions about what the FSSTND group would and
> > would not sanction is probably unwise.
>
> Surely, we've got a few FSSTND participants besides you lurking here.
> Dan Quinlan, are you out there?
I'll try to get this discussed by the FSSTND, but there are some
rather heated discussions going on around the proposed BSD merger, and
some people don't seem to like me very much.
> > However, if I try to install bar 3.0, which depends on foo 3.0, dpkg
> > will replace the existing bar - thinking that foo 3.0 must be on its
>
> > way at some point (dselect would have been complaining if foo 3.0
> ^
> > weren't available at all) - and then fail to configure bar if foo 3.0
> > wasn't installed by the end of the run.
> >
> [...]
>
> I don't agree that this is a safe assumption, but I can see where it
> is desirable (maybe even necessary) to have dselect work efficiently
> when installing a large number of packages.
I agree that the assumption isn't necessarily true, but I don't think
there's anyother way of doing this.
> OK, but why even let the installation get to the preinst script? How
> about we add a new dependency field in the control files which tells
> dpkg that the specified packages/versions must already be completely
> installed (unpacked *and* configured) before installing the new
> package? This seems *much* cleaner to me and won't clutter up some
> directory with a bunch of xyz-available links to /bin/true.
But these fields would only be used by the base packages, and the base
packages depend on practically nothing except the libc (and sometimes
each other).
If I provide and document such a field all sorts of other packages
will start to use it, which will break people's attempts to do
bulk-upgrade.
> > The X libraries are not a problem and do not require any of these
> > special mechanisms, because they're not necessary for the package
> > tools to operate.
>
> I disagree. The eventual problem with the X libraries is *very*
> similar to the current problem with libc.
No, it isn't. When the new X comes out you can unpack everything in
any order, and dpkg will sort out the ordering when it comes to set
them up. The fact that X will be broken halfway through the upgrade
is unavoidable, unless you either force the user to install things in
a particular order or have some kind of massive `atomic install of
everything' operation.
> Just because the X packages
> aren't essential to keeping the system running, doesn't mean we
> shouldn't try to make the upgrade procedure any less fool-proof.
This is true but not relevant. The reason for the special handling of
the libc is that it's required for the package installation tools
to operate. The only problem I'm trying to solve there is the
possibility that the user might upgrade their tar or dpkg or something
when the new libc wasn't there yet, and the solution I'm proposing is
to have that attempt fail.
This is not nice for the user, because it means they have to follow
some special README file to invoke dpkg/dselect in the right way in
the right order on the right files, rather than just being able to run
dselect in the usual way. Unfortunately it's necessary.
This situation does not apply to the X packages, so we can make it
easier to upgrade X than to upgrade the libc: to upgrade X you just
use dselect in the normal way.
Ian.
Bug#1801: tar manpage missing
I know the business of manpages for GNU software is a religious issue, but tar seems to be missing one. A number of different linux systems have manpages for GNU tar, although the tar package doesn't contain one as such. Could a manpage be maintained separately ? Austin
Bug#1801: tar manpage missing
Hi Austin -- Did you know about the info page on tar? All you have to do is to type info tar and you get it. I am considering starting a project which would: a) define a standard template for man pages in Linux. I know it would appear that one already exists, but it turns out that what really, really exists is a good overall description of what should be included in the man pages (in /usr/doc/HOWTO/Mini/Manpages), but that's leaves room for ambiguities, and I believe a template would be a very useful addition. b) begin the slow, laborious process of writing new manpages where they don't exist, then start re-formatting existing man pages to a standard template. Once that happens (this coudl take more than a year) then it seems to em the manpages would be ready for a major overhaul -- i.e., an automatic transformation into hypertext, which could/should be combined with a much more powerful indexing scheme than is currently available through apropos. Perhaps you know of some other progress on this issue. If so, I'd be interested to hear about it. BTW, I did write the man pages for the acct package myself, and have forwarded them to the author for comments and to the package maintainer. It turned out (no surprise) that in the process of doing this, I found a number of ambiguities and actual inaccuracies in the information that had existed. So it produced (I hope) some technical progress as well as straight information transfer. The package developer may take a few days yet, though, to go through all of the stuff I sent him and to change whatever needs changing. That's why you haven't heard more about it. Sorry for such a long email. Susan Kleinmann [EMAIL PROTECTED] > > I know the business of manpages for GNU software is a religious issue, > but tar seems to be missing one. > > A number of different linux systems have manpages for GNU tar, > although the tar package doesn't contain one as such. > > Could a manpage be maintained separately ? > > Austin > >
Bug#1800: missing terminfo keydefs
On Fri, 3 Nov 1995, Bill Mitchell wrote: > The apparent missing defs I noticed are for kf20-kf29 (Shifted F1-F10, > or f11-f20), kil1 (insert key) and kdel1 (delete key). It looks like I picked the wrong Capnames off the terminfo(5) man page for these last night. Should be kich1 instead of kil1, and kdch insted of kdel1. The linux console seems to have these defs: kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~, kf20=\E[34~, kich1=\E[2~, kdch1=\E[3, I identified these by using "cat -v" I've tried the same thing in an xterm, and get seemingly strange sequences from the HOME and END keys. One other thing I notice about an xterm is that the NumLock key seems to have no effect. I'm not very familiar with X11, and I may be doing something to cause this. More likely, though, I'm failing to do something and seeing unexpected default behavior which I'll be able to change if I figure out how to do that.
Bug#1802: source.deb package has unexpected Debian subdirectory
package: source version: 1.2.13-4 I ran into a debian user a while ago, and he asked me what the Debian directory was doing in the kernel sources. I'd never noticed it and had to say I didn't know. I see now that /usr/src/linux/Debian contains kernel-headers, kernel-image, and kernel-source subdirs, each with what look like debian packaging files related respectively to include, image, and source packages. It seems as if these should be in the source*.tar.gz package, but not in the unpackaed source*.deb package.
Bug#1803: /etc/termcap linux definition incomplete
package: base version: 0.93.6-8 /etc/termcap is missing some keydefs. Following is a linux entry with the missing keydefs added. console|con80x25|linux:\ :do=^J:co#80:li#25:cl=\E[H\E[J:sf=\ED:sb=\EM:\ :le=^H:bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\ :ce=\E[K:cd=\E[J:so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[m:\ :md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:is=\E[1;25r\E[25;1H:\ :ll=\E[1;25r\E[25;1H:al=\E[L:dc=\E[P:dl=\E[M:\ :it#8:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kb=^H:ti=\E[r\E[H:\ :ho=\E[H:kP=\E[5~:kN=\E[6~:kH=\E[4~:kh=\E[1~:kD=\E[3~:kI=\E[2~:\ :k1=\E[[A:k2=\E[[B:k3=\E[[C:k4=\E[[D:k5=\E[[E:k6=\E[17~:\ :k7=\E[18~:k8=\E[19~:k9=\E[20~:k0=\E[21~:\ :k;=\E[21~:kA=\E[21~:\ :ke=\E[4~:kh=\E[1~:\ :K1=\E[1~:K3=\E[5~:K2=\E[[G:K4=\E[4~:K5=\E[5~:\ :F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\ :F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:\ :pt:sr=\EM:vt#3:xn:km:bl=^G:vi=\E[?25l:ve=\E[?25h:vs=\E[?25h:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr:\ :r1=\Ec:r2=\Ec:r3=\Ec: The xterm entry also has missing keydefs, but I had trouble resolving the HOME, END, and keypad keys in an xterm, so can't provide an update. [EMAIL PROTECTED] (Bill Mitchell)
Bug#1804: manpage of irc missing
Package: irc The manpage of irc is missing. Winfried
