Git: Only push some commits upstream

To me it happens quite frequently that I have several local commits (in a private Git checkout), of which I only want to push some upstream. One option is to use cherry-pick and extra branches. Today I found a more straightforward solution:

git push origin $SHA_OF_LAST_COMMIT:master

Git only pushes the commit specified by it’s hash sum and all it’s ancestors (on the current local branch) that aren’t yet upstream (on the master branch of the origin remote). Finally, git rebase -i can be used to consecutively rearrange the (local) commits you want to push. Much easier, no?

Two little Firefox search helpers

One thing I missed after switching from rekonq to Firefox are KDE’s web shortcuts. It turns out that Firefox allows something similar, you can set shortcuts for your registered search engines:

Nothing new so far, it turned out that the only thing I missed was a search for Novell Bugzilla entries and for openSUSE’s feature database openFATE:

• openSUSE Features Search
• Novell Bugzilla Search

When adding them to Firefox, you should set appropriate keyword shortcuts like in the above screenie. Then you can simply type ‘bnc 1′ or ‘fate 10000′ in the address bar and save some time

The times they are a changin’

Everything changes, so do our packages. But change needs to be explained in order to become relevant. Regarding packaging, this involves the art of writing good changelog entries. Here is an example from an otherwise very capable packager:

• Spec files updates:
• Changes in License.
• Updates in Group:, Summary: and %description entries.
• Updates in %build section for lib64 compilation.
• Minor other updates.

More often, a reviewer stumbles upon those classics:

• Fixed build
• Fixed dependencies
• Changed license to $FOO

These lines surely took some time to write but they explain only what was changed, not why. The ‘what’ is easily visible from the diff of the old and new package version (kindly provided by the Open Build Service), but it’s the ‘why’ that matters. Your benevolent Factory review team kindly overlooks such insignificant matters most of the time, but you may leave your users baffled. Changelogs usually serve a purpose, for the package reviewer it’s ‘Why should I take the time to look at this at all and why does it belong into Factory?’. For the user it’s simply, ‘Dang, yet another update, why’s that for?’. You better provide some good answers for those questions or your carefully crafted fix may remain misjudged. As a reference you may use guides that others have written. They’re mostly about VCS commit messages, but it’s the same thing:

• http://who-t.blogspot.com/2009/12/on-commit-messages.html
• http://lbrandy.com/blog/2009/03/writing-better-commit-messages

Happy changelog writing!

Importing Amarok statistics into Clementine

Recently, I switched from Amarok to Clementine for my daily music needs. Clementine is basically a port of the old Amarok 1.4 to Qt4 with some fancy features added. However, my old Amarok database is full of playcounts, scores and ratings for my music, so I wrote this little shell script to import it into Clementine’s SQLite database:  https://github.com/saschpe/amarok2clementine

It updates (i.e. overwrites) both scores and ratings and adds your old (Amarok) playcounts to the playcounts in Clementine. Note that it is not particularly fast as it uses neither MySQL’s nor SQLite’s C/C++ library interface but the respective command line tools instead. In case anything goes wrong, you will find a backup of your Clementine database in /tmp/clementine.db.backup. Enjoy!

Summer of Code approaches

As in the past years, Google’s Summer of Code is going to happen again and we’re currently collecting ideas for openSUSE. So if you want to support your favorite distribution or seek a way to getting involved more deeply, be sure to check out our GSoC info page.

Or, if you want it cross-distro, the awesome Build Service always needs some helping hands that are curious on how to expand it’s massive feature set . This includes adding support for currently unsupported distros like Arch Linux or Pardus as well as making it’s web user interface more social.

