Re: [Tracker] Building the current cvs version.

[Anders Aagaard <aagaande gmail com>]

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

This was surprisingly simple to do (assuming it works on your end that 
is).  It might be better with a runtime check though, although I'm not 
sure how I'd implement that.  To support distro's who can't make a 
package that requires a new kernel, but still want to support ioprio.

> thanks for pointing this out - it seems a really useful addition to 
> tracker (for those who's kernel supports it).

Attachment: ioprio-patch2.patch.gz
Description: GNU Zip compressed data