The collected works of canavan - Page 2

Edit: No use to suggest 7035 and 7065 CPUs - these are not pin (ball :) ) compatible with the RM5271.
The 7035 should be a perfect match for the rm5231 in the Cobalt Qube. I'll trade you one Qube2 for an upgrade :D
hamei wrote: [...]Gave the executable a double-click and wham ! computer locked up tighter than a Shanghai Princess' pocketbook. Not the desktop, the entire thing. Vulcan death grip failed, power button failed, I had to pull its life support cord. Sumbitch.
This is an r5k-350 O2 running 6.5.22, graphics is 1440 x 900, neko glut (the latest one, forget what rev.)
Same lockup here with another O2 r5k-350. Tried two different default visuals because it's working fine on my O2 R12k-400. While one did show me a false-color window frame of Die Planeten and the other showed nothing at all, both resulted in a lock up.

Martin, could you please link the next version with "-rpath /usr/nekoware/lib" (or "-Wl,-rpath -Wl,/usr/nekoware/lib" depending on how you invoke the linker)?
Synergy is the official successor to teleffect. It's in nekoware and works fine for me. Windows, Mac, Linux and other versions are on Sourceforge.
Chromewave crashes my O2 r7k 350 even when I'm running it remotely, i.e. it's obviously a problem with the graphics, not the program itself.

For a little bit of extra performance, consider the enclosed patch to chromewave's makefile.
Does the -IPA switch bring a decent performance gain?
In this case, apparently not. In other cases, I've seen massive improvements, i.e. 10x speedups if code from other files gets inlined, and cases where the compiler produces defective code with -IPA and needs to be prevented from inlining specific functions with #pragma noinline.

I think there's a larger gain in performance by using "-lfastm -lm" than by using -IPA - still not much but at least visible in direct comparison. See man libfastm. I haven't tried that with the R7k.
You can't really enfoce it, but you should be able to set this as default by running the xset commands either in Xsetup or Xstartup and add xlock or xscreensaver to the default Xsession.
I was just trying to compile GEDA yesterday, and so far, I've failed.

GEDA needs a newer cairo with pango support that has pango_cairo_show_error_underline. That again requires a few other updates to glib, guile and pixman, and of course fontconfig. I'm currently stuck at fontconfig, as the fc-cache just segfaults somewhere when it's traversing some double linked lists. Another issue is that poppler in nekoware is too old for cairo, but the current one fails with gspawn.h complaining that it only wants to be included from glib.h (which it is).

I was going to try kicad, but that needs a newer cmake than the one in nekoware, and I can't compile cmake because my /tmp is too small.

So far, all I've got is a tardist of guile and glib, plus some trivial patches for pango and fontconfig.

Edit: fontconfig just seems to have trouble with the old nekoware fontconfig, so I'll try removing that first tomorrow. A new harddrive mounted as /tmp enabled me to build cmake (will provide nekoware tardist tomorrow), but kicad fails to build with:
Signal: Segmentation fault in Front End Driver phase.
Error: Signal Segmentation fault in phase Front End Driver -- processing aborted
I've just uploaded a fixed neko_pango to /incoming.
grabbed the source for the server, it compiled out of the box.. Yippee. Someone with a brain. Didn't try any of the clients. Xmms2, you may lick my sweaty nutsack.
Over here, it compiles, but without libmad support, i.e. no mp3. Just like with ffmpeg, curl and sqlite, it appears to require pkgconfig support for almost everything, but I don't see anything related to pkgconfig in either the libmad sources or tne nekoware package. It turns out those .pc-files are only part of the debian packages. I've just sent maxk of the mpd project an email about this - if he's not out cycling or flying

The otther problem of course is that the old mpd versions don't compile against the current libflac.
What's the trick to compile supertuxkart 0.6.2a so that it doesn't segfault when trying to load the tracks? I'm using

Code: Select all

LDFLAGS="-rpath /usr/nekoware/lib -L/usr/nekoware/lib -lfastm -lm -lGLU" CXXFLAGS="-I/usr/nekoware/include/ -I/usr/nekow
are/include/SDL"  CFLAGS="-I/usr/nekoware/include/ -I/usr/nekoware/include/SDL" ARFLAGS="-ar -o"
AR="CC  -ptused -quiet_prelink "
./configure  --prefix=/usr/nekoware  --mandir=/usr/nekoware/man

