SGI: Development

I'm running 6.5.29 on my Octane2. Was running 6.5.27. Never had the memory problems before. Only occurred when I installed the new glib. Very weird.

On the GIMP/GTK issue. I read the nice write up on rqs that chervarium wrote and that combined with some checks stuart had me do with gmemusage and GIMP I think it's pretty likely close to target. I want to make sure I understand the issue correctly so I can "rectify" whatever machine is in a non-standard state. Is it the opinion of others that the packages are not and cannot be twisted, just the install system(s)?

Edit: Another thought...could the rqs explain why I couldn't even build the GIMP? (damn, I wished I'd recorded the error message).



Taking a hard line, eh? I think I'd best wait a bit before responding.

Schleusel mentioned during an IRC session that his new neko_db4-4.4.2 package, which is currently located in /beta comes with a libdb-4.4.so and not with a libdb-4.3.so anymore. This breaks some apps because they links against libdb-4.3.so and not against libdb-4.so

We take a look into the specs files and see the following packages with uses db4 as a direct prereq.

neko_kdesdk
neko_kdevelop
neko_openldap
neko_php5
neko_webalizer

Both kde apps links against libdb-4.so and arent effected but all the other breaks. Maybe there are a few more outthere....

Edit:
On of the submodule of kdevelop (r++)links against the old libdb.

The new neko_imagemagick also breaks neko_php5_imagick because it dont provide the needed libWand.so.7.

As a temporary help its possible to create a symlink which point to the right file ... but that is only a workaround.

I have uploaded newer versions of openldap and php5 which uses the db4-4.20.

Btw. it would be fine if a note would be postet in this thread if some uploaded into /beta, or whats more importent directly into the /current dir. Silent upgrades of a base library should be announced in some way so its possible to create the right prereqs for new packages.

regards
Joerg

Placed neko_dia-0.95 into /beta. It has whiter's new neko_perl_xml dependancy.

Still looking into the rqs issue...as well as xft.

Cool!; I'm a big fan and user for Dia!; Thanks a lot!

About libxft: ...last night I've experienced some weird behavior on Mozilla Composer. After edited some simple HTML page, the characters appears to be corrupted at one floating window (Create Link), and the whole content at the main Composer window appeared to be with some paragraphs randomly deleted. I've saved these file with a different filename, to close Composer. Once I've re-opened Composer, opened these new file, and everything was there, no randomly deleted paragraphs, and no problems at all.

So, my question is: -Since Mozilla depends on the same libxft which already brings problems to FLTK/Fluid; are we facing here the same troubles?

New packages in the /beta directory
neko_ffcall-1.10 - function call interfaces in embedded interpreters
neko_black-box-1.4.7 - some kinf of puzzle game
neko_squid-2.6.stable3 - Webproxy and Cache

Updated but also in /beta.
neko_webalizer-2.01-10 - log file analysis program


Some more trouble looking around the corner. The updated neko_openldap doesnt provide the libldap-2.2.so.8 any more. So some apps wont work. From a first look the following packages might be effected by this issue.

neko_evolutiondataserver,
neko_evolutionexchange,
neko_evolution,
neko_postfix,
neko_python_ldap,
neko_samba,
neko_sylpheed_claw s

If the system runs a recent IRIX version and you have installed "OpenLDAP LDAP server and client tools, 2.2.23" youre safe, because the right version stays in /usr/lib32. This isnt true for people which runs IRIX 6.5.22 on their machines because the OS only comes with "OpenLDAP LDAP server and client tools, 2.1.22" which isnt enough.

regards
Joerg

Moved the following items to /current due to positive feedback/testing:

current/neko_cdrdao-1.2.1.tardist
current/neko_cdrtools-2.01.01a11.tardist
current/neko_ctorrent-1.3.4-dnh2.tardist
current/neko_smake-1.2a36.tardist
current/neko_xcdroast-0.98alpha15.tardist
current/neko_yafray-0.0.9.tardist

Let me know if there are any others.

The 2 games black-box and defendguin and the lib ffcall. The last one have no dependancie and im sure we didnt break anything there :)

regards
Joerg

neko_fltk-1.1.7-xft.tardist is perfectly stable, and ready to work; already tested building about a dozen and half different sources, and never meet a problem.

On the other hand, neko_fltk-1.1.7+xft.tardist does not works as intended, either using the older/newer libxft on nekoware. The weird thing is, it works perfectly if built agains SGI Freeware libxft.

That's cool and all, but I'm not moving these over until we get a unified version

Sure. Actually we need to have a revised libxft before to reach such stage, since it seems to be producing some crashes at Mozilla too...

I just uploaded neko_gaim-2.0.0beta3.1 and the corresponding neko_guifications-2.13beta3.1 to incoming. This should take care of the gaim/msn issue we've been seeing; at least on my boxes it works like a charm however, it depends on the glib in beta, so perhaps it'd be best to keep it there til glib also moves.

Great! I've PM'd you the Nekoware login info so you can upload directly to 'beta' in the future.

Sweet, thanks

neko_glib-2.12.2 (beta) fixed neko_mozilla-1.8a5 on my system! Hello AA fonts (again).

Do you know what would be awesome...a wrapper to the "install" command that (when invoked by gmake install) would autiomagically create the file databased used by inst. I know it would have issues (i.e. Makefiles that by pass install and do cp/mv commands instead), but wouldn't that be awesome---if install actually installed packages in a managable database at the end of the build. Tardist building would be a no brainer.

new in beta triggered by the neko_openldap update:

neko_postfix-2.3.2.tardist - quite a version bump, works fine for me so far though
neko_sylpheed_claws-1.0.5.tardist still the same version (the gtk 1.x branch is dead ) only rebuilt against the new openldap
neko_sylpheed_claws_gtk2-2.4.0.tardist newest member of the gtk2 branch
neko_libetpan-0.46.tardist multi purpose mail library (needed by claws gtk2)

the .opt subsystem of the previous claws gtk2 packages was accidentally marked as version 6 (instead of 1), hence i decided to mark the new package as version 7 to prevent the .opt subsystem from being declared as downgrade.

I keep being disturbed by the sheer slowness of gtk2 on irix, something is just wrong there. QT blows it away at the same level of questionable eye candy

You are right there. If our gtk2+ is using cairo/glitz which relies on openGL for rendering instead of the software in libXrender, the silly thing should be flying on VPros which have awesome 2D capabilities---blowing away even top of the line nVidia cards on things like pixel readback. I honestly believe digging into the code a bit could dramtically speed up gtk (unless it's some other software inefficiency).

Indeed!; In fact I've wondered at some point if such tool was already present on Nekoware under any strangeous name! ...You know, there is such big amount of packages there, that many times I have to check to see what I'm installing!

Yup; Nekoware is growing up fast, we have a huge amount of tools already available here, which makes me think if it is not time to bring alive a brand-new company just building Godson-based MIPS/IRIX clones!

Installed and running as expected here. Thanks!