Open source project licensing

Whenever you decide to publish some code somewhere in the internet, you have to think about the license. For many of us not being lawyers, this is a rather random choice. Given what we’ve been told is best, we usually just use any GPL flavor or Apache, MIT or BSD and don’t spend much time on the matter. Trouble usually starts when you add 3rd-party dependencies to your code which have different licenses. At first, you wouldn’t care, you only need the functionality. But when it comes to distribution, problems may arise. There’s countless articles on how to mix and match various licenses, which one is compatible to the other, etc. One website I found particularly useful is www.tldrlegal.com. It presents licenses in a brief TL;DR form and allows to compare licenses. Most importantly, it also allows to combine licenses, i.e. what happens if your code becomes LGPL-3.0+ and Apache-2.0 licensed. A very helpful thing:

Going to FOSDEM

This weekend I’m going to FOSDEM together with the awesome SUSE bunch and my fellow Cloud colleagues. On Saturday, I plan to visit some of the DevOps talks whereas I’ll hang out  in the Cloud devroom for the whole Sunday. If you want to talk about OpenStack on openSUSE or SLES, look for some guy in a openSUSE shirt

OBS 101: How to treat packages with multiple spec files

If you have an OBS package containing multiple spec files, you may have discovered that OBS only builds the spec file matching the OBS package name. If you want to have the other(s) spec file(s) built, you should use a link, don’t use copypac!

For example, devel:languages:python / python-nose is a OBS package containing four (!) spec files. In this case, documentation building is separate because doc building dependencies (python-Sphinx) would create a build cycle. A second set of packages are Python3-related, because devel:languages:python builds both Python and Python3 at the moment. So we end up with the following list of spec files:

    python-nose/python-nose.spec
    python-nose/python-nose-doc.spec
    python-nose/python3-nose.spec
    python-nose/python3-nose-doc.spec

As you can see here, only python-nose.spec is build, so we have to do the following (on a command line near you, given you have the rights to do it in the project):

    $ osc linkpac devel:languages:python python-nose \
                  devel:languages:python python-nose-doc
    $ osc linkpac devel:languages:python python-nose \
                  devel:languages:python python3-nose
    $ osc linkpac devel:languages:python python-nose \
                  devel:languages:python python3-nose-doc

Even though you end up with four OBS packages, you only have to change or fix python-nose due to the links. This is better than using copypac (as I’ve seen recently). Of course you should only split up into several spec files if there’s a very good reason for the extra work. Here are some:

• To avoid build cycles
• To off-load looong-running parts of a package build, like:
  • Running a testsuite ($PACKAGE-testsuite.spec)
  • Building documentation ($PACKAGE-doc.spec)
• When building the same thing against a different set of (build) requirements, like:
  • Different $DYNAMIC_LANGUAGE interpreter versions
    (usually $INTERPRETER-$PACKAGE.spec)

Lastly, to make sure other people branch from the right package, you should set the “base” package as the devel package of the linked ones like this:

    $ osc changedevelrequest devel:languages:python python-nose-doc \
                             devel:languages:python python-nose
    $ osc changedevelrequest devel:languages:python python3-nose \
                             devel:languages:python python-nose
    $ osc changedevelrequest devel:languages:python python3-nose-doc \
                             devel:languages:python python3-nose

This way, people always end up branching from python-nose when they try to branch python-nose-doc (or python3-nose / python3-nose-doc).  Thanks to vuntz for reminding me of the last point!

GNU screen window title and SSH

If you want to keep track of all your GNU screen sessions, it’s helpful to set the window title to the current machine you ssh‘d into. One way to achieve this is to put this into your .zshrc (.profile should work too):

# Set/reset hostname in screen window title SSH’d machine:
if [ $TERM = "screen" ] ; then
function ssh () {
args=$@
echo -n -e “33k${args##* }33\\”
command ssh “$@”;
echo -n -e “33k${HOST}33\\”
}
# Set it initially for new windows:
echo -n -e “33k${HOST}33\\”
fi

There are other ways, too…

Official Last.fm scrobbler for openSUSE

Good news, the official Last.fm audio scrobbler is now available for openSUSE through the Packman package repositories.

Why do I care, you might question yourselves and you’re partly right, openSUSE already ships a big bunch of multimedia apps (like Amarok, Clementine and Banshee) that all have Last.fm support built-in. However, for all of those you need a paid account to use it for anything else than just scrobbling, but the official app (still) allows to listen to Last.fm radios (like My Recommendations) for free!

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