[19:04] What's up with this? [19:04] Unpacking linux-image-extra-3.13.0-63-generic (3.13.0-63.103) ... [19:04] dpkg: error processing archive /var/cache/apt/archives/linux-image-extra-3.13.0-63-generic_3.13.0-63.103_amd64.deb (--unpack): trying to overwrite '/lib/modules/3.13.0-63-generic/kernel/mm/hwpoison-inject.ko', which is also in package linux-image-3.13.0-63-generic 3.13.0-63.104~precise1 [19:11] argh, somehow I have a precise kernel on this system === Elimin8r is now known as Elimin8er [20:50] danjared, are you doing an upgrade ? [20:51] that looks like an lts backport being overritten by a non-lts version of the same package [20:52] otherwise it looks like you have a linux-image package for trusty and an lts backport of near same version from precise [20:52] and they ought not be on the same machine [20:52] Which is fine, but why is that module in extra in one, and in image in the other. [20:52] apw: The problem is the split being different, so it's not upgrading correctly. [20:52] Which is... Weird. [20:53] well it depends if it is an upgrade, if not its just fail [20:53] if it is then we hasve moved something in one release and the breaks only affect the same package [20:53] apw: That upgrade is meant to work. :P [20:53] so its broken [20:53] It's from precise+lts to trusty, if you read the output. [20:54] ie the breaks you'd need ofr th move need to affect linux <= X and linux-lts-trusty <= X [20:54] and they arn't there [20:54] And it's saying extra has the module on trusty, and image has it on lts-trusty. [20:54] Shouldn't need a breaks, should just need the split to match. [20:54] So extra upgrades extra and image upgrades image. [20:54] but one is one upload older [20:54] so if the move occured ni a non-abi bumper, that might account for it [20:54] But yes, maybe the module moved between those uploads? [20:54] Seems unlikely, though. [20:54] or ... as you say the split could just be wrong [20:54] Moves should be an ABI break. [20:54] ie not copied back ... [20:55] moves should be an abi break but arn't no doubt [20:55] so i suspect we moved one in the non-lts and didn't backport it right ... [20:55] They have to be, the ABI checker screams when a module moves. [20:55] bjf, ^ [20:55] it notices when the old had and the new does not [20:55] if it is in either we have it from the module checker point of view [20:55] and likely we should notice and hwine [20:56] Oh, it doesn't check post-split? [20:56] but ... i bet this is different in lts and non-lts because we don't copy it [20:56] That's probably a bug. [20:56] But it's probably just a bad backport. [20:56] copy the module-inclusion.generic [20:56] sigh [20:56] and now we are pooped [20:56] If you could check the split difference and just commit a fix for next upload? I don't care if old ones don't upgrade right. [20:56] Life's like that sometimes. [20:56] danjared, could you file a bug against linux-lts-trusty for us with the details above and drop the bug number in here [20:57] danjared, and ping me with it [20:57] and i'll get it fixed up [20:57] now how does he get out of this [20:57] Dear armhf test runner, run tests faster. [20:58] apw: Best way out is just to dpkg -i --force-overwrite /var/cache/apt/foo.deb [20:58] danjared: ^ [20:59] 103 and 104 were identical, so it didn't move between uploads. [21:00] It's just a backport bug in the split, then. [21:01] I don't think lts-trusty has the new and improved "rsync all the things" backport method. [21:01] So, it's potentially sketchy and out of sync. [21:03] yeah, likely [21:05] danjared, ... ok i'll file a bug now [21:07] https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1492466 [21:07] Ubuntu bug 1492466 in linux-lts-trusty (Ubuntu) "linux-lts-trusty: inclusion list out of sync with trusty linux" [High,Triaged] [21:07] will sort later === bdmurray_ is now known as bdmurray