[01:37] <haobug> hi hi, got problem again. http://pastebin.com/XxaqxmbJ after about 3 days of waiting...
[14:41] <cjwatson> haobug: You don't need to redo it all from scratch, at least, but there's some manual work to do to recover from a failure there without re-downloading - it should be possible to look at /usr/share/lxc/templates/lxc-ubuntu and search for "Installing updates" to find where it got to, but you'll have to trace the function call sequence up to there for yourself
[21:09] <cjwatson> http://people.canonical.com/~cjwatson/tmp/lp-livefs-built.png   progress!
[21:12] <cjwatson> five-ish to-do items remaining, but pretty close.
[21:12] <cjwatson> unfortunately will need another lp-buildd deployment.
[21:43] <cjwatson> wgrant: Perhaps we could try to squeeze a launchpad-buildd update in with RT#69868, since the risk of buildd upgrades seems to be more strongly correlated with how many of them we do rather than how much they contain?  I'd like to include https://code.launchpad.net/~cjwatson/launchpad-buildd/abort-race/+merge/218222 if possible, as well as the fairly obvious stuff that's in trunk.
[21:43] <_mup_> Bug #69868: Contrast setting is bad <gxine (Ubuntu):Invalid> <https://launchpad.net/bugs/69868>
[21:45] <cjwatson> (I haven't yet done a QA pass on the whole lot.)
[21:46] <cjwatson> I've been meaning to do that abort-race stuff for months, but doko keeps running into it so I thought I'd better make an effort to sort it out ...
[21:48] <wgrant> cjwatson: Looking
[21:49] <wgrant> cjwatson: Is that screenshot of a full test run with a local buildd? Nice.
[21:54] <cjwatson> It is indeed.
[21:54] <cjwatson> Not that that took ages to set up or anything.
[21:58] <cjwatson> Remaining to-dos: some bits of view need to be disabled if the feature flag is off; latest builds table for +livefs; UI for requesting a build; a way to delete a LiveFS (much like for recipes)
[21:58] <wgrant> I should probably rewrite the docs, as they don't really work well when not running LP in a heavyweight VM.
[21:59] <cjwatson> I'm afraid I ignored the docs as I was fairly sure I knew which bits I needed
[21:59] <wgrant> Do we need UI for requesting a build?
[21:59] <wgrant> Deletion is probably easy, as the LiveFS can just take all the LiveFSBuilds and their files with it.
[22:00] <cjwatson> I expect to eventually get to the point where some builds don't require cdimage, at which point a UI would be useful
[22:00] <cjwatson> deletion - I was expecting to do what we do with recipes, i.e. leave the builds intact but disconnected
[22:02] <wgrant> Why?
[22:02] <wgrant> It's basically impossible to find a build if you don't know the livefs.
[22:02] <cjwatson> just seems odd to delete builds that happened
[22:02] <wgrant> We avoid deleting SPRBs because that would leave SPRs without a signature and with no way to trace the owner.
[22:03] <cjwatson> well, ok, I guess I can do either way
[22:04] <cjwatson> my local setup was basically sampledata, initseries trusty, run the initialize job, feed in the production chroot, install launchpad-buildd listening on a port not one of those already in sampledata, add that builder
[22:04] <wgrant> What value does a LiveFSBuild with no LiveFS provide? How would you use it, or even find it (except by looking through all the builds for an archive or builder)?
[22:05] <wgrant> Hm, you were able to get it working in a container?
[22:05] <cjwatson> wouldn't be any good for normal package builds, but it worked for this
[22:05] <cjwatson> I had to make the container allow arbitrary mounts, with some help from hallyn
[22:05] <wgrant> Ah, right.
[22:05] <cjwatson> almost exploded my system on the first attempt since it enabled qemu-x86_64 in my host :-)
[22:06] <wgrant> Heh
[22:06] <wgrant> I normally just run a KVM instance which lives on lxcbr0.
[22:06] <cjwatson> LiveFSBuilds> I was thinking builder history views and the like, but you're probably right.  I didn't know there was a specific reason for SPRBs.
[22:07] <cjwatson> The use of old LiveFSBuilds is their logs.
[22:07] <wgrant> Right, but if you want the logs you probably shouldn't be deleting the thing that lets you find them :)
[22:07] <cjwatson> Perhaps I should have a way to disable a LiveFS
[22:07] <cjwatson> Not deleted, but it wouldn't allow new builds any more
[22:08] <cjwatson> Basically to avoid stupid mistakes
[22:09] <cjwatson> Given that I'm not even sure we particularly need deletion
[22:10] <wgrant> We need to be able to delete builds individually, and also the LiveFS and its builds as a whole unless there's a good reason not to
[22:10] <cjwatson> What's the point of deleting individual builds?
[22:11] <cjwatson> I don't think any other build types are individually deleteable, are they?
[22:11] <wgrant> There doesn't need to be UI or API for it
[22:11] <wgrant> but I'm working on the other types as we speak.
[22:11] <cjwatson> Just the principle that all objects should be deleteable?
[22:12] <wgrant> Though those are just being neutered, rather than deleted, since they produce artifacts that are referenced elsewhere.
[22:12] <wgrant> Mostly for proper PPA deletion
[22:13] <cjwatson> A LiveFSBuild associated with a PPA *could* just be neutered, since it doesn't actually build something *in* the PPA as such, it just uses it as a source; but there's probably not much use for such a build
[22:13] <wgrant> Right
[22:14] <wgrant> We delete where we can, neuter where we can't.
[22:14] <wgrant> Keeping useless data around isn't something we should be doing.
[22:14] <cjwatson> But I thought the database was too small
[22:16] <cjwatson> I guess we do erase evidence of builds that happened in some other situations albeit in different ways, e.g. cancel/retry
[22:16] <cjwatson> Anyway, thanks.  Bed then bank holiday, I think
[22:17] <wgrant> Right. It's theoretically nice to have a full history of everything, but in practice it's somewhat onerous and not terribly useful.
[22:17] <wgrant> It's rare that I need to look way back in a builder's history.
[22:17] <wgrant> And for short-term stuff I mostly look at logs.