Bug 393521 - Miro doesn't yet work with xulrunner properly
Miro doesn't yet work with xulrunner properly
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Miro (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Thorsten Scherf
Fedora Extras Quality Assurance
:
: 436980 (view as bug list)
Depends On:
Blocks: 408361
  Show dependency treegraph
 
Reported: 2007-11-20 20:54 EST by Alex Lancaster
Modified: 2008-06-10 10:27 EDT (History)
8 users (show)

See Also:
Fixed In Version: 1.2.3-2.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-10 10:27:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
minimal build patch (8.73 KB, patch)
2007-12-03 07:21 EST, Martin Stransky
no flags Details | Diff
updated xulrunner patch (9.26 KB, patch)
2008-01-08 09:29 EST, Martin Stransky
no flags Details | Diff
minimal miro xulrunner 1.9 patch (3.03 KB, patch)
2008-04-28 07:34 EDT, Martin Stransky
no flags Details | Diff

  None (edit)
Description Alex Lancaster 2007-11-20 20:54:59 EST
Miro doesn't rebuild against the latest xulrunner in rawhide: 1.9-0.beta1.1.fc9.
This is the error:

Traceback (most recent call last):
  File "setup.py", line 262, in <module>
    raise ValueError("Can't find mozilla include base directory")
ValueError: Can't find mozilla include base directory
error: Bad exit status from /var/tmp/rpm-tmp.81507 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.81507 (%build)

Full build log and task: 

http://koji.fedoraproject.org/koji/getfile?taskID=252253&name=build.log
http://koji.fedoraproject.org/koji/taskinfo?taskID=252253
Comment 1 Martin Stransky 2007-11-21 08:45:36 EST
That's because miro uses mozilla internals what are not exported now. (and the
build script is broken). But I'm working on it...
Comment 2 Alex Lancaster 2007-12-01 17:56:01 EST
In the Miro setup.py (below), it seems that it searches the pkg-config file for
the include directory, which looking at:

http://koji.fedoraproject.org/koji/rpminfo?rpmID=292162

would appear to be:

/usr/include/xulrunner-1.9b2pre/

then attempts to look for

/usr/include/xulrunner-1.9b2pre/dom
/usr/include/xulrunner-1.9b2pre/gfx
/usr/include/xulrunner-1.9b2pre/widgets

which are all found in xulrunner-devel.  So either the check isn't working, or
the include directory /usr/include/xulrunner-1.9b2pre/ isn't being properly set
in /usr/lib/pkgconfig/xulrunner-xpcom.pc.  I don't have access to a rawhide box,
so I can't check the contents of the file.  Anyway, this seems to be the
proximate cause of the build failure, so we need to find the ultimate cause... ;)

xpcom_includes = parsePkgConfig("pkg-config", xpcom)
mozIncludeBase = None
for dir in xpcom_includes['include_dirs']:
    if allInDir(dir, ['dom', 'gfx', 'widget']):
        # we can be pretty confident that dir is the mozilla/firefox/xulrunner
        # base include directory
        mozIncludeBase = dir
        break
if mozIncludeBase is None:
    raise ValueError("Can't find mozilla include base directory")
for subdir in ['dom', 'gfx', 'widget', 'commandhandler', 'uriloader',
            'webbrwsr', 'necko', 'windowwatcher']:
    path = os.path.join(mozIncludeBase, subdir)
    mozilla_browser_options['include_dirs'].append(path)
Comment 3 Alex Lancaster 2007-12-02 04:18:08 EST
I patched the setup.py file to print out some debugging and here's the log:

http://koji.fedoraproject.org/koji/getfile?taskID=269348&name=build.log

If I "print xpcom", itt is correctly using:

 xulrunner-xpcom

If I "print xpcom_includes", I get:

{'libraries': ['xpcomglue_s', 'xul', 'xpcom', 'plds4', 'plc4', 'nspr4',
'pthread', 'dl'], 'library_dirs': ['/usr/lib/xulrunner-1.9b2pre'],
'extra_compile_args': ['-fshort-wchar'], 'include_dirs':
['/usr/include/xulrunner-1.9b2pre/stable', '/usr/include/nspr4']}

So ultimately include_dirs is set to /usr/include/xulrunner-1.9b2pre/stable and
it then looks for for subdirectories "dom", "gfx" and "widget" underneath
/usr/include/xulrunner-1.9b2pre/stable, but of course fails because they are
under /usr/include/xulrunner-1.9b2pre

Does this mean that xulrunner needs to be updated to put these files in stable/
or does Miro need to only look under the stable/ subdirectory?

The setup.py script later goes on to look for more subdirectories:

