The collected works of canavan - Page 4

I've just measured one of the black cables I bought from richtom, and if I'm not mistaken, they are not wired like the cameralink cables as described in the Wikipedia article. Cameralink appears to specify that the top left pin should be connected to the bottom right one on the other end. The SGI cable has the top left pin connected to the top right one, and so one going towards the center. I was unable to find any connection for the bottom row.

I do have a pair of MDR-26 cables (50 cm long) that are wired 1:1, i.e. pin 1 to pin 1, pin 26 to 26.
That's actually a german auction on, but even if you can understand German, there are no details about the internal configuration of the cable. Theoretically, anyone in the EU could buy one, measure it and return it, while only paying for shipping...
Read the wiki article make sure you check the releasenotes and dist files of older versions of the same software, and if you're lazy, try the two scripts i've posted here viewtopic.php?f=11&t=16723208&p=7321579 (but I suspect won't get the subsystems right since you're installing directly into /usr/nekoware.
I've just uploaded neko_python-2.7.3 to /incoming. It replaces the "old" python 2.5 and adds "proper" dependencies for the modules. If you just "inst upgrades", you'll probably lose all dynamic modules, "inst default" should fix this.

I've also added File Type Rules for .py files - this may or may not interfere with any attempts to start python scripts by double-clicking on the desktop. This definitively needs testing.

If there's anything out there that depends on python 2.5, that may have to be upgraded as well.
I thought I'd need expat 2.1 to get python 2.7 to compile, but I was wrong - I just had a typo in the configure flags. I've just uploaded neko_expat-2.1.0 to /incoming anyway (and the expat module in my python 2.7.3 now depends on expat 2.1.0).
I'd recommend a "universal" 13W3 cable. I have one similar to this and it has served me well so far. Since only the sync signals pass through the switches, the signal quality is not degraded in comparison to "original" SUN or SGI cables.
The fix is to also install the eoe.lib subsystem, which I neglected to include in the previous version of the package. A new and significantly larger package is in /incoming. There's also a new neko_youtube package and a neko_fetchmail package (to get rid of old python2.4 cruft).

My updated python 2.7.3 package is now at ... .3.tardist
/usr/gfx/stopgfx; /usr/gfx/startgfx

would have done the trick as well, I think. Otherwise, restarting xdm with /etc/init.d/xdm (start/stop) would definitively help.
Concerning the lifetime of an SSD under IRIX, has anyone thought about using fx and the various options for mkfs_xfs (such as sunit, swidth , lazy-count) to reduce write amplification?

Here's a forum thread of some NeXT users , where someone recommends using hdat2 to reserve part of the SSD as a Host Protected Area, such that a larger fraction can be used for wear leveling.

Has anyone run any benchmarks on an ACARD-connected SSD in something more modern (IP35)?
The same problem was discussed here viewtopic.php?f=10&t=16726761 but there's no conclusion. I'd also try to zero the disk, that should work from the miniroot with cat /dev/zero > /dev/rdsk/dks0s2vol (possibly substitude dsk for rdsk, vh for vol, the numbers, use dd instead of cat, etc). If that doesn't work in the miniroot, try another box to zero the disk. In case the disk is actually broken, I have a few 18GB drives that I want to get rid of, you can have one for whatever shipping from cologne to vienna costs.
Co-workers said something like that..
Your cow-orkers may be mistaken. libjpeg-turbo is actually measurably faster than the standard libjpeg, even without any SIMD support. However, the performance gains are small in comparison to a SIMD-enabled libjpeg-turbo.

I may have to update the neko_libjpeg package to include the libjpeg v8 backwards compatibility, as some programs expect In-memory source and destination managers nowadays.
I have never gotten my Ultra64 to work, because I don't have usable IRIX 5.2 media, so I can't provide any specific help. To check what dbgif is even trying, run
par -i dbgif
It may be trying something like
open("/ns/.local/hosts.byname/localhost", O_RDONLY, 072)
or sending something to to UDP port 53 of your DNS. I'd guess it's trying to resolve localhost or something equally silly. Have you verified that your /etc/nsswitch.conf (if it exists in 5.3...) lists "files" first for hosts?
jsloan wrote:
Ok, here is what I got from 'par'

9mS dbgif( 536): read(5, "nameserver\t192.168.1.1\n", 4096) = 23
9mS dbgif( 536): read(5, 0x10134b18, 4096) = 0
9mS dbgif( 536): close(5) OK
9mS dbgif( 536): gethostname(indy64, 256) OK
9mS dbgif( 536): getpid() = 536 ppid=535
10mS dbgif( 536): getpid() = 536 ppid=535
10mS dbgif( 536): time() = 1355791715
10mS dbgif( 536): getdomainname((null), 256) OK
10mS dbgif( 536): socket(PF_INET, SOCK_DGRAM, 0) = 5
10mS dbgif( 536): connect(5, <00 02 00 35 c0 a8 01 01 00 00 00 00 00 00 00 00>, 16) OK
10mS dbgif( 536): send(5, <00 01 01 00 00 01 00 00 00 00 00 00 06 69 6e 64>..., 24, 0) = 24
11mS dbgif( 536): select(6, IN:set=5 OUT:set=5, 0, 0, sec=5 usec=0) = 1
27mS dbgif( 536): recv(5, <00 01 81 83 00 01 00 00 00 01 00 00 06 69 6e 64>..., 1024, 0) = 99
28mS dbgif( 536): close(5) OK
28mS dbgif( 536): open(/usr/lib/locale/C/LC_MESSAGES/uxsyserr, O_RDONLY, 01752601414) errno = 2 (No such file or directory)

So it finds hostname just fine, and then correctly returns null for domainname, since there is none.
While gethostbyname and getdomainname are both OK, it still proceeds to contact a DNS server (0x35 is 53 decimal, which is DNS,
0xc0 0xa8 0x01 0x01 is your configured name server. Not sure what it tries (forward or reverse lookup), you may have to check with tcpdump, or a higher log level for your DNS, or just make sure that both forward and reverse lookups work for the indy.
But it seems to fail on:
open(/usr/lib/locale/C/LC_MESSAGES/uxsyserr, O_RDONLY, 01752601414) errno = 2 (No such file or directory)
and indeed, I do not have a:
directory at all ... should I ?
That's most likely OK. There are no translations for this text, so the file for a translation table to the "C" language (locale) doesn't exist. This just means that the message is printed as is - "gethostbyname call failed",
Another round of measuring my black cables with a DMM that actually beeps and some finer probes resulted in the following pinout is

Code: Select all

1 <> 14
2 <> 2
3 <> 23
4 <> 22
5 <> 21
6 <> 20
7 <> 19
8 <> 18
9 <> 17
10 <> 16
11 <> 15
12 <> 26
13 <> 25
24 <> 24

and vice versa.
Is this a rack mount tezro? I don't see the "BOOST" zone or Fans 8-10 listed.
This seems to be a linking error but I ain't no programmer ... what's the best way to figure this out ?
It's a linking error, but it's really something that probably has been cought by configure, but isn't handled in svg.c. Just copy the snippet below from render.c over to svg.c, and report that as a bug upstream, since it's a portability issue.
#ifndef HAVE_VFORK
#define vfork fork
Shouldn't even gcc find things like this ? Defining the same thing several times cannot be good.
No, the compiler can't catch any of those Multiply defined: problems, because the symbols are independently defined in multiple .c files, and the compiler only ever gets to see one of those at a time. The two culprits are referred to as "Local Variable definitions" in both .c files, just declare one set as external, and the warning should go away. Open another bug for this one, I'd say.
conversion from pointer to same-sized integral type (potential portability
Not sure where that comes from - could even be the Xt headers. You could always just suppress those with -diag_suppress 3970.
Try pointing configure to your gnu install via INSTALL=/usr/nekoware/bin/install
/usr/nekoware/bin/install is in neko_fileutils.sw.eoe
neko_dia specifies no dependencies, however, they should look approximately like this:
neko_atk.sw.lib 5 maxint
neko_bzip2.sw.lib 5 maxint
neko_cairo.sw.lib 5 maxint
neko_esound.sw.lib 1 maxint
neko_expat.sw.lib 6 maxint
neko_fontconfig.sw.lib 4 maxint
neko_freetype2.sw.lib 13 maxint
neko_gconf.sw.lib 4 maxint
neko_gettext.sw.lib 9 maxint
neko_glib.sw.lib 10 maxint
neko_glitz.sw.lib 2 maxint
neko_gnomekeyring.sw.lib 2 maxint
neko_gnomevfs.sw.lib 2 maxint
neko_gtk.sw.lib 8 maxint
neko_libart.sw.lib 2 maxint
neko_libaudiofile.sw.lib 1 maxint
neko_libbonobo.sw.lib 4 maxint
neko_libgnomecanvas.sw.lib 3 maxint
neko_libgnomeui.sw.lib 2 maxint
neko_libgnome.sw.lib 2 maxint
neko_libiconv.sw.lib 4 maxint
neko_libjpeg.sw.lib 6 maxint
neko_libpixman.sw.lib 2 maxint
neko_libpng.sw.lib 10 maxint
neko_libxft.sw.lib 2 maxint
neko_libxml2.sw.lib 7 maxint
neko_libxrender.sw.lib 2 maxint
neko_openssl.sw.lib 22 maxint
neko_orbit2.sw.lib 3 maxint
neko_pango.sw.lib 13 maxint
neko_pixman.sw.lib 1 maxint
neko_popt.sw.lib 2 maxint
neko_zlib.sw.lib 6 maxint
It also has python bindings that should be in a separate subsystem and should depend on neko_dia.sw.eoe as well as neko_pygtk.

I'd update dia, but then I'd have to build pygtk for the python 2.7.3 that has found its way into /current by now. That needs a newer pygobject (a not current anymore version of which is bundled in neko_pygtk for unknown reasons), which again requires a new glib, which requires libffi (would be in /incoming by now, but the ftp server says "I'm sorry anonymous, I'm afraid I can't do that."), and the new glib requires constructor and destructor support. I have no Idea how that's supposed to work with c99. At least fec_360 seems to have constructor support, and I can use that with -Zf,_360, but it still just produces errors.
$ strings /usr/lib32/cmplrs/fec_360  |grep __attr |grep const
__attribute__ ((constructor)) specified for %s

$ c99 -Zf,_360 -c constructor.c  -o constructor.o
cc-1079 c99: ERROR File = constructor.c, Line = 2
A type specifier is expected.

static void __attribute__((constructor)) glib_init_ctor (void);

cc-1137 c99: ERROR File = constructor.c, Line = 2
Unnamed prototyped parameters not allowed when body is present.

static void __attribute__((constructor)) glib_init_ctor (void);

cc-1129 c99: ERROR File = constructor.c, Line = 2
A left brace ("{") is expected at this point.

static void __attribute__((constructor)) glib_init_ctor (void);

cc-1012 c99: WARNING File = constructor.c, Line = 7
Parsing restarts here after previous syntax error.


cc-1196 c99: WARNING File = constructor.c, Line = 8
The indicated function is declared implicitly.

glib_init ();

unable to proceed because of earlier errors
3 errors detected in the compilation of "constructor.c".
$ cat constructor.c
static void __attribute__((constructor)) glib_init_ctor (void);

static void
glib_init_ctor (void)
glib_init ();
If anyone wants to update the dia package, below are file type rules and icons for dia and .dia files.
In most cases, the proper fix for LD_LIBRARYN32_PATH is linking with -Wl,-rpath -Wl,/usr/nekoware/...., but I suspect it won't make much of a difference in this case.
You should set your MANPATH properly in your ~/.profile (or whatever it is ksh sources).

Obviously, manpages for nekoware packages belong in /usr/nekoware/man, not /usr/nekoware/share/man....
anon ftp is working now, neko_libffi-3.0.11.tardist is in /incoming. Will contact you the next time I stumble upon this or similar problems.
You could add OpenML drivers to e.g. Blender, Cinelerra, Kdenlive, LiVES, Ekiga or Linphone. If you need an IRIX dmedia audio driver before you build a nekoware package for any of those, I'll be glad to be of assistance.
I'll also vote for the automatically displayed release notes for information critical for the installation or operation. Some SGI/commercial packages just echo some additional information to the console or the log pane in swmgr, but that's just too easy to overlook. Any patch/configure/build/dependency info etc. can still go into an optional file in /usr/nekoware/relnotes.

While we are discussing changes, I think manpages should always go into /usr/nekoware/man, not share/man, and patches into /usr/nekoware/patches, not /patch. There's also a doc/ and docs/ subdirectory, and we should standardize on at most one of those.
That thing looks suspiciously like an acenic and would probably also work with Irix
Sounds like the network configuration is somewhat broken. Start a shell and check with ifconfig and netstat -rn if the interfaces and routes are correct.
$ versions long |grep stddef.h
f 64565     1 irix_dev.sw.headers     usr/include/stddef.h

The base package is on the development libraries CD, and you'll need the update from e.g. CD 1 of IRIX 6.5.30 or 6.5.22 (or whatever you have installed, I only have those two at hand).
I can't see any reason to introduce /lib32 either.

jpstewart makes a few good points, and I'll add that I don't have any strong preference for share/man vs. man or share/info vs. info, just that we should agree upon one. I've been using --mandir=/usr/nekoware/man for most packages I've made in the past few years, but I don't mind switching to share/man for any future packages or updates.

In case no such thing exists yet, could someone please write a quick script that lists all files in all nekoware packages with the package name and subsystem they are contained in, like debian has in the e.g. Contents-mips.gz, separately for /current and /beta?

Back on topic regarding the release notes: If we decide to package releasenotes in /usr/relnotes, we'd need some kind of guidance what should go in there, and how it is to be structured. Those supplied by SGI look suspiciously like manpages (or catman pages, i.e. pre-rendered by roff/groff). Does anyone know which tools are used to generate them?
All the relnotes files will be named like the package, so there certainly won't be any misunderstandings where they come from. My nekoware packages already spill stuff in /usr/lib/filetype/local (where they don't really belong, local probably shouldn't be touched by packages), /usr/lib/desktop/iconcatalog and /usr/lib/images, and I have to say I'd hope more packages would do the same.

The man page claims that release notes can be found in $RELNOTESPATH, but I don't think it's a good Idea to require non-standard stuff in root's environment to display "essential" information during installation.

Some time ago I thought it would be a good idea to turn the current releasnotes (i.e. the build/patch instructions) into a shell script or makefile that would automatically extract, configure, build, install and gendist the nekoware package. That would make small updates rather convenient, but requires some more standardization where sources, patches, dist files etc. need to be for the build process, and where gendist can find relnotes etc. Relative paths should be sufficient, as I'd prefer not to put unfinished stuff in /usr/nekoware while upgrading a package.

I've just tried the relnotes as Makefile Idea on neko_youtube_dl-2013.01.08.tardist (now in /incoming, I just forgot the unpacking and patching part), and while it's convenient, it doesn't really look nice. Suggestions for improvements are welcome.
make -f relnotes/neko_youtube_dl.txt PATCH BUILD PACKAGE
Substitute with -lgl or -lGL, if none of those work, i.e. the linker complains about missing symbols, check if you have the manpage for the missing function installed (it may contain hints which library is needed), if not just use a shell loop over /usr/lib32/*.so and check with nm if the function is in there as MIPS_TEXT (as opposed to UNDEF).
That thing will most likely - just like any other VPN client nowadays -require a TUN or TAP device, neither of which is available on IRIX, as far as I know. However, I haven't checked...
Since it's not quite clear what you tried to spot the difference between a 24 and 8 bit desktop or what version of IRIX you're using, I'd almost guess it's the icon antialiasing. Read these topics viewtopic.php?t=8899 viewtopic.php?t=1344 and report back which settings exactly have helped.

If that's not your problem,. are you using jpegs as backgrounds? I suspect you can still save a small bit of memory by converting them to 256 color PNGs (or XPMs), e.g. with pngquant or pngnquant from nekoware /beta.
The MIPSpro C++ compiler isn't c99 compliant, the C compiler however can be if you want (by calling it as c99 or with -c99), but that'll not help you with C++ source files. You'll have to supply a family of replacement macros with a fixed number of parameters, e.g. _MSG1(x), _MSG2(x,y) etc.
Autoconf/Automake/libtool apparently fail to install convenience Libraries if an RPATH is set via LDFLAGS, e.g.
-Wl,-rpath -Wl,/usr/nekoware/lib

Somehow, libtool comes to believe that convenience libraries need to be build dynamically, but since they are not to be installed, the entire installation fails. However, I'd like to set an rpath for the binaries, so that I don't have to set an LD_LIBRARY_PATH and potentially confuse programs linked against older IRIX system libraries. Obviously, this is a problem for any program that makes use of convenience libraries in the build process, or even libraries that come with demo programs. Does anyone know a workaround for this?
How would I pass -non_shared to the compiler, if I still want some shared libraries to be built in the process?

Patching libtool seems possible, but would require always up-to-date autostuff to be able to autoreconf everything.
I thought it was time to update the libtiff available in nekoware, because the version in /current is vulnerable to a number of overflows of one kind or another. It turns out that the previous updates bundled an even older version of libtiff etc, as well as libport, which should not have been included in the first place. As a result, neko_tiff-4.0.3, which should appear in /beta soon, is going to break a number of packages.

As an experiment, this package includes an inst.README that basically warns about this incompatibility and is displayed automatically by inst or swmgr when opening the tardist. Additionally, it includes "real" relnotes that can be read with relnotes, grelnotes or (if you're running the required services) via Help/Release Notes from the toolchest.
I've just uploaded a current build of Imagemagick to /incoming to make sure that there's anything that can be used to test the neko_tiff-4.0.3 that's discussed here .

neko_imagemagick also includes 'proper' release notes that should be readable with relnotes or grelnotes. Just like the ones that I've bundled with neko_tiff, they are html based, as I didn't find the proper tools and commands to genereate "old style" release notes. Instead, I've just modeled the release notes on those supplied with ml_xtdigvid. If anyone wants to replicate that, It should be noted that there appear to be some rather arbitrary limitations that cause the text to be cut off or not displayed at all, e.g. the table I've used to list the dependencies can only have a limited number of rows.

Since those release notes are experimental at best, I'm looking for some feedback to improve the whole thing.
I overlooked the fact that there was an old neko_mtr, and started from scratch. I suspect you have the graphics frontend of the old one left over, since the new one can just switch between gtk and curses display with a commandline switch, but I'd say the incomplete upgrade is a reason to pull the package. Didn't you encounter the "loaders.cache': No such file or directory" Error with Firefox as well, or was that someone else?
Icons for minimized windows: either compile them in, or place a 85x67 "IRIS RGB" (xv) or .sgi (imagemagick) file in /usr/lib/images with the name of the WM_CLASS property (according to xprop) and the suffix .icon in /usr/lib/images. There's a more detailed description here: ... /ch06.html

For the vector icons in the Icon Catalog, on the desktop or in the file manager in general, build icons with iconsmith (I recommend reading ... /ch12.html since thre's ), then write file type rules for both the application itself as well as the documents/files it creates (man ftr gives a good overview, more information ... /ch11.html ). Don't recycle any tag, unless you provide an update for another package, I'd recommend just generating a random-ish number with echo -n appname | md5sum (use any 8 digits that don't start with >=8).

If you don't enjoy the limitations of iconsmith, try

There's more information here: viewtopic.php?f=10&t=3437 and if you want to include any of those in a nekoware package, check the nekoware packaging FAQ (and add anything that's missing).