Author Archive

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.

So, after having dumped Mozilla Suite, the Mozilla Foundation is now pushing Thunderbird out to pursue its goal of an "open web" (understand: MoFo only cares about Firefox).

Why is it called the Mozilla Foundation, again ?

... is that more than one are likely to have the same crazy ideas.

When I started to play with xulrunner, which according to my oldest post in the xulrunner category would be near 2 years ago, I had this crazy idea (and here, when I say crazy, I almost think dumb) that it would be neat to have a window manager based on libxul, being able to display both "native" windows and XUL or HTML windows.

Indeed, it would be neat, as in web-2.0-hype or i-can-use-gmail-directly. But that would be so much impossible to secure, and introduce so many different new ways to compromise users...

Guess what... It now exists.

Update: Waw, the GUADEC keynote slides are really full of crap. My favorite ones are about "The Fox" : Good engineering practices and Small, extensible core.

Guess what happens when someone complains to ffmpeg developers that their software management and API suck. Well, he gets answered repeatedly to include a CVS snapshot of ffmpeg and link statically against it, "like everyone does". Splendid.

... is that more than one are likely to have the same crazy ideas.

A while ago, when I was fooling around with VMware ESX and wrote diskimgfs (which I hope to be able to release some day), I found another implementation of the same root idea (without partition level access, though) in dm-userspace.

A few months ago, Sam posted his code for a SSH/HTTPS port sharing program, idea of which had been on my mind since a few weeks earlier.

And now that I'm playing around with git, I was thinking about having a FUSE filesystem to access a git repository. Guess what, it already exists.

And it actually happens quite often. This is also one of the reasons there are so many implementations of the same things (another being the NIH syndrome).

I got the idea reading this question on the webkit-dev list, and from my recollection of the git documentation. Well, for the webkit case, the basic script I put up would be of no help because the tarballs don't contain all the files (plus, they use subversion, not git, so it would also require a long importing process). Anyways...

Considering how SHA-1 hashes of objects are created with git, it is actually pretty easy to generate a SHA-1 hash from a random (non-git) tree, and then, the corresponding commit. First, you have git-hash-object that helps you creating a hash for a particular object (though it's also trivial to do with sha1sum). For regular files, git-hash-object -t blob $filename is enough. For symbolic links, you have to read the link destination, and give it without a trailing character (be it the NULL character or a carriage return) to git-hash-object -t blob --stdin. For directories, you have to generate a tree "structure" by yourself and pass it to git-hash-object -t tree --stdin. I haven't bothered looking at other file types.

The tree structure can be guessed by either looking at mktree.c or at the output of git-cat-file tree $sha1 where $sha1 is the SHA-1 hash for a tree object. It contains 3 informations for each node in the tree : the file mode, with the same format as what stat() returns, except for some reason, permissions are 000 for directories and symbolic links ; the file name ; and the SHA-1 hash. These informations are written with the following format : file mode in octal ascii and no padding zero ("%o") followed by a space character, then the filename followed by a NULL character, and the binary form of the SHA-1 hash.

Nodes are sorted in a not-so-quite lexical order (take a look at base_name_compare in read-cache.c) and are not separated by any special character: the mode of a file just follows the SHA-1 hash of its predecessor.

With all this new knowledge, you should be able to write some code that would return the SHA-1 from an arbitrary directory. Okay, since you must be at least as lazy as I am, you can take the script I wrote.

Now, let's take a look at a real life case : what commit is the latest nightly snapshot for the linux kernel from ? First, download the latest snapshot patch and its baseline, and extract the whole. Then, run my git-hash-tree.pl script with the directory containing the extracted kernel as an argument. It will return, after a while, the SHA-1 hash for the whole tree. During this long process, you also have plenty of time to git clone linus's tree.

Once you're all done, you can search for the commit corresponding to the tree hash (let's call it $hash) with the following command :

git-rev-list --all | while read h; do git-cat-file commit $h | grep -q "^tree $hash" && echo $h && break; done


If you just followed these steps, you should just have spent a great moment having no result at all. There are actually 2 things that prevent this method to properly work with the linux kernel nightlies :

• The snapshot patches contain a change to the top Makefile that doesn't exist in the repository. You need to remove the -gitn from the EXTRAVERSION variable in the Makefile.
• git diff only includes diff headers for removal of empty files, so if you apply the snapshot patch with the patch utility (and you can't apply it with git-apply since you don't have a .git directory), empty files that were marked as deleted will still be on your tree. It happens with the current snapshot patch (2.6.22-rc7-git6): it doesn't remove include/asm-blackfin/macros.h.

Note this is a naive method, because I haven't dedicated much time going through git documentation and code to find better ways, if there are any. Also note it's pretty much worthless to do this with the kernel nightly snapshots, since a file containing the SHA-1 hash of the corresponding commit can be found alongside the patch.

I guess a similar method could be used with mercurial, though I could not find a documentation detailing what are the hashes calculated from (I've not searched a lot, I must say, but for git, it was just before my eyes).