Jamie McCracken wrote: > Anders Aagaard wrote: >> Jamie McCracken wrote: >>> Anders Aagaard wrote: >>> >>>> Checked out a clean version now and that fixed it. >>>> >>>>> >>>>>> And when taking that out I get the error: >>>>>> aclocal: macro `AM_PROG_MKDIR_P' required but not defined >>>>>> aclocal: macro `AM_PROG_MKDIR_P' required but not defined >>>>>> in the libextractor directory. >>>>>> >>>>> dont remove dirs please! >>>> >>>> I just did a clean checkout and I still get that error. >>> >>> you are probably missing some standard automake macros then >>> >>> try upgrading automake? >>> >>> or google for more info on that macro >>> >>> You can download a different version of libextractor and use that >>> (tracker will not build its internal libextractor in that case) >>> >>>> >>>>> >>>>>> Attaching a theoretically working implementation of ionice. >>>>>> trackerd.c would have to run the ionice_init() function. I would >>>>>> have tested it and made it a bit cleaner if I could get the cvs >>>>>> version compiled at all :P >>>>>> >>>>>> Most of the code for ionice is gotten from the snippet in the >>>>>> Documentation/block/ioprio.txt file in the linux kernel. >>>>> Correct me If I am wrong, but does not ionice default to the cpu >>>>> nice value (which is +10 for tracker and +19 for text filters)? >>>> >>>> Just tried a nice --adjustment 19 on a process now, and used ionice >>>> -p <process> to check the ionice level. And it reported ioclass >>>> none, ioprio 0. (which in the kernel translates to ioclass best >>>> effort, ioprio 4) >>>> >>>>> AFAIK, its linux specific and only in 2.6.13+ so I can't really >>>>> depend on it. >>>> >>>> Might be possible to get configure to check for this, but I'm >>>> horrible at autotools. >>> >>> me too! I hate the auto-foo shit (I always end up copying stuff from >>> other packages!) >>> >>> I dont have ionice support in my kernel so I cant really implement >>> this but Im happy to accept patches that does (with auto-foo and >>> #ifdefs) >> >> Attaching a patch that works for me, when running ioprio now reports >> best-effort priority 7. Which should improve desktop performance >> quite a bit while running tracker updates. >> >> Do you want the #define IOPRIO_SUPPORT moved from tracker-ioprio.h to >> configure.in? And if you do, does anyone know how to get autoconf to >> check for the existance of a define? :P, that shouldn't be that hard ;) >> > > part of the problem is Im using the dapper kernel and its headers do not > contain the setioprio stuff so detecting the header wont guarantee that > I can include this automatically (and also wont compile in my case)
Yeah, detecting the header wont work, but I'm guessing you dont have the defenition __NR_ioprio_set? I was looking into autoconf and writing custom tests, I think I'll do that, make a little program that uses the function itself, and if it fails it'll be disabled. > > I think whats needed is an --enable-ionice option to configure. I will > look at adding that in the next few days (although feel free to send a > patch if you want it sooner) I'll see what I can do :) > > thanks for pointing this out - it seems a really useful addition to > tracker (for those who's kernel supports it). > > > _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
