Friday, May 21, 2010

It seems like Flattr, the flatrate donation service is slowly taking off. The thing is still in beta, but when you subscribe for an invite, you seem to have a good chance of getting one. Currently they require a minimum monthly fee of 2€ for donation. This donation is then split across all the things whose flattr buttons you clicked and I think 10% go to the company as fee itself.

One issue I have with the current system is that it doesn't allow multiple clicking of the flattr button, which in turn makes the distribution seem quite unfair, as you sometimes flattr a single blogpost, while at other times you might flattr a complete blog or something else that is much larger then a single blogpost. This missing feature aside, it seems like a great idea and you can already find it in the wild. I spotted flattr buttons on http://taz.de/, on Chaosradio on lawblog.de and on spreeblick.com. The Flattr webpage itself also keeps a list of things you can flattr. And as you can see I added a few flattr buttons to this blog and to Pingus, Xboxdrv and some other things.

Update: I have some invite codes for Flattr.com, if you want one, drop me a mail.

Valve is currently giving away Portal for free for both Mac and Windows (only till May 24th 2010, so hurry up if you want it) and as I haven't played it before, aside from the first few levels in the demo version, I downloaded it and gave it a try.

Lets start with the bad things. The game is short, really short. I already knew that it was gonna be short and its to be expected to be smaller then a full game, but I didn't expected it to be this short. In just around three hours I was through the main game and it really ended up feeling more like an elaborate tutorial then a proper full game.

The graphics are also not all that great and while my not-so-great graphics card is certainly getting some of the blame for that, I have seen better looking and more fluent games then this. The game also suffered from quite a bit of noticeable tearing, that even with vsync didn't want to completly go away. The main issue in the end however is really the graphic design itself, which is for most part just blunt and boring. Some of that might be needed to not distract from the puzzles, but still, a few more interesting things couldn't have hurt.

The controls are a bit of a mixed bag. For one thing I very much welcomed that the game can be played with a gamepad and my Xbox360 controller worked right out of the box without configuration. But the text-hints in the game still showed keyboard commands, not gamepad buttons. Not a big deal in a simple game as this, but still distracting. The controls itself also suffered a bit more getting stuck on wall-edges, there where quite a few situations in the game where something had to be executed fast and I ended up needing multiple tries since my character ended up hanging on an edge instead of moving forward. Edges of course become an even bigger issue when you carry something. The game also reorientates your character when it comes upside down out of a portal, which while necessary, just felt slow and distracting, making it hard to target anything directly after you got out of a portal. An added issue is that the game doesn't have clear visual indications for up and down, so its hard to guess in which way the auto-reorientation will rotate you ahead of time.

The actual puzzling in the game isn't bad, but neither all that great. Maybe thats due to the game already being a little older and me having seen 2D flash versions of the mechanics, tutorial videos and all that stuff that describes the mechanics that thus the novelty already wore off long ago. But overall I simply felt that the whole game could be completed with just a small handful of simple patterns and most of the time the execution was more tricky then figuring out the solution. Another issue with the puzzles is that most or them are just boring to solve, as you are forced to do lots and lots of waiting for platforms, energy balls and other moving things and there is simply nothing fun in waiting for a platform to be at the right position.

The worst part of the game is, as typical for a Valve game, yet again the story or lack there of. Some people might like it, but for me the whole speechless hero thing is just annoying. A story should be there to give motivation and reason behind your doing, but here it is, quite literally, just paint on the wall.

After all this trashing, the game of course also has its good points. The core Portal mechanic is fun and especially the last level is pretty nice. As that level breaks with the rigid nature of the other Portal puzzles and thus feels more like fun improvisation, then tedious executing of switch puzzles. The graphic style also changes for the better in that level.

Overall however Portal for me is kind of in the "meh"-territory. It is not bad, but neither all that remarkable. It has its one-trick-pony game mechanic that is fun for a while, but doesn't really go much beyond tutorial style gameplay with it. The last level opens things up for the better, but after that the game is already over.

