[02:05] <cjwatson> dear console-setup, please build more quickly, love Colin
[02:06] <stgraber> :)
[02:09] <cjwatson> stgraber: preseed apt-setup/use_mirror to false, I think
[02:10] <stgraber> cjwatson: thanks, I'll try
[02:47] <cjwatson> tepsipakki: you're sure you're prepared for the massive mail volume that ubuntu-installer gets (all ubiquity bugs, for instance)?
[02:47] <tepsipakki> hmm
[02:47] <tepsipakki> I knew there was a catch ;)
[02:47] <cjwatson> you've sent patches before so I'm fine with adding you, but you'll probably want to set up filtering
[02:48] <tepsipakki> all bugmail go to a specific folder
[02:48] <tepsipakki> but maybe I should add another for those
[02:48] <cjwatson> I have
[02:48] <cjwatson> :0:
[02:48] <cjwatson> * ^X-Launchpad-Bug: distribution=ubuntu;.*sourcepackage=ubiquity
[02:48] <cjwatson> ubuntu/bugs-ubiquity
[02:49] <tepsipakki> yep, I'll write a rule for sieve in a minute, so I'm fine with it :)
[02:49] <tepsipakki> do you mind me looking at some of the pending merges?
[02:49] <tepsipakki> like rootskel
[02:51] <tepsipakki> just to keep them in sync
[03:01] <cjwatson> tepsipakki: you'd need to be in ubuntu-core-dev ...
[03:02] <cjwatson> tepsipakki: in principle I don't mind, but most of those packages are maintained in bzr and it's usually just as easy for somebody in ubuntu-core-dev to bzr merge directly as to review and merge somebody else's bzr merge
[03:02] <cjwatson> unless the merge is very complicated
[03:03] <tepsipakki> ah, ok
[03:03] <cjwatson> I would, however, like there to be somebody else in ubuntu-core-dev willing to take care of a chunk of the installer merge work
[03:03] <tepsipakki> :)
[03:03] <cjwatson> so if that's something you want to help with, I'd support it
[03:03] <tepsipakki> to get in core-dev?-)
[03:03] <tepsipakki> I'm not even -dev yet
[03:04] <cjwatson> yeah, it might take a while
[03:04] <tepsipakki> but I've done some minor merges and stuff to get some credibility ;)
[03:08] <cjwatson> but yeah, the merge load is something that can be spread out relatively easily, and as long as you're reasonably careful it's a good way to get an idea of the sorts of changes made to the installer in Ubuntu
[03:09] <tepsipakki> yep
[03:10] <tepsipakki> hmm, you could maybe add some links to the /topic
[03:10] <tepsipakki> like, this one http://people.debian.org/~fjp/talks/debconf6/paper/
[03:11] <tepsipakki> it's a good reference, and seen it here pasted quite often ;)
[03:13] <cjwatson> how's that? links to fjp's paper
[03:13] <tepsipakki> yes, works
[03:13] <cjwatson> I'm trying to get the CIA bot in here too to track commits, but Micah hasn't answered my mail yet
[04:44] <tepsipakki> hmm, how can I run multiple commands with in-target, does it accept parentheses?
[04:45] <tepsipakki> maybe I'll just shove them in a script
[04:52] <cjwatson> it ends up doing:
[04:52] <cjwatson> log-output -t in-target chroot /target "$@" || ERRCODE=$?
[04:52] <cjwatson> so you can use sh -c '...'
[04:53] <cjwatson> sh -c 'foo; bar; baz' or whatever
[04:55] <tepsipakki> ok, thanks
[04:55] <tepsipakki> just noticed that it failed
[04:57] <tepsipakki> I could also just put the scripts in finish-install.d :)
[05:01] <cjwatson> that works too, though you might want to chain to in-target from those
[05:08] <tepsipakki> how's that?
[05:08] <tepsipakki> error handling?
[05:24] <cjwatson> tepsipakki: in-target deals with debconf plumbing, so if you need to install packages it's best to use in-target
[05:27] <tepsipakki> ah, right