A few weeks ago I stumbled up on an old photo of my watch, an old Casio A300U, and today marks the 20th anniversary of that photo, so I took another one at the exact same time:
Sunday, May 30, 2010
Friday, May 21, 2010
Flattr taking off
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.
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.
Thursday, May 20, 2010
Death of a Pixel
My Canon A590 camera just lost one of its 8 million pixels on the sensor, so I did a little montage of its death:
Done with:
for i in *.JPG ; do echo $i; convert -crop 16x16+2610+1310 "$i" "out/${i}"; done
montage -background black -geometry 16x16+2+2 -frame 0x0 -border 0x0 -quality 85% *.JPG out.jpg
Done with:
for i in *.JPG ; do echo $i; convert -crop 16x16+2610+1310 "$i" "out/${i}"; done
montage -background black -geometry 16x16+2+2 -frame 0x0 -border 0x0 -quality 85% *.JPG out.jpg
Portal Review (PC)
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.
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
How to build an Ubuntu Package
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 dependencies
Before 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 work
You 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:
3. Native vs non-native packages
Deb 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 numbers
Version numbers for packages are build in the form of: UPSTREAMVERSION-DEBIANREVISION
UPSTREAMVERSION 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:
dpkg --compare-versions "0.1.2" ">" "0.1.2~svn123" && echo "Yes" || echo "No"
5. Where to store the debian/ directory
Deb 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:
6. Creating the initial debian/ directory
Once 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:
7. Fine tuning debian/rules
The 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:
override_dh_auto_install:
make install PREFIX="/usr" DESTDIR="$(CURDIR)/debian/xboxdrv"
To override the build process you would use override_dh_auto_build.
8. Building the package
If 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 package
To 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 environment
If 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:
sudo pbuilder update --components "main restricted universe multiverse" --override-config
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 repository
Once 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 packages
You 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 package
To finally use your finished and release package you just have to add the PPA to your apt sources, which can be done with:
sudo add-apt-repository ppa:your_username/ppa
sudo apt-get update
sudo apt-get install your_package
14. Getting your package accepted into the official Debian/Ubuntu repositories
[TODO]
Trouble
1. Figure out the dependencies
Before 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 work
You 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
3. Native vs non-native packages
Deb 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 numbers
Version numbers for packages are build in the form of: UPSTREAMVERSION-DEBIANREVISION
UPSTREAMVERSION 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:
dpkg --compare-versions "0.1.2" ">" "0.1.2~svn123" && echo "Yes" || echo "No"
5. Where to store the debian/ directory
Deb 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
6. Creating the initial debian/ directory
Once 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
7. Fine tuning debian/rules
The 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:
override_dh_auto_install:
make install PREFIX="/usr" DESTDIR="$(CURDIR)/debian/xboxdrv"
To override the build process you would use override_dh_auto_build.
8. Building the package
If 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 package
To 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 environment
If 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:
sudo pbuilder update --components "main restricted universe multiverse" --override-config
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 repository
Once 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 packages
You 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 package
To finally use your finished and release package you just have to add the PPA to your apt sources, which can be done with:
sudo add-apt-repository ppa:your_username/ppa
sudo apt-get update
sudo apt-get install your_package
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
Tuesday, May 11, 2010
Ubuntu Package Updates
I started building a few more Ubuntu packages over the last few days, so here is what's new:
The Gimp Double Toolbar packages got moved to a new PPA, so the URL has changes, new sources.list URL can be found at:
I also now provide packages for Galapix, xboxdrv and sdl-jstest:
More packages might follow over the next days, currently thinking about packaging the Supertux editor and all of Windstille.
Edit: construo and wordwarvi got added to the PPA, windstille and windstille-editor are now present as well. feuerkraft and netbrush are now in the repository too. Added netpanzer-editor.
The Gimp Double Toolbar packages got moved to a new PPA, so the URL has changes, new sources.list URL can be found at:
I also now provide packages for Galapix, xboxdrv and sdl-jstest:
More packages might follow over the next days, currently thinking about packaging the Supertux editor and all of Windstille.
Edit: construo and wordwarvi got added to the PPA, windstille and windstille-editor are now present as well. feuerkraft and netbrush are now in the repository too. Added netpanzer-editor.
Subscribe to:
Posts (Atom)