That's because miro uses mozilla internals what are not exported now. (and the
build script is broken). But I'm working on it...

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)

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)

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).

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.

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).

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

(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.

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.

No, I'm not in touch with Miro upstream, that's definitely a responsibility of
Miro package maintainer.

(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."

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.

Created attachment 291054 [details]
updated xulrunner patch

Thanks, applied new patch and did rebuild for rawhide:

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

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

*** Bug 436980 has been marked as a duplicate of this bug. ***

Now that it builds against xulrunner, updating summary to reflect that it
doesn't really work with xulrunner.

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.

I'm going to work on it after the final firefox release (or after a first RC).

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.

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

ditto on comment #21, I miss my miro. :(

I hope I can check/fix that (and other remaining) packages in ~two weeks...

(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.

Does xulrunner provide gtkmozembed widget and the bindings? Check them too.

Try Miro 1.2.3:
http://www.getmiro.com/blog/2008/04/miro-123-released-youtube-mp4s-bugs-fixes-and-updates/
.

(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).

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.

(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.

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.

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

Since Miro works with xulrunner on what was RAWHIDE (and is now F-9), closing bug.