XULRunner in rawhide

[Martin Stransky]

Hello,

there's a new package in rawhide, xulrunner
(xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
XUL application and run in by xulrunner.

So no more firefox-devel packages in rawhide, you should use
xulrunner-devel (gecko-libs == 1.9) now.

If you maintain any package what is built against gecko-libs (or
firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
pkg-config files are provided and you may add "--with-gecko=xulrunner"
directive to configure script.

As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is based
on the latest mozilla xulrunner trunk (a.k.a. Firefox 3 Alpha) so some
package may not compile with it (for instance epiphany) and we need to
fix all those errors before F9 GA...

Please contact me or Chris if you have any questions.

Ma.

[Alex Lancaster]

> >>>> "MS" == Martin Stransky  writes: 
MS> Hello, there's a new package in rawhide, xulrunner
MS> (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to
MS> provide gecko-libs instead of Firefox and the plan is to ship
MS> Firefox as a pure XUL application and run in by xulrunner.

MS> So no more firefox-devel packages in rawhide, you should use
MS> xulrunner-devel (gecko-libs == 1.9) now.

MS> If you maintain any package what is built against gecko-libs (or
MS> firefox-devel), please rebuild it with the xulrunner. The
MS> xulrunner-*.pc pkg-config files are provided and you may add
MS> "--with-gecko=xulrunner" directive to configure script.

MS> As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is
MS> based on the latest mozilla xulrunner trunk (a.k.a. Firefox 3
MS> Alpha) so some package may not compile with it (for instance
MS> epiphany) and we need to fix all those errors before F9 GA...

MS> Please contact me or Chris if you have any questions.

Martin,

I just tried rebuilding Miro against the new xulrunner (by bumping BR:
gecko-devel = 1.9), and I got the following build log.

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

relevant excerpt is:

Traceback (most recent call last):
  File "setup.py", line 244, in <module>
    "gtk+-2.0 glib-2.0 pygtk-2.0 %s %s" % (gtkmozembed, xpcom))
  File "setup.py", line 194, in parsePkgConfig
    output = getCommandOutput(commandLine).strip()
  File "setup.py", line 165, in getCommandOutput
    (cmd, stderr))
RuntimeError: pkg-config --cflags --libs gtk+-2.0 glib-2.0 pygtk-2.0
  xulrunner-gtkmozembed xulrunner-xpcom outputted the following error:
Package xulrunner-gtkmozembed was not found in the pkg-config search
  path.
Perhaps you should add the directory containing
  `xulrunner-gtkmozembed.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xulrunner-gtkmozembed' found

Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
package somehow?  Is there another BuildRequires I need to add?

Alex

[Martin Stransky]

Alex Lancaster wrote:
>  Is 'xulrunner-gtkmozembed' supposed to be provided by the
> xulrunner
>  package somehow?  Is there another BuildRequires I need to add?
>  
>  Alex 
gtkmozembed is not shipped by xulrunner, we need to check what's going on...

[Christopher Aillon]

Martin Stransky wrote:
>  Alex Lancaster wrote:
> > Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
> > package somehow?  Is there another BuildRequires I need to add?
> >
> > Alex
>  
>  gtkmozembed is not shipped by xulrunner, we need to check what's going 
>  on... 
Hm, I think this got split into a different tarball.

[Martin Stransky]

Alex Lancaster wrote:
>  Is 'xulrunner-gtkmozembed' supposed to be provided by the
> xulrunner
>  package somehow?  Is there another BuildRequires I need to add? 
First and experimental xulrunner-gtkmozembed is in 
rawhide/xulrunner-1.9-0.alpha9.5.fc9 now. I don't have any proper 
test-case (galeon doesn't compile because of some other problems) so it 
can fail but please test it...

[Alex Lancaster]

> >>>> "MS" == Martin Stransky  writes: 
MS> Alex Lancaster wrote:
> > Is 'xulrunner-gtkmozembed' supposed to be provided by the
> xulrunner
> > package somehow?  Is there another BuildRequires I need to add? 
MS> First and experimental xulrunner-gtkmozembed is in
MS> rawhide/xulrunner-1.9-0.alpha9.5.fc9 now. I don't have any proper
MS> test-case (galeon doesn't compile because of some other problems)
MS> so it can fail but please test it...

Thanks, Martin: this goes further than last time, I don't get the
"Package xulrunner-gtkmozembed was not found in the pkg-config search
path." error messages any more, but I now get a new 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

Full log here:

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

Any more ideas?

Alex

[Martin Stransky]

Alex Lancaster wrote:
>  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
>  
>  Full log here:
>  
>  http://koji.fedoraproject.org/koji/getfile?taskID=244635&name=build.log 
I'll check it locally, looks like some misconfiguration...

[Alex Lancaster]

> >>>> "MS" == Martin Stransky  writes: 
MS> Alex Lancaster wrote:
> > 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
> > 
> > Full log here:
> > 
> > http://koji.fedoraproject.org/koji/getfile?taskID=244635&name=build.log 
MS> I'll check it locally, looks like some misconfiguration...

Martin,

I retried with the latest xulrunner in rawhide: 1.9-0.beta1.1.fc9
thinking that maybe the new xulrunner would fix this but I get the
same thing:

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

here's the task:

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

Alex

[Christopher Aillon]

On 11/21/2007 02:31 AM, Alex Lancaster wrote:
>  Martin,
>  
>  I retried with the latest xulrunner in rawhide: 1.9-0.beta1.1.fc9
>  thinking that maybe the new xulrunner would fix this but I get the
>  same thing:
>  
>  http://koji.fedoraproject.org/koji/getfile?taskID=252253&name=build.log
>  
>  here's the task:
>  
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=252253 
Can you file a bug so we can better track this?

[Alex Lancaster]

> >>>> "CA" == Christopher Aillon  writes: 
> > On 11/21/2007 02:31 AM, Alex Lancaster wrote:
> > Martin,
> > 
> > I retried with the latest xulrunner in rawhide: 1.9-0.beta1.1.fc9
> > thinking that maybe the new xulrunner would fix this but I get the
> > same thing:
> > 
> > http://koji.fedoraproject.org/koji/getfile?taskID=252253&name=build.log
> > 
> > here's the task:
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=252253 
CA> Can you file a bug so we can better track this?

Already done:

https://bugzilla.redhat.com/show_bug.cgi?id=393521

Alex

[Erik van Pienbroek]

Op donderdag 15-11-2007 om 18:45 uur [tijdzone +0100], schreef Martin Stransky:
>  Alex Lancaster wrote:
>  > Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
>  > package somehow?  Is there another BuildRequires I need to add?
>  
>  First and experimental xulrunner-gtkmozembed is in 
>  rawhide/xulrunner-1.9-0.alpha9.5.fc9 now. I don't have any proper 
>  test-case (galeon doesn't compile because of some other problems) so it 
>  can fail but please test it... 
I've just installed the latest xulrunner package from koji, but the
compilation of my gtkmozembed based program fails due to a missing file:

$ pkg-config --libs xulrunner-gtkmozembed
-L/usr/lib/xulrunner-1.9a9pre -lxpcomglue_s -lxul -lxpcom -lplds4 -lplc4
-lnspr4 -lpthread -ldl  

$ find /usr/lib/xulrunner-1.9a9pre -name xpcomglue*
<no results>

The library xpcomglue_s doesn't exist yet in the xulrunner{,-devel}
package.

Regards,

Erik van Pienbroek

[Christopher Aillon]

Martin Stransky wrote:
>  Hello,
>  
>  there's a new package in rawhide, xulrunner
>  (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
>  gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
>  XUL application and run in by xulrunner.
>  
>  So no more firefox-devel packages in rawhide, you should use
>  xulrunner-devel (gecko-libs == 1.9) now.
>  
>  If you maintain any package what is built against gecko-libs (or
>  firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
>  pkg-config files are provided and you may add "--with-gecko=xulrunner"
>  directive to configure script. 
Actually, this is not going to work for many apps if it works at all. 
They would need some porting.  I haven't had time to write up some info 
on this yet, though.

[Mamoru Tasaka]

Hi,

Martin Stransky wrote, at 11/14/2007 10:59 PM +9:00:
>  So no more firefox-devel packages in rawhide, you should use
>  xulrunner-devel (gecko-libs == 1.9) now.
>  
>  If you maintain any package what is built against gecko-libs (or
>  firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
>  pkg-config files are provided and you may add "--with-gecko=xulrunner"
>  directive to configure script.
>  
>  As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is based
>  on the latest mozilla xulrunner trunk (a.k.a. Firefox 3 Alpha) so some
>  package may not compile with it (for instance epiphany) and we need to
>  fix all those errors before F9 GA... 
I tried to rebuild kazehakase against xulrunner, however it failed
with complaint of many missing headers like:
----------------------------------------
In file included from kz-gecko-embed.cpp:37:
kz-mozwrapper.h:31:33: error: nsIDOMEventReceiver.h: No such file or directory
----------------------------------------
http://koji.fedoraproject.org/koji/taskinfo?taskID=241394

Are these header files supposed to be removed? If so I will
contact with upstream developer to look into latest xulrunner.

Regards,
Mamoru

[Christopher Aillon]

Mamoru Tasaka wrote:
>  Hi,
>  
>  Martin Stransky wrote, at 11/14/2007 10:59 PM +9:00:
> > So no more firefox-devel packages in rawhide, you should use
> > xulrunner-devel (gecko-libs == 1.9) now.
> >
> > If you maintain any package what is built against gecko-libs (or
> > firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
> > pkg-config files are provided and you may add "--with-gecko=xulrunner"
> > directive to configure script.
> >
> > As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is based
> > on the latest mozilla xulrunner trunk (a.k.a. Firefox 3 Alpha) so some
> > package may not compile with it (for instance epiphany) and we need to
> > fix all those errors before F9 GA...
>  
>  I tried to rebuild kazehakase against xulrunner, however it failed
>  with complaint of many missing headers like:
>  ----------------------------------------
>  In file included from kz-gecko-embed.cpp:37:
>  kz-mozwrapper.h:31:33: error: nsIDOMEventReceiver.h: No such file or 
>  directory
>  ----------------------------------------
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=241394
>  
>  Are these header files supposed to be removed? If so I will
>  contact with upstream developer to look into latest xulrunner. 
nsIDOMEvenReceiver was removed completely from upstream. 
https://bugzilla.mozilla.org/show_bug.cgi?id=363089

A good starting point to see if the header is still upstream is: 
http://lxr.mozilla.org/mozilla/find

Also, there will be some compilation failures due to incompatible 
changes that you may notice.

[Dennis Jacobfeuerborn]

Martin Stransky wrote:
>  Hello,
>  
>  there's a new package in rawhide, xulrunner
>  (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
>  gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
>  XUL application and run in by xulrunner. 
Is this really going to work? The Mozilla guys made it clear that they 
don't want to make Firefox depend on xulrunner as that would limit their 
ability to push the envelope with firefox. If Fedora wants to make that 
move wouldn't that eventually require a fork?

http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/

Regards,
   Dennis

[Christopher Aillon]

Dennis Jacobfeuerborn wrote:
>  Martin Stransky wrote:
> > Hello,
> >
> > there's a new package in rawhide, xulrunner
> > (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
> > gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
> > XUL application and run in by xulrunner.
>  
>  Is this really going to work? The Mozilla guys made it clear that they 
>  don't want to make Firefox depend on xulrunner as that would limit their 
>  ability to push the envelope with firefox. If Fedora wants to make that 
>  move wouldn't that eventually require a fork?
>  
>  http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/ 
Um, did you read the article?  Specifically the "What are we doing?" 
opening text and the third bullet point underneath it?

[Jef Spaleta]

On Nov 14, 2007 2:41 PM, Christopher Aillon <caillon(a)redhat.com&gt; wrote:
>  Um, did you read the article?  Specifically the "What are we
> doing?"
>  opening text and the third bullet point underneath it? 

firefox as shipped in Fedora, isn't what I'm most concerned about.
I'm pretty confident that for firefox in Fedora has a roadmap on how
handle the maintenance burden of a firefox package that diverges from
upstream development over the course of a Fedora release cycle.

What I am really concerned about is the other gecko lib based
applications we have.  xulrunner is a clear win for these applications
but only if the upstream developers for these applications are ready
to make use of xulrunner. We've been talking about xulrunner since F8
testing started.  I would have hoped that the maintainers for
applications that depend on gecko-libs would know by now if the
upstream projects are ready to support xulrunner.

So it really comes down to this. Out of the applications that depend
on gecko-libs in fedora right now, other than firefox, which of those
applications are xulrunner-ready?  And out of the ones that are not,
is upstream development actively working on making their app work with
xulrunner?

Worst case scenario is that we are going to get into a situation with
some of these apps where the upstream development does not support
xulrunner and it will be up to our package maintainers to try to make
it work and end up in over their heads keeping up with patches as app
updates are issued.  As a project we need to know about this sort of
potential problem as early in the development cycle as possible.

-jef"if I had a hammer, I'd hammer in DOOOOOOOM"spaleta

[Christopher Aillon]

On 11/15/2007 09:56 AM, Jeff Spaleta wrote:
>  On Nov 14, 2007 2:41 PM, Christopher Aillon
> <caillon(a)redhat.com&gt; wrote:
> > Um, did you read the article?  Specifically the "What are we doing?"
> > opening text and the third bullet point underneath it?
>  
>  
>  firefox as shipped in Fedora, isn't what I'm most concerned about.
>  I'm pretty confident that for firefox in Fedora has a roadmap on how
>  handle the maintenance burden of a firefox package that diverges from
>  upstream development over the course of a Fedora release cycle.
>  
>  What I am really concerned about is the other gecko lib based
>  applications we have.  xulrunner is a clear win for these applications
>  but only if the upstream developers for these applications are ready
>  to make use of xulrunner. We've been talking about xulrunner since F8
>  testing started.  I would have hoped that the maintainers for
>  applications that depend on gecko-libs would know by now if the
>  upstream projects are ready to support xulrunner. 
Most of them ought to be using gtkmozembed which should not be that 
affected by the xulrunner changes too much.