There are a bunch of cad-like packages in debian; I'm hoping that
people have tried enough of them to make a recommendation:
I'm looking for something to do a house-walkthrough, with enough
detail to show (for example) if a given size of book case will really
fit in a particular location (so 1cm r
> I'm connected with the cable modem. This thing is not coming from inside for
O, you should have said that first. When a cablemodem powers up, it
does a dhcp and net-boot; for diagnostic reasons, many of them seem to
try the ethernet first, then the cable net. You might also be seeing
boot
> This was precisely the problem. The EMACSLOADPATH was set in my
> user account, and I was trying to install in a window with su root,
Ahhh. I think it would be reasonable to explicitly unset this (and
probably other variables) in the emacsen-common handler
scripts... just as they should avoi
I'm not sure I've seen this reported before (but I'm way behind on
list mail, and haven't checked the bug system for this specific thing)
> Cannot open load file: bytecomp
Seems like the most likely problem, but things have to be very odd for
that not to be found... what does dpkg -S bytecomp sho
You can *also* do this with lsof:
% sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
sendmail 239 root4u inet 0x005bc810 0t0 TCP *:smtp (LISTEN)
%
using -i tcp:smtp works as well, "lsof -i :domain" is an example of
finding either...
--
To UNSUBSCRIB
actually, something like
dpkg --remove smail
dpkg --install exim*.deb --auto-deconfigure
is more likely to work safely - force-depends really should only be a
last resort, *and* should usually be accompanied by a bug report...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a s
> available on a name-brand workstation, such as a SPARC. Assuming you're
> using Linux, do commercial SPARC software packages work with Linux?
Well, sunos ones appear to; on my SS1+ here, which is booting
sparc-linux off of a zip disk, but still mounts the original SunOS
4.1.3 disks under /sd/
well, the important parts of that patch appear to be standard part of 3.3.1:
#define HasPosixThreads YES
#define ThreadedX YES
#define HasThreadSafeAPIYES
#define ThreadsLibraries-lpthread
#define SystemMTDefines -D_REENTRANT
in the config file... a q
>> Though I have not tried this yet (the machine with the
>> development environment has not yet been upgraded) but I
>> presume that by "... first purge all the '-dev' packages
>> ..." he is referring to using dselect or dpkg ...
Yes, exactly. Dselect handles this directly (though I'm the
wrench
> I have used --force-depends now quite a few times without being
Not to pick on you in particular, but I can't emphasize this enough:
if you use --force-depends while doing an upgrade from libc5 to libc6,
you *will* hurt yourself. Practically guaranteed. Really, honest! :-)
There are *other*
>The best chance of an answer is probably to post the questions
>to one of the developer lists, if that is where the experts are
Actually, I've always made a point of ignoring user questions on the
developers list, but I've *also* started putting more time in on
debian-user. (I've also gotten a
>>[10-31]) SearchStr="$Month $Day";;
That means "a single character in the set 1, 0 through 3, and 1", so
it will match any of 0 1 2 3 and nothing else.
>># [12][0-9]) SearchStr="$Month $Day";;
>># 30 | 31 ) Day=02; SearchStr="$Month 9";;
That's more like it; the [12][0-9]
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 Pyth
>libgdbmg1_1.7.3-21 conflicts with ligdbm_1.7.3-19 (that came with my Debian
So get libgdbm_1.7.3-21 from the same place you found libgdbmg1_1.7.3-21...
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
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 a
> 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)
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/lo
> 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.)
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...
> 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, t
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]
> 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
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
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]
As I think I mentioned elsewhere, if anyone admits to *using* the gnat
package, I'll deal with it. (please send me mail directly...)
Short term, I will (1) upgrade to the latest upstream release (3.05)
and (2) change it to supply it's own "adagcc" or "gnatcc" instead of
diverting gcc.
Long term,
You can't just replace compress with gzip for X because there are two
places in the X tree where uncompression is done in-line (server code
and font code.) I'm almost finished with some patches to use "zlib"
directly instead, which will eliminate the last place debian has any
need for the compress
> 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_
doesn't wu-ftpd use builtin code for simple ls?
dselect should have shown you that the "xlib" package now provides
elf-x11r6lib.
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 :-)
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...
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 -- k
> > 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,
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 mo
> 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
>> 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...
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
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
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 li
> 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
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
m
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...
> 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 actua
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...
if you prefer the bash behavior of ignoring the pattern failure, just
set nonomatch
in tcsh or csh.
> 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
> 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
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.
>> 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 n
: > 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...)
> traceroute: IP_HDRINCL:Protocol not available
Probably you're still running the 1.2.13 kernel, but the new
traceroute uses some features only in 1.3... at least that's why I see
that message.
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 c
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
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.
> 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
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 ad
>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
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 ldc
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 f
59 matches
Mail list logo
