Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
Beagle reasles is out, searching and a whole lot more. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Sorry forgot to attach URL, http://www.gnome.org/projects/beagle. This may be assigned to the wrong section as it is nto the same app-sci/beagle.
You can find cvs ebuilds on breakmygentoo.net, but IMO these ebuils are not very stable.
I think this issue should be assigned to gnome@gentoo.org, as this beagle is defintely not identical to app-sci/beagle.
Poke 0.4 is out now Any word on this at least getting properly assigned and added to portage?
Well, I guess this one should go to gnome. I'm not in gnome herd, but I would like to take care of it and suggest gnome-extra/beagle ? kai
afaic this still very much alpha quality software and as such should be p.mask-ed if it has to enter the tree (but i guess its too hyped up to get around that sooner or later). kzimmerman : post an ebuild here so we can see how it works out.
Created an attachment (id=49050) [edit] beagle-0.0.4.ebuild Well this ebuild is a fix on this bug. However, several things have to be considered: 1. Beagle needs a running DBUS session, that means we are touching 77504 here. 2. Beagle has a lot of nice extra features that are not included in the proposed ebuild. 3. The code seems to be stable but in my opinion it needs too much memory. 4. A lot of stuff has to be done to get Beagle to work (kernel options, DBUS, Beagle daemon). I fear we won't be able to automate this. kai
Created an attachment (id=49344) [edit] beagle-0.0.4.ebuild There has been a typo. Also, there is now support for the evolution-sharp extension. I decided to use the "evo" USE flag, but I'm open for other suggestions. latexer: If I see it right you have already done some work on this stuff (beagle, evolution-/gsf-/gst-sharp)? kai
As I said, there are a lot of extensions that we should take care of... kai
This is really more dotnet than gnome, all of the dependencies are handled by the dotnet herd.
* evo USE flag should be eds, plus that it's a cvs snapshot, so i wouldn't work with that as this point. * no configure time switch for the eds flag, bad. * there is a fair amount of duplication in the ebuild. * it misses RDEPS for sure. * why does it dep sharp on one dbus version, declarded like this it won't even take revision bumps. * why is there commented out code ? * the xattr part doesn't mention you need kernel support, only the inotify part does and that doesn't necessarily coincide. @ obz : don't turn the dotnet herd into a second gnome herd.
> * evo USE flag should be eds, plus that it's a cvs snapshot, so i wouldn't work with that as this point. Could be done in a later release, maybe we should send this upstream. > * no configure time switch for the eds flag, bad. I know, but the configure autodetects if the *-sharp stuff exists. > * there is a fair amount of duplication in the ebuild. I guess you mean the "built_with_use ... mono" stuff? Well, I thought this would make it more clear to the user, but I could change that... > * it misses RDEPS for sure. I don't know of any that I missed, but I may be terrible wrong at this point. > * why does it dep sharp on one dbus version, declarded like this it won't even take revision bumps. My mistake :) > * why is there commented out code ? Because its still in devlopment...and I will change that, too. > * the xattr part doesn't mention you need kernel support, only the inotify part does and that doesn't necessarily coincide. I will add a sentence.
Created an attachment (id=49370) [edit] beagle-0.0.4.ebuild I don't like diffs here, so again a complete version :) kai
@foser: almost every dependency is handled by the dotnet herd - doesn't it make sense? at least until we herd by function.
Almost all of those deps are CVS, or rely on CVS things to function. So if you folks choose to throw this over to dotnet@g.o, you'll get a big old "RESOLVED LATER" from it. I've been following beagle for a while now. It's pretty neat stuff, but just not ready for general use/portage at this point.
Created an attachment (id=49493) [edit] beagle-0.0.4.ebuild This one includes some fixes (thanks foser): 1. eds USE flag 2. sqlite 2.X API 3. no autodetection anymore kai
Created an attachment (id=49494) [edit] beagle-0.0.4-configure.in.patch
Beagle 0.0.5 is out! Regarding the ebuild/patch nothing has changed. Rename it and it will work with 0.0.5, too. kai
Created an attachment (id=49642) [edit] beagle-0.0.5.ebuild As you may see, there is still a lot of work to be done.. 1. Now we have the mozilla-extension installed in /usr/share/beagle (based on mozilla use flag). However, the user has to run firefox -install-global-extension /usr/share/beagle/beagle.xpi manually. Hopefully there will be a solution sometime to get this done from inside the ebuild. 2. I think I found out why foser had such a problem with my autoconfiguration-patch. I mixed enable/disable, it still worked because I made the mistake twice:) 3. I also put some work into the mozilla-backend and epiphany-extension (46486) but without any results for this ebuild. kai
Created an attachment (id=49643) [edit] beagle-0.0.5-configure.in.patch
* about the patch : i just looked at it, never tested it. I still it doubt it does in all cases exactly what we want, but your ebuild is incomplete in that respect, it uses the old 'myconf trick' instead of use_enable like you really should. * It uses einstall instead of 'make DESTDIR' like it really should. * I don't really see the point of the mozilla flag, is it really harmful to just install the thing by default. Does it really only work with firefox/mozilla, not with other mozilla variants ? * imo lots of text is still redundant & rather incomplete (eg. your mozilla extensions stuff sais nothing about what user should install the extension) * you point to a wiki that is not gentoo specific... don't let ppl mess up their config files because you said it was ok to do stuff that is said there. * i bet it still misses buildtime deps. * you do inherit nsplugins, but does it get used ? * you do inherit gnome2 eclass, but actually override all of its functionality. You shouldn't be overriding stuff without a good reason (and I don't think you have here).
Created an attachment (id=49665) [edit] beagle-0.0.5.ebuild > * about the patch : i just looked at it, never tested it. I still it doubt it does in all cases exactly what we want, but your ebuild is incomplete in that respect, it uses the old 'myconf trick' instead of use_enable like you really should. Ok, here comes my second guess what you mean. My patch works only if --enable-evolution is set (what I did in the ebuild). It won't work with use_enable because both --enable/--disable will result in actication? I changed that and will continue with guessing :) And of course it uses use_enable now... > * It uses einstall instead of 'make DESTDIR' like it really should. Done > * I don't really see the point of the mozilla flag, is it really harmful to just install the thing by default. Does it really only work with firefox/mozilla, not with other mozilla variants ? About the mozilla flag: I'm not so shure whats Gentoo typical at this one. Its not harmful to install, but maybe people wan't only what they ordered? Anyway, its gone now. About other mozilla variants: I guess everything that supports mozilla extensions (tested only firefox and mozilla). > * imo lots of text is still redundant & rather incomplete (eg. your mozilla extensions stuff sais nothing about what user should install the extension) Please be more specific or change what has to be changed. However, I reduced the text a bit. > * you point to a wiki that is not gentoo specific... don't let ppl mess up their config files because you said it was ok to do stuff that is said there. Didn't know that this is Gentoo policy. Anyway, the HOMEPAGE="XXX" stuff should be enough. > * i bet it still misses buildtime deps. We will see :) > * you do inherit nsplugins, but does it get used ? Not anymore, gone now. > * you do inherit gnome2 eclass, but actually override all of its functionality. You shouldn't be overriding stuff without a good reason (and I don't think you have here). Well, I used the eclass because its such a nice solution for the URL=".." thing. But you are right, I should use the whole thing...done. I guess beagle will become part of gnome someday :) @foser: Again, thanks for your help. I'm still learning a lot :) kai
Created an attachment (id=49666) [edit] beagle-0.0.5-configure.in.patch
Is it possible to build beagle against Mozilla Firefox instead of the Mozilla Suite? If so, could the dependency on net-www/mozilla be changed in such a way that net-www/mozilla and net-www/mozilla-firefox provide a virtual/gecko and beagle depends on that?
@24: Argh, stupid me. Only after submitting did I see that it is dev-dotnet/gecko-sharp that depends on net-www/mozilla. But the same reasoning stands for dev-dotnet/gecko-sharp's dependency.
No, you can't. There's a bug marked WONTFIX for gecko-sharp about this. Firefox is *not* an SDK, they make no claims that they won't change things in firefox, etc, etc. Mozilla is a browser *AND* an SDK. There's no changing that any time soon. gecko-sharp *might* build against firefox with some gross hacking, but there's no assuring that the next minor firefox release won't completely hork things. Sorry to be curt, but we get requests for this all the time, and I love firefox as much as the next man/woman, but it's *not* a replacement for the SDK portion of things.
When I'm trying to search it crashes :( $ beagle-query gimp (<unknown>:22496): Gdk-WARNING **: locale not supported by Xlib (<unknown>:22496): Gdk-WARNING **: cannot set locale modifiers file:///home/genady12/cxoffice/changelog.txt file:///usr/share/applications/gimp-2.0.desktop file:///usr/share/applications/gimp-2.1.desktop *** glibc detected *** free(): invalid pointer: 0x081ea000 *** /usr/bin/beagle-query: line 13: 22496 Aborted MONO_GAC_PREFIX="/usr:$MONO_GAC_PREFIX" MONO_PATH="$THIS_PATH:$MONO_PATH" BEAGLE_FILTER_PATH="$BEAGLE_FILTER_PATH:$THIS_FILTERS" mono --debug $MONO_EXTRA_ARGS $THIS_EXE "$@" $ best (best:22404): Gdk-WARNING **: locale not supported by Xlib (best:22404): Gdk-WARNING **: cannot set locale modifiers Qt: Locales not supported on X server Rendering Done Rendering: .33s SetSource: Rendering Done Rendering: .12s Rendering Done Rendering: .11s Rendering Unhandled Exception: System.NullReferenceException: A null value was found where an object instance was required. in (unmanaged) (wrapper managed-to-native) Gtk.Application:gtk_main () in <0x00004> (wrapper managed-to-native) Gtk.Application:gtk_main () in <0x00007> Gtk.Application:Run () in <0x00007> Gnome.Program:Run () in [0x0007f] (at /var/tmp/portage/beagle-0.0.5/work/beagle-0.0.5/Best/Best.cs:92) Best.Best:Main (string[]) *** glibc detected *** free(): invalid pointer: 0x0875b000 ***
*** Bug 79931 has been marked as a duplicate of this bug. ***
Why it's not at portage?
I did everything OK, and it seems to work fine. Finds DBUS and all, but on every query both with beagle-query and best, I get: The query failed with error: DBus.DBusException: Message did not receive a reply in [0x0005d] (at /var/tmp/portage/dbus-0.23-r1/work/dbus-0.23/mono/Message.cs:205) DBus.Message:SendWithReplyAndBlock () in <0x0007c> Beagle.Factory.Proxy:NewQueryPath () in [0x00005] (at /var/tmp/portage/beagle-0.0.5/work/beagle-0.0.5/BeagleClient/Factory.cs:52) Beagle.Factory:NewQuery () in [0x00005] (at /var/tmp/portage/beagle-0.0.5/work/beagle-0.0.5/tools/Query.cs:160) QueryTool:Main (string[]) free(): invalid pointer 0x80187000! What could that be? a bug in dbus?
Created an attachment (id=50200) [edit] beagle-0.0.5.ebuild Small changes in the deps (this include gmime-2.1.11 that is currently not in protage) and einfos. kai
i tried this out on my system install wasnt to bad setup was a bit painfull since the kernel patch is required perhaps due to the fact im running nptl on glibc it eats all my memory and swap when it starts indexing so adding a warning might be suggested to the ebuild or perhaps just completely stop when nptl is enabled fyi i used a mono 1.1.3 ebuild i found and it didnt help any ether also isnt having packages in portage called the same thing a no-no? cause portage already has sci-libs/beagle...
from my experience, it works with mono-1.0.4-r1 from portage perfectly, but if you have a system with nptl, you must compile mono with nptl, which means to compile it with gcc-3.4. Also - do you use by any chance the Inotify path version 0.18 ? If you do that might cause memory problems, as beagle-0.0.5 needs Inotify 0.17 . Inotify 0.18 is for Beagle CVS Hope that helps to anyone
.18 is prob my problem then silly me thinking it would be backwards compatable... i dont feel like rebooting any more for now so ill prob just wait for 0.0.6 unless a patch is back ported from cvs
No problem, even though that's a really easy patch, and beagle is lovely :)
$ beagle-query asdasdas *** glibc detected *** free(): invalid pointer: 0x081e6000 *** /usr/bin/beagle-query: line 13: 14993 Aborted MONO_GAC_PREFIX="/usr:$MONO_GAC_PREFIX" MONO_PATH="$THIS_PATH:$MONO_PATH" BEAGLE_FILTER_PATH="$BEAGLE_FILTER_PATH:$THIS_FILTERS" mono --debug $MONO_EXTRA_ARGS $THIS_EXE "$@"
my old 100 lire i found out that in my home directory i got a link [Transgaming stuff] pointing to /usr/share/blabla, beagled crashed all the times in that point [rights stuff?] ... removing that link i got it work, now my indexing process keeps on browsing through the other folders and best can seek everything a nerd like me wants to find
It seem that I need >=dev-libs/gmime-2.1.11. Where can I get this?
tried to do a version bump of gmime from 2.1.10 to 2.1.11. Seems to compile ok.
gmime-2.1.11 should be in portage already - just emerge sync :-)
dbus got bumped in portage to dbus-0.23-r3, and keyworded x86. The only problem is that once dbus is upgraded, beagle no longer works (and also does not compile anymore)...
dbus got bumped in portage to dbus-0.23-r3, and keyworded x86. The only problem is that once dbus is upgraded, beagle no longer works (and also does not compile anymore)... downgrading back to dbus-0.23-r1 fixes the problem.
This is not actually a real problem. dbus had to get rid of mono support to become stable. Well, beagle needs the mono support of dbus. foser don't like this litle fellow anyway, so I guess he decided that getting dbus stable is more important than beagle :) kai
mono support removed from dbus? I didn't notice anything unstable with mono support in dbus. In any case - shouldn't there be at least a version with mono support which is keyworded and has a higher version figure? That way if I have dbus in package.keywords I can easily have mono support... That makes sense to me more than marking the latest stable dbus in p.masked and then using the keyworded one...
Beagle 0.0.6 is now available at http://ftp.gnome.org/pub/GNOME/sources/beagle/0.0/beagle-0.0.6.tar.gz
Created an attachment (id=51333) [edit] beagle-0.0.6.ebuild This is the ebuild for 0.0.6. It depends on debus-0.23.1 that is not in portage yet. kai
Hopefully we will also get mono support back :) kai
A comment about the deps: #79300 : This is evolution support for beagle #77504 : Well, whenever beagle goes to protage we need a user friendly solution for a dbus session. #81794 : Right now we need dbus-0.23.1 with mono support enabled. kai
Created an attachment (id=51351) [edit] Some changes to beagle-0.0.6.ebuild 1. beagle depends on >=net-www/mozilla-1.6 for gtkmozembed (or firefox/thunderbird, but these don't currently have gtkmozembed in Portage). 2. All the g*-sharp deps should be strict e.g. =dev-dotnet/gnome-sharp-1.0*. An issue if, like me, you have gtk-sharp-1.9.x and derived g*-sharp installed. 3. Suggest use flags and deps for mozilla, network, epiphany, msoffice. Later gstreamer and zeroconf, when their respective deps have been released.
Created an attachment (id=51352) [edit] beagle-0.0.6-configure.in.patch
Also: need to add dep >=dev-libs/atk-1.2.4 as this is not implied by any existing deps (at least not directly).
scratch that, we do depend on atk indirectly and 1.6.1 is lowest version in portage. my bad.
Created an attachment (id=51361) [edit] beagle-0.0.6.ebuild Network support is currently broken. Note also that epiphany support will fail as it wants epiphany-1.2; not much we can do about this atm.
Well, right now network, epiphany and msoffice does not work and that is the reason why it was not included in my proposed ebuild. kai
Created an attachment (id=51503) [edit] beagle-0.0.6.1.ebuild This is version 0.0.6.1 of beagle. Does not look as stable as 0.0.5 was, but you should try it by yourself. I included also ed's suggestion about the mozilla dep for gtkmozemb (thanks ed). You can use the existing configure patch. kai
Beagle-0.0.6.1 seems to work much much better with mono-1.1.4 rather than 1.0.5. First I don't get the crashes I got with 1.0.5, and second - it hardly ever reaches the 62MB mem limit, which is broken ith 1.0.5 every 2-3 secs :) at least I didn't notice it with 1.1.4 anymore. I really suggest using mono-1.1.4 with beagle-0.0.6.1. It should soon be in portage. Mono-1.0.6 is already in portage, I'm not sure if it works as well as 1.1.4 (I would guess not...) but you might test and report :)
dbus 0.23.2 is out Change Log: * fix a bug in the mono bindings in which non-deterministic class finalization could cause dbus errors at application shutdown * a ton of thread locking-related bugs fixed * enforce that apps speaking on the session bus are the same user as the bus itself
Please look at: #82657 dev-dotnet/mono-1.1.4 #82656 sys-apps/dbus-0.23.2
yes you posted the same changelog thrice now, will you please stop spamming.
RE: comment #58, maybe this should act as a tracker bug and other bugs related to beagle and its dependancies should be added to dependancies for this bug.
I get this when trying to emerge beagle-0.0.6.1.ebuild, and I used the beagle-0.0.6-configure.in.patch and renamed it to beagle-0.0.6.1-configure.in.patch: configure:20513: checking for gtk-sharp glade-sharp gecko-sharp = 0.6 gnome-sharp dbus-sharp >= 0.23.1 gconf-sharp gmime-sharp >= 2.1.11 configure:20552: error: Library requirements (gtk-sharp glade-sharp gecko-sharp = 0.6 gnome-sharp dbus-sharp >= 0.23.1 gconf-sharp gmime-sharp >= 2.1.11) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. why is it looking for =0.6, should be 1.0.6 right? Did no one else have this problem?
=0.6 applies to gecko-sharp only, which is correct. You need to find out which pkgconfig package it is failing on; try $ pkg-config --modversion 'gtk-sharp glade-sharp gecko-sharp = 0.6 gnome-sharp dbus-sharp >= 0.23.1 gconf-sharp gmime-sharp >= 2.1.11'
I confirm that using the 0.0.6.1 beagle ebuild + patch from this bug and renaming to 0.0.7 works great. I only found a strange bug so far, causing best to crash only when I search for the keyword 'linux' :)
looks like mono is now in dev-lang/
Created an attachment (id=53262) [edit] new ebuild new ebuild for the new version (and integrate the mono's change in portage)
Created an attachment (id=53433) [edit] eagle-0.0.7-r1.ebuild added USE-flags "nework" and "epiphany"
(From update of attachment 53433 [edit]) typo, sorry
care to explain what are those USE flags meant to do? the 'epiphany' is rather obvious but not so the 'network'....
Created an attachment (id=53512) [edit] beagle-0.0.7-r2.ebuild What the hell brings me to invoke an eds USE-flag?? "epiphany" is the right one.
Created an attachment (id=53513) [edit] beagle-0.0.7-r3.ebuild O no, its not my day. Please ignore the ebuild above. The current one is the one you should use :-/
Based on my experience, and the howto at http://forums.gentoo.org/viewtopic.php?t=288526 , 0.0.7 needs >=dev-lang/mono-1.1 Also, I encountered a bug where trying to 'reveal in file manager', would launch nautilus such that it would take over my desktop (managed by xfce). I would imagine this would occur with any environment not that didn't use nautilus for the desktop. Could others verify this? I started a bug over at: http://bugzilla.gnome.org/show_bug.cgi?id=171309
Created an attachment (id=54241) [edit] epiphany-extensions is in www-client, not net-www I modified line 26 of the ebuild so it looks as follows: epiphany? ( >=www-client/epiphany-extensions-1.6.0 )" rather than epiphany? ( >=net-www/epiphany-extensions-1.6.0 )" because the epiphany-extensions package exists in www-client. After doing this, I was able to emerge beagle w/o a problem.
(From update of attachment 54241 [edit]) epiphany-extensions is in www-client, not net-www
Created an attachment (id=54243) [edit] beagle-0.0.7-configure.in.patch Ok, this may be a noob mistake, but I simply copied the beagle-0.0.6-configure.in.patch file and saved it as beagle-0.0.7-configure.in.patch. Everything compiled w/o a problem.
0.0.8 is out
Created an attachment (id=54293) [edit] beagle-0.0.8.ebuild Here is an ebuild that I put together and was able to install successfully.
Created an attachment (id=54294) [edit] beagle-0.0.8-configure.in.patch Updated patch.
damn..derek beat me to it by 30 seconds. why is this not in portage yet?
From the release announcement: http://mail.gnome.org/archives/dashboard-hackers/2005-March/msg00101.html <snip> DEPENDENCY HECK --------------- Beagle has many dependencies, and thus can be difficult to compile. It requires: * The full Mono stack, including Gtk#. (We all use 1.1.4, and you probably should too, but 1.0.6 will also work. 1.0.5 and earlier will NOT work.) * D-BUS 0.23.4 * Evolution-sharp 0.6 * Gecko-sharp * Gsf-sharp * Gmime 2.1.13 For the best possible Beagle experience, you should also have: * An inotify 0.20-enabled kernel </snip> <snip> KNOWN ISSUES ------------ It doesn't take that much ingenuity to confuse the file system backend. In particular, the right thing doesn't always happen if a file's name changes rapidly. (i.e. "mv foo bar; mv bar baz; mv baz foo") The beagle daemon tends to grow over time, using more and more memory... but we now grow *much* more slowly than previously-released versions. It might need to be periodically killed and restarted. Sometimes the daemon or its associated helper process fail to shut down cleanly. Occasionally you will need to kill a beagle-related process by hand. At this point in development, we cannot commit to stable APIs or file formats. You will almost certainly need to delete your indexes and start again at some point in the future. </snip> It's not stable on 1.0.x, it's got lots of unsatisfied deps (that aren't going to instantly fix themselves), and they developers themselves admit that it's a memory hog, dies, needs restarting, and is not API stable, etc, etc, etc. I have no intention of putting this in til this is more mature. Hurrah for folks like NLD shipping it, they have the people to support it. dotnet herd is mostly a one man show right now, and there's other more pressing, and stable things on my place right now. This bug is a great reference for those wishing to give beagle a try, but I'm not willing to put this in the tree at this time. Hope that helps clear things up. Thanks.
And the folks behind the Beagle project beat out the programmers in Redmond by what ... a few years ;-)
DEPENDS should not have * in them, so for DEPENDS that look like =dev-dotnet/gecko-sharp-0.6*, they should look like >=dev-dotnet/gecko-sharp-0.6 (See http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3 ) Also, it may be a good idea to update the bug summary to 0.0.8.
@Josh: *DEPENDs with "*" in them are fine,
