The collected works of whiter - Page 2

remember that SI|3D has been an M$ app for a while.. ;-)

Stupid move of them to sell that. The best aplication they got... and they sell it. HAH! Sucks to be M$ :-)

horrible?

SI|3D has the best user interface I've ever seen in any program. I love it extremely.

isn't it possible to package the plugins in neko_gimp.sw.plugins and then do let that one have the dependencies on perl & python?

I actualy wrote a tool that did exactly that a while ago.

Cool thing was: it caught anything you did (copy, chown, mv, ...) and secretly put the stuff in /usr/nekoware_dev instead of /usr/nekoware without make (or any other tool) knowing about it :)

Oh I LOVE rld override :)

Problem is that I lost most of it and would need to rewrite a shitload again :S

The version I 'shipped' didn't have the override code with it. But that's what I was working on, yeah.
I'll see if I can dig it up again.

squeen: yeah I know, but it's the same principle. You want to capture all the stuff the system is doing when running the install, and then do something with that info.

*searches deep into old backups*

they both are ;) (if you mean the prereq generator that shipped with autopkg)
I use them a lot.

anyway, I found my code and just created a little thingy that captures mkdir:


It's fun :)

Now.... Squeen... if you feel like helping out with developing this further, that would be great. I'm not such a brilliant c coder :)

Well, this is about wrapping something around the make install process, and I think we can be sure that that is all dynamicaly linked code. (We obviously don't have to worry about the way the files it is actualy installing are linked.)

Moving your custom library in a folder that appears earlier on in the standard RLD_ROOT sounds a bit like a non-nice way of doing it. :)
_RLD_LIST was specificaly designed for adding custom libraries that are not in the library paths to the list.

I know about no restrictions. I've succesfuly overridden loads of syscalls. The biggest problem I'm facing is "How the hell do those va_arg things work in irix?"

My wrapper function needs to be something like

int theSysCall(const char *path, mode_t mode, ...)
{
* do override stuff here *

* call the original method here with all the args, but we don't know how many we got or what type they are *
}

:S

hmm... partialy :)

I did get underway with implementing a wrapper for all possible syscalls and outputting useful information to a log. However I did NOT yet look at gmake to see what command it actualy uses. Also I think that's not gonna cover everything, because I also want to catch it if a program adds a line to this and that system config file. read() and write() are very important ones to catch then, because gmake will probably just do system('somecustomshellscriptthatdoesalot.sh') in that case.

The list of syscalls I looked up that need a wrapper is as follows:
A long list, but some are more important than others. :)

I had done a load of those already (ones with static number of args) but lost that code. However I do know how to do it again. It's not that hard.

The varargs are a BIG problem though. As the very fine FAQ points out:
And then the question is.... what to do with the wrappers :)
I wanted it to do all actual writing in a separate diverted location, so packaging it all up is very easy then. But possibly just recording all changes in a log, and then writing a tool that reads the log and generates an idb would be nicer. Loads of options :)

ok... static things are indeed a problem :)

'ln' is staticaly linked so overriding symlink(char *, char *) doesn't have any effect.

Any ideas ? :)

Is the irssi 0.8.15 build and packaged according to nekoware standards, or should I update it? As package maintainer I just compiled it last week since there is a security hole in all older versions.