Postings by Mathias on March 7, 2008
Projector for GNOME Events Box
The GTK+ Hackfest has its first positive result already: The GNOME Events Box got a brand new DLP projector. Decision was made to buy one, since renting a projector for a week costs about 200 EUR, wereas you get entry level projectors for only 600 EUR. The Foundation's brand new projector was about 580,99 EUR - including shipment (projector with bag and cables, back side).
Incredible how much technology advanced since I had a projector into my own hands for the last time: It's "just" a 2400 Lumen projector, still it produces a clear and cripsy picture under day light conditions. Awesome.
I also like the fact, that Acer was that kind, to ship not only a German power cable, but also some british and a third one I cannot identify. It looks like an Euro plug with a third pin:
Update: Seems the third cable has a Swiss plug.
Launchpad's Personal Package Archives
Probably inspired by openSUSE's Build Service Launchpad provides this excellent Personal Package Archive (PPA) service.
It's quite exciting service: You just request your PPA, upload your source packages via dput command, and get them built within freshly setup Ubuntu environments. When building succeeds your packages are placed within some apt-get repository. No further maintenance steps required.
Unfortunately the service is not perfect yet: It seems to be driven by cron jobs and you only get feedback per mail. This makes the entire process very slow and inefficient. You have to find tiny tasks to fill up the 10 to 20 minute delays. Those tasks are rare, so at least I either end up idling/chatting or doing larger tasks. Very distracting. As a result it takes several hours until I know, that some PPA package is ready for use. I absolutely do not like this working style, I prefer staying focused on my current task, instead of wildly jumping arround between tasks.
Well, but this is just a minor annoyance, compared to the fact that PPA doesn't seem to allow you to delete/overwrite the upstream tarballs forming the base of your self-made Ubuntu packages. The idea of immutable upstream tarballs works nicely if you assume, that you aren't the maintainer of the software uploaded to your PPA: In that scenario you take an upstream tarball and apply patches until it works properly in Ubuntu, but you have no serious chance to modify the upstream tarball.
Things are different when you use PPA to publish software you maintain. In that case it happens, that you use PPA to package your release candidate and test it on your various Ubuntu VMs. During tests you spot minor show stoppers, commit fixes to your code repository, and run "make dist" to get another release candidate. After that you increase the PPA release number in debian/changelog and invoke "debuild -S -sa" to get the next interation of your Ubuntu package. Next step would be uploading that fresh package to your PPA, but that fails since suddenly the MD5 hash of your upstream tarball has changed. Of course! The bugfixes! Duh!
Only solution I've found so far: Skip an upstream release to make PPA happy. Not very convincing. Maybe the LazyWeb has some suggestions to work around that limitation?
Update: Yes, I didn't update the tarball's release number. It's just a release candidate. I'd expect a personal package archive to support release candidates. I prefer PPA over "debuild -i", since the build services attached to PPA provide a clean build environment.
