I’m a supporter of mail encryption since I started using free software. At least, I sign all my own mails, with the exception of mails to people, who don’t know what an *.asc file is and might not open my mail for this reason.

By the way, my public gpg key fingerprint is:

F6A9 332D AA28 625E 59A8 F758 7BF6 0F4A 861B C3A3

I’m also involved in the CAcert project. If you want to get “assurced”, don’t hesitate to contact me, if you are in Berlin.

There is just one problem. If you want to sign all your mails, you have to type your hopefully long passphrase at least once[^1] for every single mail. If you get some encrypted mails from your friends, you have to type your passphrase for viewing mails, too. That’s not so nice. So were the gpg-agent invented, which task is to cache your passphrase for a given time, but it didn’t work for me - until today.

I followed the tutorial from the opensuse SDB with no success. Please note, that you might need to change the pinetry-qt to pinetry-qt4.

The solution, which works for me, was to copy the mentioned line to ~/.zprofile instead of .xinitrc, as I am using the awesome zsh.

I had a side project the last two weeks: Make the build service more fun to use.

No matter how much fun you have creating packages, if they don’t build, there is little point in using a Service that has Build in its name, no? So one of the major goals of the service is actually to help those that want to build packages as good as possible. But there is a problem:

Let me quote from the landing page of build.opensuse.org: “The openSUSE Build Service hosts 16,414 projects, with 107,691 packages, in 26,259 repositories and is used by 25,967 confirmed users.”. That are quite some high numbers – especially in the relation to the ~25 servers we have for actually building.

If you look at the build statistics of the last month (and this is just i586, x86_64 has around the same), you notice that there is not much purple in the “Busy workers / Idle workers” graphic:

Every 2nd weekend or so we have some pause where the servers actually idle around, the rest of the time they are usually under full load and it’s not exceptional that we have over 20,000 build jobs for said 25 servers at the same time. So if Sue comes wants to build her packages at that time, she competes with quite some other packages and she gets frustrated to still see “scheduled” when she goes away. So we use some algorithms in the so called dispatcher to distribute the power to the right packages.

Over years of its existence the dispatcher used the algorithm I would dub “Randomness with exceptions” – it would if the job’s filename matches a regexp and if so, preferred it, otherwise picked a random job. Such algorithms create some fairness if you have 28.000 users all active at the same time, because there is usually not a really good balance between those.

But with 2.0 this changed: we got load and priorities. A script of mine parses the logs of download.opensuse.org and counts how many users are for the repositories. From that I calculate priorities, so that repositories of interest to people get more build power than others. E.g. KDE:Release:45 for 11.3 is downloaded 65 more often than for 11.1, so the 11.3 packages should see more attention. For that the build service calculates how many workers were busy for the repositories and then allows a factor to lower that load while picking the next repository to build for. This is much more complex than “pick a random one”, but it lead to faster return times for those projects that see actual downloads (and new projects as they have no load registered). To give some fun for those actually working on their packages, we also lower the registered load if we see commits.

But there was one problem left: with so many projects registered you also have quite some that aren’t interesting at all. They are not downloaded and very often not even their maintainers care, e.g. for some testing subproject they created in 2009 and then forgot about it. But those repositories build against the often changing openSUSE:Factory and see rebuilds because of that. Those repositories had a very low load because they have few packages, so they are often preferred over projects that have a lot of packages.

To free up more power to recent changes, we now experimented with various ways. It turned out to be useful to look at the relation between since last source change in the project and time since the jobs are “scheduled”. From this we calculate a staleness penalty – when the job is freshly scheduled, it’s basically one chance for a worker for 2 months since the last commit to the project. But this chance rises quickly, the penalty gets smaller the longer the job is in scheduled. Even those projects that have no source commits are valid “customers” and deserve to be rebuild against the latest gcc from openSUSE:Factory.

So what does this mean to you as user of the OpenSUSE Build Service?

• Don’t add repositories unless you really plan to use it. I know that clicking the checkbox to also add all SLE versions is easily done, but remember this is build power and disk space on various mirrors you’ll be using
• If you really care for your project, it’s a good idea to fix build failures from time to time. You’ll get more build power in return
• If you plan to do a larger update of some package in your project and want to test the resulting packages building against it, it’s a good idea to disable all other repositories while you do so. The fewer build jobs you create, the lower is your load, the higher are your chances to get more build power
• Make your repository popular by telling the world about it. More users means more build power
• And last but not least: don’t get frustrated, remember there are almost 26000 other users

