2:22 a.m.
Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished
version and we appreciate if you test it and report all issues to
bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run
Firefox 3 on Fedora 8, too. Just download and compile the latest
xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install
firefox from rawhide.
There's one side effect of this update. The former firefox-devel package
has been removed from rawhide and gecko-libs 1.8 is no more shipped. All
packages have to run with xulrunner (gecko-libs 1.9) now.
If you're a package maintainer and your package already uses xulrunner,
please rebuild it against the new rawhide version. Xulrunner directory
has been changed and many gecko packages (if not all) are linked with
--rpath linker directive. As long as rpath is used you have to rebuild
gecko-libs based packages after each xulrunner change so please consider
to remove it. Gecko libraries are registered system wide by
/etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Happy testing&hacking! :)
ma.
2:41 a.m.
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished
version and we appreciate if you test it and report all issues to
bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run
Firefox 3 on Fedora 8, too. Just download and compile the latest
xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install
firefox from rawhide.
There's one side effect of this update. The former firefox-devel package
has been removed from rawhide and gecko-libs 1.8 is no more shipped. All
packages have to run with xulrunner (gecko-libs 1.9) now.
If you're a package maintainer and your package already uses xulrunner,
please rebuild it against the new rawhide version. Xulrunner directory
has been changed and many gecko packages (if not all) are linked with
--rpath linker directive. As long as rpath is used you have to rebuild
gecko-libs based packages after each xulrunner change so please consider
to remove it. Gecko libraries are registered system wide by
/etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Happy testing&hacking! :)
ma.
Hi,
That's good news! Just some little questions. Has epiphany been ported
on xulrunner or do I need to wait just a little more to upgrade firefox?
Are you interested also in gtk rendering issues? I noticed so far (using
mozilla's nightly builds of FF3) that the close buttons on tabs aren't
highlighted on mouseover action and checkboxes and radiobuttons seems to
have slightly wrong positioning when displayed on web pages. Also
widget's backgrounds seem to be derived from window's background, but
IMHO it should be derived from page element background it is on (but
this is really just a small issue).
Thanks,
Martin
2:58 a.m.
Martin Sourada wrote:
That's good news! Just some little questions. Has epiphany been
ported
on xulrunner or do I need to wait just a little more to upgrade firefox?
Epiphany in rawhide still runs with firefox-devel, xulrunner support
will be included in epiphany-2.22.
Are you interested also in gtk rendering issues? I noticed so far
(using
mozilla's nightly builds of FF3) that the close buttons on tabs aren't
highlighted on mouseover action and checkboxes and radiobuttons seems to
have slightly wrong positioning when displayed on web pages. Also
widget's backgrounds seem to be derived from window's background, but
IMHO it should be derived from page element background it is on (but
this is really just a small issue).
Please check if that issues are in the fedora package and when they are
not fedora related please report them at upstream. We generally don't
have an ability to fix all bugs.
ma.
6:43 a.m.
On 12/20/2007 09:41 AM, Martin Sourada wrote:
That's good news! Just some little questions. Has epiphany been
ported
on xulrunner or do I need to wait just a little more to upgrade firefox?
Christian Persch has a private branch that he's been working on that he
hasn't released yet, to get it to more or less work. He said he wants
to clean up the code for it, but it depends on when he feels like
releasing it. I'm not sure when that will be, but hopefully soon. :-)
Are you interested also in gtk rendering issues?
Getting linux type issues sorted is one of the reasons we're shipping
FF3 in rawhide now. Before it becomes final and "too late" to fix any
non-security/stability type things.
Please report bugs upstream since we're taking it pretty much as-is.
Additionally, please check any bugs you may have filed in RH bugzilla
about firefox 2, to see if they still exist in FF3.
I noticed so far (using
mozilla's nightly builds of FF3) that the close buttons on tabs aren't
highlighted on mouseover action and checkboxes and radiobuttons seems to
have slightly wrong positioning when displayed on web pages.
Please report it upstream, if you haven't! Nobody can fix it without
knowing about it. This is the reason it's a beta still.
Also
widget's backgrounds seem to be derived from window's background, but
IMHO it should be derived from page element background it is on (but
this is really just a small issue).
More upstream, please :-)
6:47 a.m.
On Thu, 2007-12-20 at 13:43 +0100, Christopher Aillon wrote:
On 12/20/2007 09:41 AM, Martin Sourada wrote:
> That's good news! Just some little questions. Has epiphany been ported
> on xulrunner or do I need to wait just a little more to upgrade firefox?
Christian Persch has a private branch that he's been working on that he
hasn't released yet, to get it to more or less work. He said he wants
to clean up the code for it, but it depends on when he feels like
releasing it. I'm not sure when that will be, but hopefully soon. :-)
> Are you interested also in gtk rendering issues?
Getting linux type issues sorted is one of the reasons we're shipping
FF3 in rawhide now. Before it becomes final and "too late" to fix any
non-security/stability type things.
Please report bugs upstream since we're taking it pretty much as-is.
Additionally, please check any bugs you may have filed in RH bugzilla
about firefox 2, to see if they still exist in FF3.
> I noticed so far (using
> mozilla's nightly builds of FF3) that the close buttons on tabs aren't
> highlighted on mouseover action and checkboxes and radiobuttons seems to
> have slightly wrong positioning when displayed on web pages.
Please report it upstream, if you haven't! Nobody can fix it without
knowing about it. This is the reason it's a beta still.
> Also
> widget's backgrounds seem to be derived from window's background, but
> IMHO it should be derived from page element background it is on (but
> this is really just a small issue).
More upstream, please :-)
OK, will do when I am at home :)
Thanks,
Martin
3:53 a.m.
Hi.
On Thu, 20 Dec 2007 09:22:46 +0100, Martin Stransky wrote:
Firefox 3 has finally landed in Rawhide. It's a slightly
unpolished
version and we appreciate if you test it and report all issues to
bugzilla (like missing locales, broken plugins and so on).
Does not start for me (says "Could not fild compatible GRE between version
1.9b3pre and 1.9b3pre"). I just pulled the firefox RPM from koji and
installed, so all deps are met.
3:58 a.m.
Ralf Ertzinger wrote:
Hi.
On Thu, 20 Dec 2007 09:22:46 +0100, Martin Stransky wrote:
> Firefox 3 has finally landed in Rawhide. It's a slightly unpolished
> version and we appreciate if you test it and report all issues to
> bugzilla (like missing locales, broken plugins and so on).
Does not start for me (says "Could not fild compatible GRE between version
1.9b3pre and 1.9b3pre"). I just pulled the firefox RPM from koji and
installed, so all deps are met.
Had the same problem. Seems like it needs xulrunner from koji as well.
After I installed that it starts fine (although most of my Add-ons are
incompatible).
Rgds.
Ola (T)
--
_,--', _._.--._____
.--.--';_'-.', ";_ _.,-' Ola Thoresen
.'--'. _.' {`'-;_ .-.>.'
'-:_ ) / `' '=. It is easier to fix Unix
) > {_/, /~) than to live with Windows
|/ `^ .'
4:22 a.m.
Hi.
On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote:
Had the same problem. Seems like it needs xulrunner from koji as
well. After I installed that it starts fine (although most of my
Add-ons are incompatible).
adding "extensions.checkCompatibility = false" to about:config got
some of them back (especially adblock, which is quite essential).
7:17 a.m.
On Thu, 2007-12-20 at 11:22 +0100, Ralf Ertzinger wrote:
Hi.
On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote:
> Had the same problem. Seems like it needs xulrunner from koji as
> well. After I installed that it starts fine (although most of my
> Add-ons are incompatible).
adding "extensions.checkCompatibility = false" to about:config got
some of them back (especially adblock, which is quite essential).
Does it work OK with java-icedtea-plugin and also flash?
--
Mike Chambers
Madisonville, KY
"The best lil town on Earth!"
8:03 a.m.
Hi.
On Thu, 20 Dec 2007 08:50:09 -0500, Jesse Keating wrote:
> Java-Applets that work with icedtea
> (even in Firefox 2).
Huh. Every java applet I've come across has worked in IcedTea.
Well, most of those I come across don't. Not that I care about Java applets
in general, but from time to time I look at the state of icedtea.
8:49 a.m.
On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote:
Huh. Every java applet I've come across has worked in IcedTea.
Sorry, but situation is not that rosy. Trivial applets
work, that's true, but more complicated (and interesting
ones) depend on LiveConnect, and those break badly.
In fact, for some cases the situation is worse than
not having Java, because it looks like its available
(and thus prevent a decent fallback), and when they
start they block/crash the browser.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
8:59 a.m.
* Dimi Paun <dimi(a)lattica.com> [2007-12-20 09:50]:
On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote:
> Huh. Every java applet I've come across has worked in IcedTea.
Sorry, but situation is not that rosy. Trivial applets
work, that's true, but more complicated (and interesting
ones) depend on LiveConnect, and those break badly.
This is being worked on. It's not trivial and there is no free
implementation at the moment. I'm sure Tom Fitzsimmons and others would
love help in this area if anyone is able to give it.
Andrew
9 a.m.
On Thu, 20 Dec 2007 09:49:49 -0500
Dimi Paun <dimi(a)lattica.com> wrote:
Sorry, but situation is not that rosy. Trivial applets
work, that's true, but more complicated (and interesting
ones) depend on LiveConnect, and those break badly.
In fact, for some cases the situation is worse than
not having Java, because it looks like its available
(and thus prevent a decent fallback), and when they
start they block/crash the browser.
How much of that is icedtea vs just not being java 1.5 or 1.4, given
that icedtea is 1.7 I think.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:49 a.m.
* Jesse Keating <jkeating(a)redhat.com> [2007-12-20 10:00]:
On Thu, 20 Dec 2007 09:49:49 -0500
Dimi Paun <dimi(a)lattica.com> wrote:
> Sorry, but situation is not that rosy. Trivial applets
> work, that's true, but more complicated (and interesting
> ones) depend on LiveConnect, and those break badly.
>
> In fact, for some cases the situation is worse than
> not having Java, because it looks like its available
> (and thus prevent a decent fallback), and when they
> start they block/crash the browser.
How much of that is icedtea vs just not being java 1.5 or 1.4, given
that icedtea is 1.7 I think.
None. LiveConnect is the java<->javascript bridge. Tom Fitzsimmons is
working on it.
Andrew
12:37 p.m.
On Dec 20, 2007 5:49 AM, Dimi Paun <dimi(a)lattica.com> wrote:
On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote:
> Huh. Every java applet I've come across has worked in IcedTea.
Sorry, but situation is not that rosy. Trivial applets
work, that's true, but more complicated (and interesting
ones) depend on LiveConnect, and those break badly.
All I know is, the realtime display java applet for the superdarn
radar system works... and that's all i need.
-jef"Now if I could just get the license of superdarn related C
libraries changed so I could re-distribute them, I could start
submitting packages to Fedora and work on a superdarn spin"spaleta
11:30 a.m.
On Thu, Dec 20, 2007 at 08:50:09AM -0500, Jesse Keating wrote:
On Thu, 20 Dec 2007 14:23:43 +0100
Ralf Ertzinger <fedora(a)camperquake.de> wrote:
> Java-Applets that work with icedtea
> (even in Firefox 2).
Huh. Every java applet I've come across has worked in IcedTea.
Citrix Java ICA client doesnt work with IcedTea. Worse, native ICA
client has bugs with seamless windows. Workaround is to disable seamless
windows.
--
Michael
1:48 p.m.
Jesse Keating Ãrta:
On Thu, 20 Dec 2007 14:23:43 +0100
Ralf Ertzinger <fedora(a)camperquake.de> wrote:
> Java-Applets that work with icedtea
> (even in Firefox 2).
>
Huh. Every java applet I've come across has worked in IcedTea.
Head in the sand, ostrich? :-)
Please try this link, a gaming site: http://jojatek.hu/indexold.html
At the left column you will find single-person games.
I tried some, none worked. Try e.g. REX at the end
of the page, both i386 and x86_64 Firefox/IcedTea
shows "Applet not initialized" after loading the applet.
Sun Java 1.6u3 works for the FF2/i386.
Best regards,
Zoltán Böszörményi
3:27 p.m.
On Dec 25, 2007 10:48 AM, Zoltan Boszormenyi <zboszor(a)freemail.hu> wrote:
Please try this link, a gaming site: http://jojatek.hu/indexold.html
do you have to register to play them? I don't understand the language,
so it's difficult to know
how to get to the games, just clicking on the title takes me to what
looks like a registration page.
In contrast, the free non-registation games I've tried listed at
http://www.java.com/en/games/
are working in IcedTea.
http://www.java.com/en/games/desktop/astrocrusher.jsp looks like a
great 5 minute time waster.
-jef
4:28 p.m.
Jeff Spaleta Ãrta:
On Dec 25, 2007 10:48 AM, Zoltan Boszormenyi
<zboszor(a)freemail.hu> wrote:
> Please try this link, a gaming site: http://jojatek.hu/indexold.html
>
do you have to register to play them? I don't understand the language,
so it's difficult to know
how to get to the games, just clicking on the title takes me to what
looks like a registration page.
The button with the text "Belépés próbajátékra" should give you
the game without registering. It's something like "Enter for a trial game".
Registering has the advantage of keeping your own high scores, etc.
In contrast, the free non-registation games I've tried listed at
http://www.java.com/en/games/
are working in IcedTea.
http://www.java.com/en/games/desktop/astrocrusher.jsp looks like a
great 5 minute time waster.
-jef
8:10 a.m.
On 12/20/2007 02:17 PM, Mike Chambers wrote:
On Thu, 2007-12-20 at 11:22 +0100, Ralf Ertzinger wrote:
> Hi.
>
> On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote:
>
>> Had the same problem. Seems like it needs xulrunner from koji as
>> well. After I installed that it starts fine (although most of my
>> Add-ons are incompatible).
> adding "extensions.checkCompatibility = false" to about:config got
> some of them back (especially adblock, which is quite essential).
Does it work OK with java-icedtea-plugin and also flash?
To avoid answering everyone's "does it work with XYZ?" questions, I'm
going to suggest you try it and file bugs if it doesn't. :-)
9 p.m.
On Thu, 2007-12-20 at 07:17 -0600, Mike Chambers wrote:
Does it work OK with java-icedtea-plugin and also flash?
On two x86_64s, one running Fedora 7 and the other 8, it runs the
flash-plugin quite well (mostly YouTube) and IcedTea java plugin seems
to run this applet alright:
http://www.java.com/en/download/help/testvm.xml
Again, that's on x86_64.
--
Richi Plana
10:06 a.m.
On Dec 20, 2007 8:22 AM, Martin Stransky <stransky(a)redhat.com> wrote:
Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished
version and we appreciate if you test it and report all issues to
bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run
Firefox 3 on Fedora 8, too. Just download and compile the latest
xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install
firefox from rawhide.
There's one side effect of this update. The former firefox-devel package
has been removed from rawhide and gecko-libs 1.8 is no more shipped. All
packages have to run with xulrunner (gecko-libs 1.9) now.
If you're a package maintainer and your package already uses xulrunner,
please rebuild it against the new rawhide version. Xulrunner directory
has been changed and many gecko packages (if not all) are linked with
--rpath linker directive. As long as rpath is used you have to rebuild
gecko-libs based packages after each xulrunner change so please consider
to remove it. Gecko libraries are registered system wide by
/etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Happy testing&hacking! :)
Is anyone seeing issues with adding sites with problematic SSL cert
(self generated etc) to the exceptions list? I get the error "If you
still wish to add an exception for this site, you can do so in your
advanced encryption settings." but if I go into prefs -> advanced ->
encryption I don't see the option to add exceptions. Or am i just
looking in the wrong location. Other than that its excellent!
Peter
10:08 a.m.
On Thu, 20 Dec 2007 16:06:19 +0000
"Peter Robinson" <pbrobinson(a)gmail.com> wrote:
Is anyone seeing issues with adding sites with problematic SSL cert
(self generated etc) to the exceptions list? I get the error "If you
still wish to add an exception for this site, you can do so in your
advanced encryption settings." but if I go into prefs -> advanced ->
encryption I don't see the option to add exceptions. Or am i just
looking in the wrong location. Other than that its excellent!
You have to click on View Certificates.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
10:17 a.m.
> Is anyone seeing issues with adding sites with problematic SSL
cert
> (self generated etc) to the exceptions list? I get the error "If you
> still wish to add an exception for this site, you can do so in your
> advanced encryption settings." but if I go into prefs -> advanced ->
> encryption I don't see the option to add exceptions. Or am i just
> looking in the wrong location. Other than that its excellent!
You have to click on View Certificates.
Ah yes. So you do. So intuitive :)
Thanks for your help.
Pete
10:43 p.m.
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
[snip]
If you're a package maintainer and your package already uses
xulrunner,
please rebuild it against the new rawhide version. Xulrunner directory
has been changed and many gecko packages (if not all) are linked with
--rpath linker directive. As long as rpath is used you have to rebuild
gecko-libs based packages after each xulrunner change so please consider
to remove it. Gecko libraries are registered system wide by
/etc/ld.so.conf.d and rpath should not be necessary in rawhide.
But isn't it the case that the libraries in question do not have
soversions?
If the rpath is eliminated, how do we know when things really *do* need
to break?
--
Braden McDaniel e-mail: <braden(a)endoframe.com>
<http://endoframe.com> Jabber: <braden(a)jabber.org>
2:50 a.m.
Braden McDaniel wrote:
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
[snip]
> If you're a package maintainer and your package already uses xulrunner,
> please rebuild it against the new rawhide version. Xulrunner directory
> has been changed and many gecko packages (if not all) are linked with
> --rpath linker directive. As long as rpath is used you have to rebuild
> gecko-libs based packages after each xulrunner change so please consider
> to remove it. Gecko libraries are registered system wide by
> /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
But isn't it the case that the libraries in question do not have
soversions?
If the rpath is eliminated, how do we know when things really *do* need
to break?
gecko-libs 1.9 exports only frozen interfaces so ideally we don't need
to rebuild any package unless we move to a completely new gecko (firefox
4 ;-))
11:40 p.m.
Martin Stransky wrote:
Braden McDaniel wrote:
> On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
>
> [snip]
>
>> If you're a package maintainer and your package already uses xulrunner,
>> please rebuild it against the new rawhide version. Xulrunner directory
>> has been changed and many gecko packages (if not all) are linked with
>> --rpath linker directive. As long as rpath is used you have to rebuild
>> gecko-libs based packages after each xulrunner change so please consider
>> to remove it. Gecko libraries are registered system wide by
>> /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
>
> But isn't it the case that the libraries in question do not have
> soversions?
>
> If the rpath is eliminated, how do we know when things really *do* need
> to break?
gecko-libs 1.9 exports only frozen interfaces so ideally we don't need
to rebuild any package unless we move to a completely new gecko (firefox
4 ;-))
I don't find that rationale particularly confidence-inspiring. (Since
when did software development proceed "ideally"? ;-)
Are we sure there are no external symbols accessible from public headers
that aren't considered "frozen"? Or are we just sure that blessed
interfaces are frozen?
I don't like the idea of playing without a net here. soversions are how
we track backward compatibility; software that doesn't follow
conventions *should* be handled with the kind of caution that is
reflected in (for example) an rpath. It's a pain in the ass because it
breaks a lot. But it breaks *predictably*. I'm sure I'm as unhappy with
the rebuilds as anyone; but I *like* determinism *a lot*.
Do we have any statements of intent from upstream regarding these
issues? A commitment to change library names when frozen interfaces
change, perhaps?
--
Braden McDaniel e-mail: <braden(a)endoframe.com>
<http://endoframe.com> Jabber: <braden(a)jabber.org>
9:19 a.m.
Miro needs updating, I think.
(This is on f8)
--> Finished Dependency Resolution
Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package Miro
9:38 a.m.
Neal Becker wrote:
Miro needs updating, I think.
(This is on f8)
--> Finished Dependency Resolution
Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package Miro
And then there's this:
ERROR with rpm_check_debug vs depsolve:
Package devhelp needs libgtkembedmoz.so, this is not available.
Package devhelp needs gecko-libs = 1.8.1.10, this is not available.
Package devhelp needs gecko-libs = 1.8.1.10, this is not available.
5:12 p.m.
>>>> "NB" == Neal Becker writes:
NB> Miro needs updating, I think. (This is on f8)
--> Finished Dependency Resolution
NB> Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by
NB> package Miro
Unfortunately this isn't as simple as a rebuild, this requires
upstream changes to enable Miro to compile against xulrunner:
https://bugzilla.redhat.com/show_bug.cgi?id=393521
There's a minimal patch on that bug, but it's incomplete and will need
further work upstream to get it work properly (according to Martin
Stransky, xulrunner maintainer). I've filed this bug upstream:
http://bugzilla.pculture.org/show_bug.cgi?id=9370
but have had no response yet. (I'll try to bug the Miro maintainers
on IRC).
Many packages don't current compile out of the box against xulrunner
unfortunately and require patches and/or adding support from-scratch
in upstream, see the full list here:
http://fedoraproject.org/wiki/Releases/FeatureXULRunner
This will take a *lot* of work from various packagers to make sure
that F-9 works out of the box. With all the packages that used to
build against firefox and we should probably bug all those package
maintainers to test the various packages and/or report things against
upstream to give them time to fix them so these packages work
properly. Otherwise, I fear, Release Engineering will be forced drop
them from the next release (at least from the the final package list).
Alex
5:27 p.m.
Alex Lancaster wrote:
This will take a *lot* of work from various packagers to make sure
that F-9 works out of the box. With all the packages that used to
build against firefox and we should probably bug all those package
maintainers to test the various packages and/or report things against
upstream to give them time to fix them so these packages work
properly.
Since i maintain galeon, i got word from an upstream developer that
xulrunner is still not exactly in a nice state to work with. To quote
him: "I'm holding off on this until mozilla sorts out the microb
problem. Apparently a good chunk of the brokenness is due to a bunch of
unreviewed microb (the n800 browser) patches being committed. They claim
they are going to back them out. Hopefully after that, [galeon] won't be
so crippled.".
Galeon now compiles thanks to Martin's patch, but it still has a number
of issues and disabled features..
I know almost nothing about mozilla/xulrunner upstream development, but
I have to ask: it's not just them (the packages that depend on firefox)
that have to be ready for xulrunner, will xulrunner also be ready for
them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?)
Otherwise, I fear, Release Engineering will be forced drop
them from the next release (at least from the the final package list)
If it comes to that, I hope we can debate whether it should not be
xulrunner that gets dropped and firefox-devel restored (assuming that's
even possible).
-denis
3:06 a.m.
Denis Leroy wrote:
Since i maintain galeon, i got word from an upstream developer that
xulrunner is still not exactly in a nice state to work with. To quote
him: "I'm holding off on this until mozilla sorts out the microb
problem. Apparently a good chunk of the brokenness is due to a bunch of
unreviewed microb (the n800 browser) patches being committed. They claim
they are going to back them out. Hopefully after that, [galeon] won't be
so crippled.".
I know almost nothing about mozilla/xulrunner upstream development,
but
I have to ask: it's not just them (the packages that depend on firefox)
that have to be ready for xulrunner, will xulrunner also be ready for
them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?)
I hope this will be fixed before the final firefox 3 release. If you
have any serious problem please file a bug at bugzilla.mozilla.org (or
bugzilla.redhat.com and I'll move it upstream).
Things are still fresh and any feedback is highly appreciated.
If it comes to that, I hope we can debate whether it should not be
xulrunner that gets dropped and firefox-devel restored (assuming that's
even possible).
We are not going to ship two firefox versions (2 and 3). Xulrunner-devel
is generally a firefox3-devel package, there isn't any difference and I
believe all developers will be able to transfer their packages to
Firefox 3 (or xulrunner in our distro).
Martin
1:39 a.m.
Martin Stransky wrote:
Denis Leroy wrote:
> Since i maintain galeon, i got word from an upstream developer that
> xulrunner is still not exactly in a nice state to work with. To quote
> him: "I'm holding off on this until mozilla sorts out the microb
> problem. Apparently a good chunk of the brokenness is due to a bunch
> of unreviewed microb (the n800 browser) patches being committed. They
> claim they are going to back them out. Hopefully after that, [galeon]
> won't be so crippled.".
> I know almost nothing about mozilla/xulrunner upstream development,
> but I have to ask: it's not just them (the packages that depend on
> firefox) that have to be ready for xulrunner, will xulrunner also be
> ready for them ? :-) (i.e. with enough time for maintainers/upstream
> to port/debug ?)
I hope this will be fixed before the final firefox 3 release. If you
have any serious problem please file a bug at bugzilla.mozilla.org (or
bugzilla.redhat.com and I'll move it upstream).
Things are still fresh and any feedback is highly appreciated.
> If it comes to that, I hope we can debate whether it should not be
> xulrunner that gets dropped and firefox-devel restored (assuming
> that's even possible).
We are not going to ship two firefox versions (2 and 3). Xulrunner-devel
is generally a firefox3-devel package, there isn't any difference and I
believe all developers will be able to transfer their packages to
Firefox 3 (or xulrunner in our distro).
Ah i see, so the porting problems stem from the transition to firefox 3
(gecko 1.9), not so much from the the xulrunner packaging transition.
That makes sense, thanks.
Finally had a chance to try galeon on rawhide (tough to run rawhide on
vmware currently), unfortunately it segfaults on startup.
Maybe we should create a firefox/mozilla/xulrunner SIG, to bring
together the people that are comfortable around mozilla code ? The SIG
page could track the various porting efforts to gecko 1.9.
1:05 p.m.
On 12/23/2007 12:27 AM, Denis Leroy wrote:
I know almost nothing about mozilla/xulrunner upstream development,
but
I have to ask: it's not just them (the packages that depend on firefox)
that have to be ready for xulrunner, will xulrunner also be ready for
them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?)
As a maintainer of gecko-dependent packages, you're on the hook for
determining this. The code is still beta. If it isn't ready for your
application(s) to make use of it, you should make sure bugs get filed.
With either Mozilla or your package's upstream(s) or both. This is sort
of the whole purpose of sticking XULRunner in now... so we can find any
showstopper bugs and get them fixed.
10:42 a.m.
On Thu, 20 Dec 2007, Martin Stransky wrote:
Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished
version and we appreciate if you test it and report all issues to
bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run
Firefox 3 on Fedora 8, too. Just download and compile the latest
xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install
firefox from rawhide.
I have installed it on F8 and it seems to have brought back the annoying
behaviour of moving the Firefox window when opening a link. Is this
Fedora-specific?
3:09 a.m.
Adam Huffman wrote:
I have installed it on F8 and it seems to have brought back the
annoying
behaviour of moving the Firefox window when opening a link. Is this
Fedora-specific?
Please check the generic upstream version
(http://developer.mozilla.org/devnews/index.php/2007/12/18/firefox-3-beta-...)
1:19 p.m.
On Sun, 2007-12-23 at 10:09 +0100, Martin Stransky wrote:
Adam Huffman wrote:
> I have installed it on F8 and it seems to have brought back the annoying
> behaviour of moving the Firefox window when opening a link. Is this
> Fedora-specific?
>
Please check the generic upstream version
(http://developer.mozilla.org/devnews/index.php/2007/12/18/firefox-3-beta-...)
I was going to post about this, too (FF3 window popping up in the
virtual desktop that the user is in around the time a link is clicked),
but assumed that it had always been the behavior of the upstream version
of FF (including ver. 2) and that we were just applying patches to it in
Fedora to adopt a different behavior.
So that isn't the case?
--
Richi Plana
1:09 p.m.
On 12/22/2007 05:42 PM, Adam Huffman wrote:
I have installed it on F8 and it seems to have brought back the
annoying
behaviour of moving the Firefox window when opening a link. Is this
Fedora-specific?
This is a metacity bug[1].
walters added a patch to our rawhide metacity package, which ought to be
fixed in metacity-2.21.5-2.fc9.
[1] http://bugzilla.gnome.org/show_bug.cgi?id=482354
12:15 p.m.
I don't know what's causing this:
gcjwebplugin.cc:1045: thread 0x821fb0: Error: Failed to spawn applet viewer:
Failed to execute child
process "/usr/lib64/mozilla/plugins/../../bin/pluginappletviewer" (No such
file or directory)
So 2 things about this:
1) gcjwebplugin? I thought iced-tea replaced gcj.
2) Obviously that path is wrong - but I have clue where it came from
To make things complicated, I have nspluginwrapper installed. But, I expect
most Fedora x86_64 users also do.
12:50 p.m.
Neal Becker wrote:
I don't know what's causing this:
gcjwebplugin.cc:1045: thread 0x821fb0: Error: Failed to spawn applet
viewer: Failed to execute child
process "/usr/lib64/mozilla/plugins/../../bin/pluginappletviewer" (No such
file or directory)
So 2 things about this:
1) gcjwebplugin? I thought iced-tea replaced gcj.
2) Obviously that path is wrong - but I have clue where it came from
To make things complicated, I have nspluginwrapper installed. But, I
expect most Fedora x86_64 users also do.
After removing nspluginwrapper, the problem is removed. BTW, I was testing
using this page: http://www.java.com/en/download/help/testvm.xml
5:16 p.m.
For me it refuses to load any site until I change
"network.dns.disableIPv6" to "true"
So I propose to make this the default ..
6:43 p.m.
On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
For me it refuses to load any site until I change
"network.dns.disableIPv6" to "true"
So I propose to make this the default ..
Works fine for me without doing that. Let's not supposedly "fix"
things by crippling new functionality and discouraging adoption of new
technology, shall we? What is the real problem here? We should be
focused on fixing that instead.
6:46 p.m.
On Dec 23, 2007 1:43 AM, Chuck Anderson <cra(a)wpi.edu> wrote:
On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
> For me it refuses to load any site until I change
> "network.dns.disableIPv6" to "true"
> So I propose to make this the default ..
Works fine for me without doing that. Let's not supposedly "fix"
things by crippling new functionality and discouraging adoption of new
technology, shall we? What is the real problem here? We should be
focused on fixing that instead.
the problem is that it does not work with some ISP .. and thats not
something that we can fix that easily (well or we can try to add some
fallback logic)
8:44 p.m.
drago01 wrote:
On Dec 23, 2007 1:43 AM, Chuck Anderson <cra(a)wpi.edu> wrote:
> On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
>> For me it refuses to load any site until I change
>> "network.dns.disableIPv6" to "true"
>> So I propose to make this the default ..
> Works fine for me without doing that. Let's not supposedly "fix"
> things by crippling new functionality and discouraging adoption of new
> technology, shall we? What is the real problem here? We should be
> focused on fixing that instead.
the problem is that it does not work with some ISP .. and thats not
something that we can fix that easily (well or we can try to add some
fallback logic)
Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address locally
while your ISP won't respond properly to IPv6 -> IPv4 nat translation? I'd
suggest making sure your local network configuration has IPv6 disabled and see
if that firefox now does not care whether IPv6 is not disabled.
If your ISP misbehaves, try not letting IPv6 traffic out of your machine (don't
configure an address for the family). The application should not choose to try
and generate IPv6 traffic if it is not told you have IPv6 connectivity.
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
6:39 a.m.
Andrew Farris wrote:
drago01 wrote:
> On Dec 23, 2007 1:43 AM, Chuck Anderson <cra(a)wpi.edu> wrote:
>
>> On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
>>
>>> For me it refuses to load any site until I change
>>> "network.dns.disableIPv6" to "true"
>>> So I propose to make this the default ..
>>>
>> Works fine for me without doing that. Let's not supposedly "fix"
>> things by crippling new functionality and discouraging adoption of new
>> technology, shall we? What is the real problem here? We should be
>> focused on fixing that instead.
>>
> the problem is that it does not work with some ISP .. and thats not
> something that we can fix that easily (well or we can try to add some
> fallback logic)
>
Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address locally
while your ISP won't respond properly to IPv6 -> IPv4 nat translation? I'd
suggest making sure your local network configuration has IPv6 disabled and see
if that firefox now does not care whether IPv6 is not disabled.
If your ISP misbehaves, try not letting IPv6 traffic out of your machine (don't
configure an address for the family). The application should not choose to try
and generate IPv6 traffic if it is not told you have IPv6 connectivity.
well my ISP is connected to a wireless router and I got the
configuration over dhcp from the router. There seems to be indeed a ipv6
adress assigned to the interface in question (dunno why maybe because
the router does support ipv6 but the ISP does not).
nevertheless if ipv6 does not work it should atleast fall back to ipv4.
I know how to deal with this but I doubt that all other users affected
will be able to deal with it. And a webbrowser _must_ work out of the
box .. else they cannot even try to google for a solution etc.
12:51 p.m.
drago01 wrote:
Andrew Farris wrote:
> drago01 wrote:
>
>> On Dec 23, 2007 1:43 AM, Chuck Anderson <cra(a)wpi.edu> wrote:
>> the problem is that it does not work with some ISP .. and thats not
>> something that we can fix that easily (well or we can try to add some
>> fallback logic)
>>
>
> Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address
> locally
> while your ISP won't respond properly to IPv6 -> IPv4 nat
> translation? I'd
> suggest making sure your local network configuration has IPv6 disabled
> and see
> if that firefox now does not care whether IPv6 is not disabled.
>
> If your ISP misbehaves, try not letting IPv6 traffic out of your
> machine (don't
> configure an address for the family). The application should not
> choose to try
> and generate IPv6 traffic if it is not told you have IPv6 connectivity.
>
>
well my ISP is connected to a wireless router and I got the
configuration over dhcp from the router. There seems to be indeed a ipv6
adress assigned to the interface in question (dunno why maybe because
the router does support ipv6 but the ISP does not).
nevertheless if ipv6 does not work it should atleast fall back to ipv4.
I know how to deal with this but I doubt that all other users affected
will be able to deal with it. And a webbrowser _must_ work out of the
box .. else they cannot even try to google for a solution etc.
I agree that the primary browser *should just work*. But I do not think the
right path is to go and disable IPv6 entirely by default (in a hidden option)...
the longer this type of ad hoc 'fix' for ISPs that are not yet making the
conversion the longer the entire internet will suffer with it.
The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails
(and yes I know that is more work). In the meantime if it has an option to
'prefer IPv4' even if IPv6 is configured that might be fine, but I really
don't
think disabling it is a good option.
We still probably should not be enabling the IPv6 address unless requested by
the users (for which there is a very obvious UI option already right in the
network configuration), but that is a broader discussion that has happened a few
times before.
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
1:28 p.m.
On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
The correct fix is to make firefox fallback on IPv4 if an IPv6
address fails
(and yes I know that is more work). In the meantime if it has an option to
'prefer IPv4' even if IPv6 is configured that might be fine, but I really
don't
think disabling it is a good option.
We still probably should not be enabling the IPv6 address unless requested by
the users (for which there is a very obvious UI option already right in the
network configuration), but that is a broader discussion that has happened a few
times before.
A better fix (and one that other subsystems could use) is a program that
detects whether IPv6 will be a problem for the user and set a flag
somewhere global that programs can check or scripts can recognize and
thus set the defaults for programs like FF to enable or disable IPv6.
Cascade effect from a global config to a minor. After all, if IPv6 isn't
enabled in the Network layer, then applications shouldn't either.
It's an ugly solution for an ugly situation.
As for not enabling IPv6 by default, you'll find by going back through
fedora-devel archives that you'll find just as many IPv6 proponents for
the sake of enabling new technologies as you'll find anti-IPv6 for the
sake of security/not-installing-unneeded-functionality/etc. Can o' worms
for you.
--
Richi Plana
2 p.m.
On Dec 23, 2007 8:28 PM, Richi Plana <myfedora(a)richip.dhs.org> wrote:
On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
> The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails
> (and yes I know that is more work). In the meantime if it has an option to
> 'prefer IPv4' even if IPv6 is configured that might be fine, but I really
don't
> think disabling it is a good option.
>
> We still probably should not be enabling the IPv6 address unless requested by
> the users (for which there is a very obvious UI option already right in the
> network configuration), but that is a broader discussion that has happened a few
> times before.
A better fix (and one that other subsystems could use) is a program that
detects whether IPv6 will be a problem for the user and set a flag
somewhere global that programs can check or scripts can recognize and
thus set the defaults for programs like FF to enable or disable IPv6.
Cascade effect from a global config to a minor. After all, if IPv6 isn't
enabled in the Network layer, then applications shouldn't either.
It's an ugly solution for an ugly situation.
As for not enabling IPv6 by default, you'll find by going back through
fedora-devel archives that you'll find just as many IPv6 proponents for
the sake of enabling new technologies as you'll find anti-IPv6 for the
sake of security/not-installing-unneeded-functionality/etc. Can o' worms
for you.
I have no problem with ipv6 enabled by default as long as ipv4 only
networks still work whit out requiring the user to change a hidden
option. (as it did until now).
2:03 p.m.
On Dec 23, 2007 9:00 PM, drago01 <drago01(a)gmail.com> wrote:
On Dec 23, 2007 8:28 PM, Richi Plana <myfedora(a)richip.dhs.org> wrote:
> On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
> > The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails
> > (and yes I know that is more work). In the meantime if it has an option to
> > 'prefer IPv4' even if IPv6 is configured that might be fine, but I
really don't
> > think disabling it is a good option.
> >
> > We still probably should not be enabling the IPv6 address unless requested by
> > the users (for which there is a very obvious UI option already right in the
> > network configuration), but that is a broader discussion that has happened a
few
> > times before.
>
> A better fix (and one that other subsystems could use) is a program that
> detects whether IPv6 will be a problem for the user and set a flag
> somewhere global that programs can check or scripts can recognize and
> thus set the defaults for programs like FF to enable or disable IPv6.
> Cascade effect from a global config to a minor. After all, if IPv6 isn't
> enabled in the Network layer, then applications shouldn't either.
>
> It's an ugly solution for an ugly situation.
>
> As for not enabling IPv6 by default, you'll find by going back through
> fedora-devel archives that you'll find just as many IPv6 proponents for
> the sake of enabling new technologies as you'll find anti-IPv6 for the
> sake of security/not-installing-unneeded-functionality/etc. Can o' worms
> for you.
I have no problem with ipv6 enabled by default as long as ipv4 only
networks still work whit out requiring the user to change a hidden
option. (as it did until now).
one thing that I noticed:
ipv6 is NOT disabled in firefox 2 but it still works for me. So this
is a regression in firefox 3's ipv6/ipv4 handling.
1:14 p.m.
On 12/23/2007 09:00 PM, drago01 wrote:
I have no problem with ipv6 enabled by default as long as ipv4 only
networks still work whit out requiring the user to change a hidden
option. (as it did until now).
So if you are having problems, file a bug at https://bugzilla.mozilla.org/
3:17 p.m.
On Sun, Dec 23, 2007 at 12:28:37PM -0700, Richi Plana wrote:
On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
> The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails
> (and yes I know that is more work). In the meantime if it has an option to
> 'prefer IPv4' even if IPv6 is configured that might be fine, but I really
don't
> think disabling it is a good option.
>
> We still probably should not be enabling the IPv6 address unless requested by
> the users (for which there is a very obvious UI option already right in the
> network configuration), but that is a broader discussion that has happened a few
> times before.
A better fix (and one that other subsystems could use) is a program that
detects whether IPv6 will be a problem for the user and set a flag
somewhere global that programs can check or scripts can recognize and
thus set the defaults for programs like FF to enable or disable IPv6.
Cascade effect from a global config to a minor. After all, if IPv6 isn't
enabled in the Network layer, then applications shouldn't either.
It's an ugly solution for an ugly situation.
As for not enabling IPv6 by default, you'll find by going back through
fedora-devel archives that you'll find just as many IPv6 proponents for
the sake of enabling new technologies as you'll find anti-IPv6 for the
sake of security/not-installing-unneeded-functionality/etc. Can o' worms
for you.
There is no technical reason why we should have to choose between enabling
and disabling IPv6 in firefox. If it correctly follows the RFC 3484 for
DNS resolution then it would 'just work'. Applications which are correctly
written will use 'getaddrinfo' to resolve names. This will automatically
decide whether to return IPv4 addrs, or IPv6 addrs or both, and will sort
them in the order most likely to succeed. If you have only link-local
IPv6 addresses (which all Fedora installs do by default) then it will
*not* give you back IPv6 addrs since you can't reach them. Likewise if you
have a site-local IPv6 address, it will not give you back IPv6 addrs that
are out on the internet because they would not be routable. There's all
sorts of rules on prioritization, but the effect is IPv4 & IPv6 will always
be enable in the DNS lookup and apps should 'just work' whatever interface
address config they have.
http://people.redhat.com/drepper/userapi-ipv6.html
http://www.rfc-editor.org/rfc/rfc3484.txt
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
1:02 p.m.
On Dec 23, 2007 6:49 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
drago01 <drago01 <at> gmail.com> writes:
> For me it refuses to load any site until I change
> "network.dns.disableIPv6" to "true"
> So I propose to make this the default ..
You can't be serious...
Trying IPv4 first would make sense, but disabling IPv6 altogether?
disabling it seems to be too much .. but should atleast fallback to
ipv4 when v6 does not work.
3:28 a.m.
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
[snip]
Gecko libraries are registered system wide by
/etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Does this also mean that rpm can be smart and "Requires: gecko-libs" is
no longer necessary?
--
Braden McDaniel e-mail: <braden(a)endoframe.com>
<http://endoframe.com> Jabber: <braden(a)jabber.org>
5935
days inactive
5972
days old
58 comments
26 participants
participants (26)
-
Adam Huffman -
Alex Lancaster -
Andrew Farris -
Andrew Overholt -
Braden McDaniel -
Christopher Aillon -
Chuck Anderson -
Daniel P. Berrange -
Denis Leroy -
Dimi Paun -
drago01 -
Janina Sajka -
Jef Spaleta -
Jesse Keating -
Kevin Kofler -
Martin Sourada -
Martin Stransky -
Michael E Brown -
Mike Chambers -
Neal Becker -
Ola Thoresen -
Peter Robinson -
Rahul Sundaram -
Ralf Ertzinger -
Richi Plana -
Zoltan Boszormenyi