Archive for the 'debian' Category

The fact is, the 3.0 release is just exactly the same code base as version 3.0rc3, which only has a MacOSX-only fix more than 3.0rc2, which is what we have in unstable, already.

For 10 days now, I've had ADSL problems. Basically, there is something fishy somewhere between my end and the DSLAM. That can be anything, and for the moment, all I can do is wait for either my ADSL provider or France Telecom, whichever is responsible for the problem, to fix this. Anyways, my network connectivity is sometimes working (though quite slowly, especially on uploads), but more often not, with sometimes connectivity for a few seconds (enough to download small files or pop mail).

The glandium.org server being behind this ADSL line, it means that you're probably not able to see this post. Or maybe a feed-reader/planet/whatever got it while the line was somehow working. Note I've been able to setup another MX server, so that mail sent to my domain go somewhere I can fetch them. Don't worry about sending me messages, they will reach me. Just that it may take time for me to be able to see and/or answer them.

Anyways, the main downside is that it makes it harder to handle the upcoming xulrunner transition.

On the other hand, the upside is that I finally could take some time to work on ext3rminator again, basically rewriting the code from scratch for reasons I'll explain when it will be ready for a release. It's good to see that some new APIs in libext2fs, added since 2002~2003, when I first wrote ext3rminator, make some of the work easier. It's still sad there is nothing to handle reading the journal. Not that it's difficult (though not documented much), but that would downsize my code some more ;).

Update: It seems to be back to normal.

How do you see this message in python2.5 changelog:

* Add README.db4 describing the db4.6 -> db4.5 change (Steve Greenland). Closes: #469770.

when apt-listchanges has been broken by the db4.6 -> db4.5 change ?

I uploaded xulrunner 1.9~b5-1 yesterday, and today was webkit's turn, with an upload of svn revision 31841, which happens to be the last revision on trunk as of writing.

Thanks to Mark Rowe, the most problematic crashers I experienced with webkit while preparing this upload have been fixed in revisions 31821 and 31787. This had the side effect to delay the upload enough that we now have the benefit of improved SVG animations support, and CSS gradients.

For those who like numbers, you can take a look at the Sunspider results for xulrunner 1.9~b5 (running mybrowser ; very similar results to what I got with 1.9~b4), and Sunspider results for webkit r31842 (when you compare to previous results for webkit r27674, there are significant improvements).

For another kind of numbers:

~/git/xulrunner$ git diff upstream/1.9... | filterdiff -x b/debian/* -x a/configure | diffstat | tail -1
36 files changed, 507 insertions(+), 291 deletions(-)

Compared to:
~/git/xulrunner$ git diff upstream/1.9...1.9+b4-1 | filterdiff -x b/debian/"*" -x a/configure | diffstat | tail -1
53 files changed, 932 insertions(+), 466 deletions(-)

~/git/webkit$ git diff upstream... | filterdiff -x b/debian/* | diffstat | tail -1
1 file changed, 4 deletions(-)

Compared to:
~/git/webkit$ git diff upstream...0+svn27674-4 | filterdiff -x b/debian/* | diffstat | tail -1
17 files changed, 61 insertions(+), 18 deletions(-)

Somehow, I prefer to work on webkit...

I'm preparing a new upload for WebKit, which will be targetted at unstable. It is much easier to deal with than Gecko, fortunately, so it won't take several months to get something in shape. The main "difficulties" here is that I'm dropping the Qt WebKit package, since this will be provided along Qt, and the upstream build system for the Gtk port switched from qmake to autotools, which is not a really bad thing ; so, nothing impossible.

Note that switching to autotools also means using libtool, which means no way to use -Wl,--as-needed anymore :-/. Yes, libtool, by trying to be smart, puts it almost at the last position in the arguments list, making it useless.

It finally happened, sorry for the delay. 1.9b4 is currently being uploaded to experimental. Yes, I know, this is not 1.9b5, which was released a few days ago. This is because I wanted to do some more work on 1.9b5 and didn't want to delay the upload any longer.

Now, for the uninteresting statistics, following are the diffstats, excluding directory debian/ and configure:

for version 1.8.1.13-1: 113 files changed, 1393 insertions(+), 824 deletions(-)
for version 1.9~b4-1: 53 files changed, 932 insertions(+), 466 deletions(-)
for work in progress version 1.9~b5-1: 39 files changed, 848 insertions(+), 423 deletions(-)

(the latter will obviously evolve)

It smells like an april fool, it looks like an april fool, it tastes like an april fool, but it's not an april fool.

Would there have been a better day than today to announce such a great news ?

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won't be ready this week-end. It's always when you come closer to the goal that it gets farther...

And I still haven't decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue.

Considering we will more than probably have both schemes in use within reverse dependencies, I'm not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul... That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though.

I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI.

The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package.

I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast !

For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I'm planning to package a new Webkit snapshot soon after I'm done with xulrunner and Iceweasel, we'll see then how it performs.

While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn't crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0).

Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I'm testing on x86-64).

It's been a while I've not talked about my packages. I've been preparing a xulrunner trunk upload for a while now, and I must say that while I'm not totally happy with evolutions in Mozilla codebase, I do appreciate that a significant amount of the patches we were applying have been applied upstream. And even more will be applied when Firefox 3.0beta5 is released. I even got patches that were *not* in Debian to be applied. Thanks have to go to Reed Loden for all this.

Another nice thing on Mozilla trunk is that they finally stopped patching sqlite, which means we can now have Mozilla linked against the system one. It is even more important now that libnss uses sqlite, too.

And now that we have libcairo 1.5 in experimental, and recent enough nss and nspr in unstable (uploaded a few days ago, creating some mess with iceweasel, iceape and xulrunner), we have all the necessary bits to have (most of) the bundled libraries replaced by system ones.

The sad thing is they did implement APNG (animated png) in their bundled libpng, so, to have APNG support, we need to either patch libpng or use the bundled one. I'll see if I can just disable APNG for the moment.

I hope to be able to upload the package to experimental on saturday or sunday, based on the firefox 3.0pre4 codebase. Iceweasel should follow a few days later.