Bug 187292 - Review Request: gecko-sharp
Summary: Review Request: gecko-sharp
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Thorsten Leemhuis (ignored mailbox)
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Keywords:
: 187290 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-29 20:14 UTC by Sindre Pedersen Bjørdal
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-05-28 20:45:28 UTC


Attachments (Terms of Use)
Patch file for the gecko-sharp spec file (1.76 KB, patch)
2006-04-19 00:22 UTC, Paul F. Johnson
no flags Details | Diff

Description Sindre Pedersen Bjørdal 2006-03-29 20:14:04 UTC
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

Comment 1 Ville Skyttä 2006-03-29 20:31:26 UTC
*** Bug 187290 has been marked as a duplicate of this bug. ***

Comment 2 John Mahowald 2006-04-18 23:39:22 UTC
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/*


Comment 3 Paul F. Johnson 2006-04-18 23:58:38 UTC
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

Comment 4 Paul F. Johnson 2006-04-19 00:13:39 UTC
http://fedoraproject.org/wiki/Packaging/Mono

Should help

Comment 5 Paul F. Johnson 2006-04-19 00:22:04 UTC
Created attachment 127957 [details]
Patch file for the gecko-sharp spec file

This should sort out a few problems. Hope it helps

Comment 7 Jason Tibbitts 2006-04-27 02:10:00 UTC
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?

Comment 8 Paul F. Johnson 2006-04-27 08:40:58 UTC
It's the same package, just has a different name. I'll close this request and
reopen if I find differently

Comment 9 Sindre Pedersen Bjørdal 2006-04-27 09:44:03 UTC
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. 

Comment 10 Jason Tibbitts 2006-04-27 13:37:28 UTC
> 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.


Comment 11 Sindre Pedersen Bjørdal 2006-05-09 18:00:50 UTC
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. 


Comment 12 John Mahowald 2006-05-28 20:45:28 UTC
Closed. Turns out porting to gecko-sharp2 was not hard at all, merely changing
some macros.


Note You need to log in before you can comment on or make changes to this bug.