Yesterday PostgreSQL released new security/bug fix microreleases 8.4.2, 8.3.9, and 8.1.19, which fix two security issues and a whole bunch of bugs.
Updates for all supported Ubuntu releases are built in the ubuntu-security-proposed PPA. They pass the upstream and postgresql-common test suites, but more testing is heavily appreciated! Please give feedback in bug LP#496923.
Thanks!
PostgreSQL recently published new point releases which fix the usual range of important bugs (data loss/wrong results, etc.) and additionally fix another case of insecure “security definer” functions (the analogon to setuid programs in file system space for SQL functions) (CVE-2007-6600). Please see the complete changes for 8.1.18 (Ubuntu 6.06 LTS), 8.3.8 (Ubuntu 8.04 LTS, 8.10, and 9.04), and 8.4.1 (Ubuntu 9.10).
8.4.1 is already in Ubuntu 9.10 and in my PostgreSQL Backports PPA for Ubuntu 8.04 LTS and 9.04. Updates for the other supported Ubuntu releases are currently in -proposed, waiting for testing feedback.
If you use PostgreSQL, please give the -proposed packages some testing and report back in Ubuntu bug #430544. Thanks!
It has been broken for two months, since we upgraded to the “new” (not quite any more) gdm in Karmic: But I finally got around to re-doing the gdm patch for supporting a guest session for 2.27. I use it myself a lot for testing stuff with a clean user profile, so I can finally delete my herd of test users again.
One known drawback is that the guest session is not currently restricted by AppArmor rules yet. I’ll get to this at some point, I filed LP #425793 to keep it on the radar.
This morning I added a test script to the Apport bug patterns.
This finally allows you to reliably test a new bug pattern before you actually
commit/push it. You can invoke it with either a .crash file, or a Launchpad bug
number:
$ ./test-local 122988
Matched bug pattern: https://launchpad.net/bugs/122637
$ ./test-local /var/crash/_bin_bash.1000.crash
No match
Some days ago, the first public beta of PostgreSQL 8.4 was announced. I uploaded a CVS snapshot to Debian experimental two weeks ago, but it didn’t make it out of NEW yet.
Packaging the actual 8.4 bits was actually pretty easy, just took me half a day to adapt the 8.3 packaging and eventually figuring out how to build the entire documentation from SGML sources with Debian/Ubuntu’s broken docbook-utils.
I spent much more work work on supporting 8.4 in postgresql-common, especially with the new per-database locales, migrating changed postgresql.conf parameters in pg_upgradecluster, and so on. Now almost all of the > 1000 tests pass, so I believe it is pretty solid now.
The only exception is the changed behaviour in verifying the server side’s SSL certificate from the client side. At first I thought it was a bug, and reported it to upstream, but it evolved into a pretty lengthy and interesting discussion about the right defaults for SSL verification. I’ll work on better defaults, and the test suite to pass 100% soon.
I invite you give the beta a good beating. Packages for Ubuntu 8.04 LTS and 9.04 are in my
postgresql PPA. Due to postgresql-common, you can safely run 8.4 in parallel with existing 8.3 instances, test-upgrade your 8.3 ones to 8.4 and compare them, etc.
Feedback appreciated!
Mrz 11
Still remember the “hal is dead, long live DeviceKit” buzz? It’s time to finally lay our hands on it.
DeviceKit and DeviceKit-power themselves are available for a while in Jaunty’s universe, but installing them by themselves is pretty boring, of course.
Last Saturday I packaged the new gnome-power-manager 2.25.x which is now devkit-ified and doesn’t use hal any more. It is now available in the ubuntu-desktop PPA. Please try it, break it, and complain over there 
It works quite well for me, the only thing I noticed is that it currently seems to break my hibernate hotkey. Still investigating..
Apr 8
Today I was playing with python-coverage, which seems to be the tool of choice for code coverage measurement in Python. Since I am constantly hacking on Jockey’s test suite, I want to strive for perfection and cover everything, so it does sound like something worthwhile.
First I tried to use it like documented:
python /usr/share/python-support/python-coverage/coverage.py -x tests/run
which just caused the tests not to run at all, for no immediately obvious reason (it worked fine with real Python modules in apport). However, it gets much nicer once you stop trying to wrap it around the command line call and start to integrate it into the test suite code itself:
import coverage
coverage.erase()
coverage.exclude('raise NotImplementedError')
coverage.start()[... run all the tests ... ]
coverage.stop()
coverage.report(glob(‘jockey/*.py’))
coverage.report(glob(‘examples/handlers/*.py’))
coverage.erase()
(which is more or less what I committed).
This will run all the tests, and give me a report about how much code they covered, plus a list of code lines which weren’t touched. For example:
Name Stmts Exec Cover Missing
jockey/handlers 248 242 97% 402-405, 420-421, 514
Also, the exclude() interface is much more flexible than putting #pragmas all over the place (which do not seem to really work anyway unfortunately).
Now, off to fixing everything to get 100%. I was surprised how many little bugs I found and fixed while completing the tests. Test suites FTW!!