karmic uec builds fail to publish due to 2 installed -ec2 kernels

per James in irc:
| it's the machine that the archive actually lives on
| what is happening is that LP is calling apt-ftparchive in such a way that it adds Task to all the packages as appropriate
| it does that using override files
| these are not generated by LP as it works
| the files list "package-name Task foo" stuff
| so we need those updated based on an updated germinate run
| however, I have no idea how to do that
| the files are owned by lp_publish, but that user doesn't have a cron job to do it or anything
| so, I don't know if it is done manually on occasion, or LP handles it out of the path of publishing

This can be demonstrated / reproduced from inside an instance with:

$ sudo apt-get update
$ delpkgs=$(dpkg -l "linux-*" | awk '$1 == "ii" {print $2}')
$ sudo apt-get --purge remove ${delpkgs} -y
$ sudo apt-get install uec^

You'll see that the 'install' says:
| The following extra packages will be installed:
| linux-ec2 linux-firmware linux-image-2.6.31-14-virtual
| linux-image-2.6.31-19-virtual linux-image-2.6.31-302-ec2
| linux-image-2.6.31-304-ec2 linux-image-ec2 linux-image-virtual linux-virtual

'apt-get install uec^' looks up all packages with 'uec' in their Task field, and installs them. The Task fields are set by magic automatically generated overrides in the archive, based on germinate output. Sadly, they are not generated properly for karmic-updates.

However, this isn't really the core problem in this case. Putting kernels in the uec seed at all is the core problem, and I must apologise for not noticing this at the time. The reason this is bad is that the kernel ABI changes frequently, and once a release is final we never change its Packages files again! Thus "Task: uec" on linux-image-2.6.31-302-ec2 in dists/karmic/main/binary-*/Packages is frozen for the lifetime of karmic; while technically we *could* regenerate those files, we have never done so for stable Ubuntu releases, preferring to update only karmic-updates and the like, and I expect that things would go wrong if we did - for example, consider what happens when somebody tries to build an image using only karmic and not karmic-updates, or consider that some mirrors may well assume that dists/karmic/ will never change.

My recommendations are as follows:

  * For Karmic, perhaps it is possible to work around this in vm-builder. For example, 'apt-get install uec^ linux-image-2.6.32-302-ec2- linux-image-ec2- linux-ec2-' installs the uec task without the ec2 kernel bits; some elaboration of this might be constructed to use the updated ABI.
  * For Lucid, remove all kernels from the uec seed, and instead install them manually (so 'apt-get install uec^ linux-ec2 linux-virtual' or whatever). It is not safe to put kernels in seeds for which Task fields are generated.
  * We should institute some kind of archive-level test to ensure that kernels never have Task fields.

Is there anything to be done in vm-builder to fix this?

changes were made to vm-builder 0.11 specific at http://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.11/revision/367 .

I'll look into getting this into lucid's vm-builder

Soren,
  Attached is the patch applied to vmbuilder-0.11 moved to vmbuilder trunk.

Soren, I'm assigning this to you. The patch attached is what was applied to vm-builder 0.11. If you think its reasonable to pull into trunk then do so, otherwise you can mark wontfix.

@Scott,

this was marked fix released for karmic and lucid. The patch isn't in the upstream tree - does it need to be? If not, should the bug be marked fix released instead of triaged? If so, I'll apply the patch.

I'm marking this "Wont fix". You could fix it, but really the issue was with karmic's archive. and no need to work around that.