Feel free to add you ideas to our list and discuss them on our IRC channel (#opensuse-project on FreeNode).

I can haz groups in deh Build Service!

A new feature of the upcomming openSUSE Build Service release is the revised role management for users and groups in the web user interface:

As you can see, all the available roles are now directly exposed, allowing you to manage all users and groups for your project or package in one place. Currently, group creation is reserved to administrators, but that is likely to change soon. So for now you have to bug your local OBS admin if you need a new group.

On splitting strings

Splitting strings is cool, but most languages have their subtle differences in how it is done. The three contenders are JavaScript, Python and Ruby. As an example, suppose you’re getting a string in the form “type_role_name” and you want to split it into type, role, name. The little twist here is that ‘name’ can also contain underscores. Let’s start reversed, it’s an easy job in Ruby:

irb> type,role,name = "user_admin_john_doe".split('_', 3)
=> ["user", "admin", "john_doe"]


Ruby’s split method want’s to know how much pieces you want. Onwards with Python:

>>> type,role,name = 'user_admin_john_doe'.split('_', 2)
('user', 'admin', 'john_doe')


I prefer this style slightly, as you have to express how many splits you want. The mindset here is that when you’re saying ‘split twice’, you’re expecting that the last element may contain the remainder of the string. By contrast, when saying, ‘give me three pieces’, it is unclear whether you want the remainder or not. Besides that, both are equally cool. Last but not least, how to do it in JavaScript? Well, turns out it’s rather messy:

“user_admin_john_doe”.split(‘_’, 3)
["user", "admin", "john"]

Altough this is somewhat similar to Ruby (i.e. ‘gimme three pieces’), it continues to split and discards the remaining stuff. Furthermore, JavaScript doesn’t support multiple assigment (could also be called iterable unpacking), so you have to store the result into an array first and assign individually. But more importantly, how to get “john_doe”? Turns out that you have to fiddle with splitting off substrings:

str = "user_admin_john_doe"
type = str.slice(0, str.indexOf('_'));
str = str.slice(str.indexOf('_') + 1);
role = str.slice(0, str.indexOf('_'));
str = str.slice(str.indexOf('_') + 1);
name = str


Not exactly what I would call elegant but it does the trick. I’d say, it’s a draw game between Python and Ruby, whereas JavaScript failed big time

Getting the sources of your RPMs

According to the GPL, you have to provide the source code of any (GPL-licensed) software you distribute (i.e. package and publish). Traditionally, this is satified by Linux distributions in several ways. Like any other package management system, RPM metadata contains the URL of the upstream project that created the software. This is where the (unmodified) source code can be retrieved.

But, packaging almost always means modifying the original sources. This could be in order to add patches or to make it conform better to certain (distro-specific) conventions. Therefore, distros offer a download repository where you can fetch source RPMs, i.e. packages which distribute the modified sources (containing the spec file, patches and additional files).

However, out of curiosity or to contribute back, you may want to know where exactly your package is maintained and developed. Luckily, packages that originate from one of the many Build Service instances (like build.opensuse.org, packman.links2linux.com or build.meego.com) have that information:

% rpm -q --qf "%{DISTURL}\n" bash   obs://build.opensuse.org/openSUSE:Factory/standard/fd6e76cd402226c76e65438a5e3df693-bash

Now you can copy this URL into your browser, replace ‘obs:’ with ‘http:’ and you should see something interesting Well, this is gonna be part of the next OBS release, for now you have to modify the URL slightly further to use the OBS test instance (stage):

https://build.opensuse.org/stage/openSUSE:Factory/standard/fd6e76cd402226c76e65438a5e3df693-bash

Additionally, you could simply put the disturl into the Build Service search and it will come up with the same results. Now you can inspect the development history (revisions) of the package, see who did it and become a part of it! The only thing that is left would be a RPM patch allowing a saner syntax, like:

% rpm -q --disturl bash

Reclaim me blocks!

Ever wondered why your filesystems fill up so quickly and why those new discs aren’t as big as advertised? While the latter may have several reasons (measuring units, the metric system or just damn lies), it may also be just an overly precautious default filesystem setting. On Linux, every filesystem gets some 5% of the available blocks reserved for the root user. This way, you can still work on your machine even if you forgot to rotate your log files Changing this default to something more realistic on today’s big hard discs may come with a nice surprises. Here’s my laptops root partition before:

saschpe@minime:~% df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 168G 144G 16G 91% /


Now let’s do a courageous tune2fs changing this to 0.2% (more than enough to be able to login and remove logfiles):
sudo tune2fs -m 0.2 /dev/sda1

And check again:

saschpe@minime:~/download% df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 168G 144G 24G 86% /

How neat, 8 fresh new gigs of storage

Braindead Python packaging

As you all know, distributing and building packages with the openSUSE Build Service is easy and fun. The only party pooper is that you have to write a spec file to get your RPMs out there. Thanks to darix, we have a decent solution at least for Ruby packages: gem2rpm, a script which auto-generates RPM spec files for Ruby gems. Ever wondered why we don’t have something similar for Python? Well, I did so too. Thus, after a half a week of hackery, I’d like to introduce py2pack, my take on braindead Python packaging. Here’s how it goes:

Lets suppose you want to package zope.interface and you don’t know how it is named exactly or where to download from. First of all, you can search for it and download the source tarball automatically if you found the correct module:


$ py2pack search zope.interface
searching for module zope.interface...
found zope.interface-3.6.1
$ py2pack fetch zope.interface
downloading package zope.interface-3.6.1...
from http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.6.1.tar.gz


As a next step you may want to generate a package recipe for your distribution. For RPM-based distributions (let’s use openSUSE as an example), you want to generate a spec file named python-zopeinterface.spec:


$ py2pack generate zope.interface -t opensuse.spec -f python-zopeinterface.spec


The above command has the parameter “-t opensuse.spec”, which is also the default (and thus optional). Well, this seems to imply that you can generate other files (and rumor has it that Debian support is on the way, too)

Back to the topic, the source tarball and package recipe is all you need to generate the RPM file. This final step may depend on which distribution you use. Again, for openSUSE (and by using the openSUSE Build Service), the complete recipe becomes:


$ osc mkpac python-zopeinterface
$ cd python-zopeinterface
$ py2pack fetch zope.interface
$ py2pack generate zope.interface -f python-zopeinterface.spec
$ osc build
$ osc vc
$ osc commit


The first line uses osc, the Build Service command line tool to generate a new package (preferrably in your Build Service home project). The py2pack steps are known already. Finally, the package is tested (built locally), a changes (package changelog) file is generated (with ‘osc vc’) and the result is sent back to the Build Service for public consumption. However, depending on the Python module, you may have to adapt the generated spec file slightly. Py2pack is quite clever and tries to auto-generate as much as it can, but it depends on the metadata that the module provides. Thus, bad metadata implies mediocre results. To get further help about py2pack usage, issue the following command:


$ py2pack help


To demonstrate its capabilities, I re-packaged some Python packages that are in devel:languages:python. As you can see (when logged in to the Build Service), those package now build for all RPM-based distros we currently offer in the Build Service. Currently, you can download py2pack from the Python Package Index or install the package python-py2pack from the devel:languages:python repository.

Happy Python packaging!