Update:I have now played two or three hours of the Portal - Flashgame mappack that Mathnerd314 has recommend, but I have to say that I am not all that impressed. It sure is a heigh quality mappack that gets very close to the quality of the original game, but its also just more of the same and the dialog is 100% recycled material. The puzzles mostly just get more annoying and not really harder. The electric ground just adds extra "standing around and waiting" time and the mappack is full of situations where you have to shot a portal to a wall far away that you can barely see, thus it becomes less about thinking your way through and more about just shooting the single place where the portal will stick. I haven't finished it and I am not sure I ever will.

Update 2: One annoying part of Portal that I haven't yet mentioned is the lack of cross-hair, that makes aiming quite troublesome at times, but it looks like Portal actually does have a cross-hair, just not when you use the gamepad. How come they haven't fixed that bug in all those years? Its not like a gamepad makes aiming somehow easier that you no longer need a crosshair, quite the opposite.

Thursday, May 13, 2010

The following text is meant to give a quick little overview on how to build a package for Ubuntu from preparing your source code to publishing the final results. The text assumes that you want to package a project of your own, so for packaging other peoples work, you can skip a few steps. It won't go into to much detail and leave out quite a bit, so have a look at the official manuals for anything not explained here:

1. Figure out the dependenciesBefore one starts with the actual package building, one should cleanup and fix the projects source code itself. This basically means getting a rough overview of what the dependencies are and which of those are already available in Ubuntu. If something is not in Ubuntu it either needs to be moved into the source tree or packaged separately.

2. Write a Makefile and make sure that all targets workYou need to make sure that your Makefile can not only build the project, but also install it and handle PREFIX and DESTDIR properly, namely the following targets should work:

./configure --prefix=/tmp/foobar

make install DESTDIR=/tmp/

make clean

If you are not using make, but some non-standard build setup, it can be useful to simply wrapper your build setup into a make file. This is not strictly needed, but can make things a little easier later on, see this example Makefile. You also need a way to build a proper tarball release file, I simply use git archive or svn export, but you can also make that part of your build system if you prefer, it doesn't really matter when it comes to building a .deb package.

3. Native vs non-native packagesDeb packages come in two forms, native ones and non-native ones. The core difference is that non-native ones come with an .orig.tar.gz, that contains the original source code, and a patch file, that contains your changes, while native ones just come with a single tarball. Native packages make only sense for things for which the .deb release is the primary and only release in existence, for software that is supposed to be released via a normal .tar.gz release a native package are never the right choice.

To make it short: You want to build a non-native package.

4. Version numbersVersion numbers for packages are build in the form of: UPSTREAMVERSION-DEBIANREVISIONUPSTREAMVERSION is the version number of your package, i.e. 1.2.3, while DEBIANREVISION is normally just an integer giving the version of your deb package. The package build scripts will take the version number out of the debian/changelog file.

For packages that are based on a development version directly out of SVN, Git, etc. you want a non-standard version number that smoothly integrates with official releases To accomplish that you have basically two ways "0.1.2~svn1234" and "0.1.2+svn1234". The tide (~) character is special in that it lowers your version number, not increases it, so "0.1.2" is larger then "0.1.2~svn1234", which makes this numbering scheme extremely useful for pre-releases, beta version and all that stuff that comes before a final release. The plus (+) on the other side increases the version number, so "1.2.3" is small then "1.2.3+svn1234". This is useful for cases where the next release is still far of, but SVN contains some small bug fixes that you want to package.

If you are not sure about version numbers, you can use dpkg to test them:

5. Where to store the debian/ directoryDeb packages are build by having some meta data and scripts in a debian/ directory in the source code of your project, however you do not want to have the debian/ directory to actually be in your repository. The reason for that is that it muddles the borders between Ubuntu specific hacks and your main source tree. Things are cleaner and easier when you keep them separate and all package build tools basically assume that.

Luckily you don't have to keep things managed manually git-buildpackage will do most of the work for you and automatically track what changes you do to the upstream source tree. So here is how it works:

build a normal tarball release of your source code

go to an empty directory (named ubuntu/ here) and create in that directory a directory named after your project, we need two levels of directories here since git-buildpackage will store files in "../"

