[Tracker] strigi 0.7 rc1
phreedom.stdin at gmail.com
Thu Jul 23 10:31:38 BST 2009
On Thursday 23 July 2009 11:52:46 Philip Van Hoof wrote:
> On Thu, 2009-07-23 at 07:31 +0200, Jos van den Oever wrote:
> > I've just uploaded Strigi version 0.7 RC 1 to
> > http://www.vandenoever.info/software/strigi/strigi-0.7-RC1.tar.bz2
> > This version is the first Strigi version using the Nepomuk ontologies.
> > For the KDE people: hooray, this can be used in KDE 4.3.
> > For the Tracker people: yay, you can start using libstreamanalyzer
> Question for Evgeny:
> Does this libstreamanalyzer already take into account the latest changes
> that we made to the Nepomuk Message Ontology, for MIME files?
> In particular the nmo:hasContent changes that we made.
Not yet. I'm planning an overhaul of email analyzer. I'd really like to see
his discussed and finally decided on first. Maybe NMO proposal is a good
candidate for ticket-a-day :)
This pre-release is intended to compile a list of issues to be fixed. If you
find any other, please let me know.
We're sort of forced to rush 7.0 out of the door, because we really have to
break stuff^H^H^H^H change ontology before kde 4.3 is out. After this, minor
releases aren't going to be a problem. This doesn't mean I consider 7.0 to be
very broken. But I guess it still has some rough edges.
> Explained here:
> > If you encounter any problems, please let me know, so the fix can make
> > it in 0.7 final.
> I wonder what the ideal way is to build a package just for libstreams
> and libstreamanalyzer, out of this release candidate. I also wonder
> whether packagers are instructed to package these libraries separately.
Deb guys will break it up. Actually it's already separated AFAIK. not sure
about other binary distros. Might give them a hint.
For Gentoo it's going to be a sort of a problem. Gentoo guys usually prefer
one package per one released tar.gz with a set of use flags to compile library,
daemon, support for various deps etc. So it means than in gentoo tracker
ebuild would depend on strigi ebuild. Alternatively if you can build
libstreamanalyzer separately they might introduce two conflicting ebuilds for
strigi and libstreamanalyzer with tracker ebuild being able to use either of
Which approach is taken depends on tracker guys being willing to be bashed by
anti-kde trolls :)
I'm putting it on my todo list to ensure that there's an option to build
P.S. just checked and it seems that if I run regular build commands in
streamanalyzer dir, everything builds properly and is installed.
P.P.S. One more unresolved issue: libstreamanalyzer currently drags ontologies
along. We might want to fix this to use shared ontologies, or rather fix it to
not care about ontologies at all. The question is: should libstreamanalyzer
try and validate analyzer output(especially 3rd-party analyzer output) against
the ontology or should it be done at backend level?
More information about the kde-core-devel