Re: Which browser ?
I personally use emacs w3-mode, and lynx. qweb is nice, but has the significant flaw of being Qt base (KDE isn't the only cool program that fell into the Qt license trap after all.) I've heard some good things about the W3C arena/amaya programs as well, and there was a web browser written in Python that was pretty featureful... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: XTerm on XFree86 3.3-3 trouble
I'd have to double check, but I suspect that none of these were ever bugs... just confusion among people as to what the difference between application mode and the default mode is, wrt cursor and keypad keys; there are sequences that change these. I'm pretty sure xbase itself hasn't changed at all in this regard -- but termcap might have, and if a program crashes without switching back you can see changes too... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: emacs won't install if /usr/local is read-only
I don't see any need to post that restriction on dpkg. dpkg is just a Uhh, it's not a *restriction on dpkg*. It's an *extension* to dpkg to make it more aware of a site's policy. We've already got a policy that says packages (ie. those part of debian; what you do with your own is up to you) don't put files in /usr/local, but if they *look* for files, there, they should put directories in place. Now some, maybe even many, sites have a networked /usr/local (yeah, sounds like a condradiction; Oh Well) that a particular machine can't write to; it should be possible to handle this. This should also be an *option*; a normal site will unstall them as they are... Has this made things at all clearer? If some official debian packages try to install files in /usr/local Files are irrelevant -- *directories* are still permitted, and even required, by the policy, and dpkg should handle this. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: emacs won't install if /usr/local is read-only
what needs a review are the outstanding inconsistencies between dpkg and the policy guide. (The guide should of course win :-) I understand Klee has put some effort into this though probably hasn't gotten around to this particular one; the simple approach is for the installer to tell dpkg /usr/local is off-limits and dpkg can then just drop anything that would go there. [This feature should be somewhat general; it could be used to some extent to terminate the info vs. html vs. stone tablets (:-) thread...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: A Qt alternative for KDE?
From: Lars Hallberg Micro++ [EMAIL PROTECTED] What do You think of a Wrapper Class Libary that makes it easy to write code that runns on diferent widget sets? Don't forget OI (there was an interface builder based on it that was free-of-cost for linux, a while back, but I forget the name.) OI let you switch between an OpenLook and Motif lookfeel [in fact you could switch at runtime, which was kind of scary] though it was a fairly sophisticated C++ toolkit. Though originally commercial I thought I'd heard it had been freed; in any case, it's another source of ideas...
Re: xscreensaver and Motif...
I'd prefer there were still a free version (even a static motif version has to go in non-free, right?) although I usually use xlockmore instead...
Re: Bug#8119: e2fsck should be linked with -static
Put root.bin from the rescue disk under /boot. Add a rescue option to the lilo.conf that boots your regular kernel with INITFS=/boot/root.bin . You can now type rescue at the LILO prompt and boot into the rescue disk without a floppy. Total cost in disk space: 700K. This is less Hey, that's a cool idea. Someone want to go package it? If not, I'll try to do so this weekend [I ask mostly because it may be easier for the boot-floppies maintainer to package it for this use too...]
Re: IMPORTANT: RSA Data Security Challenge participants please read
subtle, but correct. I've switched (my not terribly significant) machines over... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: please use V
It's difficult enough to promote freeware in industry with the common lack of support misperception. Combine this I'd suggest that rather than fixing that with wierd licenses, you just do better marketing. Works for us :-) _Mark_ [EMAIL PROTECTED] Cygnus Solutions, Eastern USA (http://www.cygnus.com/, Making Free Software Affordable, Professional Support for Cygnus SDK, Cygnus Network Security, etc etc etc :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: g77 failure
The Ada package as shipped from NYU includes a replacement gcc binary for the matching release; I was going to avoid the problem by shipping it as ada-gcc instead of the redirected gcc (I didn't really expect 2.7.2.1 to come out, and 2.8 will have all the changes built in...) The GNAT package has to match the gcc release anyway, so having the patches in wouldn't have helped much -- 3.05 is still current, and still requires 2.7.2 [3.08 was the last one mentioned as a release candidate after 3.07 had some problems...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: installing emacs 19.34---is this a bug?
could you be more specific about what you're actually seeing? The postinst script does not, in fact, delete anything... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Anonymous ftp and the ls command.
doesn't wu-ftpd use builtin code for simple ls?
Re: Debian Logo?
Logo. (And before people complain that Logo is too frivolous a language to have in the distribution, remember we have an Intercal package already.) If there's a decent unix logo out there, point me at it and I'll take a look... _Mark_ maintainer of frivolous languages :-)
Re: elf-x11r6lib
dselect should have shown you that the xlib package now provides elf-x11r6lib.
Re: seeking WWW browser (smaller than Netscape)
don't forget amaya, w3c's replacement for arena. (Then again, if I want *information* I use lynx or emacs w3. emacs w3 is often more convenient in conjunction with gnus and All Things Emacs; lynx is a lot faster and easy for standalone use... and it's a rather nice ftp client :-)
Re: How to migrate a Debian system to another hard drive?
and note that unlike tar, cp -a will actually *handle* pathnames over 100 characters (of course, dpkg won't have installed any, but they may be around for other reasons...) I used the tar approach for years, but cp -a turns out to be much more reliable (and I can fall back to tar if I have to -- knowing that I have to keep an eye on it as well and diff the trees later...)
Re: emacs troubles
yes, just install the xlib package -- it's small, just enough shared libraries to let the program run. It won't actually *use* the X code if you don't have $DISPLAY set, and it is in the end cleaner than having seperate packages for X and non-X versions...
Re: Cross posting per request
On a debian system I am looking at has a /usr/local/lib/emacs which I consider to be stranded. Please check that the _current_ Emacs package still does this. Current emacs does *create* the directory (ie. it is in the package contents), as recommended by the debian packaging guidelines, as a hint to the user that emacs will *look* there if there's anything in it. It does not put any files there, of course.
Re: Do you use SLIP or a variant with Debian?
I use SLIP because I have been using it for years and would need to reconfigure things to use ppp. Also, SLIP is easy to set up: you set five parameters, and it works -- with PPP, it only really needs one (the phone number) but if it doesn't work, the debugging problem is harder. (SLIP is also more available on unix systems - I run older systems too, and some of them don't have PPP.)
Re: How to debianize packages?
While it is considered a little crude, it is possible to convert tar files into debian packages... You should look at the debian packaging instructions for how to do it right (which will fill in the gaps in this explanation) but then you'll find that if you do: mkdir x cd x tar xzvf .../package.tar.gz (assuming it unpacks from /) mkdir DEBIAN cat DEBIAN/control # follow the packaging guildelines, or just crib the contents of the control file from the hello package cd .. dpkg-deb --build x dpkg-name x and if you've set up the control file right, you'll end up with a package-version.deb that you can then install. It would be nice, if you have the time and decide to rebuild from sources anyway, to put together a proper package; it doesn't take much work, and the hello package is a good example... but the above tricks might be enough to get you hooked -- worked for me :-)
Re: /etc/passwd migration between systems
Last time I ran into it, it turned out that for *legitimate* salts, the linux crypt() was compatible, but for out-of-range ones, there were differing results. An easy way to test is to use perl. For example: solaris2.4+% perl -e 'print crypt(pass, ab).\n' abccBcrPOxnLU solaris2.4+% perl -e 'print crypt(pass, ++).\n' ++kT1mYjlikoI debian1.1+% perl -e 'print crypt(pass, ab).\n' abccBcrPOxnLU debian1.1+% perl -e 'print crypt(pass, ++).\n' ++1clPVO6npvw Note that with a salt of ab they match, but with a salt of ++ they don't. Classic crypt() used 4096 legal salts (: was obviously out, I don't recall exactly what range was used.) If anything, the bug is that the solaris system is generating out of range salt values...
Re: UPDATE: deb-view.el 1.2: emacs tool for browsing deb files!
w3 can be found via anonymous ftp to ftp.cs.indiana.edu:/pub/elisp/w3. More usefully, w3 can be found in the binary-i386/net/w3-el_2.2.25-4.deb on any debian mirror...
Re: Extended memory?
limit on 8086, 8088, and 80186-based systems. (yes, there _was_ an 80186 chip; it just wasn't widely used in the same way that the 8088, 80286, 80386, and 80486 were.) ... Actually, the 186 is probably *more* used than the others, just not in home-user pc's: * many X terminals used the 80186 as network/keyboard controller * the HP95/100/200 LX handhelds use a cmos 80186 * the ATT ISDN phones have an 80186 in them Needless to say, linux doesn't run in any of these environments (though I suppose ELKS would, I don't know how far along that is...)
Re: floppy set
The way I've found to do a PCMCIA install most easily was 8 floppies: 2: standard boot+root 3: base.tgz 3 disk set 3: pcmcia-2.3.18_2.0.7.deb, then dpkg --split kernel-image_2.0.7 You can probably fit the last 3 onto 2, the pcmcia code is small and kernel-image is only a little bit larger than one floppy. I could only find the kernel-image_2.0.7 on master.debian.org in Incoming, though, which implies that it should show up *somewhere* soon but may be hard to find in the meantime. (You don't need special support for pcmcia network cards in the kernel -- the pcmcia package ships with the appropriate new modules (and everyone uses the 8390 anyway :-)) As for compiled-in ether cards: look in the special-kernels directory with the boot disks for alternate boot disks; I don't know if there is documentation other than the config files there to tell you which one you want.
Re: dump for a.out?
the sources to main (ie. not non-free or contrib) debian packages are *always* in source on the mirror site... mirror/binary-i386/admin/dump_0.3-6.deb mirror/source/admin/dump_0.3-5.diff.gz mirror/source/admin/dump_0.3-6.tar.gz (odd that the diff and tar are out of phase, but that could just be mirror skew; just grab the tar file, unpack it, tweak the dependencies and version (probably in debian.control) and then ./debian.rules binary, and you'll end up with an a.out-based package...)
Re: How do I get GATEWAY2000 PS/2 mouse to work
This did not work, however - the make failed (after the best part of an hour had elapsed) when it was unable to find as86. I could not find as86 anywhere on my system, and so was stuck. Hmm. Perhaps kernel-package should depend on bin86? You definitely need the bin86 package to build a kernel (it has as86 and ld86.) Package: bin86 Status: install ok installed Priority: standard Section: devel Maintainer: Joost Witteveen [EMAIL PROTECTED] Version: 0.3-1 Depends: libc5 Description: Assembler and loader for kernel compilation.
Re: The * character (was: Latex )
if you prefer the bash behavior of ignoring the pattern failure, just set nonomatch in tcsh or csh.
Re: Re^2: How do I get GATEWAY2000 PS/2 mouse to work ? (fwd)
on the other hand, most laptops with builtin mouse or trackball or force stick or glidepoint seem to use the PS/2 interface... which is an argument (polite request :-) for having it in the default kernel. Can't free up the IRQ in that case either...
Re: Cannot compile mouse support - help!
The file /dev/inportbm clearly exists, it is character special (10,2) and it does have appropriate ownership and permissions. So what does the error No such device mean? No such device means that while the name exists in the filesystem, the kernel doesn't have any idea what c/10/2 actually *is*. Perhaps you don't have the needed support in the kernel, or the needed module loaded?
Re: Ught Oh =O
note that some anti-virus software will decide that lilo *is* a boot sector virus :-) so you may want to just give up and use loadlin...
Re: Compose characters in X
which puzzles me. Why does the order differ? (BTW, in a mono xterm it works like under Emacs.) I'm even more surprised, as color_xterm maintainer -- because color_xterm should only differ from mono xterm in, you guessed it, color features... as far as I can tell I'm building it with the same sources and options as the xbase xterm is using...
Re: gpm and X mouse conflicts
without the -R option. However, -R does seem to be needed for bus mice and in some cases it seems to be needed even for serial mice. I It *used* to be needed for busmice and in particular ps2 mice. However, many of the busmouse drivers (and definitely the ps2 mouse driver) were fixed to permit multiple opens during 1.3, so -R is not needed *any more* for most if not all of the cases it was used for previously.
Re: linking with termcap under 1.1
you'll also have to toggle the setting of HAS_SETUPTERM (if telnet crashes in an infinite recursion, it's set the wrong way) in config/mt-linux.
Re: linux v2.0: networking sendmail changes?
problems. The dbm library must have been compiled to use fcntl (or lockf). gdbm, as shipped by the FSF, compiles for fcntl or flock, depending on which it finds. I'd taken over maintenance (though lacking bug reports haven't uploaded a new package) but for my own use, built a version that did no locking at all (it interferes with kerberos V5 database locking, for one thing.) If I could come up with a good interface (environment variable? mode bits on the database?) I'd submit the patches for real...
Re: FAQ: Work-Needing and Prospective Packages
:o GNAT (GNU Ada Translator) : I believe this was released the other day, too. Cool, I didn't even notice that it was on the wanted list when I uploaded it. (I better put together -2, since -1 is missing a few files...)
Re: security hole in X????
If you share a home directory on both machines, and you're using xdm, then the access is based on the .Xauthority file in your homedir. xauth list should show the same thing on both systems, if this is the case. (Generally this isn't much better -- it means you're still vulnerable to the magic cookie being sniffed as it goes over the net, but other users on the remote host can't connect as they could if you'd used xhost...) As for rlogin: no bug, it's just that rlogin has no mechanism to pass environment variables (and there's no way to extend the protocol portably, rlogin is doomed, use telnet :-)
Re: problem with traceroute
Scott Barker [EMAIL PROTECTED] writes: Interesting. I've had no problems at all with BIND... If you're running a 1.2.x kernel and an unstable bind, zone transfers from your machine will fail (because it attempts to get the ip options, something not supported in 1.2.x, and on failure drops the connection.) This only matters if you're the primary DNS for some domain (which my 1.2.13 machine is.)
Re: problem with traceroute
Scott Barker [EMAIL PROTECTED] writes: traceroute: IP_HDRINCL: Protocol not available I've also noticed this under 1.2.13. (the same package works fine on my 1.3.79 machine, and I should really update both kernels...) There are actually a number of unstable packages that don't work under 1.2.13 -- most have explicit dependencies (diald used to, for example) but some don't. BIND, for example, needs the ip_options support that was added in 1.3 (though I've submitted a reasonably clean fix for that, I understand if there isn't much interest in it.) Certainly once 2.0 comes out I'll give up and upgrade :-)
Re: regular (aka bsd) compress distribution?
they often come without a C compiler. And it's more than just compress Often? Solaris is the only unix I know of that doesn't come with a compiler that can build gzip. (Note I did not say a C compiler -- HP/UX ships with a toy for building kernel config files, that is still enough to build gzip.) And for solaris, you can get binaries of gcc on the net or on Sun's demo-ware cdrom. SGI may be similar - but I'm pretty sure they ship gzip (along with gcc, in the stack of cdroms you get with the machine.) If you mean non-unix platforms, well, there are DOS, Windows, and MacOS gzip's available free. I'm sure there's an amiga one on the Fish disks, if not I'll bug Fred :-) What did I miss? If you *really* want a CP/M gzip (given that there isn't a CP/M compress either, though there is a *different* lzw based tool) I can give it a shot, but I'll need some convincing :-) I think that gzip handles things quite well - read the old format, but don't write it, so we can bring old data forward. PNG will take a little longer to catch on, but it's getting there. The compression technique used in gzip is now an RFC (issued last week, RFC1950, RFC1951, and RFC1952.) Consider also: why does debian need to be in the business of helping unisys make money? Anyone running linux who needs to read compressed data can already do so, via gzip. If they need to generate lzw-compressed data, *even if there is a package* they need to talk to Unisys about licensing, and can build the package themselves. We don't need to make it easy; we can instead make it easy for people to *avoid* the problem. And would people stop using X11 fonts as an example? Or do I have to actually post patches to make xfs use gzip or zlib [zlib is the *free*, non-gpl'ed, compression library using the algorithm; see RFC1950 for a pointer to the source.] (Sorry to rant like this; I just don't like seeing fellow debian developers get flamed for already doing what I consider the right thing, and flamed for spurious reasons - I haven't seen a reason posted yet that the above doesn't refute, nor have I seen a refutation of the above arguments...) _Mark_
Re: regular (aka bsd) compress distribution?
Perhaps we can fix the font-file compression issue instead? Under older releases, the X server actually ran a seperate program (so having uncompress-gunzip did the right thing) to handle both uncompression and bdf conversion. If XFS doesn't already have gzip support it should be easy enough to add (and if I remember right, anything old enough to not support XFS doesn't support compressed fonts either :-)
Re: which..
I would just like to add, as which is originally from tcsh (IMHO), why not use tcsh to run which and we'll have the same behaviour in bash as in tcsh. *Actually*, which comes from the BSD shell script /usr/ucb/which. Using it as a usage example would probably be poor, since it did things like set prompt=; source $HOME/.cshrc and other gross kludges. The tcsh builtin is simply doing it right; the common bash 'alias which=type' is usually close enough. Given that the script is for invocation by programs, not users, it doesn't *need* to locate builtins...
Re: Ftpd annoyance - DIR doesn't work for anonymous ftp
This is probably the most frequently asked question over on the wu-ftpd list :-) Easy way: compile ls from sources, but use gcc -static at the end so it doesn't need shared libs. Works on all systems. Hard way: update a *lot* more of lib, you need ld.so and/or ld-linux.so, and you need to run ldconfig on that copy of lib (see the ldconfig man page for details.) The specific details vary a lot from system to system. (There's something to be said for having the debian ftpd package either handle this or include a script to do so... even if it means dpkg --root ~ftp -i base*.deb :-)
Re: strange message
It's a new log message (umm, why are you running 1.3.96 if you're not reading [EMAIL PROTECTED] it's been hashed to death there...) to catch a certain usage of flock in libc, which should have been fixed around 1.3.10... Apparently the 5.3.x libc has the fix now, but you'll only get that message five times anyway (some systems would get it fairly often, without it really being fixable.)
