Spec Name or Url: http://folk.ntnu.no/sindrb/packages/gecko-sharp.spec SRPM Name or Url: http://folk.ntnu.no/sindrb/packages/gecko-sharp-0.6-1.src.rpm Description: GeckoSharp is a wrapper for the GtkEmbedMoz widget. It provides the abilty to embed the Mozilla rendering engine (Gecko) into a Gtk# application
*** Bug 187290 has been marked as a duplicate of this bug. ***
Doesn't build on x86_64, this appears to be a mono package that actually installs to %{_libdir}: Processing files: gecko-sharp-0.6-1 error: File not found: /var/tmp/gecko-sharp-0.6-1-root-mockbuild/usr/lib/gecko-sharp error: File not found: /var/tmp/gecko-sharp-0.6-1-root-mockbuild/usr/lib/mono/gecko-sharp error: File not found by glob: /var/tmp/gecko-sharp-0.6-1-root-mockbuild/usr/lib/mono/gac/gecko-sharp/*
The spec file needs altering Just add %define _libdir /usr/lib at the start and alter under %install that huge make install line to make DESTDIR=%{buildroot} install and all should be fine Mono really can be a PITA over needing to be in /usr/lib I'll update the wiki to reflect this practise
http://fedoraproject.org/wiki/Packaging/Mono Should help
Created attachment 127957 [details] Patch file for the gecko-sharp spec file This should sort out a few problems. Hope it helps
Updated spec: http://folk.ntnu.no/sindrb/packages/gecko-sharp.spec Updated SRPM. http://folk.ntnu.no/sindrb/packages/gecko-sharp-0.6-2.src.rpm
I was going to review this, but then I noticed the gecko-sharp2 package in core. It has the exact same readme as this package, and the changelog for this package stops in 2004 whereas the core package is developed at least into 2005. Does the the package which depends on this one not work with the more recent gecko-sparp package?
It's the same package, just has a different name. I'll close this request and reopen if I find differently
The reason I'm doing this package in the first place was to fill a dependency for the blam news reader (#187621) which doesn't build with the gecko-sharp2 package. I'm sure blam can be patched to use gecko-sharp2, but that's work that should happen upstream.
> I'm sure blam can be patched to use gecko-sharp2, but that's work that > should happen upstream. Well, it's work that should coordinate with upstream. If it's a simple fix, there's no reason not to make it and carry the patch until upstream incorporates it if it lets us avoid adding what is essentially a dead package into extras. That said, there's certainly precedent for keeping in extras old packages that have been superceded by incompatible versions in core. (See gtk+.) But it's worth at least asking upstream to see what their plans are and what they recommend.
Got some response from the blam developer Mikael Hallendal today: "the only reason is the same as for Blam depending on old Gtk#, I haven't had time to change this. I'd happily accept patches for this though in case you happen to be a developer. As for the best way to do it I guess it would be to change in configure.in what it is built against and start there by fixing problems arising. I'm not sure how many issues might be involved." Updating blam to use gecko-sharp2 is far beyond my abilities as I'm no developer. If anyone else wants to take a shot at it, please do go ahead. As long as gecko-sharp is required as a dependency for blam I would like to add it to Extras, despite it being superceded by gecko-sharp2.
Closed. Turns out porting to gecko-sharp2 was not hard at all, merely changing some macros.