This affects specifically users who have statoverrides set for /usr/sbin/apache2. This doesn't seem to be done by anything in the current packaging; it could either be manual, or the relics of an old script. Did you intentionally make /usr/sbin/apache2 non-executable?
The bug is that cut is invoked with its default delimiter, namely tab, but dpkg-statoverrides separates the fields in its output with spaces. Therefore, the correct fix is to add the -d' ' option to that invocation of cut.
This was fixed by Debian in 2.2.12-1 (merged into karmic) by way of removing that upgrade code entirely - indeed, there's no clear evidence that they ever noticed the bug. However, since this is code to handle upgrades from apache 2.0 to 2.2, and dapper had 2.0, I don't think that's a valid option for hardy. However, the version in jaunty (and jaunty-updates) suffers from the same bug, and should be fixed at the same time.
This affects specifically users who have statoverrides set for /usr/sbin/apache2. This doesn't seem to be done by anything in the current packaging; it could either be manual, or the relics of an old script. Did you intentionally make /usr/sbin/apache2 non-executable?
The bug is that cut is invoked with its default delimiter, namely tab, but dpkg-statoverrides separates the fields in its output with spaces. Therefore, the correct fix is to add the -d' ' option to that invocation of cut.
This was fixed by Debian in 2.2.12-1 (merged into karmic) by way of removing that upgrade code entirely - indeed, there's no clear evidence that they ever noticed the bug. However, since this is code to handle upgrades from apache 2.0 to 2.2, and dapper had 2.0, I don't think that's a valid option for hardy. However, the version in jaunty (and jaunty-updates) suffers from the same bug, and should be fixed at the same time.