[02:00] <paulm_> Hi. Any live cd gurus here?
[02:01] <cjwatson> I play one on TV. What's up?
[02:02] <paulm_> cjwatson: :-) is it possible to setup a static IP on a live cd?
[02:03] <cjwatson> paulm_: are you concerned about the running live CD, or installing from it, or both?
[02:04] <paulm_> cjwatson:  it's a custom live cd, running off a USB stick.  Not worried about installing off it.
[02:05] <cjwatson> paulm_: ok, in that case not at the moment without modifying casper, I'm afrid
[02:05] <cjwatson> afraid
[02:05] <cjwatson> oh, hang on
[02:05] <cjwatson> there's a weird partially-merged thing here
[02:06] <paulm_> cjwatson:  the man page alludes to one being able to do it.
[02:06] <cjwatson> paulm_: I think booting with something like STATICIP=eth0:192.168.0.2:255.255.255.0:192.168.0.1 might do it
[02:06] <cjwatson> name:address:netmask:gateway
[02:07] <cjwatson> maybe , not :
[02:07] <cjwatson> the ip= thing *should* work but some changes from Debian's casper weren't merged properly :(
[02:07] <paulm_> cjwatson: where you looking at scripts/23networking which is part of the boot cd initrd?
[02:07] <paulm_> ok, so I'm not going mad then.
[02:07] <paulm_> ;-)
[02:08] <cjwatson> let me see if I can repair any of this
[02:09] <paulm_> it would seem to me that the nfs booting might work, but the static IP won't
[02:09] <cjwatson> I don't see a reason why STATICIP= won't work
[02:09] <cjwatson> ip= won't 'cos the command line parsing isn't there
[02:09] <paulm_> I asked a question (#10492) in launchpad regarding this.
[02:10] <cjwatson> paulm_: I've turned that into a bug report
[02:10] <paulm_> ok let me quickly try staticip.
[02:11] <cjwatson> oops, shouldn't have been on casper upstream though
[02:11] <cjwatson> STATICIP, caps are important
[02:11] <cjwatson> paulm_: bug 128689
[02:20] <cjwatson> paulm_: if it works, let me know, I have the patch here in my casper working tree to fix the ip= boot option
[02:21] <paulm_> cjwatson: ok
[02:21] <paulm_> cjwatson:  just faffing with qemu parameters
[02:21] <paulm_> cjwatson: it's booting right now.
[02:22] <paulm_> cjwatson:  why is their only one package for casper?  It seems it is just for upstream.
[02:25] <cjwatson> paulm_: hmm? casper was written as an Ubuntu package ...
[02:26] <cjwatson> in any case I don't think anyone ever really looks at bugs.launchpad.net/casper
[02:26] <cjwatson> (only bugs.launchpad.net/ubuntu/+source/casper)
[02:27] <paulm_> cjwatson: i see, so bugs are generally lodged against their source packages?
[02:28] <paulm_> cjwatson: or is it because in this case it is a source code problem?
[02:28] <cjwatson> paulm_: if you're experiencing them in Ubuntu rather than by building the source package on some other distribution and determining that there's a bug in the upstream code, then yes, they should be filed against the source package
[02:30] <paulm_> cjwatson: ok, but isn't the ubuntu source code different from the upstream src code?
[02:31] <cjwatson> in this case, Ubuntu is upsteam
[02:31] <cjwatson> upstream
[02:31] <cjwatson> although in general, yes - which is exactly why if you're reproducing a bug in Ubuntu you should file it on Ubuntu, since it might be Ubuntu-specific
[02:34] <paulm_> ok, so i guess my confusion comes in that I am unable to determine from https://launchpad.net/casper : 1) what/where the source code package is (2) whether or not launchpad knows that it belongs to ubuntu
[02:35] <cjwatson> yeah, I'm not going to get into the Launchpad UI for it, I have no control over that
[02:35] <paulm_> :-)
[02:35] <cjwatson> my general recommendation to people filing bugs on Ubuntu is to start at https://bugs.launchpad.net/ubuntu
[02:41] <paulm_> cjwatson:  STATICIP, seems to have done something weird...
[02:43] <paulm_> cjwatson:  while it hasn't got it the /etc/network/interfaces right, it HAS changed something in it.  Just need to check that it wasn't my fiddling last night with the 23networking script that caused it.
[03:23] <cjwatson> tepsipakki: debconf 1.5.14 seems to be basically working here, so if you could try a few gutsy install tests on a machine where previous versions were hanging in pkgsel, I'd greatly appreciate it
[03:24] <cjwatson> tepsipakki: if we can confirm that it fixes the hang, there's a chance I can get the fix into Ubuntu 6.06.2
[03:24] <cjwatson> it's a complicated fix, but it's basically self-contained
[03:53] <paulm_> cjwatson: STATICIP with the format eth0,192.168.1.2,255.255.255.0,192.168.1.1 works with std feisty iso.
[03:55] <paulm_> cjwatson: so I guess this needs to go into the casper man page?  and or the IP parameter needs to be patched?
[03:57] <cjwatson> just the latter
[03:58] <cjwatson> thanks for the test, I'll get that fixed in gutsy shortly
[04:00] <paulm_> cjwatson:  great!
[04:07] <cjwatson> paulm_: ok, ip= should work in tomorrow's gutsy live CD build, assuming it builds properly
[04:11] <paulm_> cjwatson: good stuff.  Is it possible to download just the patch?  or the initrd.gz?
[04:21] <tepsipakki> cjwatson: ok, I'll try when I get back to work (a week from now)
[04:52] <cjwatson> paulm_: I doubt we support running gutsy's initrd with an otherwise feisty live CD
[04:53] <cjwatson> paulm_: the patch is here: http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/revision/cjwatson%40canonical.com-20070727135921-59v71wt3sr6a1leb?start_revid=cjwatson%40canonical.com-20070727140415-k6yclgeve2h6xck1
[04:53] <cjwatson> tepsipakki: thanks
[05:07] <paulm_> cjwatson:  no worries, just interested to see the changes.  Thanks for your help.  It's weekend time. :-)
[07:06] <cjwatson> I think I'm in the position of being able to debug partman-auto-loop into existence now, which is good
[07:07] <superm1> When using the --automatic, how is a decision made upon what to partition?
[07:08] <cjwatson> preseeding, I'd have thought
[07:09] <superm1> so making an assumption then at least to what disks are present when things are preseeded
[07:09] <cjwatson> same as automatic d-i installs
[07:09] <superm1> i see
[07:09] <cjwatson> last I checked anyway, the point of --automatic was to let you preseed ubiquity the way you can preseed d-i
[07:20] <evand> indeed, it's all preseeding
[07:20] <evand> if you don't preseed a question it needs to ask, it's supposed to error out (it doesn't do that in all cases yet)
[07:21] <superm1> and this preseeding can be done via the seed at the root of the cd, eg ubuntu.seed et al
[07:21] <evand> yes
[07:21] <evand> but --automatic does not work perfectly with gtkui yet.
[07:22] <evand> it doesn't do page skipping, which I'm working on, on my local system
[07:22] <superm1> once it's working as expected in gtkui, i might opt to port that over to the mythbuntu_ui as well.  i can see that very useful for someone who wants to do an install no questions asked and just use their one big disk
[07:22] <evand> currently -> partman is being annoying, but the rest works
[07:23] <evand> so I should be able to commit that soon
[07:23] <evand> err by page skipping, I mean graceful page skipping.  That is, not showing filled pages for a brief moment and then skipping to the next page
[07:23] <superm1> you can't use a .hide()?
[07:23] <superm1> on the interface
[07:24] <evand> that's actually still a bit of work (knowing when to call it), and the effect that produces (constantly disappearing UI) is not the best solution
[07:25] <evand> this way it stays on the last page until it has a page to show (skipping the ones that don't have questions to ask)
[07:25] <superm1> so --automatic is still showing the summary page then
[07:25] <superm1> giving you a chance to ack it
[07:26] <mirkobuholzer> hi evand and superm1
[07:26] <superm1> hi mirkobuholzer
[07:26] <evand> yes and no.  I believe there's still a bug on the summary page where if you don't preseed an answer to it, and thus skip it, it sits there in limbo, never calling allow_go_forward.
[07:26] <mirkobuholzer> what about if the summary is also a answer
[07:27] <evand> hello mirkobuholzer
[07:27] <evand> Template: ubiquity/summary
[07:27] <mirkobuholzer> meaning that you could also provide a preseed answer to skip the summary page
[07:27] <evand> so right now, it's possible to do the entire install unattended
[07:28] <mirkobuholzer> great
[07:28] <superm1> perhaps would it be better to not even show any of the interface, and rather a specially crafted page for that summary, to get around both those issues?
[07:28] <evand> you hit f6 and change the kernel parameters to include url=http://evalicious.com/evan.seed (or whatever you want)
[07:28] <evand> and then launch ubiquity with ubiquity --automatic
[07:29] <evand> and after saying yes to the welcome page (I'll fix that), it should go through the rest without issue
[07:29] <evand> or you can add noninteractive to the kernel parameters and it will do an install without ever starting X
[07:29] <evand> superm1: specially crafted page? get around what issues?
[07:30] <superm1> so that you don't have any of the interface showing as the data is preseeded
[07:30] <superm1> just show an alternative summary dialog that isn't part of the normal interface
[07:30] <evand> superm1: well, it still needs to check if your data is correct, so what it does (on my local system) is that it runs the dbfilters until it has a question to ask, then it shows that page
[07:31] <evand> now, if there are no questions, it will sit there running through the questions and then show the install progress dialog
[07:31] <cjwatson> superm1: normally much better to make it all run smoothly than hack about with alternative dialogs :)
[07:31] <superm1> oh didn't consider that
[07:31] <evand> which is the eventual goal for wubi, if I remember correctly
[07:32] <superm1> well this reminds me of something else i had wanted to ask then too.  would it be feasible to derive another class from partman that the standard option chosen creates an additional partition and mount point, or will that be more work than worth?
[07:33] <cjwatson> superm1: that doesn't belong in ubiquity
[07:33] <evand> superm1: preseed the partition settings
[07:33] <cjwatson> superm1: could you give a concrete example, though?
[07:33] <evand> but then you can't do dual boots, afaik
[07:33] <superm1> okay concrete example:
[07:33] <cjwatson> evand: you could if you were using the auto-resize option
[07:34] <cjwatson> which == resize then autopartition free space
[07:34] <superm1> most myth installs setup a seperate partition for /var/lib or /var/lib/mythtv, and put most of their space there - and only 10G or so to the OS
[07:34] <cjwatson> superm1: sounds like a perfect example of an autopartitioning recipe; see the docs
[07:34] <evand> cjwatson: would that work if there were no partitions available?  I haven't looked much at that part of the code
[07:34] <superm1> alright cjwatson, will do :)
[07:34] <cjwatson> evand: you mean a blank disk?
[07:35] <evand> cjwatson: right, so if I have a blank disk with a resize recipe, will it error out?
[07:35] <evand> as there's nothing to resize
[07:35] <cjwatson> evand: it will, but then dual-booting isn't a concern ;)
[07:35] <evand> cjwatson: well I'm thinking that superm1 may have users who dual boot, others who don't.
[07:36] <cjwatson> oh, right. we might have to provide the facility for custom hook scripts that can look at that
[07:36] <cjwatson> and generate a recipe on the fly
[07:36] <superm1> well the type of person that sets up a mythbuntu install, i wouldn't expect to dual boot the box
[07:36] <superm1> since its typically a standalone machine as a target
[07:36] <cjwatson> come ON, busybox, build
[07:37] <evand> haha
[07:39] <cjwatson> the problem with debugging stuff into existence is keeping track of the extra random stuff in your running copy of d-i
[07:41] <evand> indeed
[08:09] <evand__> arr
[08:19] <superm1> cjwatson, when trying to use debconf in other applications, i saw there is a debconf.py that can be imported.  When I tried to use it however, it appears that it tries to run interactively (not good for a PyGTK app)  I looked for some docs upon it, I didn't seem to find any.  is there anything somewhat informative you could point me at with regard to the proper way to be using debconf other than bringing in a lot of the code from what
[08:19] <superm1> ubiquity is doing to use it?
[08:58] <cjwatson> superm1: you need to call debconf.runFrontEnd() at the top of your program if you don't have a debconf frontend running already
[08:58] <cjwatson> superm1: ubiquity does very complicated things to act a bit like a debconf frontend, which isn't the sort of thing you'd want to try to do in anything simpler
[09:00] <superm1> cjwatson, ah okay
[09:00] <superm1> that would be the issue then
[09:00] <superm1> i'll experiment more with it tonight when i get home
[09:02] <cjwatson> if you need to use INPUT and GO, then you need to do the sort of stuff that ubiquity's doing
[09:02] <cjwatson> but it's probably not a good idea unless you're prepared to put that level of work into it - might well be better and simpler to just use GET, SET, FGET, FSET, and that sort of thing
[09:02] <cjwatson> pure database work
[09:08] <superm1> i was planning on sticking to GET and SET
[09:08] <superm1> so things should be okay then
[09:12] <cjwatson> yeah