go to ubuntu/project/ and call: git init

call: git-import-orig -u 0.1.0 ../../path/to/project-0.1.0.tar.gz

If you have done all that you can check git tag and git branch to see that git-import-orig has created a upstream branch and a master branch. The master branch is where you will do your work, the upstream branch is a copy of the content of your tarball, you should handle it as read-only and not touch it.

6. Creating the initial debian/ directoryOnce you have imported the upstream source into git, you can start creating the debian/ directory. dh_make is a tool that will provide some guidance in the process, but you can also just copy a debian/ directory from another project and modify it, which can often be easier. The following files are important:

changelog: This contains the version number of the package as well as a comment for the release

control: This contains metadata, such as the project name, a description, etc. the Build-Depends field is where you have to enter all the dependencies, the Dependencies for the binary itself can be figured out mostly automatically

rules: This is the Makefile that will be used to build the package, you might notice that the default one is extremely short, containing not much more then "dh $@"

copyright: This describes the copyright of the package

When using dh_make, make sure to change unstable to lucid in debian/changelog, as the former one would be rejected by launchpad (see below).

7. Fine tuning debian/rulesThe debian/rules script will call dh and automatically try to guess what build system your program is using and call the appropriated scripts, when things don't work, you don't need to get rid of dh, instead you can override steps of the build process. To override the install process you would simply add a target like this to debian/rules:

8. Building the packageIf you think the debian/ directory is finished, you can start to build the package. Go to the top level directory and execute:

git-buildpackage --git-ignore-new

Normally when your repository contains uncommited changed, the process would fail, but --git-ignore-new allows it to continue. When everything went well, you should end up with a bunch of packages in "../", if stuff went wrong, you should have gotten a easy to read error message.

When running git-buildpackage it will do a "make clean" before each build, which can be annoying when you try to find an error late in the build process, to work around that you can also simply call debian/rules binary directly.

9. Testing the packageTo test the package just install it with dpkg -i, you might also want to look at the content with dpkg-deb -c, if the build script contains a bug, its easy to have a few files gone missing, this way thats easy to spot.

10. Building the package in a clean environmentIf you have successfully build and tested your package, you are not done yet. You also want to make sure that it builds and works on a clean installation. Luckily you don't have to install a new Ubuntu or manually mess around with chroot, the pbuilder script will do that automatically for you. Simply apt-get install pbuilder and then call:

sudo pbuilder --create

Once pbuilder is finished downloading and installing the necessary components, you might also want to run:

This will allow you to not only use standard Ubuntu packages, but also things from universe and multiverse, which you will likely need for any more complex package.

Once pbuilder is completly finished the actual package building is just a matter of:

sudo pbuilder --build yourpackage_version.dsc

pbuilder will automatically grab all the build dependencies and build your package, if successful it will put the results in /var/cache/pbuilder/results/.

11. Building source packages and tagging your repositoryOnce you are completly done with the testing and building in a clean environment you want to finish up and publish your results, to do that you have to build a source package and while at it, you can also tag your repository automatically with the right version number with:

git-buildpackage --git-tag --git-builder="debuild -S"

12. Uploading your packagesYou don't want to upload a raw .deb, instead you want to provide a complete apt repository, luckily this process is completly automatic, all you need is create yourself an account at https://launchpad.net/ and upload your GPG key. Once done, you can simply upload your package with:

dput ppa:your_username/ppa package_version-1_source.changes

Launchpad will take the source code and build it automatically for i386 and amd64.

Note: I am not sure why dput wants sources.changes, while pbuilder is happy with .dsc.

13. Using your packageTo finally use your finished and release package you just have to add the PPA to your apt sources, which can be done with:

14. Getting your package accepted into the official Debian/Ubuntu repositories[TODO]

Trouble

Sometimes build files slip into the git repository, not sure when or why this happens, I guess it is at the git-import-orig step when you import into a non-cleaned working directory

Some files tend to constantly get in the way, namely .pc, debian/${yourproject}/, debian/${yourproject}.debhelper.log and debian/${yourproject}.substvars not sure why they get left over and not cleaned up