Re: page fault in mkfontdir
oops, should have looked, bug 82601 is already open (says sparc only, though) and that it is probably due to some other lib, not mkfontdir code itself. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=82601 They point out that this: required from libc.so.6: 0x0d696911 0x00 05 GLIBC_2.1 0x0d696912 0x00 03 GLIBC_2.2 0x0d696910 0x00 02 GLIBC_2.0 (from objdump) is somewhat odd, and probably wrong...
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: 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.
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: slink problems on Sparc 5
> 1) When I invoke vi from an xterm, after I exit vi, the cursor does not > reset itself to the first unused line on the screen. Instead, it seems to I'm pretty sure this is not sparc-specific; this is a known problem on x86 too, though I don't recall if ncurses or xterm is to blame, it should be one or the other.
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: Debian 2.1 on sparc clone (compstation ii)
> that since i went through fdisk and deleted/re-created the partitions, > that everything would work. If the disk already had a PC partition table, fdisk will assume you want to keep it that way - and (this was recently fixed) hide the "s" command which initializes the sparc-style partition table. You can still run it, it just doesn't get listed...
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 :-)
Re: Thanks: X works as root, not as user
> The usual: You must have a Sun disklabel and the first partition > can't be swap on the boot disk. Be sure to note that you can hit "s" to *create* such a disklabel, even if fdisk doesn't offer it (and yes, I've filed the bug report already :-)
Re: 2.1_r0 install experience
> On the sparc, fdisk has: >s create a new empty Sun disklabel Indeed, it *has* that option - but it won't *show* it to you if it finds a DOS partition table already there, for example. That's another one to either (1) fix (2) put in the install notes (3) mention in the "partition a disk" dialog in the install kit...
Re: 2.1_r0 install experience
> Hmmm. If that's correct then it's a bug - the comment should say to run > _dselect_ with the last binary CD in the drive, not to boot that way... Indeed, I misremembered. The comment was really from README.multicd, and it very clearly says *after* you've done the install, etc. Sorry about that... _Mark_
Re: 2.1_r0 install experience
> On the sparc, fdisk has: >s create a new empty Sun disklabel Hmmm, does it only have this if it *doesn't* find some existing disklabel? (I'll try it when I get back home, but I didn't see it...) > sure if all the endian issues are worked out.) Intelsilo is at: > http://www.cse.msu.edu/~dunham/debian/silo/ tnx. There isn't one in unstable, at least not as of last night... and it wasn't obvious how to build it from the silo-0.8.5.tar.gz, which seemed to be stripped down to sparc-only. (I did have an old 0.6.7 intelsilo binary but it seems to be cd-rom specific...)
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: 2.1_r0 install experience
So, I went through the install, and an old problem reappeared... When booting off of this disk (sd(0,2,0)), I get Bad magic number in disk label! S Bad magic number in disk label! IProgram terminated. ok I assume this is because (1) the disk was originally formatted on an x86 linux box, so it has a DOS partition table (2) fdisk isn't a "big enough hammer" to fix that... I did note that fdisk had a "b" option for "edit bsd partition table" but all it said was "/dev/sdb has no BSD-style partition table"... I did find (after rebooting with the rescue zip disk) the eXpert mode "g" option for "create an IRIX partition table" which is somewhat distressing... and in fact, that looks like what it *does* do. Very very strange. Suggestions for hammering in a partition table/disklabel that silo will deal with? What would happen on a blank disk (which I can turn this one into, with dd)? _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
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: 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: status: pass 1 complete
> But I am about to manually compile slang, ncurses, emacs*, libgtk1, > and the gimp anyway -- they just might work nowadays. For now I'll > leave xfree86 to X Strike Force member Michael Shuey. Yeah, avoid compiling "emacs" itself, but the emacs19 sources should already have the sparc fixes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: inital install & fdisk
Actually, though, the kernel will *mount* disks that have x86-linux style partition tables -- sparc-fdisk will core dump on them, though. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: SS1+ and stability
yes, there have been a few critical improvements (the select fix in the kernel syscall table, some libc things, and others I don't have at the tip of my tongue...) My SS1+ here has been up for over 2 weeks, and done an X build and a bunch of other random packages. (I still need some X server patches, but the libraries are up and running so a lot of people have been able to work on things further, from there...) -- 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: 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: 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: xserver package wanted
RIght, there are no xserver* packages yet. I'm still working on that (with help from a few others here) but figured I'd upload the development and base stuff so that (1) you could pop up xterms and emacs to other machines (2) imake and xmkmf were available, so builds of other packages could continue... -- 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: Bug#16987: xpm4g: attempts libc5 build on sparc
I didn't realize there were that many altdev libraries. Since there never *were* libc5 X libs, I'd just as well not build altdev ones either -- it's not like we have a "bo" sparc release to support, right? Unless I hear some *really* good arguments, I'm not going to add an X altdev package, either... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New glibc
> This is very common in glibc. They want the programmer to > include *only* , and not . That way, Hmm, I'll try and see what the code was really doing, but I seem to recall that something *else* was including the incompatible set... Nonetheless, having different definitions like that (enum vs #define) really are *wrong* and should be fixed... even if they don't just get put into *one* file. I'll look into fixing the code to avoid it though. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New glibc
As I posted earlier:
> 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 :-)
My fix was to edit linux/socket.h, put in an #if 0 right after the
include , and an #endif right after the #define
MSG_PROXY. That's sufficient to allow a number of network programs to
actually build. I suspect, but have not confirmed, that you can ditch
the SOL_* defines (since they're in bits/in.h) and the IP_TOS defines
(same place); TCP_NODELAY is in netinet/tcp.h. Looks like SOPRI_*
haven't shown up anywhere else yet, so I guess you can't completely
ditch the file, though.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: pb compiling with gcc-2.7.2.3-3
> You can initialize variables in a library using a constructor. Not portably. __attribute__ ((constructor)) is [obviously] a GCC extension. As such a change would then be gcc specific, it would probably not be accepted as an upstream change by any but the most linux-specific packages... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 select problems?
> 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, That's cool. I'm told[1] that the 1.10 e2fs libraries should certainly support both byte orders, so just rebuilding silo should be enough to get it to solve my problem (booting off an x86-linux formatted scsi disk.) Of course, rebuilding with libc6 is harder than it looks, though I've gotten it as far as linking second.b and failing (setjmp problems, and some missing libgcc-type functions [lshrdi3, ashldi3] which libc6 now uses that can probably be cobbled up from somewhere.) studentloan+% ld -N -Ttext 0x28 -Bstatic -o second crt0.o decomp.o console.o printf.o malloc.o jmp.o prom.o tree.o bmark.o main.o cmdline.o disk.o file.o misc.o cfg.o strtol.o ranges.o timer.o memory.o ufs.o divdi3.o -L../include -lext2fs mark.o -lc /usr/lib/libc.a(setjmp.o): In function `_setjmp': setjmp.o(.text+0x0): multiple definition of `__setjmp' jmp.o(.text+0x0): first defined here /usr/lib/libc.a(_itoa.o): In function `_itoa': _itoa.o(.text+0x16c): undefined reference to `__lshrdi3' _itoa.o(.text+0x184): undefined reference to `__lshrdi3' _itoa.o(.text+0x690): undefined reference to `__ashldi3' [1] by Ted T'so, who would probably know :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pb with modutils & sparclinux-2.0.32
I get the same error (on a fresh built 2.0.33 kernel, though I saw it under 2.0.32 as well.) However, the modutils on ftp.debian.org expects a later sysvinit which isn't there: Depends: libc6, sysvinit (>=2.71-2), debianutils (>=1.6) vs. Package: sysvinit Version: 2.70-1 so I'm curious as to how you managed to install it. Nonetheless, % sudo insmod fat /lib/modules/2.0.33/block/fat.o: create_module: Unknown error 30359552 Exit 1 (which is 0x1cf4000, not that that means much.) >>/lib/modules/2.0.32/fs/ufs.o: create_module: Unknown error 30363648 (which is 0x1cf5000, hmm, a pattern? :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pb compiling with gcc-2.7.2.3-3
Problem is, some programs are hard to change like that (some stuff in tetex-bin, for example, does that initialization for an extern in a library, so there isn't a main() into which to move the initialization...) Note, also, that as far as I can tell from the X build, the *only* platform ever to have this problem is LynxOS, and that was about as marginal a Unix you could get (it's a realtime unix, just this side of the unix vs. realtime line from vxworks...) Even if there isn't a standard to back me up [if there is, then this is a bug, plain and simple] I'd still argue that it should be fixed since it's going to break so much code [as we've learned on this project...] -- 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: 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] .
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 , 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] .
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] .
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
+#include /* 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] .
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: 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: libc6 select problems?
If anyone is still following this thread, the bit I mentioned earlier about write, rather than select, being broken, is based on instrumenting rsync with lots of fprintfs... Basically, what happens in io.c is writefd(4,e388,4), bfi 5 write(4,e388(0),4) got 4 [that's fine...] writefd(4,e001f000,17982), bfi 5 [this is attempting to dump the COPYING file over the pipe...] recv_files(rsync-1.6.7/COPYING) write(4,e001f000(0),17982) got 4076 <== PARTIAL [the write() of 17982 bytes returned after writing 4076.] write(4,e001ffec(4076),13906) got 4096 <== PARTIAL [the write() of the remaining 13906 bytes returned after writing a suspicious 4096 bytes...] write(4,e0020fec(8172),9810) got -1 <== PARTIAL [further logging indicates that this write returned EAGAIN... but as soon as we select on it, we get EBADF, even if we sleep to let it drain.] select details: fdc 6 bfi 5 fd 4 count -1 PID 27324 select more: r[0] 20 r[1] 0 w[0] 10 w[1] 0 select error: Bad file descriptor Now at least I've got someplace else to look. Question: where are the sources to the *libc5* that we're using? It's 5.3.12-mumble, not the debian standard 5.4.x, for which sources are on the mirrors, which doesn't have *any* sparc support that I can find... Ah well, maybe I can start on X next weekend. It isn't really worth trying until we get more of this worked out (even if I do punt the -lpthread stuff, I'd rather not go further with a known broken libc when I've got useful small examples that break...) -- 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: 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: 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] .
pthread trouble, anyone?
looks like pthread library isn't in sync with libc: gcc -o makekeys -O2 -ansi-I../.. -I../../exports/include -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_REENTRANT -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RETURNS_NULL util/makekeys.c -lpthread /usr/lib/libpthread.so: undefined reference to `__clone' In i386 libc-2.0.6, it has T __clone and W clone; sparc libc-2.0.90 only has W clone... -- 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] .
libc6 select problems?
I've built a couple of things with gcc 2.7.2.3-3 and libc6-dev 2.0.90-971126-1, and find that there's some significant problem with select. Both rsync and xntpd die (or spin) with errors from select, reported as "select error: Bad file descriptor". I haevn't debugged it in any detail yet, has anyone else seen it, and have suggestions? -- 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] .
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] .
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] .
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: ZIP disk sparc install, anyone?
> making Xsun work on my IPC. You don't even want to know how slow the > compile is. However, I'm able to build most of X11R6.3 (from ftp.x.org) Heh. The x86 debian X packages (libc6+alt-libc5) take about 60 hours to build and package on my 486/40 (my personal debian machine.) > integrated into the current X sources? Keep in mind that X11R6.3 does not > support S/Linux out of the can; you need to do lots of patching. I'll note that the sparc in question is an SparcStation 1+ w/cg6, currently running SunOS 4.1.3_U1, and since a bad sector took out openwindows (such a loss :-) I built XFree86 3.1.2 instead... which took *surprisingly* little patching, mostly makefile stuff as I recall. I haven't had a chance to update it, this would be an excuse to look at that too. Still, I'd be interested in seeing the patches you've got -- since, ideally, it would just be another case of running dpkg-buildpackage in the debian X sources (the m68k and alpha are *almost* there, I've not been as careful as I should about getting all their changes folded in but the bulk of them are now...) > Actually, I happen to have a 25mb root image kicking around that'll get > you up and running in a hurry (I use it whenever I totally screw up my Mmmm. I'll contact you directly tomorrow after I've figured out a short-term dropoff point. _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] .
ZIP disk sparc install, anyone?
Anyone have a premade ZIP disk-sized install that I could just stick in a Sun and boot? Or are there enough pre-cooked materials that this would be easy to construct (something like (1) mke2fs the zip disk (2) unpack some base.tgz onto it (3) dpkg --root /zip -i *.deb (4) some sort of command to make it bootable...) from a running x86-debian box, in which case I'll do it myself :-) _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] .
[Debian Installer ] 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] .
