Re: page fault in mkfontdir
I'll note that the xutils 4.0.2-1 mkfontdir also segv's on Debian/SPARC using 2.2.18pre21 (kernel-image-2.2.18pre21-sun4cdm) so maybe it really is an all the world is an x86 bug :-) Setting up xfonts-base (4.0.2-1) ... Running mkfontdir in misc font directory.../var/lib/dpkg/info/xfonts-base.postinst: line 58: 24276 Segmentation fault $currentcmd $longdir dpkg: error processing xfonts-base (--configure): subprocess post-installation script returned error exit status 139 I'll poke at it with gdb... Hmm: % gdb /usr/bin/X11/mkfontdir (no debugging symbols found)... (gdb) run /usr/lib/X11/fonts/75dpi Program received signal SIGSEGV, Segmentation fault. 0x0 in ?? () (gdb) where #0 0x0 in ?? () #1 0x5006f9ec in _init () from /usr/lib/libz.so.1 #2 0x5006f99c in _init () from /usr/lib/libz.so.1 #3 0x500102c8 in _dl_init () at dl-init.c:136 #4 0x500032b4 in _dl_start_user () at rtld.c:147 That would at least explain why it it faulted just as quickly as a user as it did as root... (*type type* yep, same trace when run as root.) libz.so is from from zlib1g 1:1.1.3-12, if that helps. gzip and gunzip work though. Not up to doing an X build tonight, but if noone gets anywhere in the next day or two I'll poke at it...
Re: ntp hangs...
Not that it helps much, but I remember that ntp used to do nasty things to the 2.0 series kernels as well, though last I'd checked (haven't unpacked that box after moving) that got fixed in 2.2...
Re: xfree86 config package
AFAIK, sparc xfree86 doens't *use* a config file; you just pick the server you want, and you're done. (At least this used to be the case.) Thus neither xf86config nor XF86Setup are useful on the sparc (though there may be command line arguments to the server to set things like fontpath.)
Re: SSH key generation
I had ssh going a few months ago. Has anyone else seen this problem? Any hints on how to debug it? The problem has been mentioned a number of times on debian-sparc; if you look in the archives, you should find a URL for an expiremental replacement libgmp2 that isn't broken. My recollection is that it fixed the key-generation problem, but still had trouble in normal usage; pending other updates, I just rolled enough things back to stable for it to work again.
bootstrapping up to the next kernel
I just tried building 2.2.10 on a 2.2.1 system and got this: vfork(BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! bad dynamic tag' failed!) = 12682 (from strace -fv make oldconfig) I'm pretty sure it isn't kernel build specific, I suspect just about any make that actually vforks would do it. However, the 2.2.9 image would hang (on my SS1+, sun4c) after running for a little while. Do I just wait for 2.2.(x 9) kernel images? libc6 2.1.1-13 doesn't indicate a kernel dependency, is there a newer (or older) one I should be using instead? Or is this just random lossage and I should try again closer to debian-2.2 :-)
Re: Pthread brokenness
hmm, I updated a months-old unstable sparc SS1+, and now sshd spins, apt-get spins sometimes (rolling back to slink apt-get helped some, but not enough; for now, I just run it under (limit cputime 2min) so it dies and I run it again :-) This is with a 2.2.1 kernel; 2.2.9 'made things worse' but I don't see anything newer on the debian.midco.net rsync mirror at least.
Re: Problem upgrading x fonts
The clients package is indeed there, although it is an earlier version. And, in fact, that's the problem. Note that the xfonts-100dpi package has: Depends: xbase-clients (= 3.3.3.1-5) and 3.3.2.3a-11 doesn't satisfy that... _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian Package Maintainer
Re: Problems booting Slink
(Is it possible to dd the boot floppy onto a spare hard disc partition then boot from there with appropriate arguments to SILO? This is the It is a little trickier than that because you need *two* floppies. Check the debian-sparc archives for my comments on doing this with a zip disk, the approach would be the same with any scsi disk that works at all with the boot prom you're using (basically, dd the boot disk, dd skip=offset the ramdisk, then boot it and use the linux sd(...)[offset...] syntax.) I'd give more details here but I'm at the IETF now which means I have fast access to the rest of the net, but I'm on the wrong side of the 28.8 link to thok.org :-)
2.1_r0 install experience
I have a vintage SS1+, ROM 1.3. It has been running a crufty Debian install for a while, so 2.1 seemed a good replacement. Using the 2.1_r0 binary-sparc-1.iso, I discovered that the 1.3 roms can't boot it, at least using the drive I have (which *does* have the right blocksize support that it works, otherwise.) I then discovered that the floppy drive doesn't work (couldn't read sector 1, self test failed so it is probably mechanical.) At this point, things start getting complicated; probably moreso than a normal install... certainly more than the would have been if I could find a version of intelsilo and just make a bootable zip disk. This led me to discover a few minor holes in the install along the way, though nothing that needs fixing before 2.2... Rather than deal with tftp, I copied the rescue image on to a *zip* disk, dd if=resc1440.bin of=/dev/sda and tried booting from the scsi zip drive. That worked: boot sd(0,5,0) got me the Debian 2.1 rescue banner and silo prompt. However, now I need to tell it to get the rest off the cdrom. This should work from here, but I didn't get to far with the install.txt: it has what appear to be non-silo instructions... 6.2. Booting with the Rescue Floppy You can do two things at the `boot:' prompt. You can press the function keys _F1_ through _F10_ to view a few pages of helpful In fact, F1..F10 are a loadlin or whatever feature; silo only supports TAB and help. Searching /install/install.txt for root.bin was kind of vague; nothing ever suggested I actually *put* the file anywhere. % dd if=root.bin of=/dev/sda However, since the rescue is *really* looking for the root on a floppy, I still lose. I've tried a few arguments to the rescue disk: boot: /linux root=/dev/sde load_ramdisk=1 prompt_ramdisk=1 # just mounted the rescue zip disk as the root. Suggest # adding a dummy /bin/sh or /sbin/init to the rescue disk to # at least echo why it failed... boot: /linux root=/dev/sde initrd=/dev/sde initrd-prompt # complained about not finding /dev/sde, *then* booted, and # mounted the zip disk as root... boot: linux initrd=!cd5 # got Loading initial ramdisk..., then booted, then # RAMDISK: couldn't find ramdisk image starting at 0 # and insert floppy and press enter. boot: linux show_arguments # said # Kernel args: silo() root=/dev/fd0 rw load_ramdisk=1 prompt_ramdisk=1 boot: linux root=/dev/scd0 initrd=!cd5 load_ramdisk=1 prompt_ramdisk=1 show_arguments # seems to have ignored the show_arguments, and blasted # straight on to booting and mounting the cd as /. # Unfortunately, the CD doesn't have /sbin/init or /bin/sh either... I suspect the problem with the !cd paths is that they'd work if I were really booting off the cd, but from the zip disk, they don't seem to... Any suggestions from here? or do I need to set up a special silo config on the zip disk, to get it to look at the cd? other bits: % cat /mnt/cdrom/dists/slink/main/disks-sparc/2.1.8.1-1999-03-01/fdisk.txt ** man page not found ** % ls -l /mnt/cdrom/dists/slink/main/disks-sparc/2.1.8.1-1999-03-01/fdisk.txt -r--r--r-- 2 root root 26 Feb 24 22:03 fdisk.txt In silo/second/main.c, the PROM_V0 You have to type image name... help message doesn't fit in 80 columns. _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian Package Maintainer
Re: 2.1_r0 install experience
Woohoo, found the right hack (as usually happens *after* I send mail :-) Since I couldn't get it to treat switch disks, I looked more closely at the image naming code (main.c, misc.c)... On the same zip disk that I'd already put resc1440.bin on, I skipped over that to an easy-to-type offset, and dropped root.bin there: +% dd if=resc1440.bin of=/dev/sda +% dd if=root.bin of=/dev/sda seek=3000 1907+1 records in 1907+1 records out Then booted the zip disk boot: boot sd(0,5,0) Then at the silo prompt: boot: /linux initrd=sd(0,5,0)[3000-5000] root=/dev/ram (the root= may have been redundant...) and it worked! The installer is grinding through the badblocks check even as I type this. Anyway, if someone would like to turn this into English, it looks like we have a relatively easy boot from zip disk path to add to the install instructions... (I'd write it up more clearly myself, but it is 3am. Maybe later.) Whee! _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian Package Maintainer
Re: 2.1_r0 install experience
another minor nit: one of the install docs suggests that one should boot off of the last binary cd in your set - so disk 1/1, 2/2, or 2/4 (in the set that is 2 bin + 2 src.) binary-sparc-2 doesn't appear to be bootable, though - or at least, it has no /boot and no disks-sparc. (As mentioned earlier I can't boot ISO disks on my machine anyway.) Probably the doc should be changed, though there's plenty of room on b-s-2 if we wanted to make it bootable as well...
Re: slink CDs
The sparc images are now on cdimage.debian.org. yay. Will sunsite.org.uk just pick them up? and if so, what path? (rsync -v sunsite.org.uk:: just says pub which isn't helpful... using rsync -n to browse is really painful...) I really want to reinstall this SS1+, so I can stop booting from zip disk :-) _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian Package Maintainer
Re: while installing, can't get swapon to work for sun4u
set to linux swap type, no flags, mkswap it, then run swapon -- again, invalid argument. This may be a red herring, but I used to see that all the time with swap *files* on x86 2.0... because for some reason you had to sync between the mkswap and swapon or the kernel would read the disk block instead of the buffered block, or something like that. Couldn't hurt to try...
Re: slink_cd - progress
This reminds me: once the sparc cd images are ready, is there anyone else in the Boston/Cambridge Massachusetts (US) area that wants to coordinate burning them? are there enough of us that doing this would usefully reduce load on whatever servers will be hosting them?
Re: dpkg on other unix
indeed, over a year ago there were reports that people had gotten (with some patching) the .tar release of dpkg built on solaris. I'm actually more interested in something like debian-netbsd-sparc, or even debian-netbsd-sun3 :-) but I haven't had time to go down that path...
Re: System Call 119, etc; and apt broke
If you simply install kernel_image 2.0.35 from sid, you'll be fine - it has the required patches. That reminds me - does SILO handle x86-formatted drives yet? (I'm still booting off of an old zip disk installation, since I haven't had time to make the slush space to actually reformat an entire drive... and all the SCSI disks on this sparcstation are borrowed from an intel system...)
Re: xbase
Xsun does (unfortunately) not know about gzipped fonts. The easy fix Off hand, why not? It's just a config option, and you've got zlib... (Remember, gzipped fonts aren't debian specific -- I contributed them to the X consortium first, and they did go out in normal X11R6 releases.) is to set up a local X font server (xfs), and start Xsun with Umm, no, won't xfs just send the gzip'ed fonts over, or did that get fixed? (This was a problem I had when I wrote the code in the first place - Xnest couldn't test them and xfs didn't help...) Just curious (I haven't tried the server yet myself; in fact, I turned over X package developement to someone else, though I'm still advising...) _Mark_ [EMAIL PROTECTED] The Herd of Kittens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xsun works :-)
Cool. Looking forward to it... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of the new glibc
Is there any reason not to change the soname, if it's that incompatible? it's going to be *hard* to upgrade if we have to basically redo the last month worth of bootstrapping from scratch. If we can use a new soname, I can deal with moving forward with this release... but if we can't do that, or the equivalent, I'd have to recommand *not* using this libc release until it does change enough (and stabilize) that an soname change gets made. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of the new glibc
It's not incompatible with glibc-2.0; it is with older pre-2.1 Oh, I see, and 2.0.90 is really 2.1-- rather than 2.0++. Note: I think all the programs will still work. They will only display 2 warnings when executing them. If you want, that I guess I misinterpreted -- I thought you were saying the new libc made older programs things dump core? The warnings I can live with (as long as they go to stderr, and even then, a way to turn them off (temporary environment variable?) will probably make some autoconf-based tests happier.) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: List of Uncompilable Sparc Packages
Does Debian-sparc have problems with C++ in general, or is it this specific Given that groff built (with libg++272 and libc6 stuff) I'd suspect that particular test... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: -altdev packages (was Re: Bug#16987: xpm4g: attempts libc5 build on sparc)
OTOH, libc5 library packages could be required to run any other binaries not coming from Debian. altdev stuff already exists; my question is *why*. The answer appears to be that redhat had a bunch of libc5 X packages (I'm guessing, I joined the sparc side of the project late enough to be able to do a pure-debian installation...) However, mere existence of those binaries doesn't cut it. After all, practically everything from there exists in source form; we can just recompile and be done with it. Is there anything that's *not* recompilable that we need to be able to run? Otherwise, I'd just as well not build libc5 X libs -- they add a *big* chunk of time and disk space to an already immense build (and I only have an SS1+; if someone wants to send me an ultra and some faster disks, I wouldn't complain :-) In the meantime, I'm going to focus on getting a server to build (having snarfed enough missing defines from the sunos includes to get it to compile, I still need to find out where it lost functions like GetTimeInMillis, in order to get it to link...) I'll also note that currently, only the x86 and m68k build altdev X libs. The alpha and ppc ports specifically do not (and my default as X maintainer is to leave it off unless the port really needs it.) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dpkg ... 1.4.0.20?
I've put sparc dpkg on ftp1.us.debian.org but haven't uploaded it because, on my system, dselect doesn't seem to work properly. Like some other ncurses3.4 stuff I've tried, it seems you sometimes have to Can you be a little more specific about ncurses3.4 problems? info and emacs seem to work fine for me... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: emacs and sigprocmask
sigprocmask(SIG_BLOCK, 0x800, 0xefffe8c8) = -1 EFAULT (Bad address) So, armed with only strace, I dug a little further into this. A useful trick for interspersing your own logging with strace output is to use write(99, ...) -- strace will log the args, and the ignored EBADF return... Turns out that the problem is that the posix-faked sigmask in emacs syssignal.h isn't getting used, instead the one from bits/sigset.h, which is either useless or just different, is getting called in... so I override it in emacs/src/syssignal.h, and emacs appears to work fine now. Upload later tonight after I test a fresh build... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 select problems?
Uh? Aren't the sources on ftp.debian.org? In fact, they are not. The binary is in unstable/binary-sparc/base; there is nothing matching unstable/source/*/sil* at all. (This is in my own local mirror of ftp.debian.org, but I've never seen it drop anything, especially anything that should have been there for a long time.) I have uploaded a silo package a lot of time ago (now I'm working on a glibc silo), and sources should be there. I can't verify, Any advice on what it would take to make it handle x86-created partitions (the kernel handles them fine...) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
strace (was Re: libc6 select problems?)
Thanks. Since then I've also noticed that the
vger.rutgers.edu:/pub/linux/Sparc/userland has a sparc strace rpm...
That RPM is the same one as at the nuclecu site.
Working with the strace-3.1 sources from vger, I found that they sort
of work with libc6. There were a couple of little glitches (PEEKUSR
vs. PEEKUSER), a major bug in libc6-dev (linux/socket.h and
bits/socket.h have *totally conflicting* definitions of SOCK_*, MSG_*,
and structs sockaddr, msghdr, and at least one other. The definitions
are an enum in bits/socket.h but #defines in linux/socket.h... and
funny, the C compiler doesn't like enum { 1 = 1; } very much :-)
and lastly, strace (mem.c) needs some definitions from asm/mmap.h,
that *aren't* in bits/mmap.h, but it only includes sys/mmap.h which
now gets the latter. Anyway, I include the diffs to strace itself
here; you should be able to figure out what to patch out of
/usr/include/linux/socket.h yourself [I *suspect* that if you kill
everything after the 3 #include's at the beginning it will be correct,
but I leave that to others to get right.] If you can't get it to
build, http://www.kitten.gen.ma.us/me/sparc-linux-strace.exe
temporarily has a copy of the binary (244K, over a 28.8 link - be
patient or don't bother :-)
_Mark_ [EMAIL PROTECTED]
The Herd of Kittens
diff -wurp strace-3.1.orig/defs.h strace-3.1/defs.h
--- strace-3.1.orig/defs.h Tue Jul 30 01:00:58 1996
+++ strace-3.1/defs.h Mon Jan 5 14:57:44 1998
@@ -86,8 +86,10 @@ extern int ptrace();
#endif /* !SVR4 */
#ifdef LINUX
+#ifndef __sparc__ /* eichin */
#definePTRACE_PEEKUSER PTRACE_PEEKUSR
#definePTRACE_POKEUSER PTRACE_POKEUSR
+#endif
#ifdef ALPHA
#define REG_R0 0
#define REG_A0 16
diff -wurp strace-3.1.orig/mem.c strace-3.1/mem.c
--- strace-3.1.orig/mem.c Tue Sep 17 19:08:53 1996
+++ strace-3.1/mem.cTue Jan 6 03:21:40 1998
@@ -32,6 +32,7 @@
#include defs.h
#include sys/mman.h
+#include asm/mman.h /* eichin -- gets sunos stuff not in bits/mman.h? */
int
sys_brk(tcp)
diff -wurp strace-3.1.orig/process.c strace-3.1/process.c
--- strace-3.1.orig/process.c Tue Jul 30 01:00:59 1996
+++ strace-3.1/process.cMon Jan 5 15:07:56 1998
@@ -1145,7 +1145,9 @@ struct tcb *tcp;
tprintf(machine=\%s\, uname.machine);
#ifdef LINUX
#ifndef ALPHA
+#ifndef SPARC
tprintf(, domainname=\%s\, uname.domainname);
+#endif /* SPARC */
#endif /* ALPHA */
#endif /* LINUX */
tprintf(});
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
emacs and sigprocmask
so, armed with a freshly built emacs which responds to a small set of
things, and a recent (shaky) strace (mentioned in my other posting) I
find that emacs is getting a *lot* of EFAULT's on sigprocmask
calls...
sigprocmask(SIG_BLOCK, 0x800, 0xefffe8c8) = -1 EFAULT (Bad address)
fcntl(0, F_SETFL, O_RDWR) = 0
sigprocmask(SIG_BLOCK, 0x40, 0xefffe688) = -1 EFAULT (Bad address)
ioctl(0, FIONREAD, 0xefffbe04) = 0
sigprocmask(SIG_SETMASK, [ABRT BUS SEGV SYS ALRM TERM STOP CONT TTIN TTOU IO
XFSZ VTALRM LOST USR2], []) = 0
In what I suspect is related, SIGIO handling is what seems to be
failing. I've got more to explore here, but I thought this might stir
up memories or else inspire ideas about what possible bugs this
represents...
write(1, \33[32;1H\33[3m-Emacs: *scra..., 106) = 106
sigprocmask(SIG_UNBLOCK, 0x800, 0xefffe8c8) = -1 EFAULT (Bad address)
fcntl(0, F_SETFL, O_RDWR|O_ASYNC) = 0
sigprocmask(SIG_BLOCK, 0x40, 0xefffe8c8) = -1 EFAULT (Bad address)
ioctl(0, FIONREAD, 0xefffc044) = 0
sigprocmask(SIG_SETMASK, ~[HUP INT QUIT KILL BUS SEGV PIPE LOST], [ILL BUS SEGV
ALRM TERM URG TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH USR1
USR2]) = 0
gettimeofday({884075648, 246904}, {0, 0}) = 0
gettimeofday({884075648, 256147}, {0, 0}) = 0
_newselect(0x400, 0x10ebc0, 0, 0, 0xefffeb28) = 1
getpid()= 7029
kill(7029, SIGIO) = 0
gettimeofday({884075655, 104561}, {0, 0}) = 0
_newselect(0x400, 0x10ebc0, 0, 0, 0xefffeb28) = 1
getpid()= 7029
kill(7029, SIGIO) = 0
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 select problems?
whh!!! yay!!! Excellent work! That's a *nasty* one. I can even see why it sometimes worked -- in the rsync code, the branch that does the select on one fd only happens if the operation on the other fd blocked, and if it went one way, the count was n+1 which was a valid fd, the other way it wasn't and the EBADF happenned. I've built a working kernel with this patch from the sparclinux-2.0-971208 sources (and note that modules in that kernel don't seem to work -- or at least NFS as a module doesn't...) I'm working on `strace'... there is a working version (in .rpm format) in ftp.nuclecu.unam.mx:/pub/Linux/Sparc-miguel (well, I cannot Thanks. Since then I've also noticed that the vger.rutgers.edu:/pub/linux/Sparc/userland has a sparc strace rpm... Now I just need to find sources for the debian build of silo (they're not on ftp.debian.org, tsk tsk!) so I can patch it to understand x86-byte-order root partitions... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 select problems?
Well, at least I've figured out that it isn't a kernel problem. I built xntpd and rsync using libc5-altdev and alt-gcc, and aside from a typo (already reported) in the alt sched.h, they both work fine. I'm not having much luck in figuring out where in glibc-sparc select itself is built, though (the Makefiles are a little too magic.) I'm about to just build it and read the logs and see hack on it from that direction... Is anyone working on gdb, or strace? Looks like we're stuck at the printf level of debugging right now, and that's kind of sad... strace needs actual porting (I got as far a build that did a fake_exec and ran the program, but didn't see any *real* syscalls), gdb uses the bfd it ships with, and that would need to be updated to a current sparc-linux-aware libbfd. It shouldn't be too hard to port, but still... emacs actually builds, starts up, and crashes as soon as it has painted the screen once. I wouldn't be surprised if it were more of the select bug, but there's no way to tell :-( Once we have gdb and emacs, I suspect everything else will just fall into place :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Current State of Debian Sparc Port
* select() isnt working properly, which breaks glibc versions of perl, proftpd, apache, and probably much more I haven't tried. Actually, I recently discovered that *select* is fine -- it seems to be reporting the EBADF accurately. What appears to be broken is that writes of more than 4096 to a full pipe between a parent and child screw up somehow. (I'm not sure why libc5 programs don't lose too, I'm working on that one, but thought I'd point that out...) * bash 2.01 and its libreadline cant be compiled because it comes out linked against both libc5 and libc6; same with ncurses3.4. Umm, I think that's just untrue. Do you mean the *dependencies* show both libc5 and libc6? That's because dpkg-shlibdeps is getting fooled by a bug in ld.so; someone claimed they were uploading a new one to fix them problem. ncurses3.4 actually builds and works fine, I uploaded the missing binary packages a couple of days ago (since so many programs (like info had been uploaded linked against them anyway...) (My theory here is it might help if /lib/ld-linux.so.2 wasn't linked against libc5.) I think that's the symptom, but from what was posted here earlier, it *isn't* -- it just looks that way because ld.so (which is what does the work of ldd, underneath) has a bug... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Current State of Debian Sparc Port
actually, studentloan+% ls -al /lib/ld-* -rwxr-xr-x 1 root root 447196 Dec 1 14:27 /lib/ld-2.0.90.so* -rwxr-xr-x 2 root root26957 Feb 21 1997 /lib/ld-linux.so.1* -rwxr-xr-x 2 root root26957 Feb 21 1997 /lib/ld-linux.so.1.8.10* lrwxrwxrwx 1 root root 12 Jan 2 02:43 /lib/ld-linux.so.2 - ld-2.0.90.so* yet studentloan+% ldd /lib/libncurses.so.3.4 libc.so.5 = /lib/libc.so.5 libc.so.6 = /lib/libc.so.6 ld-linux.so.2 = /lib/ld-linux.so.2 Nonetheless, strings /lib/libncurses.so.3.4 only lists libc.so.6 and ld-linux.so.2. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sparcs
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/c/#, I made a symlink from /usr/lib/ld.so - the sunos copy, and then: studentloan+% ( setenv LD_LIBRARY_PATH /sd/c/1/lib:/sd/c/7/lib:/sd/c/7/5lib ; /sd/c/7/bin/uname -a ) Linux studentl 2.0.32 #1 Mon D sparc So at least randomly selected SunOS programs work :-) I've also run xdpyinfo and xlogo (an old build of X11R6 done under SunOS) though xterm didnt' quite work, probably because I needed another symlink somewhere... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ready to help again
It might not be clear, but the ncurses3.4 stuff is what I uploaded because people had uploaded packages that used ncurses3.4 but it didn't exist anywhere. Please go ahead and upload a newer ldso; I'll reupload ncurses3.4 packaged with it, afterwards. (I'll ask *again*: does anyone have decent instructions for properly uploading binary-only packages for alternate ports? for the ncurses upload, I cheated a lot, editing the .changes file by hand...) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ncurses3.4 and uploads in general...
ncurses-3.4, which doesn't exist in hamm/binary-sparc or in master's project/.../Incoming directory (only a newer binutils and at So ncurses 3.4 built cleanly with one minor patch to debian/rules which I've filed as a bug (apparently tic gets run on the rxvt.ti file using the installed shared libs, instead of the freshly built ones, but on any other platform you wouldn't notice because you *have* preinstalled libraries :-) However: I can't find (and I thought it was documented *somewher*) procedures for uploads of alternate architecture packages. I maintain a dozen or so packages and do the x86 uploads for them already... so I've already got the accounts and dupload setup to do it... is there anything more than that? Or do I just cook up a .changes file and dupload that? I looked in /usr/doc/dpkg and /usr/doc/debian-policy and didn't find what I was looking for, so a more specific pointer would be helpful (since I suspect I'll be uploading a lot of these as I make my system more useful...) _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian X Maintainer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Unimplemented SPARC system call 162
So, what is a Unimplemented SPARC system call 162? I get it once (with register dump) each login, plus a few times during bootup (with either the 970328/2.0.29 or 971208/2.0.32 kernels...) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ZIP disk sparc install, anyone?
Thanks to a tar file from Michael Shuey, the http://www.geog.ubc.ca/s_linux/faq.html web page, and the Debian-SPARC.txt in ftp://lix.polytechnique.fr/pub/Linux/debian/sparc/bo/disks-sparc/970328 I've now got a my SS1 running off of a bootable debian/sparc ZIP disk. I'm ftp'ing and installing packages to get it usable as a development system (can't really use it over the net until I get kerberos up and running, for example.) I've noticed that a number of packages in hamm/binary-sparc (less and info, for example) are built with ncurses-3.4, which doesn't exist in hamm/binary-sparc or in master's project/.../Incoming directory (only a newer binutils and at there...) So, where *did* those packages come from, if ncurses is missing? Should I just grab the sources and build it? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New install help
Debian for quite awhile, and can get around in it pretty well. What I'm looking for is an easy step by step on getting the 1+ to boot Deb. The Things are still a little dodgy, getting a *complete* debian system isn't there yet (ncurses3.4 is missing but some stuff uses it, one of the bfd packages has a trash bfd.info.gz, little things like that), but if you want something to usefully experiment, netbooting is the way to go. Aside from the tar file I got from someone else here of a running system (I don't have an appropriate system to re-serve it from, but I could maybe make bootable zip disks for people if that would be useful -- let me know, though I couldn't actually do any until january) the two most useful places to look were: http://www.geog.ubc.ca/s_linux/faq.html ftp://lix.polytechnique.fr/pub/Linux/debian/sparc/bo/disks-sparc/970328 I'll note that from my experience, tftp+nfs is the way to go; oh, and an SS1+ probably has the old proms (mine does) so you need to actually do a reset before rebooting, or it gets confused [blanks the monitor, stops listening to anything] which can make you think that the installation failed when it's just the reset that failed. Supposedly telling the monitor setenv sunmon-compat? false will fix this problem but I haven't tried it. Note of course that once you've netbooted, the first thing you want to do is install on an actual disk... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
[Debian Installer maor-installer@debian.org] ash_0.2-1_sparc.changes REJECTED
not sure why this came to me... --- Start of forwarded message --- Date: 20 Apr 1997 23:44:40 - Message-Id: [EMAIL PROTECTED] From: Debian Installer [EMAIL PROTECTED] To: Mark W.Eichin [EMAIL PROTECTED] Subject: ash_0.2-1_sparc.changes REJECTED Rejected: ash_0.2-1_sparc.deb: Old version `0.2-1' = new version `0.2-1'. If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. Your rejected files are in Incoming/REJECT/. (Some may also be in Incoming/ if your .changes file was very badly formed.) If only some of the files need to be repaired, you may use the good files from Incoming/REJECT/. Please rm the bad files from Incoming/REJECT/. Guy --- End of forwarded message --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
