[01:04] <TheMuso> xivulon: Yeah MD5 is much faster.
[01:05] <xivulon> ah great!
[01:05] <TheMuso> xivulon: It is noticable on this dual celeron I'm using.
[01:40] <twb> What infrastructure is responsible for generating the live CDs?  Presumably you aren't using Debian Live's live-helper package...
[01:44] <TheMuso> twb: livecd-rootfs is the package responsible.
[01:44] <TheMuso> twb: It does the filesystem images.
[01:45] <TheMuso> twb: http://launchpad.net/ubuntu-cdimage is what is used to build all disk images.
[01:45] <twb> The latter is not Free software?
[01:45] <TheMuso> However it is somewhat of an effort to set up.
[01:45] <TheMuso> twb: What do you mean?
[01:45] <twb> Well, you gave me a URL instead of a package name.
[01:46] <TheMuso> twb: Thats because its not a package in the archives.
[01:46] <TheMuso> twb: Its in a bzr repository.
[01:46] <TheMuso> twb: As its only ever used on Canonical's servers.
[01:49] <evand> it is free software
[01:50] <TheMuso> But it is some work to set it up.
[01:51] <evand> indeed :)
[02:00] <twb> So it's not a package just because nobody has bothered (cared enough) yet?
[02:00] <TheMuso> Another reason to dislike vista. It appears that slipstreaming SP1 is not possible. :S
[02:00] <TheMuso> twb: Its not a package, because the way the scripts are written are very inflexible. They'd need to be totally rewritten in a more flexible and modular way to be useful to the general public.
[02:01] <twb> So IOW it's a huge kludge? ;-)
[02:01] <TheMuso> At the moment yes.
[02:02] <twb> That makes me feel better about my own huge kludges to edit Ubuntu live cds because I didn't know how to make them from scratch.
[02:02] <twb> Is `mainline' a fork of debian-cd's codebase, or is it a separate codebase that assumes debian-cd is already installed?
[02:03] <TheMuso> twb: I think its a fork, as the debian-cd that is used for Ubuntu has a lot of modifications.
[02:03] <twb> OK.
[02:05] <twb> Sanity check: cdimage can make live CDs, and debian-cd only makes d-i CDs?
[02:07] <TheMuso> No, debian-cd is used to make both live and d-i CDs.
[02:08] <TheMuso> I think that is one of the modifications made.
[02:09] <twb> You're saying that even on Debian, *Debian's* version of debian-cd can make live CDs?
[02:09] <cjwatson> twb: cdimage/mainline is a wrapper around debian-cd.
[02:09] <twb> OK.
[02:09] <cjwatson> debian-cd/ubuntu is our branch (I guess fork nowadays) of debian-cd.
[02:09] <cjwatson> and sure, it's pretty much a massive (but working) kludge.
[02:10] <cjwatson> I don't feel bad about it because AFAICS nearly everyone's CD building scripts are a bit like this.
[02:10] <cjwatson> there's a fairly large pile of wrapper stuff around Debian's CD building scripts too that runs on cdimage.debian.org; I don't think it's ever been released anywhere
[02:11] <cjwatson> just to deal with the mechanics of shoving all the bits around and publishing them,
[02:11] <twb> Well, I know for a fact that live-helper's codebase has terrible error handling, and regularly breaks due to "bad" stuff entering Sid.
[02:11] <cjwatson> s/,$//
[02:11] <cjwatson> livecd-rootfs has good error handling in the sense that it completely refuses to run at the slightest provocation ;-)
[02:11] <twb> Yeah, the fact that bits of Debian's infrastructure aren't apt-gettable makes me queasy.
[02:12] <cjwatson> after you run some infrastructure for a while, it stops making you queasy, IME
[02:12] <cjwatson> running infrastructure is hard enough work without packaging it all up for everyone else as well, especially since if you get it slightly wrong you (e.g.) get mailbombed with error messages from other people's broken installations
[02:12] <twb> Bleh, some of the stuff our customers are running is developed without even any version control :-/
[02:13] <twb> I *want* to believe that productization and thorough testing and stuff is worth the investment, even for infrastructure
[02:13] <cjwatson> the only bit that I really don't like about our cdimage scripts is the fact that germinate integration is handled outside debian-cd
[02:14] <cjwatson> which was honestly just because it was about a hundred times easier
[02:14] <cjwatson> but it does mean that there's no point in packaging just the Ubuntu fork of debian-cd, because it's useless for building Ubuntu CDs on its own - it'll never get it right
[02:15] <cjwatson> also, all of our live CD infrastructure was developed before the Debian Live project got started
[02:15] <cjwatson> so it wasn't a matter of us reinventing the wheel, it's that now it's a lot of effort to switch to another codebase and would introduce an unknown number of bugs
[02:15] <twb> I know that.
[02:15] <twb> I'm in the same boat.
[02:16] <twb> I have huge swathes of crap that's still Knoppix-based because that was all there was back in 2002
[02:16] <cjwatson> we used Morphix for the first Ubuntu live CD
[02:16] <cjwatson> and then poured a hell of a lot of development time into developing something that we could actually maintain
[02:16] <cjwatson> and autobuild, and stuff like that
[02:17] <twb> Heh.
[02:17] <twb> Is Ubuntu planning to move to aufs instead of unionfs?
[02:17] <cjwatson> it's been discussed, I don't know the kernel team's current thoughts though
[02:17] <cjwatson> I don't particularly object, just didn't want to try it in hardy
[02:18] <cjwatson> we've exercised just about every corner case unionfs has, and at this point at least we know which bugs we're encountering :) aufs will take a full release cycle to shake out
[02:18] <twb> I think unionfs is persona non grata within Debian Live because it is now distributed as a kernel patch instead of as a module.
[02:19] <cjwatson> meh, it's a patch that creates a module
[02:19] <twb> They might have fixed that particular issue by now, I dunno.
[02:19] <cjwatson> or at least was when we initialised our 2.6.24 tree
[02:19] <twb> I notice that unionfs is "built in" to the ubuntu packages instead of needing m-a hand-holding (like Debian).
[02:20] <cjwatson> yes, we prefer to actually put the stuff we need in our kernel packages
[02:20] <cjwatson> one of the reasons we ended up diverging completely on the kernel
[02:20] <cjwatson> (which is sort of unfortunate and confusing but there it is)
[02:21] <twb> What constitutes "need"?
[02:21] <twb> It's not like unionfs is needed post-install, or in the alternate cd
[02:21] <cjwatson> the desktop CD is a first-class citizen (I think a Debian live CD ought to be too)
[02:21] <cjwatson> the modules it needs should be maintained properly
[02:22] <cjwatson> a unionfs-a-like is also useful for other purposes, such as LTSP
[02:22] <twb> Hmm, how does LTSP leverage unionfs?
[02:22] <cjwatson> I actually don't know the details, it's just an association somewhere among my neurons
[02:23] <twb> Doesn't LTSP just serve a read-only x terminal OS to netboot clients, then do everything as remote X?
[02:23] <twb> OK.
[02:23] <cjwatson> all I can suggest is that you grep for unionfs in the ltsp source package. :)
[02:23] <cjwatson> ./client/initramfs/scripts/ltsp-nbd:81:    mount -t unionfs -o dirs=/cow=rw:/rofs=ro unionfs ${rootmnt}
[02:24] <TheMuso> twb: You could always ask ogra when he's around in #ubuntu-devel if you really want to know I guess.
[02:25] <twb> I really must get around to grokking LTSP; it has large amounts of intersection with my stuff.
[02:26] <cjwatson> I'm assuming that it's convenient to give the netboot clients a writable root.
[02:44] <twb> I notice that e2fs-zero (in livecd-rootfs) seems to do the same thing as the `zerofree' package.
[02:46] <cjwatson> not used any more, anyway
[02:47] <twb> Because squashfs?
[02:47] <cjwatson> but that's good; zerofree is new
[02:47] <cjwatson> right, it was only needed with cloop
[02:48] <twb> I hate the cloop stuff, it was icky.
[02:48] <cjwatson> yes
[02:48] <cjwatson> and required special measures to be rsyncable
[10:50] <CIA-1> installation-guide: cjwatson * r421 ubuntu/ (build/entities/urls.ent debian/changelog): * Drop bogus "/ubuntu" from URL to example-preseed on help.ubuntu.com.
[11:24] <CIA-1> ubiquity: cjwatson * r2675 ubiquity/ (debian/changelog ubiquity/zoommap.py): * Silence deprecation warning in zoommap.
[11:26] <CIA-1> oem-config: cjwatson * r462 oem-config/ (debian/changelog lib/zoommap.py): * Silence deprecation warning in zoommap.
[18:21] <CIA-1> ubiquity: evand * r2676 ubiquity/ (debian/changelog ubiquity/zoommap.py):
[18:21] <CIA-1> ubiquity: * Usability fixes for the timezone widget:
[18:21] <CIA-1> ubiquity:  - Make the hover-to-zoom areas relative to the widget size.
[18:21] <CIA-1> ubiquity:  - Zoom in on the location of the cursor, not the edge relative to its
[18:21] <CIA-1> ubiquity:  position.
[18:21] <CIA-1> ubiquity:  - Add a delay for zooming out.
[18:22]  * evand does the hand crank motion next to bazaar.launchpad.net
[18:22] <cjwatson> location not edge> I'd noticed that one, thanks for fixing
[18:23] <evand> no problem
[18:25] <evand> We could do an uninstallation option (wipe and restore the windows bootloader after first backing it up).  Any interest in seeing that, or is the isolinux menu crowded enough :)?
[18:25] <evand> wipe the paritition*
[20:08] <evand> I'll take that as a no :)