Archive for the 'debian' Category

As MJ Ray reports, ftp.mozilla.org now has "Free software" Firefox tarballs. While they are truly free and don't contain the non-free logo nor Talkback, they are not Firefox either. Only the tarballs and the executables are named Firefox. The product itself is "Bon Echo". And the name is going to change at every major release. This is why we changed for a "static" name.

Someone in the "Why no Opera?" thread on the debian-devel list mentioned tkhtml/hv3, and how it passed the Acid Test (though he didn't mention if it was the first or the second Acid Test).

While it is a known fact that Mozilla doesn't pass the Second Acid Test yet (you have to use 1.9 alpha for this), it is also known that Safari has been for more than 2 years, and Konqueror, since version 3.5.2. So just to be sure, I gave it a try with WebKit (the one currently in unstable), and the results are... well, see for yourself.

This is what QtLauncher display, when the window is quite large, which is just perfect.

Now, this is what you get when the window is not so large, but still large enough for the whole thing to be displayed.

And what you get when you shrink the window more and more.

It goes further down when you shrink even more.

Sadly, the Gtk port is not as good.

It also does the "going down when shrinking" thing.

Update : Apparently, the "going down when shrinking" thing is a known "feature" of the Acid Test.

Update : The reason why the Gtk port is not fully passing the test is that while there is a KIOslave for the data url scheme, curl doesn't support it.

GyrosGeier has briefly talked about machine readable copyright files in Debian. I won't talk much more about it, except pointing out the current proposal, and my own first implementation on the webkit package.

Note that, huge as the source is, I didn't feel like listing copyright information file by file, but rather set of files by set of files, grouping all files under the same licensing terms. Even doing so, the copyright file is still more than 600 lines long. And well, obviously, the ftp masters didn't reject it.

Ars Technica has recently posted an article about the new Opera alpha release, with some Javascript benchmark results showing it is quite faster than version 9.23. It also goes to compare with Firefox and IE7, but omits some other not so unimportant browsers. I think the main reason is because they seem to have only tested Windows browsers. Sure, Safari has been released recently on Windows, but it is still quite marginal.

Anyways, I was wondering how all this was going under Linux, and also, how (good?) WebKit would perform compared to others.

So, I tried the same Javascript speed tests on various browsers under Linux on my laptop, which happens to be a Pentium M 1.5GHz.

And the winner is...

So, It seems the speed gain Opera got on Windows doesn't happen much on Linux.

An interesting result, is that Iceweasel, with a bunch of extensions installed, is slower than Epiphany, despite both using the same rendering engine and Javascript library. Running Iceweasel in safe mode makes it the same speed as Epiphany, though. So having extensions does not only clutter the UI, but actually has an impact on how fast the Javascript code in web pages is going to run.

And well, WebKit is the fastest for this testcase, though it stays behind Opera on some specific tests.

Thanks to whoever ftp-master who did the review and approval, WebKit is now in unstable. It has not yet been built on all architectures, but several FTBFSes have already shown up :

• on arm, because #if defined(arm) doesn't seem to do much with our toolchain, and because gcc doesn't pack a simple struct such as struct { short x ; } on arm, while it obviously does by default on all other architectures,
• on hppa, apparently because of a kernel bug,
• on s390, maybe fixable by using gcc 4.2.

I already fixed the arm issue in our git tree, but am waiting for the last buildds to keep up before uploading a new release, in case some other architecture would fail to build. I'd be very much thankful if some people with alpha, x86_64, ia64, mips, or powerpc machines could do some basic testing with /usr/lib/WebKit/GdkLauncher and /usr/lib/WebKit/QtLauncher and report any problem (BTS preferred).

Again, interested people are invited to subscribe to the pkg-webkit-maintainers mailing list.

Along with a new epiphany release using it as backend, I prepared a new WebKit snapshot, which is now waiting in NEW for some ftp-master attention. Unfortunately, while webkit now has the necessary symbols for back and forward buttons, it seems not to work properly. Scrollbars are also not yet displayed. I'll have to take a look at these some day, if upstream doesn't do it before me.

I also set up a git repository to hold the debian branch, following the already existing git repository tracking upstream. Note the filtered branch, which avoids the debian branch to contain what we don't ship, and reduce the download size from 100MB+ to roughly 16MB. I'll write more about this filtering in a few days.

Also, if you're interested in webkit and/or want to give a hand, you can subscribe to the pkg-webkit-maintainers mailing list. Everything is ready for team maintenance, so, don't hesitate ;).

If you want to track changes on the debian repo, there is also a pkg-webkit-commits mailing list where the post-receive hook sends the commit messages.

I finally uploaded the first release of WebKit to unstable. It will obviously need to go through NEW first, which might take some time.

There still is work to do, first of which being to correctly setup the git repositories. For the moment, there is only a git repository following upstream svn available on git.d.o. The branches are a bit messy, though ; I have to figure out why git-svn insists on randomly recreating the master branch... I supposedly removed the master branch to have the svn branch follow the git-svn remote.

Anyways, once it is sorted out, I'll set up a special branch to create our tarballs and from which we'd derive the debian branch (or not, this is not decided yet). This special branch will be a copy of the upstream branch with some stuff removed (see debian/copyright in the current packages source for a list of these).

Speaking of the package source, since NEW is not available, I made the packages sources and binaries available on gluck.

An important note: the version I uploaded is made from revision 24735 of upstream svn repository, which is from July 27. Unfortunately, to be able to build the first version of epiphany that includes webkit embedding (2.19.6) as is, webkit_gtk_page_can_go_forward and webkit_gtk_page_can_go_backward are needed, and these, while available in the API headers, only appeared in the source code on July 30.

However, I built a hacked epiphany with calls to these functions removed (which means back and forward buttons won't work properly), and made it available on gluck too. Be aware this version requires glib and gtk from experimental, which, I've been said, made all gtk/glib warnings fatal. That means all applications that usually fill your .xsession-errors log file are likely to crash with these versions.

You'll note integration is not yet perfect, biggest misfeature being the scrollbars missing, and some glitches such as the user agent (it is hardcoded in WebKit :-/), and the about window still saying it is based on Gecko ;)

I'll try to push a new version of WebKit soon enough.

Stay tuned.

I often see people posting on planet.d.o, or on some list, talking about how they rebuilt the whole archive to test whether X or Y. Don't you think it would be useful to have a somewhat buildd network to do such experiments or QA testing ? Or at least some infrastructure that would make it easy to do ?

For instance, I would like to do some build testing of the whole archive, with hooked dh_strip and whatever else could be necessary, so that it can be determined how many packages follow recommendations on policy 10.1 about debugging symbols. Problem is I am far from having enough resources to do this...

Update : Actually, it would probably be enough to check the result of builds with DEB_BUILD_OPTIONS=nostrip

Nicer, compared to previous version.

Following the current trend on planet... or not.

Ganneff, I could not agree more with you, especially since it matches what I first replied to aj's proposal. That went unnoticed, though.