[01:06] <cleary> cjwatson: are you about perchance?
[01:08] <cleary> I'm having a look through the ubuntu-cdimage project, just trying to kick off a test build - the README is pretty helpful
[01:08] <cleary> but, I can't get it started -
[01:10] <cleary> bin/for-project ubuntu bin/cron.daily-live exits with an OSError: No such file or dir
[01:13] <cleary> seems to be failing on the lock_build_image_set func, calling lockfile
[01:15] <cleary> ok, typing my way through it has yielded what is probably an obvious issue ... lockfile bin doesn't exist on my system ;)
[01:15] <StevenK> cleary: Install procmail
[01:17] <cleary> hi StevenK - got it, thanks
[01:23] <cleary> StevenK: do you use this cdimage tool at all?
[01:25] <cleary> I'm going through the README which documents the process somewhat
[01:26] <cleary> and the steps, while having an obvious description, don't seem obvious in what they achieve as part of the process
[01:27] <cleary> ...I don't mean to waste your time, I'll plumb through each of them and see if I can work out the tie-together
[01:28] <cleary> I'm looking for a way to a) build a standard (k)ubuntu livecd only (from scratch), and b) customise that process to include some of my own packages and changes
[01:28] <cleary> I'm not interested in a remaster process
[01:29] <cjwatson> For historical reasons not all the bits required to build an entire live CD from scratch are currently in cdimage
[01:29] <cjwatson> A while back I got clearance to release all the remaining glue provided I rewrote it all in unit-tested Python in the process
[01:29] <cjwatson> So I'm currently in the middle of that
[01:30] <cjwatson> I should have a better answer in a few weeks :)
[01:30] <cleary> cjwatson: ok, that's great news. I was trying to work out why I had never found this tool -
[01:30] <cjwatson> livecd-rootfs has code to drive live-build to do the squashfs generation
[01:30] <cjwatson> And cdimage has most of the bits required to download that from a builder and assemble it
[01:31] <cjwatson> But (a) the glue between those is currently unreleased (b) there needs to be a thing that lets you just build on the same system rather than the full mechanism of going off to a separate builder
[01:31] <cjwatson> (In general a separate builder is necessary since the livefs might need to be built for a different architecture)
[01:32] <cleary> that makes sense
[01:32] <infinity> That thing that lets you build all on one system should probably just be live-build, but teaching live-build all of debian-cd's pool construction tricks is non-trivial.
[01:32] <cjwatson> At the moment, you could start with BuildLiveCD in livecd-rootfs (which is the ssh trigger that our production cdimage instance calls), use that to build a squashfs, and then modify lib/cdimage/livefs.py to point to wherever you've stored the livefs
[01:32] <infinity> (Or, debian-cd and live-build could use tighter integration to Just Work together without a ton of glue)
[01:32] <cjwatson> At that point it ought to be possible to use bin/cron.daily-live
[01:33] <cjwatson> It'll be a bit cumbersome right now though
[01:33] <cjwatson> And yeah, you need a full local mirror to make the debian-cd bits work properly
[01:33] <cjwatson> Well, main+restricted for the relevant architecture(s) at least
[01:34] <infinity> And universe, he's building kubuntu.
[01:34] <infinity> Unless they don't have a live-ship seed?
[01:34] <cjwatson> Ah I didn't see that.  Indeed
[01:34] <infinity> Which they might not.
[01:34] <cjwatson> They do (ship-live)
[01:35] <cleary> so I couldn't get away with pointing it at an apt caching proxy of some sort then :)
[01:35] <cjwatson> No, it hardlinks to the files as part of constructing the image
[01:35] <cleary> ok, there's quite a bit of extra infrastructure I'll need to put in place
[01:36] <cleary> as a little bit of background, I've mentioned I've been using my own scripts
[01:36] <cleary> these are based on the tools used by the aptosid/sidux team for building their livecd releases
[01:36] <cjwatson> live-build is much better at being locally customisable
[01:36] <cleary> written predominantly by kel modderman, not sure if you know him
[01:36] <cjwatson> I do
[01:36] <cjwatson> Though it's been a while
[01:37] <cleary> I was involved with sidux for some time as a developer, due to my work requirements
[01:37] <cleary> we deployed livecd based desktops in production, and kel and I worked on the various building incarnations together
[01:38] <cleary> about two years ago, managing an unstable repo became too much for me
[01:38] <cleary> so I looked to ubuntu as the least cost stable repo move
[01:39] <cleary> um, actually it was 2009
[01:39] <cleary> 9.10 was my first production release here
[01:39] <cleary> anyway, I had no luck finding your tools (which makes sense, they weren't released)
[01:40] <cleary> so I forked kel's pyfll tool for ubuntu-isms
[01:40] <cleary> casper and soforth
[01:40] <cleary> and that's what I've been using since - but I've been flying solo for a long time, and I've decided I need to get ... help
[01:40] <cjwatson> cdimage has been released for a long time, but essentially in its current state
[01:41] <cjwatson> (At least as far as coverage goes)
[01:41] <cleary> part of that process was to package and release pyfll-ubuntu properly
[01:41] <cjwatson> But anyway, yeah
[01:42] <cleary> so I was creating a project in launchpad that highlighted similar projects, cdimage showed up and here I am ;)
[01:42] <cjwatson> Do you actually need complete identity with Kubuntu as your starting point, or could you get by with live-build's --binary-images=iso-hybrid mode?
[01:42] <cleary> I don't need any kubuntu identity
[01:42] <cleary> kde will be what I deploy as the DE
[01:42] <cleary> that's the only association
[01:43] <cjwatson> The latter won't give you completely accurate pool, image preseeding, that kind of thing, won't necessarily have the same boot loader menu, probably has no UEFI support right now, various other things - but the live filesystem it emits will be the same and it should at least boot and probably install with a bit of love
[01:43] <cleary> let me dive into the info you've provided
[01:43] <cjwatson> And it will be much less setup
[01:44] <cleary> well, that's somewhere near what I'm looking for for now
[01:44] <cleary> my tool is good, but it's duplicated work since you guys are doing this too
[01:45] <cleary> I'm trying to determine whether I commit to maintaining it as a project, or whether I can get onboard with your stuff
[01:45] <cleary> seems my timing was good
[01:45] <cjwatson> There's also ubuntu-defaults-builder, which has an ubuntu-defaults-image tool that's designed for really low-effort customised builds
[01:45] <cjwatson> It's used by various localised builds of Ubuntu for instance
[01:45] <cjwatson> And sits on top of live-build
[01:46] <cleary> hadn't heard of it either, ok - that may be useful too
[01:46] <cjwatson> Depends how extensive your customisations are, really
[01:46] <cleary> well, 99% are packaged
[01:46] <cleary> there are occasional requirements for some chroot fuckery
[01:46] <cjwatson> It was kind of designed to guide the localised projects into builds that didn't diverge too far so that the result would be supportable by us, but you might find it useful all the same
[01:47] <cleary> yeah, that sounds like what I'm after
[01:47] <cleary> however, I'm seeing some potential for the "release management" elements of the cdimage tools
[01:47] <cjwatson> It's a 300-line shell script so shouldn't be desperately hard to bodge into some slightly different shape if necessary :)
[01:48] <cleary> I will check it out now - this has been a huge help, thankyou
[01:48] <cleary> in the meantime, I might just bump a package into a ppa instead of going the whole lp project
[01:48] <cjwatson> Those elements are the biggest reason cdimage remains useful to us; OTOH they are rather tightly tied to our particular layout right now
[01:49] <cjwatson> I'm vaguely planning to make them a bit less ridiculously hardcoded as part of the Python rewrite, or at least consolidate the hardcoding in one place
[01:50] <cleary> well, I'm interested in assisting if I can - my ability to code, while tertiary backed, is pretty rusty
[01:50] <cleary> however, I have a production release requirement, version and release management requirements
[01:50] <cleary> customisations etc, so at the very least it's a good testing area for de-hardcodification
[01:51] <cjwatson> Ta.  At the moment I'm trying to rewrite from one language to another while simultaneously integrating a long-lived production fork (and the whole thing not as my most important task), so it's quite a lot to hold in my head :)
[01:51] <cjwatson> Should be easier once I'm further along
[01:51] <cleary> I understand - once again, thanks for the info
[01:51] <cjwatson> I've been procrastinating on publish-release, but it's the most important one to tackle as it's really outgrown shell
[01:52] <cjwatson> It's interesting, after a long drought you're the second person to express interest in setting up cdimage in the last week or so
[01:53] <cleary> off the record (so to speak), if you could get Kel interested in it too, you would find a strong resource
[01:53] <cleary> ...maybe too strong
[01:53] <cleary> he makes things happen very quickly
[01:54] <cjwatson> Noted, thanks
[01:54] <cleary> well, now you've got a community :)
[01:55] <cleary> I'm going to spend a day or two digesting this
[01:55] <cleary> out of curiousity, do you guys know if irssi logs automatically?
[01:56] <cjwatson> It doesn't
[01:56] <cjwatson>   "fe-common/core" = {
[01:56] <cjwatson> ...
[01:56] <cjwatson>     autolog_path = "~/.irssi/logs/$tag/$0/%Y-%m-%d.log";
[01:56] <cjwatson>     autolog = "yes";
[01:57] <cjwatson> (that's all under settings) is what I have here; season to taste
[01:57] <cleary> I haven't used irc for a long time, I'm regretting not jumping to irssi earlier
[01:57] <cleary> I might have had a clue coming back to it :P
[01:58] <cleary> thanks, I'll try and set it up properly for next time ;)
[01:58] <cjwatson> irssi is generally a good choice
[01:59] <cleary> http://puzlhed.net/2009/09/13/Saving_a_Buffer_in_Irssi.html/
[01:59] <cleary> :)
[02:00] <cleary> I hope that didn't just dump in channel...
[02:00] <cleary> holy shit
[02:00] <cjwatson> It didn't
[02:00] <cleary> few
[02:00] <cjwatson> /lastlog's always local AFAIK
[02:00] <cleary> heh, phew
[02:01] <cleary> alright, off to lunch - later
[02:01] <cjwatson> see you
[11:22] <davmor2> xnox, cjwatson:  I just had a thought if I get the install to the broken state.  I can install sshserver and probably allow access to the machine right?  Or would it need to reboot to allow the SSH to work?
[11:24] <xnox> davmor2: yeah, you could do that. Really all we need you to do is to: (a) copy / upload any /var/crash/* files (b) file a bug with ubuntu-bug ubiquity. While you are in the broken state.
[11:24] <mpt> xnox, what do you think of removing "Reinstall from sync" from the installer spec? It's a pretty marginal feature, and I don't think that school group is coming back. :-)
[11:25] <davmor2> xnox: okay I can do that too
[11:25] <xnox> mpt: go ahead, as long as it is saved in the history/revisions somewhere.
[11:25] <davmor2> I'll have a play with it in a bit and see what I can get from it I need it to report a usb mic bug first though
[11:25] <xnox> mpt: funny, since with the u1 plugin we now have full way to authenticate against u1 ;-)
[11:26] <mpt> xnox, doesn't seem to be any way to label a revision, but you can look back at this IRC log and see that I removed it on March 8th
[11:31] <xnox> mpt: i mean we should be able to view them. E.g. File -> Show revision history?
[11:31] <xnox> will that still have your sketches and text?
[11:32] <mpt> xnox, yes. It's just that the listed revisions are numerous and unlabelled.
[11:32] <xnox> mpt: good enough to scroll to 8th of March =)
[11:32] <mpt> yep
[11:32] <mpt> done
[11:33] <mpt> And now that it's gone, if the third-party software question is pushed back, the Internet connection step can go after the partitioning step as well.
[11:43] <mpt> though that would delay downloading of updates a bit.
[11:44] <xnox> mpt: download updates is the last step as it is.
[11:44] <mpt> xnox, what do you mean by "the last step"?
[11:45] <xnox> mpt: updates are downloaded and installed at the very end of the progress bar (last time it jumps back to 0)
[11:45] <xnox> mpt: i ponder if it will delay activating hard-drive / raid drivers, without which one will have hard time partitioning.
[11:45] <mpt> xnox, why not in parallel?
[11:46] <xnox> mpt: because there is no place to download them to =)
[11:46] <mpt> oh
[11:46] <mpt> I'm not familiar with how many times the progress bar jumps back to 0, mainly because it shouldn't ;-)
[11:47] <xnox> mpt: we can't store all updates in ram, so we have to partition, format, prepare the target, once we can chroot into it, that's when we do `apt-get update & dist-upgrade`
[11:47] <xnox> more or less.
[11:47] <mpt> ok
[12:32] <davmor2> xnox: okay I've just tried 3 time with the same cd that I had the issue with and now it's not locking up
[12:35] <davmor2> xnox: I'll have a play with it over the weekend and see if I can replicate it and file a bug for it. but I need to get on with some work now,  I'm assuming it is some random race condition that is triggering it :(  cause those are always the nicest things in the world to track down :(
[13:01] <xnox> davmor2: fair enough =)
=== kentb-out is now known as kentb
=== shadeslayer_ is now known as shadeslayer