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!

# 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…

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 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?

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

• 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!

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!

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).