Since late July Banshee has had AmazonMP3 store integration, earning a 10% affiliate fee. We're proud to send all of that revenue to the GNOME Foundation. Here is the cumulative revenue breakdown per store:

That totals to about $1800 USD, all going directly to the GNOME Foundation! This accounts for about half of what GNOME has earned from Amazon in the last six months.

Our revenue has increased every month, too; in December we're on track for another record month! Find out more about Banshee...

I’m happy to announce LibreOffice 3.3 rc1 packages for openSUSE. They are available in the Build Service LibreOffice:Unstable project. They are based on the libreoffice-3.3.0.1 release. Please, look for more details about the openSUSE LibreOffice build on the wiki page.

The packages are based on release candidate sources but they have not passed full QA round yet and might include even serious bugs. Therefore they are not intended for data-critical usage. A good practice is to archive any important data before an use, …

As usual, we kindly ask any interested beta testers to try the package and report bugs against the product LibreOffice .

Known bugs

• unopkg crashes (bug #655912)
• shell wrappers are still ooffice, oowriter, …; we need to discuss the new wrapper names with other distros first
• some packages were not renamed, .e.g. OpenOffice_org-thesaurus, …; they are not built from the main LibO sources; we will do it later
• user configuration is stored into ~/.libreoffice/3-suse; we might try to share the directory ~/.libreoffice/3 after we fix the incompatible BerkleyDB; Well, we are not sure if it is enough and it is a good idea, so it will need some more testing
• GNOME quickstarter is started by default; you might disable it in Tools/Options/OpenOffice.org/Memory/Enable systray Quickstarter
• SLED10 build is not available; need more love

More known bugs

• Free Desktop bugzilla
• Novell bugzilla
• OOo issuezilla

Other information and plans:

The package are based on LibreOffice-3.3-rc1 sources. There are still some openSUSE-specific bugs that needed to be fixed. I hope that they do not break the base function, though.

We expect that rc2 will be needed within next two weeks. We will try to fix more openSUSE-specific bugs in the meantime…

Just recently I found again that openSUSE is not really positioned for some usecases. In my personal case that is especially the usage as a web/mail/dns/etc server on hosted environments. IMHO it just doesn’t make sense to roll out a distribution which is supported for only 18 months to a hosted system with limited access to it. I still have been doing that with previous openSUSE releases but it’s so annoying that I really regret it. Also the possibility to zypper dup doesn’t really fix that issue for different reasons. Anyway this post is not about whining about that fact or to explain why I don’t like to update these type of systems remotely every <= 18 months.

A possible solution?

Sometime last year there was a discussion about options for something like an “openSLE” or “openSUSE LTS” distribution. There is an external page where some outcome was documented here. The dicussions stopped mainly because of health issues of the main initiator. There was done some planning and voting on the different options but no real results ever happened (as far as I know). So I’m trying to resurrect that topic a bit once again:

The amount of work related to such a project is the critical part and therefore my proposal is to try to start off with a “lightweight” approach.

This would be something like an openSUSE LTS version. That means that the community would take over (security) maintenance after Novell as main contributor drops it out of official maintenance after around 18 months. This will likely only work for a subset of packages which were delivered with the original distribution but the focus might be on server services anyway. Using the openSUSE release which also is the base for SLE could help us a bit as the work is done anyway (some of the Novell employees who are also openSUSE community members would hopefully help us here?). There are quite some details to work out still but it could be doable.

While I think we wouldn’t need a lot of people we at least need some and the more the better.  We will bring that topic up again on opensuse-project@o.o as well. The main intention of this post is to get feedback if there is enough interest and contributors to do further planning. I’m very interested in hearing from you via comments, mailing lists or personal mail.

• openSUSE 10.2:  Start 40 bugs now we have 14 bugs left.
• openSUSE 10.3:  Start 162 bugs now is 87 bugs left.
• openSUSE 11.0:  Start 526 bugs now is 346 bugs left.