After realizing Iceweasel wasn't working properly on various Debian architectures, and spending time fixing that, this week a new cairo version triggered a longstanding bug which would kill Iceweasel when closing a tab. I think I got it fixed now, but what next ?
2010-02-25 18:09:54+0900
The Firefox logo, the very reason why Iceweasel exists, is now free as in speech. Its use is still limited by trademarks, but it is free.
The news is not entirely official, but apparently the change has occurred a year ago, and the license text for the branding hasn't been changed accordingly.
Waw.
Update: Now official.
2010-02-23 23:38:03+0900
This is it! xulrunner now builds and successfully runs the checks and xpcshell-tests on all release architectures, including arm, mips, powerpc and sparc, that were all failing 2 weeks ago. 2 patch pulled from upstream, 5 patches written and sent upstream, and several more as not quite successful attempts.
What puzzles me is that e.g. the arm issue in the test suite has been known upstream for a year, yet Firefox was released on maemo (arm) without it being fixed. I mean, it only took me a few hours (if you don't count the time lost waiting for the builds to end), starting with no specific knowledge of arm, and even less of jit compilers.
Anyways, this all means work on 1.9.2 can go on.
2010-02-23 08:29:36+0900
This is what would have happened if I had waited before uploading 2.0.3-2. Courtesy of dh_install --fail-missing and its non-handling of arch:any only builds.
2010-02-18 14:33:41+0900
In there, a lot are due to dh_auto_configure not doing the right thing for autoconf 2.13 generated configure files, others are due to make setting MAKEFLAGS to "w", which prevents make -s to do what I expected it to do, armel has yet another crasher in the test suite (*sigh*), and I broke mipsel with the mips patch.
1.9.1.8-2 should fix the first two, and allow me to debug the armel issue (I disabled the test suite to be able to have the buildds generate the binaries, as they are much faster than the porterbox). Mipsel will have to wait for 1.9.1.8-3.
This also means 1.9.2 is delayed. Again. (and upstream releasing Firefox 3.5.8 one day later than scheduled didn't help either)
Update: I stand corrected, the one responsible for MAKEFLAGS setting to "w" seems to be make itself, not dh.
2010-02-18 10:29:08+0900
(maybe)
After the two updates in the previous post, I got further and eventually fixed the root of the remaining problems on ARM.
It appears I got on the wrong track at the very beginning of the investigation. My first test was to disable the JIT compiler during the tests, and it didn't affect the result. I assumed from there that the JIT compiler was doing fine and wasn't involved. Which led me to believe the alignment of the stack at 32-bits word boundary instead of 64-bits was a standard behaviour. I turns out my first test itself was wrong, because I hadn't disabled the JIT compiler at all. You need to modify the runxpcshelltests.py script to disable the JIT, and not fiddle with the javascript.options.jit.chrome preference.
The JIT compiler was misaligning the stack, and disassembling the generated code leading to broken behaviour revealed that it was doing so when setting up arguments on the stack for function calls. While I was afraid this would be difficult to fix without changing a lot of code, and first only disabled the JIT compiler, it turns out the way nanojit works by compiling the last instructions first did make it straightforward to fix.
But ARM was not the only RC buggy architecture left after sparc and powerpc were fixed. MIPS remained. Alpha fails, too, but it is not a release architecture. Update: It appears hurd fails too, but like Alpha, it is not a release architecture.
So, while I didn't want to wait 50 hours for a build, I managed to execute a failing test with the last xulrunner-1.9.1 packages that got built (before I enabled the test suite) under qemu. And I was able to track down the origin of the bug: the xpcom layer that translate function calls between languages doesn't fill arguments correctly when they are smaller than 32 bits. While the code is adapted to the mipsel case, which is little endian, it doesn't work on mips, which is big endian. I came up with a patch that should work, and which I hope won't break mipsel as a consequence. All that is left to do is to build and test the fix. I hope someone else will be able to do that for me.
All in all except a 1.9.1.8 release this week with a lot less red on the buildd status page.
2010-02-15 09:36:49+0900
That is a question I hear more and more, and I felt it had to be answered publicly. Short answer: when it's ready.
The current target for Squeeze is 3.5, for various reasons, but the main is that it shares the same Gecko version as Iceape (SeaMonkey) and Icedove (Thunderbird), which means that while the security team (or myself) will have to update these three for security updates, they will share patches. So 3.6 is less a priority than having 3.5 in shape for the release.
Last week, I wrote on a mailing list post that I was expecting 3.6 to come this week. Well, that was before I discovered the sad reality about the state of the current version.
But 3.6 is still on the radar. I already went through all the patches we apply on 1.9.1, and rebasing should now be straightforward.
Most of the 3.5 failures have now also been addressed: sparc and powerpc were fixed first, and I am now (re-re-re...-re)building on arm for, I hope, the last time. Unfortunately, mips is still missing, and without a porterbox, I can't do much. I tried, some time ago, in qemu, but there is no way I'm going to wait 50 hours for a build again ; it was already painful on a real arm box (where it takes 90 minutes just to link libxul.so). Anyways, 2 patches stolen from upstream and 5 patches sent (or almost sent for the one currently under validation) later, we should be down to one release architecture failing instead of four. Which is already good.
On the other hand, a new 3.5 upstream release, with security fixes, is planned for next tuesday, which means some time will have to be spent for stable updates, too. So, in the next few days, expect that I'll be working on stable security updates, then unstable updates, including the three architectures fix, and then work on 3.6 will continue.
Which means we can hope for a 3.6 release in experimental by the end of next week, or the following one, in the worst case.
Update: *sigh* 4 patches on arm is not enough :(. At least this time I think I'm done with xptcinvoke and xptcstubs.
Update:In the end, 2 patches and disabling the JIT compiler did the trick on arm. The 2 other patches were actually addressing bugs that only existed because the JIT is doing something wrong with the stack alignment.
2010-02-13 09:34:00+0900
When users upgrade Firefox, they are shown a special web page after restart. As this was obviously very Firefox oriented, this was disabled in Iceweasel. Until a week ago.
A week ago, I created a (quite raw) web page that users of Iceweasel 3.5.6-2 would see after they install or upgrade. The idea behind this page was suggested by Moritz Muehlenhoff during my BoF at DebConf 9, and consisted of displaying a call for help message in a splash screen. What most looked like this in Iceweasel is the Firefox feature mentioned above. I unfortunately wasn't able to implement it until now.
So, a week after these pages were put online and Iceweasel 3.5.6-2 was uploaded, even though I can't say it's a huge success, it at least led to some movement: More than 12000 users (still growing) saw the pages, out of which almost 1800 (roughly 15%) followed the link for a new logo. While there was no contribution for a new logo yet, there has already been several translations contributions for the web pages, in german, spanish and italian. Next iceweasel upload will consequently send users to a localized version of the web page when it exists.
The server logs also allow to have some figures on the usage of localized versions of Iceweasel, but as this is based on user agent strings, it is not totally accurate, though somehow interesting:
Another interesting figure is that apparently 2.4% of users haven't upgraded xulrunner-1.9.1 and are not using version 1.9.1.6 with their Iceweasel 3.5.6. I'm afraid of what this can mean for stable security updates, although, as being security updates, they may be followed better.
Somewhere around 7% of users have, at some point, changed their user agent string to include Firefox in it, because web sites suck. This is a very interesting figure because despite that being quite significant, we haven't got that many complaints (I'm not saying there weren't, but I would have expected more, considering the amount of users involved). Fortunately, this was changed recently, so all these users could reset their user agent string.
And last but not least, except amd64 and x86 users, we saw 14 powerpc users and 7 arm users.
2010-02-10 13:00:44+0900
The xulrunner test suite now passes on sparc, involving a fix for an existing bug, and a new bug report.
Next target is powerpc, where, interestingly, the test suite only failed 3 tests on the porterbox, where the buildd failed 58... And contrary to sparc, the failures don't involve crashes.
Update: powerpc is now fixed, too, with a little help from luck and good timing: the 3 failing tests had all the same origin, and it was fixed a few months ago in upstream trunk.
2010-02-05 19:40:25+0900
As part of preparing xulrunner 1.9.2 (which would lead to Iceweasel 3.6), I have gone through all the patches currently applied to the latest xulrunner release, to keep track of what should be upstreamed, what needed feedback, what patches I needed to update in upstream bugzilla, etc.
As I have talked about our differences with upstream on a few occasions already, and as I was doing this grunt work anyway, I thought it would be nice to make the results public.
First, a few reference numbers (excluding changes to generated configure files):
A few observations on the above data:
The latter used to be true, but is not anymore: xulrunner 1.9.1.6-2 added a lot of changes and is now up to: 98 files changed, 1107 insertions(+), 517 deletions(-).
What happened ? will you ask me. A lot happened: the test suite, attempts at correctly installing C++ headers and IDL files, bug fixes. Work has also been done such that make clean/distclean doesn't leave stuff around and that xulrunner can be properly built twice in a row.
Differences between 1.9.1.6-1 and 1.9.1.6-2 look like this: 31 files changed, 341 insertions(+), 167 deletions(-).
Some were stolen from bugzilla (13 files changed, 162 insertions(+), 70 deletions(-)):
Many others were sent:
make clean/distclean issues (10 files changed, 28 insertions(+), 15 deletions(-)):
A few others were filed without a patch, as I felt a proper upstreamable patch needed discussion (3 files changed, 16 insertions(+), 3 deletions(-)):
A few changes are related to the way we build and how we run the test suite (5 files changed, 35 insertions(+), 18 deletions(-)):
Finally, a few were related to the Debian changes history (2 files changed, 1 insertions(+), 26 deletions(-)):
Going through the rest of the changes between upstream and the latest Debian release, we can split in 5 categories of changes:
Those that were picked from upstream, or sent and eventually applied in 1.9.2 or trunk (12 files changed, 68 insertions(+), 41 deletions(-)):
Those that were picked from bugzilla or sent there, but are not applied upstream for various reasons (29 files changed, 138 insertions(+), 209 deletions(-)):
Those that were reported but for which I wanted feedback for a proper fix, yet a patch was applied in Debian because this was necessary (6 files changed, 22 insertions(+), 13 deletions(-)):
Those that are yet to be sent to bugzilla (15 files changed, 111 insertions(+), 54 deletions(-)):
And finally, the changes that are either Debian specific or not deemed upstreamable (30 files changed, 460 insertions(+), 77 deletions(-) ; this can sound huge, but see the details below):
Note, the numbers in the various diff stats obviously don't add up, since some changes overlap.
All that information doesn't account the few additional components added in debian/filemonitor and debian/extra-stuff, that account for nearly 600 lines (excluding licensing boilerplate), but I'll talk about these in another post.
This analysis also helped spotting another harmless merge error (the first one was spotted a few weeks ago and just left the --enable-system-lcms around, without any effect): a variable replacement in a Makefile that doesn't have any effect, since the 2 variables have the same value. Only a pointless 1 line change.
2010-02-04 12:52:14+0900
The contents of this site are licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Comments copyrights belong to their respective authors.