Nekochan Net

Official Chat Channel: #nekochan // irc.nekochan.net
It is currently Tue Jul 29, 2014 12:53 pm

All times are UTC - 8 hours


Forum rules


Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.



Post new topic Reply to topic  [ 865 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 58  Next
Author Message
 Post subject:
Unread postPosted: Wed Aug 23, 2006 3:14 pm 
Offline
User avatar

Joined: Tue Apr 29, 2003 1:02 pm
Posts: 967
Location: Rijswijk, The Netherlands. Reigate, England.
squeen wrote:
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.


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

_________________
Shall I describe it to you? Or do you want me to get you a box?


Top
 Profile  
 
 Post subject:
Unread postPosted: Wed Aug 23, 2006 4:21 pm 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
whiter wrote:
squeen wrote:
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.


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


I knew it! :P ...The idea sounded me too familiar! ...So, the script was "AutoPackager", or "Pre Requisites Generator"? ...Because I've saved both on CDROM for any future eventual need! ;)

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Wed Aug 23, 2006 11:45 pm 
Offline
Site Admin
Site Admin
User avatar

Joined: Thu Jan 23, 2003 1:31 am
Posts: 7970
Location: Pleasanton, California
squeen wrote:
schleusel wrote:
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).


Heh, I wasn't even aware that's what cairo/glitz did! You're probably right - something in there isn't properly detecting/utilizing OpenGL on IRIX.

Anyway, after a little search I found this which is interesting; seems that glitz is suffering from "maintainer bandwidth problems":

http://weblogs.mozillazine.org/tor/arch ... cairo.html

_________________
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 12:33 am 
Offline
User avatar

Joined: Tue Apr 29, 2003 1:02 pm
Posts: 967
Location: Rijswijk, The Netherlands. Reigate, England.
GeneratriX wrote:
I knew it! :P ...The idea sounded me too familiar! ...So, the script was "AutoPackager", or "Pre Requisites Generator"? ...Because I've saved both on CDROM for any future eventual need! ;)


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.

_________________
Shall I describe it to you? Or do you want me to get you a box?


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 2:19 am 
Offline
Moderator
Moderator
User avatar

Joined: Fri May 09, 2003 5:10 am
Posts: 2931
Location: Maryland, USA
Cool Whiter. I'll give it a spin if you can ressurect it (although I was more talking about just building a data base as opposed to actually relocating files).

Regarding cairo/glitz....definately Linux targeted. Who knows if it makes good use of things on IRIX. I've down loaded it and will look at the code.


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 4:18 am 
Offline
User avatar

Joined: Tue Apr 29, 2003 1:02 pm
Posts: 967
Location: Rijswijk, The Netherlands. Reigate, England.
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*

_________________
Shall I describe it to you? Or do you want me to get you a box?


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 4:32 am 
Offline
Moderator
Moderator
User avatar

Joined: Fri May 09, 2003 5:10 am
Posts: 2931
Location: Maryland, USA
In /beta: For those folks interest in playing with the GNU Flash player + a repackage to eliminate glib erros in dia.


neko_gtkglext-1.2.0
neko_gnash-cvs20060823
neko_dia-0.95


The plugin for gnash is in /usr/nekoware/lib/libgnashplugin.so. Link it to your $HOME/.mozilla/plugins directory to get it recognized. The caveats are that SDL_mixer sounds is broken, its GTK2 based so neko_firefox doesn't like it, and neko_mozilla won't execute it. So basically as a plugin it is useless until some brave soul fixes it. The command line player (/usr/nekoware/bin/gnash) works. Probably should stay in beta limbo until the issues are resolved. A build of Gstreamer would probably fix the sound.

EDIT: I plugged dia-0.95. I've got more packaging (lib) errors.


Last edited by squeen on Thu Aug 24, 2006 4:36 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Cool!
Unread postPosted: Thu Aug 24, 2006 4:35 am 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
whiter wrote:
GeneratriX wrote:
I knew it! :P ...The idea sounded me too familiar! ...So, the script was "AutoPackager", or "Pre Requisites Generator"? ...Because I've saved both on CDROM for any future eventual need! ;)


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.


Cool!
Anyway, and for the record, it seems that at least one of the two above mentioned packages is a son of you (AutoPackager), since it holds your name on the Guidelines Document! :P

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 6:40 am 
Offline
User avatar

