![](https://secure.gravatar.com/avatar/5b0355767dcb0ac7cbe371bcefc4ee4e.jpg?s=120&d=mm&r=g)
On Sat, 19 Jul 2008 16:14:17 +0200 Tilman Sauerbeck wrote:
Brett Goulder [2008-07-18 18:15]:
On Thu, 17 Jul 2008 19:38:03 +0200 crux@crux.nu wrote:
commit d26eeec41f7ff4edb3ae4eeacc63e1ec23dd1a12 [...]
You bumped the wrong component. The point of separating firefox and xulrunner was so that engine bugs (I.E. this one) could be fixed by bumping xulrunner, not firefox.
Gnnn, how very misleading that Mozilla didn't decide to put up a new xulrunner tarball :x
It's fixed now, thanks for the heads-up.
Regards, Tilman
Perhaps the most annoying thing about their current way of packaging their source-code is the lack of xulrunner-only and firefox-only tarballs, which would be very nice. P.S. I did file a bug about this (now resolved) issue as well as the general bad-setup that comes with Firefox by default, FS#334. I suppose it can be closed, but I think the problems pertaining to Firefox's retarded application.ini should be discussed, in my experience, using a 3.0 frontend (Firefox) with xulrunner 1.9.0.1 works fine. However, some may wish to have both rebuilt every time you do a minor patch-release bump to xulrunner, I don't, so I'm hacking the application.ini in my firefox 3 repo, so as to resolve their idiocy. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc