In this issue…

• 2010 Goals: Data Discussion - Today!
• Camino 2.0 alpha 1 now available
• Thoughts on Mozilla’s 2010 mobile goals
• Firefox Themes: Alex Faaborg on Firefox toolbar UI
• Six new localizations in Firefox 3.0.4
• Ubiquity Update
• Window Snyder on Mozilla security metrics
• Developer calendar
• Subscribe to the email newsletter

2010 Goals: Data Discussion - Today!

As part of the ongoing discussion about Mozilla’s proposed 2010 goals, Mitchell Baker will be hosting a public discussion about the privacy and data goals today, Tuesday October 28, at 1 p.m. Pacific Time. This discussion will be broadcast on Air Mozilla, and we’ll use the #2010goals IRC channel on irc.mozilla.org for asking questions. For more information, please see Mitchell’s blog post.

Camino 2.0 alpha 1 now available

Samuel Sidler writes, “After months of hard work following the release of Camino 1.6, the Camino Project is proud to announce the first preview release of Camino 2. Camino 2.0 Alpha 1 contains several notable improvements, including tab overview, full content zoom, better support for Full Keyboard Access in the browser window, and a ‘Recently Closed Pages’ menu. Camino 2.0 Alpha 1 also has all of the improvements in version 1.9.0 of Mozilla’s Gecko rendering engine, leading to better performance with popular plug-ins and enhanced support for web standards. For more information and to download, please visit our preview site.”

Thoughts on Mozilla’s 2010 mobile goals

Jay Sullivan has written an extensive blog post exploring his thinking about the possible 2010 goals Mozilla should have for its mobile work. “[T]he Web enables innovation and choice like no other platform, and for us to continue to act on our mission, we need to bring the capability for Web developers to build great software to mobile devices. To do this in a way that’s relevant, we need to address the needs of application developers and make the Web the best mobile platform that we can. A comparison with native capabilities is a good way to measure how we’re doing along that path. I hope that envisioning the Web as a mobile platform with this level of richness coming out of 2010 helps to drive a set of goals that we can rally around, and that we can make measureable in some way.” To read the full post and join in the discussion, head over to Jay’s weblog.

Firefox Themes: Alex Faaborg on Firefox toolbar UI

Alex writes, “When we were receiving feedback during the development of the Windows themes for Firefox 3, one question tended to come up a lot: Why are there three distinct visual styles of controls in the main toolbar?” Alex’s blog post explores the reasoning behind the Firefox 3 toolbar’s visual hierarchy, discussing why controls that are differently weighted are more useful and effective than equally weighted controls. It’s a fascinating post that delves into the depths behind some of the UI team’s decisions about Firefox 3 and the thoughts and theories that underlie the designs that were chosen. Read Alex’s full post at his weblog.

Six new localizations in Firefox 3.0.4

Seth Bindernagel writes that six new languages have been added to Firefox with the release of Firefox 3.0.4. The new languages are: Bulgarian, Esperanto, Estonian, Latvian, Occitan, and Welsh. “Congratulations to Ogi (bg), Eduardo (eo), Sander (et), Raivis (lv), Yannig (oc), and Dewi and David (cy) for all your hard work! Special thanks to Pike for driving the technical aspects of this release, Stas who managed the web services of this release, and Pascal on webparts. Finally, Gandalf stepped in sometime around 5 AM the day before the release to write a few patches and check in the code. It was a real team process.” For more information, see Seth’s blog post.

Ubiquity Update

Aza Raskin has announced the release of Ubiquity 0.1.2. “We’ve got an amazing amount of feedback about Ubiquity since its launch. One of the main points has been wanting features and bug fixes for the commands included in Ubiquity, as well as more commands. The largest update in [this release] is the ability for all of the built-in commands to be streamed in from the HTTPS-secured ubiquity.mozilla.com. Also, for those of you who are writing commands, we’ve greatly improved the Ubiquity command editor.” For a full list of the add-on’s changes, see the release notes on the wiki.

Window Snyder on Mozilla security metrics

Gen Kenai posts, “Robert Vamosi of CNet interviews Window Snyder, Mozilla’s chief security something-or-other, on security metrics at Mozilla and how we are trying to better understand security in an open-source project platform: At Mozilla, blowing the lid off security practices.” It’s an interesting interview in which Window discusses the difficulty of measuring security, the metrics we use at Mozilla, and the questions around why and how to measure security over time. You can read the original article and watch the accompanying video at the CNet news website.

Developer calendar

For an up-to-date list of the coming week’s Mozilla project meetings and events, please see the Mozilla Community Calendar wiki page.

Subscribe to the email newsletter

If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.

In my last post I mentioned that users of packages lacking a maintainer in portage should submit patches for the open bugs; while this is all good and fine, it is true that often there are bugs with patches that stays there to rot as well. I wish to point out here some things that might not be obvious to users as well as developers.

The first point I want to make is that it’s not like the problem is limited to user-submitted bugs and patches; bugs and patches submitted by developers can follow the same road too, waiting for months, if not years, before they are accepted and merged in. The problems here are many, some technical some social, some difficult to fit into a single category.

The biggest technical problem I can find is that there is no easy way to identify bugs which have patches waiting for review from a simple search. Modifying the Bugzilla workflow is probably a matter too complex to be worth it, but there is an easy way to avoid this, although it requires more coordination between reporters and assignees: using the “Status whiteboard” field to write “Patch waiting review” or something like that; the status whiteboard appears in searches by default, and would be useful to signal stuff like that (I used that to ask developers to signal me particular cases where gnuconfig_update couldn’t be removed).

Another technical problem is that maybe some developer is interested in fixing eventual bugs with patches for a particular package that lacks a maintainer, without becoming maintainers themselves; or an users would like to submit patches for the new bugs about a particular package. Adding themselves to maintainer-needed alias, or watching it, is most likely going to throw at them a huge amount of bug mail they are absolutely not interested in; I’m sure I sent some hundreds of bugs the m-n way in the last month (I’ll have fun watching the bug statistics on the next GMN), and I’m sure most people wouldn’t care of all those bugs.

The feasible way to handle this in the current infrastructure would be to set up bug whining filtering by package name in subject, but that’s not the nicest option I guess, although it is doable without changing anything. Another idea I got would require a huge effort from our infrastructure team and might not really e that feasible: creating multiple package name aliases; basically creating an @packages.g.o domain, and then creating dynamic aliasing for addresses like app-arch+libarchive@p.g.o so that it would then redirect the mail to the maintainer (developer or team) looking at metadata. This is of course a very complex solution, requires technical changes, and might as well be quite worse on other things, like for instance it would be a huge mess to search for all the bugs for a given herd, and would increase the amount of spam that each alias receive in a HUGE manner. On the other hand, the domain could be ste to only receive mail through bugzilla, and the addresses being otherwise invalid.

There are then some social problems, for instance there is the fact that Gentoo developers are volunteer, so you can’t force them to accept patches, or to improve submitted patches if they are not seen fit for merge in the tree. This means that if you want your patch to be merged in the tree you need to make sure you have a good case for it, and that you improve it as much as it’s needed for it to be merged, which might take an incremental amount of time. Of course not all users are programmers, but you cannot expect all developers to take charge of improving patches indeterminately until they can be merged, if they have no need for such patches. You can always try to find some person interested in helping out who can help you improve the patch; in the worst case you can resolve to pay someone to fix your patch up.

Also, most of the developers are likely swamped and might require some prodding to remember to take care of patches, and this is probably the heaviest showstopper; the only way to fix that is to join Gentoo and start improving the situation; of course it requires training, it’s not like we can accept every user as a developer, there are standards that one has to consider. Yes, I know there are some developers who not always live up to those standards, but that’s also a problem. I’m not saying that new developers should be perfect before joining, but they have to be open to critics and ready to learn; “works for me, it’s your problem” is not a good answer.

Does anybody have better ideas on how to fix these problems?

As reported in my previous post I am without a permanent internet connection. At this point a distributed version control system (dVCS) comes in handy, which most known variant is Git. Gentoo currently uses CVS which is a centralized VCS and needs a connection to the server to work properly and has some more disadvantages which you can find out about by your favourite search engine. For a long time people propagate a switch from CVS to a dVCS, but this is more easily said than done as we have dozens of tools which need migration, documentation and lots of other details (Git lacked some features we needed a while ago).

GNU Emacs upstream has the same problems, but the decision to switch has been made and the target will be Bazaar, one of the big three in dVCS business. Once some performance problems are sorted out, Emacs will center its workflow (branch merging has been really painful in the past there) around Bazaar...and so did I for my personal projects, after using Git for some time. Some aspects of Bazaar convinced me: It is really easy to learn, Git is a bit more cryptic and harder to grasp. And Bazaar has robust renaming where Git can get confused, learn more about it in a blog post by Mark Shuttleworth (yes, Bazaar is Canonical funded and also an official GNU project).

When Emacs upstream was discussing the switch there were three repositories of dVCS systems: tla (GNU Arch, obsolete and only used for branch merging as there was a CVS<->Arch interface), Git and Bazaar. The Gentoo Emacs team tested them regarding performance and usability and Bazaar was just sloooooow and we were really irritated by the final decision. But the situation is getting better as Bazaar is improving fast, Git still outruns it in some functions (you will find dozens of benchmarks on the net, look at the date), but everyday operation is very realiable und usable.

So we need a dVCS in Gentoo, people are working on it, though I think meanwhile that Bazaar would be the better choice. Hearing about exactly those renaming problems in Git overlays (seldomly but they are there), makes me think. And now my big but: The guy doing most of the migration work (robbat2) is really into Git, has invested lots of time, gained experience because of developer and project overlays. And Git is still a good choice in the end, especially its flexibility may proof useful for ends I cannot see now.

Another year is over, I finished my second year being a developer for Gentoo Linux. Some things have changed since my first summary one year ago. Most important of all (for me): I am no longer member of any architecture team due to personal changes, which I really pity. At the moment I have no constant net access, so I have to transfer all things I need for my desktop from my crappy laptop which I can connect at work to the world. Apart from those problems I try to do my best to still maintain Emacs and some other packages I still care for. Personally also some things have changed: My mentor and my recruiter left the project, and I near the statistical end of my term (as shown by Donnie Berkholz on LWN, cannot find the article at the moment), but I am not done yet. So expect me stick around for a while.

So if somebody was wondering why I haven’t written much lately, well, I spent the weekend with friends, and yesterday I picked up a new drug still, Unreal Tournament 3 at less than half the price (sometimes that shop has crazy low prices on stuff, I still don’t know how they do that). I used to be a heavy player of Unreal Tournament, to the point I was admin of an Unreal Tournament server, the first european server of the Thievery UT mod, too.

Anyway, I connected an extra keyboard and my trackball first to try UT3 out and.. it’s cool! The visual is much better than the good old Unreal Tournament when I started playing FPS seriously, and the response of the keyboard is not bad at all; I had to replace the trackbal with a mouse though since I couldn’t play with that (or with the gamepad), and now I’m getting my practice back. For the Gentoo developers out there playing UT3: time to get rolling with a tournament guys! :P

But even if I’m now playingone of my favourite games types, it does not mean I’m not continuing my work for Gentoo and free software; although I cannot connect to the Gentoo CVS server, because my ISp is probablty having routing problems, I left the chroot to build again a part of the tree so that it could check if something is going to break with linux-headers, especially in those bitrotting packages that lack a maintainer and most common users don’t use themselves.

Talking about bitrotting and packages lacking maintainers, last week I started filing bugs for packages that don’t respect CC and other variables by calling directly some common tools’ names, like cc, gcc, g++ and so on. Although I didn’t finish filing bugs (also because I noticed a trend in the bugs being often related to the same team of maintainers, and I wanted to give them a chance to proactively fix their ebuilds instead of waiting for the bugs to be reported), I got one idea that hopefully Zac will implement, if he hasn’t already by now: warning users for unmaintained packages.

When you install a package, explicitly, so not as a dependency, that is not actively maintained in the tree, it makes sense to warn the user of this, so that who merges it won’t find it strange if it does not build, work or if it’s so outdated that it nears uselessness. The idea is that if users start to see that the software they rely on is unmaintaiend, they can decide to either join Gentoo to maintain it or proxy-maintain it, or at least submit patches for the bugs that are open, or for the problems they do find.

Right now I’m testbuilding packages against linux-headers 2.6.27, although not a huge update, it might as well have problems, and then I’ll move on to gcc 4.4 (since 4.3 does not seem to build on that chroot right now it might as well be a good idea to try). While I’m sure automated testing that some developers are working on will be a nice thing, for nowI’m still glad I can do manual testing on my chroots, I think I’ll keep that way; adding to that I’m probably going to test for more respecting of chost-prefixed tools, like ld, ar and ranlib, and maybe if it’s no too noise to do, I would check for packages that force optimisation on even if the user requested -O0 (knowing that some software fails to build with -O0).

So while Yamato builds, I’ll take the rest of the night off, enoy!

This morning Earl Miles, also known as merlinofchaos, was named one of the 2008 Open Source CMS Most Valued People. Earl won specifically for his contributions to the Drupal project.

What is particularly exciting about this award is that Earl is the third Drupal community member to win an award for their contributions to the Drupal project this year. Bryan Ruby said it best.

What I found interesting is that most of the MVPs for projects were the projects' lead/founder. Perhaps that says something about Drupal truly being community driven.

Please congratulate Earl on a well deserved award for his contributions and leadership to the Drupal project. You can read Earl's response on his blog Angry Donuts.

Hi All,

My P4 laptop died recently, which is a pain as I now have to look at replacing it in the near future… however, this has meant I now have 2GB of DDR400 SODIMMS that can be used in the Lemote systems.

There was a catch however.  The PROM had to be flashed on one of the units so it would initialise the RAM properly, otherwise the kernel would b0rk.  With this done, both units now recognise the 1GB sticks of RAM installed.

At present, both systems are available for developer use.

How to upgrade the PROM on the Fulong.

For the reference of others who may wish to perform this upgrade on their Lemote equipment.  This is the procedure.

1. Download pmon_v1.1.zip from this page and unpack it.
2. Copy the pmon.bin file located inside, to your /boot partition (or somewhere else accessible to the PROM)
3. Reboot, and hit ESC/DEL repeatedly to break into the PMON prompt.
4. Type set, and write down any critical settings such as al and karg
5. At the PMON prompt, enter the following command (adjust:path as appropriate)
   load -r -f bfc00000 /dev/fs/ext2@wd0/pmon.bin
6. Restore the settings you wrote down using set arg value.
7. Type reboot to reset the system.

If at step 5, the load fails, DO NOT REBOOT OR POWER OFF! Hit the up-arrow on your keyboard, double check the command, then press ENTER to execute it again.

I’d like to thank the members of the Lemote Forum community who provided the necessary infromation.

Just a small note that compiz-0.7.8 has landed on a tree close to you.

After it was added on 2008-09-26 to the desktop-effects overlay, compiz-0.7.8 has now been committed to the tree. The 0.7.8 release is currently hard masked pending a final review, but should be unmasked in the next couple of days.

This version uses EAPI-2, so it will require a PM that supports EAPI-2 (currently that means a testing version from one of the 3 PMs). It's possible (preferred) to install compiz-fusion by grabbing the compiz-fusion set from the desktop-effects overlay sets dir.

package failures w/ gcc-4.4 on a barebones headless system:

gcc version 4.4.0-pre9999 built 20081025 (Gentoo SVN ebuild) rev. 141361 ()

dev-lang/perl-5.8.8-r5
dev-libs/cyrus-sasl-2.1.22-r2
dev-libs/glib-2.18.1
dev-python/dbus-python-0.83.0
dev-python/pygobject-2.14.2
dev-util/pkgconfig-0.23
net-misc/curl-7.18.2
sys-apps/busybox-1.12.0
sys-apps/coreutils-6.12-r2
sys-apps/dbus-1.2.3-r1
sys-apps/hal-0.5.11-r3
sys-devel/automake-1.9.6-r2
sys-devel/flex-2.5.35
sys-devel/gdb-6.8-r1

some of these may be testsuites that fail even with other versions (i'm looking at you coreutils and automake). i haven't looked at all of them yet but most i have are segfaults. only one (flex) is a bug, which i've already poked upstream about.

much less work than 4.3 so far. :D

When I wrote Ruby-Elf was mostly looking forward to learn about the ELF format itself and thus be able to understand more deeply the performance issues related to that. The choice of Ruby was so I could gloss over most of the tricks related to C programming, like memory management and error detection.

Over time, especially with the creation of cowstats first and missingstatic after, I thought that Ruby was a suboptimal language for what I’ve been doing; the ELF format was designed with C in mind, and indeed would map pretty well to C processing: you map the file in memory and access it as a single byte array. Pretty nice, but I couldn’t do it (easily) with Ruby. The way Ruby-Elf works is not by saving memory at all, instead it uses lots of memory, parsing and saving in memory all the information read from the ELF file. This has some disadvantages, but also some advantages.

In particular I was reminded of this today, after launching a scanelf process to look for some symbols in all the libraries of the system, I had it crash in front of me while trying to scan the debug files for libstdc++. It was trying to access an out of bound memory area since the file is actually partial (and has to be taken in consideration together with the other half in the stripped file; the fix has been committed to CVS and will be in the next pax-utils release.

But the point here is that with Ruby, such a problem wouldn’t have stopped me during my task, requiring me to put it on hold, start a new one (fixing scanelf) and then coming back to that. If something is broken in ruby-elf itself, most of the times the result is that an exception is raised, which can be rescued in the loop over the files to analyse, so that an error can be outputted to the user, and the processing resumes with the next file.

This is why I originally thought about learning Ada and converting my ELF analysis tools to that: it is compiled, so it should be faster than Ruby, but it’s also very well protected and will raise exceptions when problems are found. Unfortunately I haven’t had the time to learn it yet, which is very unfortunate since I’d really like to use it. For now I’ll have to keep working with Ruby and C, I guess.

One thing that I’m considering, though, is writing a C Ruby extension for byteswapping arrays; the reason for this is that it seems like the most time-consuming task in there is the byteswapping of data read from the ELF file itself.

I also have to consider the idea of implementing the ability of read compressed ELF files, but the fact that neither Zlib nor Bzlib2 have seeking functionalities makes it kinda hard (right now the code first reads through the file the offsets of the sections and then reads them as needed to avoid processing data that’s not going to be used, and to be able to properly identify sections by name when deciding the type.

At any rate, I might just decide to try out a basic scanelf reimplementation using Ruby-Elf for when I need stuff and I can’t wait to fix scanelf…

In my post about glib byte swapping functions I pointed out the inconsistent behaviour of glib’s macros for byteswapping, when it comes down to argument evaluation. If you look at the comments in that post, you can see that Paul points out that a very useful way to do the same thing without the problem of inconsistencies is simply to use inline functions rather than macro. I agree with him that it’s a much more useful thing to do.

Indeed, static inline functions, when the compiler supports them properly (which means, not with Sun Studio compiler), are quite better than macros: their arguments are evaluated just once, always, consistently, they have their own scope for variable names so that you can’t introduce a mystic error in your code by using the same name as a local variable in a macro, they leave the compiler free to decide what the best course of action is for them, for instance, in a loop, and so on. Additionally, they make debug a little easier than macros; when I fixed my problem with scanelf I had a segmentation fault inside a macro call for a 17 lines macro. Not exactly the nicest thing to debug (and actually made me quite wary of scanelf, I start not to like it too much, considered that complexity of the code), as you might guess.

So at the end I decided to go for it, and I submitted a patch to glib that replaces all the byteswapping macros with static inline functions; the code emitted is the same with GCC 4.3 but they are in my opinion more readable and they have more chances to work with non-GNU compilers (the previous implementation for them used the __extension__ keyword that as you might guess is a GNU extension, while static inline is a standard C99 feature).

Hopefully the patch will be merged soon, and at least the newer versions of glib will have a behaviour much more consistent with other libraries too. Now, if I can get to actually benchmark base64 encoding and decoding, and digesting through MD5 and SHA1, comparing glib with libavutil, I’d know what to look at for improvement.

Have you ever been thinking about how you could contribute to Gentoo? Here's a quick and easy way. If you are using stable, take a look at your package.keywords file and file stable request bugs for all the entries there that satisfy the requirements for being marked stable. Meaning there are no open regressions in http://bugs.gentoo.org and the ebuild has been in the tree for at least a month. Even better is if you make filing these bugs a regular habit. I would imagine that most developers are running ~arch so packages that are not that actively maintained might start to fall behind in stable.

I just released a new gentoo-sources 2.6.27 which includes linux patches 2.6.27.1, 2.6.27.2 and 2.6.27.3.

So….

Sync, emerge, make, install, reboot, wash, rinse, repeat.

As always, file bugs to http://bugs.gentoo.org

Hum, 2 blog posts in a week, this is highly unusual for me

Anyhow, back to the point.

About a week ago, I added the old i810 drivers (1.6.5 and 1.7.4) to package.mask. Since then, a few people have opened bugs and have sent me emails asking me to take them out of p.mask. I guess I owe an explanation to all who care about Intel drivers.

The situation is quite simple :

1. The old 1.x drivers are no longer maintained. Period. Upstream no longer cares about them and other distros (at least Fedora and Ubuntu) have started dropping the old drivers from their repositories.
2. Most importantly, starting with xorg-server 1.5, only 2.4.0 and up build correctly. So all drivers older than 2.3.2 do not work with xorg-server 1.5. I hope I made this statement clear enough.

I know that changing drivers can be a big pain, but there are only 2 good reasons for sticking with 1.x, I'll list them here because if you don't care about either, then you should move to 2.x.

• Old Xinerama support. XRandR is a very good extension but in some cases, the old driver was better. Especially with pre-915 chips where the framebuffer is limited to 2048 pixels in width.
• Unsupported chips. This one is very uncommon. In fact, I would say Gilles (eva) is the only one that has an unsupported DAC chip on his 830 tablet.

The rest of you, please try 2.x as soon as possible. If you still have issues, here's what you can do:

• Remove all HorizSync and VertRefresh from your xorg.conf
• Remove all "optimizations" from the Device section (such as forcing OffscreenPixmaps and what not)

If that still doesn't work, please open a bug and we'll try to sort it out.

Thanks

PS, I finally took care of the pkgmove. So please update VIDEO_CARDS in your make.conf to use "intel" instead of "i810".

Update: s/xorg.conf/make.conf/ ... thanks Donnie

Download Drupal 6.6
Download Drupal 5.12

Drupal 6.6 and Drupal 5.12, maintenance releases fixing problems reported using the bug tracking system, as well as critical security vulnerabilities, are now available for download.

Upgrading your existing Drupal 5 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement, more information on the 5.x releases can be found in Drupal 5.0 release announcement.

read more

A while ago I talked about piping all of my bash commands to twitter.com. I've kind of stopped doing that now, after I maxed out at over 14000 updates in about 2 weeks, but it was fun while it lasted.

But in order to do this kind of thing nicely, I ended up writing a command line program to make it easier. Some people have noticed it at times, by poking around in my kernel.org home directory, so I might as well announce the thing publicly.

So, consider this an announcement of the tool, bti. It allows you to send tweets to twitter.com or identi.ca directly from the command line from any Linux machine. It probably works on other systems as well, but you will have to tweak the Makefile yourself.

The latest version can always be found here.

The development for the tool is done in git, and the tree can be found on the ever-awesome github.com in this repository.

A long long time ago I voiced about the need for a wiki in the Gentoo project. In those days Gentoo-Wiki was starting up.
For some reason or other people inside the project felt that having the users producing documentation was a bad idea. For some other reasons that I never understood the gentoo-wiki.com becamed a banned issue, and Gentoo developers were advised not to mention, and not to link to him. I wrote an extensive article about Gentoo on the Efika board that got some raised eyebrows because it was written on the Wiki.

Now Gentoo Wiki has been down for a few days. And according to the backup page it does not seem a fix is going to happen soon.

If we had taken this project under an umbrella a long time ago our users would not be missing on this very important resource.

Registration for DrupalCon DC is now open and the DrupalCon DC website live. In the two hours after the first announcement went out via Twitter, 200 people registered to come to DrupalCon! Discount tickets are still available at $175 a ticket - about 200 are left now so move quickly to make sure you get the lowest rate available. Also, there are already 18 sessions submitted and voting has begun - create a profile to vote on sessions and submit your own.

read more

In this issue…

• Firefox 3.1 beta 1 now available
• Thunderbird “Shredder” alpha 3 released
• First Mobile Firefox alpha released
• Impact Mozilla: last call for submissions
• Localization schedule for Firefox 3.1 beta 2
• Discussing Mozilla’s proposed 2010 goals
• Developer tools and the Open Web
• Ubiquity: turning bookmarklets into commands
• Add-on developers: it’s that time again
• Developer calendar
• Subscribe to the email newsletter

Firefox 3.1 beta 1 now available

Firefox 3.1 beta 1 is now available for download. This milestone is focused on testing the core functionality provided by many new features and changes to the platform that are scheduled for Firefox 3.1. Ongoing planning for this release can be followed at the Planning Center, as well as in the mozilla.dev.planning discussion group, and on IRC in the #shiretoko channel.

New features and changes in this release include: web standards improvements, added support for CSS 2.1 and CSS 3, a new tab-switching shortcut that shows previews of the tab you’re switching to, improved control over the Smart Location Bar, support for the new video and audio elements, the addition of the W3C Geolocation API, JavaScript query selectors, web worker threads, SVG transforms, and improved support for offline applications.

More information about these features are available in several places including the Mozilla Developer Center’s Firefox 3.1 for Developers article, and in the Web Tech blog’s Overview of features for Web Developers post.

Thunderbird “Shredder” alpha 3 released

The third early release of Thunderbird (code-named Shredder) is now available. This release is called “alpha 3″ to emphasize its early nature and that it is not suited to regular, daily use. The alpha is available for testers, extension developers, and other people who are curious to follow the development of the next release of Thunderbird. Shredder Alpha 3 includes initial versions of some new features, and you can find more details on the release page and notes.

First Mobile Firefox alpha released

Mobile Firefox (code-named Fennec) has reached its Milestone 9 release, which is also its first alpha. The team is calling this the “User Experience alpha”, and it is targeted at the Nokia N800/N810 internet tablet. While great progress has been made on the Windows Mobile version, it is not ready for general use and is thus not included in this release. There are, however, new desktop versions of Fennec available, meaning you can now install the mobile browser on your Windows, OS X, or Linux desktop to see what all the fuss is about (and to help with testing and feedback, of course).

The Fennec Alpha 1 release notes include information about how to get started, how to install the browser, what’s new in this release, a list of known issues, and how to provide feedback. If you’ve ever been interested in getting involved with the Firefox Mobile project, now is a great time to install Fennec, watch the walkthrough video, and get started.

Impact Mozilla: last call for submissions

The Impact Mozilla community marketing challenge comes to a close on Friday October 24th, so this is your last opportunity to submit a one or two page idea summary. The purpose of this challenge is to help improve Firefox user retention. We know that tens of millions of people have downloaded Firefox but don’t continue to use it today. How do we get these past users back? How to we keep future users active once they’ve downloaded Firefox? If you have an idea about how we could solve this problem, we urge you to write it up and submit it through the Impact Mozilla website on or before this coming Friday.

Localization schedule for Firefox 3.1 beta 2

Seth Bindernagel has posted the localization schedule for Firefox 3.1 beta 2. The string freeze is going to be on Thursday, October 30 at 11:59pm (Mountain View time), which is just over a week from now. Code freeze will be Tuesday, November 4 at 11:59pm (Mountain View time). If you did not make Firefox 3.1 beta 1, we would love for you to participate in this next beta release. We have a goal of releasing a fully localized beta, so please let us know what we can do to help you get into the second beta. For more information and links to the localization team tools, please see Seth’s weblog post.

Discussing Mozilla’s proposed 2010 goals

Last month, Mitchell Baker posted a list of proposed goals she believes Mozilla should work towards achieving by 2010. Now Mitchell is looking to expand and continue the discussion around these proposed goals, and she has written a blog post outlining the next steps we’ll be taking towards ensuring that the whole Mozilla community has an opportunity to participate in the discussion and provide thoughts and feedback. “Mozilla has many groups of people who work together on particular aspects of Mozilla products, technology, adoption and mission. These groups are a natural setting for discussing the overall goals of the Mozilla project, and what motivates people to contribute. With that in mind, we’re planning a set of discussions to give more people a chance to participate comfortably. Some of these will be face-to-face meetings; others will be online discussions.” For more information about these smaller group discussions and other forums that are available for ongoing feedback, see Mitchell’s blog post.

Developer tools and the Open Web

Mozilla Labs recently announced the formation of a new group that will focus on the research and development of developer tools for the Open Web. “We believe that there’s tremendous opportunity for innovation in tools that increase developer productivity, enable compelling user experiences, and promote the use of open standards.” Dion Almaer and Ben Galbraith, co-founders of Ajaxian, the Ajax Experience, and long-time supporters of the Open Web have joined Mozilla in a full-time capacity to lead the new project. For more information, please see the Mozilla Labs blog post.

Ubiquity: turning bookmarklets into commands

Aza Raskin has put together a short video tutorial on how to turn your Firefox bookmarklets into Ubiquity commands. “Bookmarklets are clickable actions (technically a link containing some Javascript) that can be added to the bookmarks bar of your browser. They’re a good way of getting control of the web back into users’ hands, by allowing them to add whatever new functionality they want to the websites they visit. The main problem with bookmarklets is that they don’t provide a scalable solution for accessing their functionality. You can only have so many buttons on the toolbar before they become unusable.” There’s a new utility function in Ubiquity that makes it trivial to turn any bookmarklet into a Ubiquity command, and Aza’s video tutorial shows you how to do it.

Add-on developers: it’s that time again

Justin Scott writes, “With the release of the first beta of Firefox 3.1 comes everyone’s favorite release-time festivity: extension compatibility updates! If you’re an extension developer using a maxVersion of 3.0.* or less, please test your extension before declaring 3.1b1 compatibility. Some of the changes for extension developers are listed [at the Mozilla Developer Center]. 3.1.b1 is an allowed version on AMO, but 3.1.* will not be added until closer to final release. Keep in mind that you can always look at the Developer Statistics Dashboard to see how many of your users are on 3.1 betas and may be marked as incompatible/disabled.” For more information you should check out Justin’s blog post.

Developer calendar

For an up-to-date list of the coming week’s Mozilla project meetings and events, please see the Mozilla Community Calendar wiki page.

Subscribe to the email newsletter

If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.

here's a fun trap. if you're going to be changing major compiler versions often, you'll want to build lzma-utils with the nocxx flag enabled so you don't find yourself unable to unpack certain patch tarballs when you switch back.

i still don't understand why we even bother with lzma...