[01:37] hi hi, got problem again. http://pastebin.com/XxaqxmbJ after about 3 days of waiting... === jml_ is now known as jml [14:41] 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] http://people.canonical.com/~cjwatson/tmp/lp-livefs-built.png progress! [21:12] five-ish to-do items remaining, but pretty close. [21:12] unfortunately will need another lp-buildd deployment. [21:43] 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 [21:45] (I haven't yet done a QA pass on the whole lot.) [21:46] 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] cjwatson: Looking [21:49] cjwatson: Is that screenshot of a full test run with a local buildd? Nice. [21:54] It is indeed. [21:54] Not that that took ages to set up or anything. [21:58] 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] I should probably rewrite the docs, as they don't really work well when not running LP in a heavyweight VM. [21:59] I'm afraid I ignored the docs as I was fairly sure I knew which bits I needed [21:59] Do we need UI for requesting a build? [21:59] Deletion is probably easy, as the LiveFS can just take all the LiveFSBuilds and their files with it. [22:00] 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] deletion - I was expecting to do what we do with recipes, i.e. leave the builds intact but disconnected [22:02] Why? [22:02] It's basically impossible to find a build if you don't know the livefs. [22:02] just seems odd to delete builds that happened [22:02] We avoid deleting SPRBs because that would leave SPRs without a signature and with no way to trace the owner. [22:03] well, ok, I guess I can do either way [22:04] 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] 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] Hm, you were able to get it working in a container? [22:05] wouldn't be any good for normal package builds, but it worked for this [22:05] I had to make the container allow arbitrary mounts, with some help from hallyn [22:05] Ah, right. [22:05] almost exploded my system on the first attempt since it enabled qemu-x86_64 in my host :-) [22:06] Heh [22:06] I normally just run a KVM instance which lives on lxcbr0. [22:06] 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] The use of old LiveFSBuilds is their logs. [22:07] Right, but if you want the logs you probably shouldn't be deleting the thing that lets you find them :) [22:07] Perhaps I should have a way to disable a LiveFS [22:07] Not deleted, but it wouldn't allow new builds any more [22:08] Basically to avoid stupid mistakes [22:09] Given that I'm not even sure we particularly need deletion [22:10] 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] What's the point of deleting individual builds? [22:11] I don't think any other build types are individually deleteable, are they? [22:11] There doesn't need to be UI or API for it [22:11] but I'm working on the other types as we speak. [22:11] Just the principle that all objects should be deleteable? [22:12] Though those are just being neutered, rather than deleted, since they produce artifacts that are referenced elsewhere. [22:12] Mostly for proper PPA deletion [22:13] 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] Right [22:14] We delete where we can, neuter where we can't. [22:14] Keeping useless data around isn't something we should be doing. [22:14] But I thought the database was too small [22:16] I guess we do erase evidence of builds that happened in some other situations albeit in different ways, e.g. cancel/retry [22:16] Anyway, thanks. Bed then bank holiday, I think [22:17] 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] It's rare that I need to look way back in a builder's history. [22:17] And for short-term stuff I mostly look at logs. === bradm1 is now known as bradm