Joined: Tue Apr 29, 2003 1:02 pm
Posts: 967
Location: Rijswijk, The Netherlands. Reigate, England.
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:
Code:
whiter@mina:~/nekodev> cc -g3 -c nekodev.c
whiter@mina:~/nekodev> ld -shared -o nekodev.so nekodev.o
whiter@mina:~/nekodev> cd /tmp/blablabla
-bash: cd: /tmp/blablabla: No such file or directory
whiter@mina:~/nekodev> export _RLDN32_LIST=/usr/people/whiter/nekodev/nekodev.so:DEFAULT
whiter@mina:~/nekodev> mkdir /tmp/blablabla
Muhahaha, so you wanted to create '/tmp/blablabla'?
whiter@mina:~/nekodev> cd /tmp/blablabla
whiter@mina:/tmp/blablabla> pwd
/tmp/blablabla


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

_________________
Shall I describe it to you? Or do you want me to get you a box?


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 7:28 am 
Offline
Moderator
Moderator
User avatar

Joined: Fri May 09, 2003 5:10 am
Posts: 2931
Location: Maryland, USA
whiter wrote:
Code:
_RLDN32_LIST=/usr/people/whiter/nekodev/nekodev.so:DEFAULT
/tmp/blablabla


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


Didn't know you could force everthing through a single dynamic lib? I have spoofed lib functions before by forcing my (similarly named) lib to appear in a directory earlier on the RLD_ROOT doing something and then using dlopen to get and execute the proper function. What about statically link apps?---where and what function calls are you catching?--the shell? Yeah, I'd like to play with it....:)

Isn't there a restriction on rld'ing root?


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 8:08 am 
Offline
User avatar

Joined: Tue Apr 29, 2003 1:02 pm
Posts: 967
Location: Rijswijk, The Netherlands. Reigate, England.
squeen wrote:
Didn't know you could force everthing through a single dynamic lib? I have spoofed lib functions before by forcing my (similarly named) lib to appear in a directory earlier on the RLD_ROOT doing something and then using dlopen to get and execute the proper function. What about statically link apps?---where and what function calls are you catching?--the shell? Yeah, I'd like to play with it....:)

Isn't there a restriction on rld'ing root?


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

_________________
Shall I describe it to you? Or do you want me to get you a box?


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 9:30 am 
Offline
Moderator
Moderator
User avatar

Joined: Fri May 09, 2003 5:10 am
Posts: 2931
Location: Maryland, USA
I don't know if you can make a general wrapper function since dlopen needs a specific prototype and library in order to find the spoffed function. All you can do is target a certain number of syscalls and make a specifc wrapper for each...I think. There is a general problem IIRC with passing varags to another varg function (e.g. printf), which might be lurking out there. Hmm....things like mkdir() are C functions, but how is cp implimented...by read() and write() in the shell? Maybe we look just at gmake and see if it uses the system() command to send it's instructions down the pipe. In which case we just intercept system() and parse the commands for one's we care about---hell for that matter we've got the source to gmake, why not just patch it in neko_gmake to make a database copy of all commands executed as root or when a specific environment varaiable is set? Yeah, why come in through the back-door when the front-door was left open?

Am I re-inventing your wheel? Have you got this all working already?


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 9:48 am 
Offline
Moderator
Moderator
User avatar

Joined: Fri May 09, 2003 5:10 am
Posts: 2931
Location: Maryland, USA
On line #1987 of job.c in (g)make-3.81 is a function called exec_command might be fun to just put a print statement in there that echoed the command string.


Last edited by squeen on Thu Aug 24, 2006 10:00 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 9:53 am 
Offline
User avatar

Joined: Tue Apr 29, 2003 1:02 pm
Posts: 967
Location: Rijswijk, The Netherlands. Reigate, England.
squeen wrote:
Am I re-inventing your wheel? Have you got this all working already?


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:
Code:
open
old.creat
link
unlink
obs_execv
chdir
mknod
chmod
chown
old.getfsstat
old.lseek
mount
umount
chflags
old.lstat
symlink
readlink
execve
chroot
old.fstat
rename
mkfifo
mkdir
rmdir
stat
lstat
pathconf
truncate
undelete
lchown
lchmod
jail
lchflags
__getcwd

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:
http://c-faq.com/varargs/handoff.html wrote:
If you do not have the option of rewriting the lower-level function to accept a va_list, such that you find yourself needing to pass the variable arguments that one function (e.g. faterror) receives on to another as actual arguments, no portable solution is possible.

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

_________________
Shall I describe it to you? Or do you want me to get you a box?


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Aug 24, 2006 10:30 am 
Offline
User avatar

Joined: Tue Apr 29, 2003 1:02 pm
Posts: 967
Location: Rijswijk, The Netherlands. Reigate, England.
ok... static things are indeed a problem :)

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

Any ideas ? :)

_________________
Shall I describe it to you? Or do you want me to get you a box?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 865 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 58  Next

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group