[08:04] ok back :p === Ursinha is now known as Ursinha-afk === doko__ is now known as doko === Ursinha-afk is now known as Ursinha === seelaman` is now known as seelaman === brendand_ is now known as brendand [18:53] infinity: could you review libtar for me? [18:58] could someone reject kde-workspace from trusty unapproved? [19:12] shadeslayer: doing so [19:27] bdmurray: thx [19:27] uploaded the fixed package [22:04] oh [22:12] ScottK: ^^ kde-workspace uploaded [22:13] shadeslayer: since you've been asking - the livefs stuff is landed on Launchpad trunk now and is looking pretty good, so I'm optimistic that we'll have an initial production rollout next week [22:13] doing it on Friday would probably be a bit cavalier [22:13] I noticed :) [22:14] hehe [22:14] cjwatson: btw from what I've understood, using the LP derivative distro will make a entire archive fork ? [22:14] I ended up using the PPA code for testing (because I needed a hacked live-build), so maybe I can get some ops time to debug that [22:14] shadeslayer: partial [22:14] s/debug/deploy/ [22:15] buildd deployments are rather more fragile and time-consuming for ops at the moment sadly [22:15] cjwatson: so, we specify which packages to fork then? [22:15] but we'll see [22:16] *nod* [22:16] shadeslayer: something like that. I don't think it will be ready for casual use for quite a while ... [22:16] cjwatson: I mostly need it for Kubuntu Next ISO's [22:16] yeah, don't hold your breath [22:16] I would expect a PPA to be better for your use case anyway? [22:16] I see, then we'll have to figure out how to do those with PPA's [22:17] yep, however, I was more interested in the ISO side of those [22:17] I dunno, maybe it will be possible with derived distros, but the target is to get them working for a single target for August and that target doesn't require anything complicated on the cdimage side [22:17] whereas Kubuntu likely would [22:17] so would need to discuss the exact requirements in a bit more detail I think [22:18] mhm, should I email Ubuntu devel with our requirements next week then? because plasma 5 is going to be out in a few weeks, and it would be awesome to have a ISO to go along with it [22:19] I'm also kind of wary of derived distros being used for more than stabilisation branches, as it would be very easy to end up with fragmentation [22:19] I could hack around things and use ubuntu-defaults-builder and what not, but I don't know how to setup the UEFI side of things [22:19] right, you absolutely will not have derived distros in a few weeks [22:19] so sure, details please :) [22:19] ok, will send details to ubuntu-devel next week :) [22:19] if that's the right place to discuss this [22:19] will probably need some work on the cdimage side to mirror additional PPAs [22:20] maybe ubuntu-release, but whichever [22:20] well, it'll be just the one [22:20] yeah but I'm not writing special-case code for this, if I write it it'll be generic so I don't have to rewrite it later :) [22:20] fair enough :) [22:21] trying to make sure that new classes of configuration I add to cdimage are table-driven [22:21] one thing that's important to know is the scope of the PPA [22:21] in particular it would be helpful to have a guarantee that it will not touch things in the debootstrap set [22:22] ('cos debootstrap isn't much good at multi-archive bootstrapping) [22:23] if it's just the UI layer, and you're happy to deal with the utopic archive moving along under you, then a PPA should work [22:24] I highly doubt it'll touch things in the debootstrap layer [22:24] **maybe** some library like poppler, or stuff, but I highly doubt we'll touch things in debootstrap [22:27] cjwatson: the only problem is if the PPA contains extra packages (not in archive) which they need in the debootstrap set, correct? anything else, we debootstrap from the release pocket + dist-upgrade the chroot with all the right sources afterwards which should take care of any version bump for packages in the debootstrap set. [22:28] or am I missing something? [22:28] or removals. but possibly, yeah [22:28] still, I'd be more comfortable if that were excluded [22:28] it's complex enough as it is :) [22:30] yeah, I just assumed we already had that kind of logic since it's not uncommon for us to push debootstrap-set packages into -updates post-release and then build point release isos including that (where we debootstrap from release pocket, setup sources.list and dist-upgrade afterwards). [22:31] we might do, I'd just like for it not to be a requirement because it seems like a plausible source of difficulty [22:32] and this is several thousand lines of brand new infrastructure code as it is [22:36] https://dogfood.paddev.net/builders/ heh, LP is nice sometimes, I didn't explicitly put the [] bit there but it's absolutely right [22:39] ah yes, of course PackageBuildFormatterAPI does that [22:51] Howdy! With the latest upload of darkice, we have eliminated the rest of the Ubuntu delta, can you sync it (or do I need to make a formal sync request?) [22:56] that's self-service by uploaders, we don't do that centrally any more [22:56] if you have upload access, use syncpackage, otherwise, use requestsync [22:56] assuming you have an Ubuntu system to run it from? [22:58] actually, never mind, it's pretty clear, I'll switch to my uploader hat and do it [22:58] done [23:00] Sweet, thanks. And no, I have no upload rights. [23:00] (It was a simple one, yeah.) [23:10] cjwatson: could you review libtar in trusty-proposed? [23:11] looking [23:17] bdmurray: do you want to fix the grievous misspelling of the patch author's name in the changelog? :) [23:18] Magnus != Marcus, Holmgren != Holmgen [23:18] rest of it looks ok ... [23:18] cjwatson: wow, that'd be great or I can do it [23:19] can I reject and have you fix the changelog? I like to have people's names spelled right [23:19] but I'll be around for a little bit longer to accept the second try [23:21] cjwatson: sure, sounds good [23:26] cjwatson: reuploaded [23:34] bdmurray: thanks [23:37] cjwatson: thank you for pointing it out