More work on xulrunner
Xulrunner finally reached unstable on sunday, and it already needed some adjustments. I forgot a conflict, misnamed the libsmjs-dev package, the hppa assembler code got somehow duplicated, so xulrunner failed to build on hppa, and some preference files needed to be moved around the packages.
It also fails to build on alpha, but that's not my fault.
I also changed the way we identify a Debian built xulrunner in the user agent. I replaced the "Gecko/yyyymmdd" string with "Gecko/Debian/x.y.z.t-r". That has several advantages over the previous "Gecko/yyyymmdd Debian/x.y.z.t-r" string:
- It shortens the already long user agent string so that additions such as product name are not painful,
- removes pointless information (the date in the original string indicates the date of the build, not that of the API),
- keeps the
"Gecko"string (which some site might want, seing how Apple and Konqueror did put a"like Gecko"string), - and finally avoid confusion with other Debian release informations that may be present in the product specific part (I think Galeon puts one, for instance).
That needed 2 updates, because I realized in between that while you can set the general.useragent.product and general.usergagent.productSub variables, they are not actually taken into account until you change them a first time... The HTTP protocol initialization in xulrunner forces the respective values Gecko and yyyymmdd... I just completely removed that part of the code in xulrunner.
I took advantage of this needed fix to work even more on the package, enabling the typeaheadfind module, needed by galeon and epiphany, removing some old perl code that does nothing except producing useless errors during the build, and, last but not the least, enabling the "flat style" chrome, meaning that instead of being stuck in .jar files, everything is just here in a standard tree.
It appears upstream provides a way to build such trees (option --enable-chrome-format=flat to configure), but it's useless because it doesn't install the trees when running make install. In addition to that, the configure script still requires zip, even if it doesn't use it, except for some obscure .jar files in libnss, that are not installed either. So after disabling the build of these useless files and removing the zip strict requirement if we build flat chrome, and fixing the script responsible for installation of the chrome files, everything got much better.
These changes have been applied to firefox as well, so stay tuned, it's for next upload.
Having highjacked spidermonkey, I did some bug triage there as well. It appeared they could all be closed by the fact libmozjs0d is there. I still need to make some triage in my patches to xulrunner and send upstream those that I still have not sent, if they are of any interest there.
Apart from this xulrunner stuff, I also did some bug clean-up on libxml2 and libxslt, which I've been somehow neglecting for some time.
2006-02-22 21:06:21+0900
Both comments and pings are currently closed.
2006-02-22 22:51:48+0900
Unfortunately, Gecko/Debian/x.y.z.t-r is a malformed User-Agent.
How about Gecko/Debian-x.y.z.t-r?
2006-02-22 22:56:21+0900
Sounds like some excellent work. However, I’d like to point out a major issue with how you’ve structured the User-Agent field. You said:
However, this violates the HTTP specification for how the User-Agent field is structured. According to the specifiation, the user-agent consists of one or more product tokens or comments:
User-Agent = “User-Agent” “:” 1*( product | comment )
A product token consists of a product name and an optional product version, separated by a slash:
product = token [“/” product-version]
product-version = token
Note that the product name and product version are both of type “token”. Now, a token is defined as follows:
token = 1*
separators = “(” | “)” | “” | “@”
| “,” | “;” | “:” | “\” |
| “/” | “[” | “]” | “?” | “=”
| “{” | “}” | SP | HT
So a token must not include a separator, and “/” is a separator. Thus, your User-Agent “Gecko/Debian/x.y.z.t-r” violates the HTTP specification.
If you want to improve the current User-Agent, I suggest one of several alternative approaches. First, it may well be that things are relying on the build date based on the build date of well-known upstream releases; while that seems like a fundamentally bad thing to do, you might certainly want to avoid breaking it, so you could continue using the build date. Alternatively, you could use “Gecko/something_meaningful Debian/x.y.z.t-r”, which might certainly be more useful than build date; something_meaningful could be the upstream version number. If you really want just one product token, you could go with something like “Gecko/x.y.z.t+Debian-r”; that puts the Debian revision in there.
I personally feel that the best approach is to go with exactly what upstream provides, and simply append a product token for the Debian package.
2006-02-22 22:57:08+0900
Argh; it looks like your comments don’t permit the “pre” tag, so that’s slightly less readable than I’d hoped.
2006-02-23 01:03:35+0900
I’m sure you’ll find this blog entry worth a read ;-):
http://benjamin.smedbergs.us/blog/2006-02-22/debian-versioning-of-mozilla-libraries-harmful/
2006-02-23 02:29:21+0900
Dude, check out http://benjamin.smedbergs.us/blog/2006-02-22/debian-versioning-of-mozilla-libraries-harmful/
2006-03-03 17:47:11+0900
[…] The ugly. Some distribution people, notably Debian developers, outright hate us or insult us. This is part of a wider theme of upstream/downstream tension. Debian is by far the worst here and deserves to be singled out – their packagers routinely anger high profile developers, and the practice of subtly breaking software continues unabated. When autopackage 1.0 was released and we got a lot of media attention, one Debian developer implied that they would deliberately add autopackage runtimes modified against our wishes to their repositories. This behaviour is unacceptable, but is the status quo and as such is not seriously challenged. […]