Bug 851722

This is because a xulrunner-15.0-1.b6.fc19 got pushed in Rawhide, and as firefox-14.0.1-3.fc19 has a require line that just says: xulrunner(x86-64) >= 14.0.1-1.

It's too new xulrunner for our current version of Firefox in Rawhide.

The (annoying) work around for now is to:

1/ yum erase xulrunner
2/ Download and install (using rpm -Uvh <package>) a xulrunner 14.x from http://koji.fedoraproject.org/koji/buildinfo?buildID=346867.
3/ yum install firefox

Ahh, sorry for that, I didn't realize that rawhide has the automatic updates.

Added to rawhide.

I was hit by this problem Sunday, and used the procedure in #c1
to correct it. Just updated rawhide again, and firefox again
did not work, as yum update upgrade again to a xulrunner firefox
does not like.

Martin, with all due respect, I fail to understand why you closed this bug as fixed.  Your comment is not meaningful:

"Added to Rawhide"  <-- what have you added exactly?

Plus:

[root@paname ~]# repoquery firefox xulrunner
firefox-0:14.0.1-3.fc19.x86_64
xulrunner-0:15.0-2.fc19.x86_64

It would really help if you could actually test your packages on Rawhide before actually pushing them there.  Firefox is such a critical package, it would really be appreciated a basic functionnality like launching it and seeing it be launched be tested by the package maintainer.

I am sorry to state the obvious, but Rawhide actually does have users.  It's understood that things break in that distro, but frankly breaking in such obvious ways is quite frustrating.

Rawhide definitely needs more love from package maintainers.

I don't want to sound impolite, but we really need to test our packages on *each* distro where we push it.

http://koji.fedoraproject.org/koji/buildinfo?buildID=350925
http://koji.fedoraproject.org/koji/buildinfo?buildID=350628

firefox & xulrunner 15.0, you just need to wait until the repo gets updated. All rawhide builds are pushed automatically, I can't control updates like we do for other Fedoras. I added the conflict directive to firefox 15 which should prevent to update the xulrunner without appropriate firefox package.

Btw. Rawhide does not need users right now, F18 demands all the love.

(In reply to comment #6)
> http://koji.fedoraproject.org/koji/buildinfo?buildID=350925
> http://koji.fedoraproject.org/koji/buildinfo?buildID=350628

Thanks for this valuable information.

> firefox & xulrunner 15.0, you just need to wait until the repo gets updated.
> All rawhide builds are pushed automatically, I can't control updates like we
> do for other Fedoras. I added the conflict directive to firefox 15 which
> should prevent to update the xulrunner without appropriate firefox package.

Thanks.

> Btw. Rawhide does not need users right now.

I am sorry, but I disagree.  I think Rawhide always needs users.  If we do things properly and if we are more users to use it more regularly the feedback is going to help the coming Fedoras.  For instance, you said you added a conflict directive to Firefox 15.  That should help Fedora 18 too.


> F18 demands all the love

It would demand less love if we'd taken enough care to avoid breaking Rawhide uncessarily in the first place.

I know we are all very very busy.  Still, that shouldn't be a reason to make the life of Rawhide users (who are a great asset to us, Fedorans) more difficult than it ought to be.

Thank you for all your efforts.

Thanks, it now works after a rawhide update.

Currently I am using mostly rawhide, but have f17 in another computer, because I gave up on having sagemath packaged for f18 (https://fedoraproject.org/wiki/SIGs/SciTech/SAGE), but I have it mostly functional for rawhide, but not in a much trustable way (what is very desirable for a math software :-)  as well as some other dependencies to be reviewed at http://fedorapeople.org/~pcpa/sagemath/

Also, I was and still am used to running Mandriva cooker, so, too many years running bleeding edge :-)

One issue I noticed in some recent firefox/xulrunner update was that gmail became way too slow when selecting mail messages. Looks like some javascript issue, maybe running interpreted instead of jit'ed.

If you see any other issues please open a separate bug for that. If you suspect the JS speed test it with JS benchmarks (may be available on net).

Thanks. I tested some benchmarks and not much of a difference on rawhide and f17, on two different computers with almost same spec, but on f17 gmail works "as expected", while on rawhide, when clicking to select a message, it takes at least 2 seconds for it be selected, or unselected.
But it appears I am not alone http://productforums.google.com/forum/#!topic/gmail/g37QZfB67wU tried toying a bit with setup and restarting firefox, but no luck, and already using default on everything.
Funny enough, in f17 (i5 notebook) I am using:

firefox-15.0-1.fc17.x86_64
xulrunner-15.0-2.fc17.x86_64

and in rawhide (i5 desktop):

firefox-15.0-2.fc19.x86_64
xulrunner-15.0-2.fc19.x86_64

If I find some useful information I will report, for now it is barely usable, but I can use gmail in another computer...

I did some more testing, and with perf, it did appear to use most time in libsqlite3.so, after staying selecting/unselecting messages for some time to attempt to get it triggered.

[...]
 43.30%  firefox  [.] sqlite3VdbeExec                                          ◆
  3.80%  firefox  [.] sqlite3VdbeMemMakeWriteable                              ▒
  3.53%  firefox  [.] sqlite3BtreeNext                                         ▒
  3.37%  firefox  [.] _init                                                    ▒
  2.64%  firefox  [.] sqlite3VdbeCursorMoveto                                  ▒
  2.63%  firefox  [.] columnMem                                                ▒
  2.16%  firefox  [.] sqlite3_step                                             ▒
  2.05%  firefox  [.] sqlite3VdbeSerialGet                                     ▒
  2.03%  firefox  [.] sqlite3VdbeMemGrow                                       ▒
  1.96%  firefox  [.] sqlite3_value_blob                                       ▒
[...]

Testing with cleaning all cache or starting with a fresh ~/.mozilla did not help either.

But I found a way to make it fast again, just disabled the flashblock addon. I got used to that addon because in my older (single core) computer it would be almost impossible to access pretty much any site due to flash using way to much cpu...

This bug is about broken Firefox update problem and is already closed. If you like to report the performance issues please open a new bug.