Bug#3985: Wrong parameter type in src/getfd.c
Package: kbd
Version: 0.91-3
I wondered why the 'loadkeys' program didn't work as expected on m68k,
and then I found a little bug in src/getfd.c: It determines the keyboard
type via an ioctl (KDGKBTYPE) which returns a char on the kernel side, but
is put into a 'long' variable. This just happens to work on i386, but breaks
on m68k due to the endianess. Below is a patch.
Frank
Debian-1.1, libc5.2.18, kernel 2.0.8.
PS: Checking for just one explicit keyboard type (KB_101) is not good
either, but that will be fixed later.
--- cut here ---
*** src/getfd.c.origThu Aug 1 00:30:13 MET DST 1996
--- src/getfd.c Thu Aug 1 00:30:23 MET DST 1996
***
*** 14,20
static int
is_a_console(int fd) {
! long arg;
arg = 0;
return (ioctl(fd, KDGKBTYPE, &arg) == 0 && arg == KB_101);
--- 14,20
static int
is_a_console(int fd) {
! unsigned char arg;
arg = 0;
return (ioctl(fd, KDGKBTYPE, &arg) == 0 && arg == KB_101);
New gopher packages
I took the freedom to make gopher bug free. -BEGIN PGP SIGNED MESSAGE- Date: 01 Aug 96 10:03 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Ted Hajek <[EMAIL PROTECTED]> Source: gopher Version: 2.1.1-3 Binary: gopher-client gopherd Architecture: i386 source Description: gopher-client: Client software to access stuff on gopher servers. gopherd: Serves documents using the Internet Gopher+ Protocol. Changes: * Renamed function ustat in g_ustat to get gopherd compile with ELF libc * Corrected version number (Bugs #1718, #1851, #3965) * Added Architecture, Priority and Section field (Bug#3933) * Changed debian.rules file for new naming scheme * Removed 'RECOMMENDS: freeWAIS' line (Bug #1717) * Corrected extended description (Bug #3668, #3683) * Changed weekly cron script (Bug #3262) * Compress manpages Files: 92ae913b3eb3028717a5bfde563173cd 392071 non-free - gopher_2.1.1-3.tar.gz 2b9102a38ca3e551f63104f781107e30 28400 non-free - gopher_2.1.1-3.diff.gz d822bf88ab5f847773d806ef3222c44f 78426 non-free extra gopher-client_2.1.1-3_i386.deb 0cd791e21b4e47e64d0709c5c0daadc7 80930 non-free extra gopherd_2.1.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgCBASpaNcQEtuj1AQE4BAP/fOKh9tuq6e5RTm0c3VhHPQ+QLFoQyBRI WKroydas6NMxgIX7i3nXMAaun1ril6boEGxiAPTw+XHEys3k69vJWWEaHoG+wQAJ PhNh6FkUvWF+kgFZ9ZKI99Z+yXtQlDjahd8St5z9e7QCTpwzY+/luXjkLh5Byg6l CzEiuOFnh+4= =9l7l -END PGP SIGNATURE- -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Re: New virtual package names.
Well, it's been a while, so lets add: imap-client and imap-server to the virtual package names list. On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). 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 --
Re: /usr/doc/copyright/ -> /usr/doc//copyright ?
On Thu, 1 Aug 1996, Ian Jackson wrote: > Should we move the copyright file (and the examples directory) into > the per-package directory in /usr/doc ? I don't think we should move the copyright file. Most people don't ever need to look at them, so it's simpler if they're out of the way. We should discourage making a symlink from /usr/doc/ to the copyright directory. Maintainers are probably just using the copyright more as a general readme. The copyright file need only contain (surprise) copyright information. I do, however, think we should move the examples directory. I've always thought the distinction between /usr/doc/ and /usr/doc/examples/ was arbitrary. It usually leads to the obtuse arrangement where the example is in one directory and its accompanying documentation is another. Guy
Re: Bug#3795: ae should not be essential
> Christian Hudon writes ("Re: Bug#3795: ae should not be essential"):
> > Isn't it that some of the packages that look at EDITOR fall back to ae if
> > there are problems with EDITOR?
vipw and vigr do this. They're in passwd which is essential, but won't
be as soon as I upload a new version.
Guy
Re: color ls (fwd)
Jim Meyering responded: > | This come to via debian mailing list and is about how to activate > | color support for ls. I think the default should be no color at > | all but I doubt if so much aliases as in the message below are the > | proper way to activate color support. Can't this be done in a much > | easier way, for example by checking if LS_COLOR has a value (then > | color) or does not exist or is empty (then no color). > > You're right. It would be better not to alias at all > when the eval sets LS_COLORS to the empty string. (but see below) > So you (Dirk) could bracket his aliases with > > if test -n "$LS_COLORS"; then > alias ... > fi > > | Dirk Eddelb"uttel writes: > | > The old dircolors created the LS_COLORS env variable with your colour > | > selection the default or specified rc file _and_ created the aliases. > | > > | > Now it only builds LS_COLORS so that I changed the code in > | > /usr/local/etc/profile (which I source from /etc/profile) to > | > > | > eval `dircolors -b /usr/local/etc/colour-ls.rc` > | > alias ls='ls --color=auto '; > | > alias dir='ls --color=auto --format=vertical'; > | > alias vdir='ls --color=auto --format=long'; > | > alias d=dir; > | > alias v=vdir; > | > alias ols='/bin/ls ' > > Personally, I think it is bad to impose such common and short-named > aliases on all users. They will cause confusion in many users because > they'll conflict with aliases/functions users had before they switched > to debian. That's why I removed the alias-setting `feature' of the > slackware dircolors -- in addition, trying to accomodate 4-5 different > shell syntaxes made the program unnecessarily (IMHO) complex. > > | > Before, I only needed the "eval 'dircolors -b `" line and > the > | > aliases were built automagically (the format was slightly different, > though, > | > there was also --8-bit or some such). > | > > | > Mark> What is the problem? I've changed a number of things of late - > moved > | > Mark> from tcsh to bash (but same thing happens in both shells), and > | > Mark> upgraded a number of packages. So I don't know what has caused > the > | > Mark> change. Any ideas anyone? > | > > | > Your upgrade to the newest fileutils package which replaced the now > redundant > | > color-ls package. > | > > | > Erick, is there a way that you can persuade/hack dircolors to do what the > old > | > one did? Or put a note in the package to ease transition? > | > | What about it Jim? > > I'll put a note in the info documentation for dircolors on how to > do those things.
Re: /usr/doc/copyright/ -> /usr/doc//copyright ?
> It's nice to have all these files in the same directory, but people > are starting to do things like having /usr/doc/foo/REAMDE be a link to > /usr/doc/copyright/foo or vice versa, and splitting the documentation > for a package up across several directories doesn't seem to work very > well. This symlinking is bad (IMHO). The place of copyright stuff is documented in Debian FAQ (or somewhere else or it should be documented) and is there for quite some time now. Keep it that way. > Should we move the copyright file (and the examples directory) into > the per-package directory in /usr/doc ? No, the /usr/doc/ dir is a dir which normally comes with all stuff in it gzipped and I think we should keep it like that. We can not gzip copyright files (this has been decided/mandated long ago) so I think it isn't good to put an ungezipped file in there. Minor argument is that the current approach is space saving. If no documentation comes with package an dir entry needs to be created for its copyright file, when this is in /usr/doc/copyright this will not be required. I still think that copyright file can/should be autogenerated by the package building process and provide a default part and a free part. Check mailing archives if you want to know more on this. Erick > > Ian. > > >
lyx_0.10.0-1
-BEGIN PGP SIGNED MESSAGE- Date: 31 Jul 96 09:22 UT Format: 1.6 Distribution: unstable stable Urgency: Low Maintainer: Michael Meskes <[EMAIL PROTECTED]> Source: lyx Version: 0.10.0-1 Binary: lyx Architecture: i386 source Description: lyx: High Level Word Processeor (BETA version) Changes: lyx (0.10.0-1): * New upstream version Files: 6c743ed1a91ca91eacc6ea79db4275ee 545882 tex - lyx_0.10.0-1.tar.gz 4916869e071d5c68856b2f0ea0b9b10b 12543 tex - lyx_0.10.0-1.diff.gz 9d24a25eac3c9c5fb16aa717179d4c92 336308 tex optional lyx_0.10.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMf8mEipaNcQEtuj1AQHgGAP7BK1ZNnNp5Jun8Ekng6wcQcU65X/toNWq u8Mwi3eeobsGosQ76qUAh4jUVr/7LXl16kCa7QtLHKmGNms9pcVSWnOvruB9nfMl JiGrgvtcB8LVoGnW0tX6IIX/BbUjwXDkbgb2MoJ1ujQka4jjirIJezMUysRnnmM0 12lQ04F/XHc= =M7jX -END PGP SIGNATURE- -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Re: use of /usr/share
> Erick Branderhorst writes ("use of /usr/share"):
> > Perhaps this is a very sensitive subject but shouldn't architecture
> > independent things like man pages, info manuals, tex & latex styles
> > and a lot of other things being put under a subdir of /usr/share?
>
> The FSSTND people haven't really settled on this yet, and are now
> diverted.
On our network here, we've had great fun with all this. Basically,
there
are four needs:
- System installed files (i.e. debian packages)
- Machine-local installed files
- Network mounted arch-dependant files
- Network mounted arch-independant files
yet there are only three locations
- / and /usr
- /usr/local
- /usr/share
Our general solution was to create a fourth and allocate them as
follows:
- / and /usr : System installed files
- /usr/local : Machine-local installed files
- /usr/site : Network mounted arch-dependant files
- /usr/share : Network mounted arch-independant files
Brian
( [EMAIL PROTECTED] )
---
In theory, theory and practice are the same. In practice, they're
not.
Re: location of sg.h
Mr Stuart Lamble writes: > As of (at the latest) 2.0.0, /usr/include/scsi should be a symbolic link > to /usr/src/linux/include/scsi. Given that libc5 includes the kernel I'll hopefully get time to fix this next week. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: color ls (fwd)
Thanks for forwarding this note by Jim Meyerding. I like his ignoring of /etc/DIR_COLORS, I always found that filename rather ugly and kept my own file /usr/local/etc/colour-ls.rc for these colour settings. IMHO, two things remain: - the fileutils maintainer should patch dircolors so that it gives bright red for .deb files as for .tar and .tgz files. Debian's color-ls did that too - ask Jim why dircolors doesn't generate the aliases as the Slackware version did. Should we patch it to remain backwards compatible? -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Re: f2c-960717-0 uploaded to master
>Could you provide a reference to these benchmarks, and the compiler settings >they used? Or better yet, even run them? I don't really use fortran myself, >but link some of my C++ code with Fortran libraries that other folks have >done. But I could do with a speedup of factor 2 ... see the following web-site http://nils.wustl.edu/schiotz/lapack-linux.html (this is a partial quote) PERFORMANCE: I have compared the speed of the level 3 BLAS routines, using a benchmark program I found on Netlib. I ran it using Dave Webers f2c+gcc compiled library, and also using g77 compiled static and dynamic libraries. Here are the results, obtained on a 75MHz Pentium PC from Gateway2000. --- Speed in Megaflops --- Routine f2c+gcc g77 g77 (shared)(shared)(static) = DSYMM 2.9 5.3 5.6 DSYRK 2.7 5.5 5.6 DSYR2K 3.2 6.0 6.0 DTRMM 2.6 4.6 5.1 DTRSM 2.4 4.1 4.5 - Average 2.765.105.36 - rel. to f2c+gcc 100%185%194% rel. to g77(sh) 54% 100%105% rel. to g77(st) 51% 95% 100% = So I see almost a factor two increase in performance! I also see the expected 5% penalty of the shared libraries, coming from losing one register.
Re: Perl vs Python vs ....
Ian Jackson wrote: > > We only have room for one `extra' scripting language, besides the > usual sh, awk, sed, &c, on the base disks. > > Perl is widely known. It can solve most problems. There are problems > for which it is difficult to get it to work, but these don't often > occur at installation time. > > sh is not suitable for many of the things Perl gets used for - > consider update-inetd, update-info &c. Actually, a /bin/sh script to add inetd.conf entries, and another to remove entries keyed off the service field, was unmentionably simple to code, and has proved quite reliable in (lots of) practice. > For this reason we decided that Perl would be on our base disks, and > that packages could use it (well, the subset that's on the base disks) > in their preinst/postrm. Packages which want something else must > Depend on it and may only use it in their postinst/prerm. There's clearly a place for a stronger scripting language, despite the argument posed above. It's just very sad that it should be perl. perl really fits into many people's stereotypes of "unix as inherently cryptic monster", very neatly. > There is no point having a religious war over this; this decision was > taken a long time ago and can't be changed now, even if we wanted to. This is rhetoric. It could be changed and you know it. What I mean to say is, I really dislike "can't" when what's meant is "won't". I daresay that a linux distribution (or the Hurd, or *BSD, or...) that doesn't fall into the perl trap, should have a brighter future. > Ian.
Re: WWW interface to mailing list archive
> I know we have WWW access to our mailing lists one. But as far as I know, it > is only updated monthly. That is incorrect. > Would someone step forward to take care of that on a > daily basis? It will be... once I've rewritten my scripts (due to my thesis deadline, this will probably in September). Here's the setup as it was before master's disk-crash: - Mail from all mailing lists was sent to [EMAIL PROTECTED] - My .qmail on master invokes procmail - Procmail splits out the lists in per month (or, for -announce, per year) unix mbox-format archives in the master FTP structure directly. - On www.debian.org, which has access to a FTP mirror, a daily cronjob generates the WWW archives from the FTP ones. The same cronjob updates the WWW search engine (currently glimpseHTTP). Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: XF86 betas (Re: D68K: The next step...)
> Speaking of X, as a member of the beta team (XFree86), I have access to > the source code for the XF86 betas. Would it be worthwhile setting up > packages for these in the contrib section? In particular, I'm kind of > annoyed that if I want support for my W32p (revision A), I have to go > to 3.1.2E - and it's not available for Debian. Net result: either I > have proper support for my card, and can't install new X-based packages > (dpkg barfs at the postinst and configuration stages), or I'm stuck with > the SVGA server. Well you can leave the SVGA-server installed and simply add your server somewhere and let /etc/X11/server (or what is its name) have the right path to your server. No dpkg barfing for me. Erick
Re: SLIP not working?
Karl Ferguson writes: > > Hi Everyone... > > I've compiled SLIP into the kernel (2.0.10), however I get this following > message in /var/log/daemon.log: > > Aug 1 10:30:49 orion /sliplogin[319]: attaching slip unit sl0 for karl > Aug 1 10:30:49 orion /sliplogin[319]: /etc/slip.login sl0 9600 319 > 203.22.233.3 203.15.138.211 compressed > Aug 1 10:30:50 orion modprobe: Can't locate module net-pf-4 > Aug 1 10:20:51 orion modprobe: Can't locate module net-pf-5 > > Of course, slip just doesn't seem to work at all. My question is, where are > these modules it can't locate - and if I can find them, will it fix this > problem? > > Any help appreciated. You can edit /etc/mod.conf (from memory) to get rid of those modprobe warnings, but it shouldn't actually affect SLIP working, They are just an alias for particular network procotols I think. I've had those warnings for many kernels and SLIP still works for me (just couldn't be bothered fixing the file, was waiting for some debian thing to do it for me :)) Andrew -- Of course...lager...the only thing that can kill a vindaloo. -- Lister, fighting the vindaloo monster in Red Dwarf `DNA' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: XF86 betas (Re: D68K: The next step...)
In message <[EMAIL PROTECTED]>, Mr Stuart Lamble writes: >annoyed that if I want support for my W32p (revision A), I have to go >to 3.1.2E - and it's not available for Debian. Net result: either I >have proper support for my card, and can't install new X-based packages >(dpkg barfs at the postinst and configuration stages), or I'm stuck with >the SVGA server. Not at all. Install the svga server using dselect. Put it on hold. Get the 3.1.2E server binary, install it, adjust /etc/X11/config. I'm doing just this to run the current Mach64 card, since my RAMDAC isn't supported by the non-beta 3.1.2. No problems at all. Mike. -- "Don't let me make you unhappy by failing to be contrary enough"
Re: f2c-960717-0 uploaded to master
Right, I know that lapack-linux website too. Note gcc-2.7.0 and g77-0.5.17 were used, more recent ones are available. g77 got better with 0.5.18, but also slower (according to some very casual measurements I did on one piece of code). Also, Jacob Schiotz doesn't say anything about compiler versions. It would be good if someone had some time to redo these and some others benchmarks. -- Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd
Re: POSIX 1387.2 (package-management)
On Wed, 31 Jul 1996, Dale Scheetz wrote: > On Tue, 30 Jul 1996, Michael Gaertner wrote: > > > Ever heard of this "standard" for unix-package-management? How should we > > deal with this? > > > How does one get a copy? I can not help you - to get this you have to be a groupmember or you must pay for it. I am curious who in the debian-community had the chance to read this. (So by now you know I had no chance to read it) To point you how to obtain the draft - here are some links: http://stdsbbs.ieee.org/products/NumStat/NumStat11.html http://stdsbbs.ieee.org/products/press/catalog/it.html price: $72.00, 320 Pages ISBN 1-55937-537-X and as I found out there is also a correlated document bei X/Open extending P1387.2: http://xoweb.xopen.co.uk/public/pubs/catalog/p429.htm price: $70, 429 Pages ISBN 1-85912-121-7 I think some sponsors are needed !!! Michael Gaertner <[EMAIL PROTECTED]> Tel/Fax +49-761-32684
Re: Name clash in prospective package
I think it would be better to change the name of the Mercury Compiler to something like "mercc". The reasons are: 1) Minimal disturbance to current debian users. They now use mc to launch Midnight Comander. 2) Seniority (?). Midnight Commander took the name first (within Debian, I don't know which program is older). 3) Compatibility with other Linux distributions. They usually include the Midnight Commander (and they call it "mc"). 4) Popularity. Midnight Commander is more popular among Linux users than Mercury Compiler. More people in this community use "mc" to mean the former. 5) Personal preference :-) (This point is questionable, I know). Cheers, Fernando.
Re: color ls (fwd)
Answer from Jim Meyering (GNU fileutils mainstream maintainer): > | I copied this to Jim Meyering hoping that he might be able to answer > | your question Michael. > | > | Michael Meskes writes: > | > Erick Branderhorst writes: > | > > This file is in the origianl fileutils source name: dircolors.hin > | > > but is not installed as you might have noticed. > | > > | > What's the reason for this behaviour? > > I changed dircolors (to be different from the original slackware version) > so that it doesn't read any fixed-filename config file. So it no longer > reads /etc/DIRCOLORS or $HOME/.whatever-that-name-was. > > I made that change to maintain some measure of orthogonality. Otherwise, > dircolors would have been the sole program to do such a thing in all of > the fileutils/textutils/sh-utils. > > As you probably noticed, I added the --print-data-base option to print > the default, compiled-in database. So now, the config file must be > specified when dircolors is run. > > % dircolors --help > Usage: dircolors [OPTION]... [FILE] > Output commands to set the LS_COLOR environment variable. > > Determine format of output: > -b, --sh, --bourne-shelloutput Bourne shell code to set LS_COLOR > -c, --csh, --c-shelloutput C shell code to set LS_COLOR > -p, --print-data-base output defaults > --help display this help and exit > --version output version information and exit Erick
Re: Overwriting include files
Mr Stuart Lamble writes: > Ok. There is a library available, libelf (currently version 0.5.2), > which is required by a program I was idly toying about with (Eli). > I'm contemplating packaging up Eli, which would imply packaging up > libelf as well. Go ahead and package libelf. It's been on my todo list for a long time, but with my current backlog, I'll probably never get to it. > However, libelf comes with a couple of #include files > - libelf.h and nlist.h (I think) - which are also included in libc-dev; > in the case of libelf.h, this isn't a problem (the two are identical in > content), but nlist.h has a couple of things in it that (IIRC) are > #if 0'd out. > > What would be the procedure for saying to dpkg, "These files will > conflict with those in another package, but it's ok to overwrite them"? > Or would I have to use a preinst/postrm script to rename them? Shift > their location? Something else I haven't thought of? "Replaces:" is the proper dpkg mechanism for doing this, but please don't use it. Linc5 does not appear to need either nlist.h or libelf.h. Hopefully, H.J. Lu can confirm this. If this is the case, then the headers should probably be removed from libc. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: Quasi-free development tools
In article <[EMAIL PROTECTED]> Rob Browning <[EMAIL PROTECTED]> writes: > Leland Olds <[EMAIL PROTECTED]> writes: > > > (Do we have anything the links to motif?) mosaic (NCSA Mosaic) does. I only provided a statically linked version yet. When I package a released version of Mosaic I should create both versions. Sven -- Sven Rudolph <[EMAIL PROTECTED]> ; WWW : http://www.sax.de/~sr1/
Re: Name clash in prospective package
> Not completely alone---I'd prefer prompting about /usr/local. Why? > Because /usr/local on all our machines here (not just debian) is an > nfs-mounted directory, and typically mounted readonly or root-squash > so that I know nothing on the client machines is going to be able to > diddle with it. > > Prompting about /usr/local is one of the little things packages could > do that make life easier on those of us that try to maintain large > numbers of debian machines. Should this be solved by moving all /usr/local dir structure to the postinst prerm scripts and be created there after prompting the installer? Erick
