Granted, some of those are recursive but there's a lot more there than the package is allowing for at present

Believe it or not, with maybe the exception of pixmap/glitz, all those are in or prereq's of neko_gtk. (BTW, the last packing had no prereq's listed )
Perhaps other plugins are different. I'll take a look next week.

EDIT:

I resisted listing perl/python since the package will function without plugins or scripting. Again, same as last 4 versions. Also, the self dependacies is something I also had never added before and purposly left out in the first nekoware issue (but thought I had added in this case...hmmm...probably forgot the apply button inn swpkg!).

squeen wrote:Not wanting to miss out on the renaissance in nekoware upgrades I put together the following 2-12's

neko_glib-2.12.2neko_gimp-2.2.12

The glib rebuild fixes my long standing problem with GIMP (ie. I couldn't load any files with a memory error, in fact I couldn't even build GIMP until I replaced glib).They're in /beta. Please give them a whirl.

That's strange, I never got the memory error before.

Just installed glib-2.12.2 and am now get the memory error (cannot load any files). I also get the memory error in foetz's gimp-2.2.12 build with this new glib.

Just installed glib-2.12.2 and am now get the memory error (cannot load any files). I also get the memory error in foetz's gimp-2.2.12 build with this new glib.

Reverting back to glib-2.8.4 fixed the problems.

I was wondering why more folks weren't complaining about the GIMP being broken. I have 2 systems (an Octane and Tezro) runing 6.5.29 that had the same memory error problem. What version of OS are you using? Again, I'm wondering if a serious incompatability exists!?! Oh, also I'm compiling with 7.4.4m. Anyone else with and experience to share?

@joerg: About prereqs: If an app as a prereq of GTK like the GIMP does, I do not feel it is a good idea to add all of GTK's prereq's to the GIMP. That's the way all the original nekoware wer packaged.

squeen wrote:@joerg: About prereqs: If an app as a prereq of GTK like the GIMP does, I do not feel it is a good idea to add all of GTK's prereq's to the GIMP. That's the way all the original nekoware wer packaged.

Haeh?
All libs which are shown from a ldd foo.so have to be in the prereqs. No more and no less. Thats the way how sgis swpkg works and i hope the most of our packages used it in this ways.

squeen wrote:I was wondering why more folks weren't complaining about the GIMP being broken. I have 2 systems (an Octane and Tezro) runing 6.5.29 that had the same memory error problem. What version of OS are you using? Again, I'm wondering if a serious incompatability exists!?! Oh, also I'm compiling with 7.4.4m. Anyone else with and experience to share?

I had the same issue ages ago with an older glib/gimp combination. It appeared after i updated my ex-Octane from EMXI to V6 and hence updating parts of the os installation. Thinking the update simply wasn't perfectly complete i took the safe route and did an 'install same' of the complete os installation. That fixed it.. looking back i'm beginning to think this could be the rqs issue, chervarium covered again lately: http://forums.nekochan.net/viewtopic.php?t=10959

The current build works great for me so far, thanks

@joerg: About prereqs: If an app as a prereq of GTK like the GIMP does, I do not feel it is a good idea to add all of GTK's prereq's to the GIMP. That's the way all the original nekoware wer packaged.

i'm seriously prefering the route of adding all linked shared libs as direct prereqs. The above way of indirect prereqs will always be less robust (and more error-prone) unless you make sure the package you inherit the prereqs from really has the currently installed package of the .so in question as prereq (and not some older package version)..

And isn't actually a lot more work to separate all indirect prereqs that way too?

Just installed glib-2.12.2 and am now get the memory error (cannot load any files). I also get the memory error in foetz's gimp-2.2.12 build with this new glib.

Reverting back to glib-2.8.4 fixed the problems.

I was wondering why more folks weren't complaining about the GIMP being broken. I have 2 systems (an Octane and Tezro) runing 6.5.29 that had the same memory error problem. What version of OS are you using? Again, I'm wondering if a serious incompatability exists!?! Oh, also I'm compiling with 7.4.4m. Anyone else with and experience to share?

I haven't had any problems with GIMP (that I can see anyway) - I also have your new glib installed with no visible issues. IRIX 6.5.29 on a Fuel here.

squeen wrote:I was wondering why more folks weren't complaining about the GIMP being broken. I have 2 systems (an Octane and Tezro) runing 6.5.29 that had the same memory error problem. What version of OS are you using? Again, I'm wondering if a serious incompatability exists!?! Oh, also I'm compiling with 7.4.4m. Anyone else with and experience to share?

@joerg: About prereqs: If an app as a prereq of GTK like the GIMP does, I do not feel it is a good idea to add all of GTK's prereq's to the GIMP. That's the way all the original nekoware wer packaged.

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).

Joerg wrote:All libs which are shown from a ldd foo.so have to be in the prereqs. No more and no less. Thats the way how sgis swpkg works and i hope the most of our packages used it in this ways.

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_kdesdkneko_kdevelopneko_openldapneko_php5neko_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.

squeen wrote: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?