[09:21] <cjwatson> infinity: I think that's a known cdimage bug, indeed; IIRC the publishing code wipes out all the previous torrent copies in each pass for a given flavour/image-type/series in order to get rid of any previous milestones, but it doesn't work correctly in the event that we need to do more than one pass due to different build numbers on different architectures.  Would be a good thing for somebody to come up with a test case for and try ...
[09:21] <cjwatson> ... to fix, in order to learn that code better.
[09:39] <infinity> cjwatson: Was that a hint? :P
[09:39] <cjwatson> It sure was
[09:39] <infinity> Heh.
[09:40] <infinity> cjwatson: I had a look and sorted out more or less where it's happening, having a think about how to preserve the previous desired behaviour (wiping out milestones) while also doing the right thing for multiple passes will happen when I'm more awake.
[09:41] <infinity> cjwatson: I assume the FS layout makes exactly zero difference on the torrent tracker?
[09:41] <infinity> cjwatson: Cause the simplest solution is probably just to mirror the regular simple/full publishing code, where it's keyed on target directory.
[09:46] <cjwatson> Yeah, it shouldn't care about the exact layout, just make sure it all ends up consistent
[10:16] <psivaa_> cjwatson: infinity: (not hugely urgent but) systemd version in the vivid d-i iso's appear to be different from that in the archive (208-8ubuntu8 vs 215-5ubuntu1).  making the vivid d-i iso installs fail.
[10:18] <cjwatson> In general there should be nothing hugely wrong with version mismatches
[10:19] <cjwatson> I don't think that's quite the issue
[10:19] <cjwatson> Oct 31 06:59:07 in-target: The following packages have unmet dependencies:
[10:19] <cjwatson> Oct 31 06:59:07 in-target:  systemd : Depends: libsystemd-journal0 (= 208-8ubuntu8) but 215-5ubuntu1 is to be installed
[10:19] <cjwatson> Oct 31 06:59:07 in-target:  udev : Breaks: systemd (< 215-1) but 208-8ubuntu8 is to be installed
[10:20] <cjwatson> That's not so much complaining about image vs. archive being different, as that something is internally inconsistent
[10:20] <cjwatson> Though of course it may be that a refresh makes it all go away
[10:21]  * cjwatson grabs the image to check; wait a few minutes
[10:22] <psivaa_> cjwatson: ack, yes, my bad interpretation of the failure.
[10:26] <cjwatson> psivaa_: Right, it's not inconsistency between the image and the archive, it's inconsistency between the pool of .debs on the image and the live filesystem on the image that contains the base system
[10:26] <cjwatson> Which implies that perhaps the mirror sync job on nusakan is stuck again
[10:26] <cjwatson> I'll go get a belated breakfast and then poke at that
[10:27] <psivaa_> cjwatson: ack, thank you
[14:40] <cjwatson> psivaa_: There's another build running at the moment, but I've poked the semaphore state so that it should clear itself out after that finishes.
[14:41] <psivaa_> cjwatson: great. thanks for the help