for subdir in ['dom', 'gfx', 'widget', 'commandhandler', 'uriloader',
            'webbrwsr', 'necko', 'windowwatcher']:
    path = os.path.join(mozIncludeBase, subdir)
    mozilla_browser_options['include_dirs'].append(path)
Comment 4 Alex Lancaster 2007-12-02 04:31:23 EST
Here's the link to the latest setup.py in the upstream SVN repository for reference:

https://develop.participatoryculture.org/trac/democracy/browser/trunk/tv/platform/gtk-x11/setup.py

(currently this is pretty much the same as that in the Miro-1.0 package I'm
trying to build).
Comment 5 Martin Stransky 2007-12-03 03:05:07 EST
This is the less significant problem there. Miro uses mozilla internal api which
are not exported by gecko-libs 1.9. I have a work-in-progress patch what compile
Miro but it doesn't run so I have to rewrite some parts.
Comment 6 Martin Stransky 2007-12-03 07:21:16 EST
Created attachment 275631 [details]
minimal build patch

There's a minimal patch compiles miro with xulrunner.

But it needs to implement the NS_Escape (it's not exported by xulrunner) and
rewrite the commented string from HttpObserver::Observe (a different functions
are exported now, see
http://developer.mozilla.org/en/docs/Migrating_from_Internal_Linkage_to_Frozen_Linkage).
Comment 7 Martin Stransky 2007-12-03 07:23:13 EST
I believe Miro upstream is able to fix that patch for full xulrunner support.
Comment 8 Alex Lancaster 2007-12-20 09:18:00 EST
(In reply to comment #7)
> I believe Miro upstream is able to fix that patch for full xulrunner support.

Have you actually been in contact with upstream? or are you just saying that
upstream could take the patch in question and fix it to be more complete?   Is
there already an upstream bug on this (I didn't find one) I will open a bug in
upstream if there isn't one currently.  This is now more urgent with the
disappearance of gecko-libs 1.8.x from rawhide.
Comment 9 Alex Lancaster 2007-12-20 09:24:32 EST
I filed an upstream bug here:

http://bugzilla.pculture.org/show_bug.cgi?id=9370

hopefully they can fix the patch and apply it upstream.
Comment 10 Martin Stransky 2007-12-20 10:51:14 EST
No, I'm not in touch with Miro upstream, that's definitely a responsibility of
Miro package maintainer.
Comment 11 Alex Lancaster 2007-12-20 11:02:54 EST
(In reply to comment #10)
> No, I'm not in touch with Miro upstream, that's definitely a responsibility of
> Miro package maintainer.

No, I didn't think so (which is why I filed an upstream bug), but your wording
was a bit confusing because it suggested you might be.

"I believe Miro upstream is able to fix that patch for full xulrunner support."

better might have been:

"Package maintainer: please contact Miro upstream, they should be able to fix
the patch I submitted here for full xulrunner support."
Comment 12 Alex Lancaster 2007-12-28 02:48:43 EST
I've rebuilt Miro successfully in rawhide (but only using the minimal patch, so
it may not work properly, if at all):

http://koji.fedoraproject.org/koji/buildinfo?buildID=29000

I'm unable to test that it works at runtime, because I don't currently have a
rawhide box.  If anybody else is able to test the rawhide build, please do so
and report back here.  Thanks.
Comment 13 Martin Stransky 2008-01-08 09:29:23 EST
Created attachment 291054 [details]
updated xulrunner patch
Comment 14 Alex Lancaster 2008-01-09 04:09:22 EST
Thanks, applied new patch and did rebuild for rawhide:

http://koji.fedoraproject.org/koji/buildinfo?buildID=30789
Comment 15 Alex Lancaster 2008-02-10 00:29:39 EST
Hmm, now have problems just compiling it against new GCC 4.3 in rawhide:

http://koji.fedoraproject.org/koji/taskinfo?taskID=410844
http://koji.fedoraproject.org/koji/getfile?taskID=410844&name=build.log
Comment 16 Alex Lancaster 2008-03-11 10:50:08 EDT
*** Bug 436980 has been marked as a duplicate of this bug. ***
Comment 17 Alex Lancaster 2008-03-11 10:52:20 EDT
Now that it builds against xulrunner, updating summary to reflect that it
doesn't really work with xulrunner.
Comment 18 Christopher Aillon 2008-03-11 13:50:51 EDT
FWIW, even though there's no response, it may be worth looking into yourself. 
Don't forget that Mozilla and Miro have at least 1 common board member, so this
would have clearly gotten attention upstream.
Comment 19 Martin Stransky 2008-03-12 08:38:28 EDT
I'm going to work on it after the final firefox release (or after a first RC).
Comment 20 Alex Lancaster 2008-03-29 05:01:15 EDT
According to 

http://pculture.org/devblogs/wguaraldi/2008/03/26/gtkx11-platform-and-xulrunner-19-status/

and

http://bugzilla.pculture.org/show_bug.cgi?id=9692

there is a test snapshot in the works that might fix Miro for xulrunner 1.9
support.  I'm about to try building it once koji comes back online.
Comment 21 Alex Lancaster 2008-03-29 08:51:35 EDT
It now builds against xulrunner 1.9 and I could drop my patch, builds are here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=537392

but still nothing appears in the main pane.  The main window appears, and the
status and menu bars appear functional, but nothing appears in the area that is
(presumably) drawn by calls to xulrunner.  I just get a mismash of whatever
windows are opened on top of it.  

This is about as far as I've ever gotten before with our previous local patch.

xulrunner version on Fedora rawhide: xulrunner-1.9-0.50.cvs20080327.fc9.i386

I reported my findings on the upstream bug (they claim to have been able to get
it functional on Ubuntu Hardy), so we'll see what needs to be done next:

http://bugzilla.pculture.org/show_bug.cgi?id=9692
Comment 22 Rex Dieter 2008-04-15 10:57:52 EDT
ditto on comment #21, I miss my miro. :(
Comment 23 Martin Stransky 2008-04-16 02:58:13 EDT
I hope I can check/fix that (and other remaining) packages in ~two weeks...
Comment 24 Alex Lancaster 2008-04-16 10:32:11 EDT
(In reply to comment #22)
> ditto on comment #21, I miss my miro. :(

Yep, as I reported upstream:

http://bugzilla.pculture.org/show_bug.cgi?id=9692#c28

still no workie with xulrunner-1.9-0.53-beta5.fc9.  As you can see from that
bug, upstream thinks it might be a packaging bug, but I can't see exactly where
that would be.  It might be a bug in the xulrunner package, but xulrunner seems
to be working OK for other packages.
Comment 25 Jakub 'Livio' Rusinek 2008-04-16 14:22:40 EDT
Does xulrunner provide gtkmozembed widget and the bindings? Check them too.
Comment 26 Jakub 'Livio' Rusinek 2008-04-27 12:56:42 EDT
Try Miro 1.2.3:
http://www.getmiro.com/blog/2008/04/miro-123-released-youtube-mp4s-bugs-fixes-and-updates/
.
Comment 27 Alex Lancaster 2008-04-28 05:10:50 EDT
(In reply to comment #26)
> Try Miro 1.2.3:
>
http://www.getmiro.com/blog/2008/04/miro-123-released-youtube-mp4s-bugs-fixes-and-updates/

Thanks.  New koji builds of 1.2.3 for F-9 are here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=47439

Unfortunately, they don't appear to fix the problem... at least for me :(  But
please do test them and provide feedback in case you see any kind of improvement
(or even if you don't).


Comment 28 Martin Stransky 2008-04-28 07:34:25 EDT
Created attachment 303961 [details]
minimal miro xulrunner 1.9 patch

There's a minimal patch to Miro. It fixes:

- Wrong gthmozembed initialization - Xulrunner 1.9 has to be initialized 
  by gtk_moz_embed_set_path() instead 
  of the old gtk_moz_embed_set_comp_path()

- Wrong gthmozembed mozilla-runtime path - gtkmozembed path should be obtained 

  by "--variable=libdir" pkg-config argument, not extracted from --libs

Miro works fine for me with this patch.
Comment 29 Alex Lancaster 2008-04-28 09:24:36 EDT
(In reply to comment #28)
> Created an attachment (id=303961) [edit]
> minimal miro xulrunner 1.9 patch
> 
> There's a minimal patch to Miro. It fixes:

Thanks!  Miro now finally works on F-9 with this build:

http://koji.fedoraproject.org/koji/buildinfo?buildID=47457

about to request the tag for f9-final.  Can you also submit the patch upstream
on http://bugzilla.pculture.org/show_bug.cgi?id=9692 ?  I'll also make a note of
it there, but it might be useful to be on that upstream bug so you can answer
questions about the patch.
Comment 30 Jakub 'Livio' Rusinek 2008-04-28 09:47:34 EDT
Yay, I love you :D !

PS: I wonder if some beautiful day WebKit will be powerful and fast... Gecko is
ugly slow... Even 1.9.
Comment 31 Bug Zapper 2008-05-13 23:57:52 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Alex Lancaster 2008-06-10 10:27:03 EDT
Since Miro works with xulrunner on what was RAWHIDE (and is now F-9), closing bug.  

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