And the result compiles cleanly, links with the extra -lm -lGLU, but always crashes when trying to load a level (from World::loadTrack()):

Code: Select all

Process 134732 (supertuxkart) stopped on signal SIGSEGV: Segmentation violation (handler sig_fixup_mask) at [std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,ssgEntity*,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<ssgEntity*> >::operator[](const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&):158 +0x3c,0x1037d3bc]
158  _Tp& operator[](const key_type& __k) {
neko_curl-7.19.7.tardist and a neko_libtorrent-0.12.6.tardist are in /incoming. The former is guaranteed to break anything that depends on neko_curl, since the major version of the library has changed, the latter is completely untested, and, aside from the patches by PymbleSoftware required the libtool convenience libraries to be compiled -static, which may cause some symbols that should have been exported to be missing.

rtorrent has a number of problems with the curlbuild.h including <stdint.h>, which #errors out for anything but c99, i.e. CC won't work. It may be easier to just copy usr/nekoware/lib/pkgconfig/libcurl.pc from the new curl package, and leave the rest at the 7.15.0.
nekonoko wrote: Any chance for a reupload? I neglected to check /incoming before the server move.
Both are on their way.
Compiled with
c99 -n32 -mips4 -OPT:Olimit=0:roundoff=3 -TARG:platform=IP27:proc=r10000 -Ofast  tenmillion.c  -o tenmillion -lGL -lGLU -lfastm  -lm -lX11
An untested package of supertuxkart 0.62 is on its way to . While the program itself should work (the segfault is fixed), there are a few files (listed below) that are just installed via hacks, and therefore may cause errors or warnings when installing or removing the package. Please test.

Code: Select all

find ~ -exec file {} \; | fgrep executable
I'd prefer find ~ -perm -1
The new neko_mpg123-1.10.0.tardist in beta seems to have a problem or two...
Depends on how you count, I'd say, and that's probably not testing it on non gnu- non-i386 systems in the upstream package, combined with not properly testing the result on my part. A fixed package is in /incoming.
Secret Maryo Chronicles uses CEGUI which makes enough use of templates to cause trouble with the mipspro compiler.
I've always used the VESA GTF Excel-sheet, which works well with the freeware OpenOffice.
Is there an HP-41 emulator of equal quality?
I can't test it because my fontconfig setup is somehow causing a segfault, but nonpareil could be just what you're looking for.

If the attached package doesn't work for you, please install all subsystems and try recompiling and repackaging it on your box. You'll need neko_scons, neko_flex and neko_yacc to build it.
Looking at the list of dependencies it's a no-go... Intel TBB, OpenGL 2.0, QT 4.4.3, Boost 1.42...Finally, I'll just get a quote from the website :
Intel TBB should not be too hard to compile, since the source is available and it even appears to support Solaris SPARC with Sun's compiler. QT 4.4 was the last version of QT that still officially supported IRIX. Boost shouldn't be a problem. The only real problem left is OpenGL 2.0 - if that's required ar runtime, it just won't work.
What's the trick to use timeval when _POSIX_C_SOURCE=200112 is set? Consider the following small program:
#include <sys/time.h>
#include <time.h>

int main()

struct timeval tv;
return 0;
When compiled with
/usr/bin/c99 -D_POSIX_C_SOURCE=200112 -c -o tv.o tv.c
timeval is an "incomplete type", without the -D_POSIX_C_SOURCE=200112, things work as they should. I currently assume the the ffmpeg maintainers have some good reason to set _POSIX_C_SOURCE, so I don't want to remove this.
<sys/types.h> seems to be unnecessary when not in _POSIX_C_SOURCE mode, and doesn't help otherwise.
how about ffmpeg?
SIGBUS: Bus error (default) at [fill_rectangle:61 ,0x42d8a2c] It would not surprise me if that was caused by some other of my rushed patches. I just wanted to have a bunch of libavformat headers to compile blender 2.50...
I'd suspect some of the DECLARE_ALIGNED_... statements to be the source of the problem, but they should just be hints for performance optimization, and not actually required for correct operation.
If your ISO is 721MB, you're doing something wrong. The Image should be about the same size as the installation files. For 6.5.30 CD1, that should be around 420-430MB. If you're using an "original" Indigo2 CD-Rom (i.e. a 3401 or similar vintage Toshibas), it may be picky about the blanks. Try proper branded blanks (Taiyo Yuden, JVC...), and burn them at 4x or slower.
They don't need drivers. When you boot an O2 with one of those, the camera input is renamed and an additional digital output appears in the video panel.
If you have a tar, you've already done half the work to make a nekoware tardist.

Unpack the enclosed neko_pixie_kit.tar in an empty directory, run ./ on the main binary, e.g. ./dependify /usr/nekoware/bin/pixie, paste the result in the appropriate seciion while editing the relnotes and the dist/neko_pixiespec file, stick your patches in patches/, the source in src/, put the list of files/directories in a file called ./files (tar -tvf pixie_irix.tar | cut -b 52-, should be the full path to the instlalled files, starting with /), run "./ neko_pixie", put the neko_pixie.idb in dist, change to dist, run swpkg, File/Open/Both, save both, open them again, then change to the build product pane, adjust the Distribution Directory to somewhere where you can warite, Test Build, Build All, the tar the neko_pixie* in the destination directory into a neko_pixie-2.2.6.tardist.
I only have the unpacked tar around, and it's only 419735k for the entire CD1. Has it really grown on sgi's servers while I wasn't looking?
and STK for IRIX is available on SourceForge:
While the zip downloads OK, there's an unnecessary __MACOS folder inside and the tardist itself is broken:
tar: tape premature EOF; may need to use -b option
The 150MHz and 195MHz CPU Modules are different in that the 195MHz's glue chip isn't as buggy, i.e. the 150 and 175MHz modules drop frames when recording video. I think the CPUs itself should be swappable, to adjust the internal clock multiplier, You'll have to swap some SMD resistors. I'd think that the 150MHz runs at 75MHz * 2, so 187 and 225MHz should be the next possible steps without swapping the clock chip. I think the entire 150-200MHz R10k range runs at 3.3V, and at least from 250MHz on, the core voltage is separate from the 3.3V i/o and lower than that. There's a longish thread around here on upgrading the 250MHz O2 modules to 350MHz R12k.

It would be easier to just buy a 195MHz Module, I think I still have a spare one somewhere.
A nekoware-style tardist.
The required bits to re-generate a new tardist are part of the archive itself in the opt.dist component. You could either use the swpkg tool for a nice GUI to package editing and generation, or edit the .idb to add/remove files or change their location, or the .spec to change versions, dependencies, package names and descriptions. If you want to start from scratch, a number of scripts have been posted here to automate package generation, my attempt is attached to a thread discussing pixie.
The battery won't recharge. It's a lithium battery potted inside the thick Dallas Watchdog chip near the hard drives. Either buy a new one, ask Dallas/Maxim(?) for 2 free samples of the current model, or solder a CR2032 (+socket) in the right place (there's a thread about this somewhere around here).
I'd suspect that neko_fontconfig is broken. Downgrade fontconfig and/or verify that fc-cache works.
And for those of us who don't have flash, here's an update to the neko_youtubedl that also includes vimeo-dl (requires neko_xclip and neko_wget). Just copy the URL, go to Toolchest/Find/WebTools and open vimeo-dl to download the video to your Desktop.
The problem with 4GB cards is really just that IRIX only supports - at best - FAT16, apparently limited to 32k sectors and no support for either the non-standard 64k sectors required for a 4GB filesystem, or FAT32.

I've tried all three of my firewire card readers, and they are all working perfectly with 2GB media. Note that the label on the RW-19 calls it a RW-19 Rev. B.
swpkg is just a GUI to generate an idb (easy to automate) and spec (requires some manual adjustments) and a frontend for gendist.
Does anyone know the pinout of the black + white cables used to connect a VBOB to a XT-DIGVID? Is it straight through MDR26 <> MDR26 (or half pitch Centronics, whatever it is called)?
Anyone? If no one knows, could somebody please measure his?
The last Tezro with simliar specs that sold on went for a bit more than 2200 EUR, if I'm not mistaken.