[00:12] <apw> linux-image-generic-lts-* should be equivalent to linux-image-generic and there thould be no issue removing the latter if one of the former is installed
[10:14] <xnox> apw, hola =)
[10:14] <xnox> I think i see what's going on.
[10:14] <xnox> I've pasted a patch to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536810
[10:14] <xnox> it does mean a kernel upload, again =/ and thus no cloud images until 4.4 lands =/
[10:53] <apw> xnox, but why is it copying it in the first place, it should only do that if something is wrong, it should be making symlinks, which we cna do to the non-existant file
[10:53] <apw> xnox, yes in copy mode it will fail, but we should never ever use that
[10:59] <apw> xnox, your patch essentially renders the deferred building null and void in all cases
[11:00] <apw> what we need to work out is why we think we are unasble to use a symlink for htat combination
[11:57] <xnox> apw, not in all cases, only on upgrade (e.g. not reinstall as far as i can see)
[11:57] <xnox> apw, why kernel manages symlink of initramfs instead of update-initrmafs?
[11:59] <xnox> wait a minute.
[12:01] <xnox> apw, we change to '/' and check existance of 'initramfs.img' rather than checking 'boot/initramfs.img' for the link_in_boot case
[12:05] <xnox> apw, http://paste.ubuntu.com/14800299/ ?
[12:05]  * xnox tests
[12:35] <xnox> apw, however, in /etc/kernel/postinst.d/initramfs-tools INITRAMFS_TOOLS_KERKEN_HOOK=1 is set.
[12:36] <xnox> thus negating the deffered initramfs-tools update.
[12:48] <xnox> apw, i'm chatting to ben here at fosdem.
[12:48] <xnox> he totally fixed this bug 6 years ago.
[12:48] <xnox> sorry 2
[12:48] <xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738707
[12:49] <xnox> apw, https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=373d086904305699561b1eb505c33b010c24de9b
[12:49] <xnox> i shall try cherry-picking that.
[12:53] <xnox> apw, i think we shall resync our maintainer scripts.
[13:18] <apw> xnox, likely we should, but that is no small task
[13:18] <apw> given we have split linux-image and they do not, so we need to test properly
[13:19] <xnox> apw, right cherrypicking that one commit is easy. especially since it's quite easy to reproduce on amd64 with ben's steps from there.
[13:19] <apw> xnox, so i'll have a look at pulling that in to what we have for now, and get an upload done early next week
[13:20] <xnox> which is still slightly different from what i have ondisk in the old cloud image, and slightly different what live build does. but it smells as the closest thing.
[13:21] <apw> might even be able to get it in tonight, will see
[13:21] <apw> we are waiting on testing anyhow
[13:24] <xnox> apw, i think we can build cloud images with ppa's enabled, and with proposed enabled. cherry-picking above mentioned commit will be like a good thing to do (it's a valid bug on ubuntu currently). But e.g. i cannot easily validate if that will fix livebuilders or not =/ cause that needs a livebuilder, which means having a launchpad do it.
[14:19] <apw> xnox, oh if you can do PPAs i could ram one into our unstable PPA for testing
[14:20] <apw> xnox, you'd need just s390x right 
[14:20] <apw> xnox, those only take like an hour to build
[14:21] <xnox> yeah.
[14:21] <xnox> well arm64, powerpc64el, armhf are also broken. But i couldn't care less about them =)
[14:23] <apw> xnox, right, to allow you to confirm this fixes your issue, i could build it such that the others blow up
[14:23] <apw> xnox, if you can confirm a PPA would do for a test ...
[14:23] <xnox> right.
[14:24] <xnox> i need cloudy people.
[18:01] <apw> xnox, i've uploaded a +apw1 to ppa:canonical-kernel-team/ubuntu/unstable which should build for s390x
[18:56] <xnox> apw, tah.