I took a quick stab at updating several ebuilds required by gnome-extra/gnome-do-0.5.0.1.ebuild. However I am not sure if all the gtk-sharp ebuild infrastructure is still valid with the current gnome-do releases, e.g: GTK_SHARP_TARBALL_PREFIX="gnome-sharp" GTK_SHARP_REQUIRED_VERSION="2.10" GTK_SHARP_COMPONENT_SLOT="2" GTK_SHARP_COMPONENT_SLOT_DEC="-2.0" GTK_SHARP_COMPONENT_BUILD_DEPS="art" I'm not getting clean downloads, so let me start by reporting the current/new URLs: http://launchpad.net/do/trunk/0.5/+download/gnome-do-0.5.0.1.tar.gz Quoting the page, dependencies: "...Building from the latest source currently requires the following development libraries: bzr (>= 0.92) mono-gmcs cairo-sharp NDesk DBus & NDesk DBus Glib gtk-sharp2 gnome-vfs-sharp gconf-sharp glade-sharp-2 glib-sharp-2 glib-2.0 gdk-2.0 gdk-x11-2.0 gtk+-2.0 gnome-desktop-sharp-2.0 (gnome-sharp2) ...There may be other dependencies not listed here." Among the dev-dotnet dependencies that need updating, via http://www.mono-project.com/GtkSharp: http://ftp.gnome.org/pub/gnome/sources/gtk-sharp/2.12/gtk-sharp-2.12.0.tar.gz http://ftp.gnome.org/pub/gnome/sources/gnome-sharp/2.20/gnome-sharp-2.20.0.tar.gz http://ftp.gnome.org/pub/gnome/sources/gnome-desktop-sharp/2.20/gnome-desktop-sharp-2.20.1.tar.gz Note that I do not see a do-plugins-0.5.x release listed yet, not sure if it's needed. I don't see a big plugin source addition to the gnome-do-0.5.0.1.tar.gz, though. Thanks, this is kind of an awkward bug to file since it's mostly dependencies, apologies if it's out of protocol.
Recommendation from #gnome-do is that do-plugins package can be deprecated for the 0.5 series. The installed gnome-do-0.5 has an integrated plugin retrieval system that can be used per-user. When more plugins are released for the 0.5 series, it may make sense to package them up in a do-plugins again for system-wide installers.
FWIW, I've got hackish ebuilds that should get gnome-do-0.5.0.1 installed: gnome-sharp/gnome-sharp-2.20.0.ebuild gnome-desktop-sharp/gnome-desktop-sharp-2.20.1.ebuild gtk-sharp/gtk-sharp-2.12.1.ebuild gnome-do/gnome-do-0.5.0.1.ebuild but I'm stuck on some mechanism of the gtk-sharp-components.eclass: >>> Emerging (1 of 2) dev-dotnet/gnome-desktop-sharp-2.20.1 to / * gnome-desktop-sharp-2.20.1.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking gnome-desktop-sharp-2.20.1.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking gnome-desktop-sharp-2.20.1.tar.gz to /var/tmp/portage/dev-dotnet/gnome-desktop-sharp-2.20.1/work * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /var/tmp/portage/dev-dotnet/gnome-desktop-sharp-2.20.1/work/gnome-desktop-sharp-2.20.1-configurable.diff * ( gnome-desktop-sharp-2.20.1-configurable.diff ) I'm sure it's very necessary, but I don't know what that's all about ;)
I just had a look at: /usr/portage/distfiles/gnome-sharp-2.16.0-configurable.diff.gz for one example. Is that change not being accepted in upstream versions?
I just filed bug 227079 and bug 227081 for gnome-desktop-sharp and gnome-keyring-sharp, which both look like they're needed for this -- see configure.ac from the gnome-do tarball. @Jeff, if you could add these as dependencies for this bug that might be helpful.
Ok, I just tried to hack together some testing ebuilds to get gnome-do up and running. It's quite involved, so I wouldn't expect anything too soon. For those of you interested, here's why... Mono seems to ship three base packages gtk-sharp, gnome-sharp and now gnome-desktop-sharp. These actually contain multiple libraries (gnome-sharp contains gnomevfs-sharp and art-sharp, seemingly). Sadly, the autotooled configure scripts don't allow each of these to be made individually. You can think of it similarly to the gstreamer plugins; there's one great big tarball containing all the plugins, but ideally we'd be able to pick and choose exactly which ones we want. The configure scripts don't allow the choice of which libraries should be built and which shouldn't, so the dotnet Gentoo devs have been making their own patches to split the packages up. Whilst that's great for users, it's pretty tough on the devs, so I'm not surprised there haven't been updates recently. Add to this, the fact that gnome-do also relies on gnome-keyring-sharp, which hasn't ever had a stable point of release (it's currently available either through bzr or a daily snapshot). Ideally we'd use a snapshot taken on a particular date. Either way, it's not the most convenient package to get running, and to do it right will certainly take a while. I'm going to keep hacking away at my ugly ebuilds to see if I can get something running, but please don't hold your breath... Jeff, you can create fake empty patches as follows: cd /usr/portage/distfiles; touch gnome-sharp-2.20.1-configurable.diff; gzip gnome-sharp-2.20.1-configurable.diff Please note, that's *not* recommended and is purely for getting ugly ebuilds off the ground (as in, I doubt those ebuilds would get in the tree without real patches there). I also have no idea whether that patch was accepted upstream, it certainly isn't present in the current source tarballs.
While I'm not going to argue with Gentoo devs splitting these packages in traditional Gentoo fashion, I personally would not have any problem with building the full gnome-desktop-sharp package in order to get this Gnome-Do version available sooner. Frankly, the amount of time to build all of the *-sharp libraries split from gtk-sharp doesn't seem significant on a relatively modern system (and compared to building Evolution insignificant on any system!). I know that still leaves the work needed to get a bzr snapshot ebuild of gnome-keyring-sharp into the tree, which I understand is a major PITA. But if you do hack something together in a dev overlay, you might consider an ebuild for gnome-desktop-sharp that can be replaced by the individual library builds once those are in the tree.
(In reply to comment #6) > While I'm not going to argue with Gentoo devs splitting these packages in > traditional Gentoo fashion, I personally would not have any problem with > building the full gnome-desktop-sharp package in order to get this Gnome-Do > version available sooner. Frankly, the amount of time to build all of the > *-sharp libraries split from gtk-sharp doesn't seem significant on a relatively > modern system (and compared to building Evolution insignificant on any > system!). > > I know that still leaves the work needed to get a bzr snapshot ebuild of > gnome-keyring-sharp into the tree, which I understand is a major PITA. But if > you do hack something together in a dev overlay, you might consider an ebuild > for gnome-desktop-sharp that can be replaced by the individual library builds > once those are in the tree. > Has there been any progress on this? Gnome do is approaching its next major release which would put portage 2 major milestones behind upstream.
The time I can spend on Gentoo right now is very limited, I don't think I'll be able to work on this in any significant way until the end of August at the earliest. I also won't be doing any work on the C# dependencies, so that really needs to be resolved first (and thanks to Jose for filing bugs on that). Patches and ebuilds are quite welcome, currently there aren't any on the bug. Jeff, if you've got something more or less working then feel free to add the ebuilds to the relevant bugs so that people can try it out and comment on it. Obviously the same applies to others. It's much easier for me to find a bit of time to test and bump already written and tested ebuilds...
Created attachment 163211 [details] gnome-do-0.5.99.0.ebuild Here's an ebuild for gnome-do-0.5.99.0, which is a (probably last) RC for 0.6. It has one new dependancy not in portage and which hasn't had any releases yet: dev-dotnet/notify-sharp I've uploaded ebuilds for it, as well as for all other depends, to bug #221003, bug #227081, and bug #235111. Works fine for me, ~x86
This ebuild plus all the dependencies build fine on ~amd64 as well, and I haven't encountered any problems with the application yet. It's probably safe to add ~amd64 to the keywords. @Sebastian, thanks so much for your work on this!
Ok, I've added this and all the necessary dotnet ebuilds (thanks to Sebastian!) to my overlay, which you can add using "layman -f; layman -a ikelos". Hopefully there won't be any problems, but give me a shout if anything crops up. Thanks... 5:)
overlay works great so far, I had to grab the gtk-sharp patch via the bug. Everything compiled fine on amd64, not sure on gnome-do yet b/c launchpad is done for upgrade.
(In reply to comment #9) > Created an attachment (id=163211) [edit] > gnome-do-0.5.99.0.ebuild > > Here's an ebuild for gnome-do-0.5.99.0, which is a (probably last) RC for 0.6. Some feedback: please keep the DESCRIPTION below 100 characters. We can but a longer description in the metadata.xml if needed. No need to depend on dev-libs/glib and x11-libs/gtk+-2.0, this will be handled indirectly by the gtk-sharp ebuild. Instead of mentioning evolution-sharp in the pkg_postinst message, just make it a USE-flag based dependency. The proper USE flag is 'eds'. > It has one new dependancy not in portage and which hasn't had any releases yet: > dev-dotnet/notify-sharp I also have an ebuild for notify-sharp in my overlay, you may want to check it to see if there is anything you can use.
(In reply to comment #11) > Ok, I've added this and all the necessary dotnet ebuilds (thanks to Sebastian!) > to my overlay, which you can add using "layman -f; layman -a ikelos". > Hopefully there won't be any problems, but give me a shout if anything crops > up. Thanks... 5:) I compiled this when also having the gnome (2.23) overlay. In that case I could not use gnome-do to run applications. It turned out to be a wrong dllmap in gnomedesktop-sharp which mentions libgnome-desktop-2.so.2 but that file (symlink) did not exist in my /usr/lib. On the other hand I did have libgnome-desktop-2.so.7 (symlink). Could it perhaps be better to use the generic symlink libgnome-desktop-2.so instead in the dllmap of gnomedesktop-sharp? (I changed it like that on my system and it works just fine so far)
Created attachment 165986 [details] gnome-do-0.6.0.1.ebuild (In reply to comment #13) > Some feedback: > > please keep the DESCRIPTION below 100 characters. We can but a longer > description in the metadata.xml if needed. Done. > No need to depend on dev-libs/glib and x11-libs/gtk+-2.0, this will be handled > indirectly by the gtk-sharp ebuild. Done. > Instead of mentioning evolution-sharp in the pkg_postinst message, just make it > a USE-flag based dependency. The proper USE flag is 'eds'. I've added an "eds" use-flag, as well as a "gnome" one for wnck-sharp (<- in gnome-desktop-sharp), needed for the window manager plugin. The gnome flag should perhaps be renamed to a different one. > > It has one new dependancy not in portage and which hasn't had any releases yet: > > dev-dotnet/notify-sharp > > I also have an ebuild for notify-sharp in my overlay, you may want to check it > to see if there is anything you can use. I've allready posted an ebuild for a snapshot of its latest scm revision in bug #235111.
Created attachment 165988 [details] gnome-do-0.5.99.0.ebuild As 0.6.0.1 crashes constantly for me, here's also an updated ebuild for 0.5.99.0.
*** Bug 239010 has been marked as a duplicate of this bug. ***
Created attachment 172286 [details] version bump to 0.6.1.0 this version works for me on ~amd64
This version of gnome-do doesn't work for me. I am using the ebuild from the ikelos overlay. The problem I am having is that it won't parse through my applications. All of the plugins work, but nothing from my /usr/share/applications is showing up. The only difference between that ebuild and the one in this thread is the use of wnck-sharp with the gnome use flag (or the only one that would make a difference. I installed wnck-sharp, same issues. I am also running gnome-2.24 from the gnome overlay.
I think the not-parsing of apps (which I also encountered) is covered in this upstream bug (https://bugs.launchpad.net/do/+bug/287089).
(In reply to comment #20) > I think the not-parsing of apps (which I also encountered) is covered in this > upstream bug (https://bugs.launchpad.net/do/+bug/287089). > And the fix there was to gnome-desktop-sharp rather than gnome-do itself: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-desktop-sharp2/+bug/280365 This bug was fixed in the package gnome-desktop-sharp2 - 2.20.1-2ubuntu4 --------------- gnome-desktop-sharp2 (2.20.1-2ubuntu4) intrepid; urgency=low * debian/patches/02_gnomedesktop_dllmap + Actually map the new libgnome-desktop-2-7 lib. Fixes the dependency generation and library use (LP: #280365). -- Christopher James Halse Rogers <email address hidden> Thu, 09 Oct 2008 09:16:41 +1100
Using the ikelos overlay, I receive this compile time error: ./src/Do.Core/DoObject.cs(227,49): error CS1041: Identifier expected: `where' is a keyword Compilation failed: 1 error(s), 0 warnings make[1]: *** [bin/Debug/Do.exe] Error 1 make[1]: Leaving directory `/var/tmp/portage/gnome-extra/gnome-do-0.6.0.0/work/gnome-do-0.6.0.0/Do' make: *** [all-recursive] Error 1 * * ERROR: gnome-extra/gnome-do-0.6.0.0 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 914: Called gnome2_src_compile * environment, line 811: Called die * The specific snippet of code: * emake || die "compile failure" * The die message: * compile failure * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/gnome-extra/gnome-do-0.6.0.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/gnome-extra/gnome-do-0.6.0.0/temp/environment'. * The ebuild in portage (gnome-do-0.4.2.0-r2) works fine.
@Comment #22 - Jason - try updating your layman repo and emerge the 0.6.1.0, 0.6.0 isn't included in the repo anymore
Created attachment 172399 [details, diff] gnomedesktop-sharp-dllmap.patch The dllmap bug / fix does fix the problem I was having. Not sure if I new bug should be created or not, but I will go ahead and attach the fixed gnomedesktop-sharp stuff here
Created attachment 172400 [details] gnomedesktop-sharp-2.20.1-r1.ebuild the updated ebuild, it inherits the gtk-sharp-module eclass for the ikelos overlay
(In reply to comment #23) > @Comment #22 - Jason - try updating your layman repo and emerge the 0.6.1.0, > 0.6.0 isn't included in the repo anymore > I have latest version of the repo, which does not have gnome-do-0.6.1.0. Anyway, I manually downloaded and merged the new ebuild and I still have the same issue as the 0.6.0.0 ebuild.
(In reply to comment #26) > I have latest version of the repo, which does not have gnome-do-0.6.1.0. > Anyway, I manually downloaded and merged the new ebuild and I still have the > same issue as the 0.6.0.0 ebuild. > my bad, I think I might of renamed it. It was a simple rename I think.
(In reply to comment #27) > (In reply to comment #26) > > I have latest version of the repo, which does not have gnome-do-0.6.1.0. > > Anyway, I manually downloaded and merged the new ebuild and I still have the > > same issue as the 0.6.0.0 ebuild. > > > > my bad, I think I might of renamed it. It was a simple rename I think. > I think the error has to do with the use of the 'where' reserved keyword as a variable name. I don't think the compiler likes that. The strange thing is that the older version of the source code has the same usage and does not throw an error. Maybe a missing compiler option?
Ok, just to let you know, I've now bumped a lot of stuff in my repository, so you should be able to find gnome-do-0.6.1.0 in there. I've also updated most of the *-sharp ebuilds to the latest versions available. One issue this causes is that the precompiled Files plugin (and possibly some others) will no longer work because they require gconf-sharp-2.20 not gconf-sharp-2.24. I'm working on getting the gnome-do-plugins package up to date, but please don't hold your breath. If you have any problems with the gnome-do ebuilds in my overlay, please mention them here, or file bugs specifically mentioning [ikelos overlay] at the start of the summary. Thanks... 5:)
@ikelos: gtk-sharp fails building with "Unhandled Exception: System.IO.IOException: Sharing violation on path /var/tmp/portage/dev-dotnet/gtk-sharp-2.12.6/work/gtk-sharp-2.12.6/doc/gtk-sharp-docs.zip" if you use MAKEOPTS="-j3". I had to comment that line out of my /etc/make.conf for gtk-sharp to build. Building the rest of gnome-do-6.1 dependencies at the moment.
Ok, but gtk-sharp isn't one of the packages I'm handling. You should file a new bug for that. Please let me know the bug number once you have. Thanks... 5:)
You're right, I had though that gtk-sharp was from your overlay, sorry ;) Flameeyes has already done some patching to gtk-sharp as documented in this bug: http://bugs.gentoo.org/show_bug.cgi?id=236023 might be a good idea to talk to him about harmonizing your overlay and his, cause he's been doing some work on dotnet related stuff too recently.
Indeed. It looks like he's already using that patch of his[1], so you might want to report it as a bug if it's not working. I've already mentioned on the gtk-sharp-2.12 bug about bug 221003, added a dependency between the bugs, and I've mentioned on 221003 about the updated overlay. I'll give flameeyes a prod, but if he doesn't have a specific need for it, I don't think we'll want to push it to the main tree and support it. To be honest, I don't use/know enough about dotnet to be supporting this either, it's simply in my overlay to help me get gnome-do going... [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-dotnet/gtk-sharp/files/gtk-sharp-2.12.0-parallelmake.patch?view=markup
(In reply to comment #24) > Created an attachment (id=172399) [edit] > gnomedesktop-sharp-dllmap.patch > > The dllmap bug / fix does fix the problem I was having. Not sure if I new bug > should be created or not, but I will go ahead and attach the fixed > gnomedesktop-sharp stuff here > Could you please file a seperate bug about this so that the dotnet-herd takes notice? Just got bitten with this (again...) with gnome-desktop-2.25...
0.6.1.0 in portage since all other versions were breaking depgraphs.
(In reply to comment #34) > > Could you please file a seperate bug about this so that the dotnet-herd takes > notice? Just got bitten with this (again...) with gnome-desktop-2.25... > Do you still want me to? gnome-desktop-sharp-2.24 is arleady in portage and this isn't needed for 2.24, only 2.20
I've just added a version of gnome-do-plugins 0.6 to CVS, but added it to the current package.mask of gnome-do 0.6. I'd be happy to get some feedback from brave souls testing out both packages, before we unmask it.
I've unmasked gnome-do-0.6.1.0 a few days ago. Please report any problems you may encounter in new bugs.
