[06:16] <CIA-16> migration-assistant: evand * r46 migration-assistant/ (ma-ask ma-script-utils registry.c): order of operations fix.
[06:17] <CIA-16> migration-assistant: evand * r47 migration-assistant/debian/changelog: Releasing 0.4.3
[06:18] <evand> cjwatson: can you push out m-a 0.4.3?  It doesn't fix the fact that Documents and Settings doesn't get translated, but that will be done in the next build.
[06:18] <evand> There are a few other bugs that I wanted to make sure I got a fix out the door for first, which is what this release is.
[10:45] <cjwatson> evand: done
[01:34] <evand> thanks!
[01:49] <CIA-16> ubiquity: cjwatson * r1990 ubiquity/ (3 files in 2 dirs):
[01:49] <CIA-16> ubiquity: * Don't crash if Install exits due to SIGINT, SIGTERM, or SIGKILL, since
[01:49] <CIA-16> ubiquity:  these are probably user-generated.
[01:56] <evand> ah, you beat me to updating those bugs
[02:18] <CIA-16> ubiquity: cjwatson * r1991 ubiquity/ (3 files in 2 dirs):
[02:18] <CIA-16> ubiquity: * Prepare for partman-partitioning/confirm_resize being asked during
[02:18] <CIA-16> ubiquity:  autopartitioning (partman-auto 62ubuntu9).
[04:57] <jetsaredim> anyone around to have their brain picked?
[05:04] <jetsaredim> I guess that's a no
[05:36] <jetsaredim> anyone alive?
[05:47] <cjwatson> always best to ask rather than ask-to-ask
[05:51] <jetsaredim> good point
[05:51] <jetsaredim> so, i'm still having issues with glade
[05:51] <jetsaredim> I tried to upgrade to feisty, but that didn't help
[05:52] <jetsaredim> in any case, I was looking some more at the code
[05:52] <jetsaredim> in the components like user info
[05:52] <jetsaredim> what happens with the data once it is processed with the ok action?
[05:53] <jetsaredim> maybe i should put a storyboard together and that would better illustrate what i'm trying to do
[05:54] <cjwatson> self.preseed tells debconf about it and then the script on the other side (see the prepare method) responds to that
[05:54] <cjwatson> you really need to understand debconf before any of this makes any sense at all
[05:55] <cjwatson> so e.g. UserSetup.ok_handler does self.preseed('passwd/user-fullname', fullname), and the backend script is user-setup-ask
[05:55] <cjwatson> while the GUI is running, user-setup-ask is blocked waiting for what it thinks is debconf but is actually ubiquity to get back to it with the reply to a db_input command
[05:56] <cjwatson> once db_input returns successfully, it continues and retrieves the answers to the various questions from debconf
[05:57] <cjwatson> if any of the debconf questions in the questions list defined in the prepare method are asked using db_input, debconffilter will call the run method of the appropriate component
[05:58] <cjwatson> UserSetup just uses the default run method, which goes "wait for the user to hit Forward"
[06:02] <jetsaredim> hmm
[06:03] <cjwatson> (phone)
[06:03] <jetsaredim> so which packages are affected by debconf when the usersettings are set?
[06:04] <evand> jetsaredim: if you run ubiquity with the --debug option and tail the log file, it should be a little easier to see what's going on.
[06:04] <jetsaredim> maybe usersettings is a bad example based on what I'm looking to do
[06:32] <jetsaredim> i mean basically, there are three system configurations we want to provide access for
[06:33] <jetsaredim> mythtv frontend-only, backend-only and a frontend/backend combo
[06:33] <jetsaredim> and there are configuration settings for each type, some are common to all, some are specific
[06:34] <jetsaredim> its not a lot of configuration, maybe like 5 or 6 packages difference either way
[06:35] <jetsaredim> then the other complicated part is to try and run something in the install chroot, but I think we might have that figured out
[06:35] <jetsaredim> err superm1
[06:38] <cjwatson> usersetup is about the simplest of the components
[06:39] <jetsaredim> i guess i just need to know more about debconf to understand the similarities between what I want to do and what the usersettings is doing
[06:39] <evand> jetsaredim: if you're asking these questions inside the first phase of the graphical installer, you could make a debian-installer component and hook into it from Ubiquity.
[06:39] <evand> jetsaredim: you could then use a select question to figure out which option of frontend-only, backend-only or frontend/backend taht you want and ask more questions from there
[06:40] <evand> gotta run though, I can explain further later if you'd like to take that route
[06:42] <jetsaredim> hmm
[06:42] <jetsaredim> interesting thought
[06:42] <jetsaredim> is there more documentation on setting up a debian-installer script?
[06:52] <evand> jetsaredim: http://people.debian.org/~fjp/talks/debconf6/paper/
[06:52] <evand> there's also a video floating around the internet
[06:54] <jetsaredim> thx
[07:11] <jetsaredim> are there any examples of ubiquity calling out to debian-installer scripts?
[07:13] <cjwatson> er, yeah, that's how most of ubiquity works ...
[07:14] <cjwatson> e.g. user-setup
[07:14] <cjwatson> migration-assistant will be the one that Evan was thinking of, though
[07:25] <jetsaredim> so the component piece that's under the ubiquity tree is just calling the d-i piece?
[07:30] <evand> jetsaredim: to greatly simplify this, lets say that you just want to create a page that asks the user what their favorite color is
[07:30] <jetsaredim> ok
[07:31] <evand> you would create a d-i component that has a script that simply does a "db_input yourcomponent/favoritecolor"
[07:31] <evand> (assuming that yourcomponent/favoritecolor is in your templates file)
[07:31] <evand> (and is a string type)
[07:32] <jetsaredim> ok - so that was my next question
[07:32] <evand> this would have the effect in the alternative installer of presenting an input box to the user
[07:32] <jetsaredim> asking for their favorite color
[07:32] <evand> right
[07:32] <evand> when they fill out this input box, the value they type is inserted into the debconf question yourcomponent/favoritecolor
[07:32] <jetsaredim> when you say template file, do you mean the glade thing?
[07:33] <evand> jetsaredim: no, not at all.  See the debconf guide for information about templates
[07:33] <evand> now, if you wanted to interface ubiquity (the graphical installer) to this, you would create a yourcomponent.py file and place it in ubiquity/components....
[07:34] <cjwatson> "component" is a somewhat dodgy term meaning "interface to backend [usually d-i]  script"
[07:34] <jetsaredim> sure
[07:34] <cjwatson> debconf guide> that's the debconf-devel(7) man page
[07:34] <cjwatson> which is required reading
[07:34] <evand> you'd probably be best served taking usersetup.py and stripping the code out of the functions
[07:35] <evand> in the return statement in prepare you'd type the path to that d-i script (I'm skipping over how a lot of the build works for now)
[07:35] <jetsaredim> and pass that questions thing
[07:35] <jetsaredim> list
[07:35] <evand> the questions object is a list of the questions that you care about
[07:35] <cjwatson> one of these days I will make the interface a bit more rational :-)
[07:36] <evand> so in your case, questions = ['mycomponent/favoritecolor'] 
[07:36] <cjwatson> ubiquity/debconffilter.py is the core of all of this, btw - everything else is conceptually layered on top of that
[07:36] <jetsaredim> ok
[07:37] <jetsaredim> so - where are these templates stored?
[07:37] <cjwatson> if it helps, ubiquity is an intercepting proxy for the debconf protocol. If that is a confusing statement, ignore it. :-)
[07:37] <jetsaredim> no it makes sense
[07:37] <evand> now, you'd want to map that text input to an actual gtk/qt input box
[07:37] <evand> so we step away from mycomponent.py for a second
[07:37] <cjwatson> (I used to write web servers for a living; sometimes it shows)
[07:37] <evand> heh
[07:38] <jetsaredim> so
[07:38] <evand> and open up the glade file (or the kde ui file), make a new page and add an text box to it.  Be sure to name it something like "mycomponent_color" as you will reference it from another file
[07:39] <jetsaredim> k
[07:39] <jetsaredim> that's a topic for Riddell and the kubuntu peeps
[07:39] <evand> we then go into gtkui/kdeui and create a get_favorite_color function.  In that we simply return self.mycomponent_color
[07:40] <evand> as the entire glade namespace gets imported into the current namespace we can reference any glade "item" as if it were a member, so self.mycomponent_color
[07:40] <jetsaredim> ok
[07:41] <jetsaredim> sounds like I should try all of this and write it up
[07:41] <evand> now, we go back into components/mycomponent.py and we either create or go to the ok_handler definition that you copied from usersetup.py.
[07:42] <evand> this function will be called when the user presses the "next" button
[07:42] <jetsaredim> right
[07:42] <evand> so we'll say something like color = self.frontend.get_favorite_color()
[07:43] <evand> which will call that function in the ui code we're using, either gtkui.py or kdeui.py, which will then grab it from the actual interface item
[07:43] <evand> err object
[07:43] <evand> ignore my poor terminology
[07:43] <jetsaredim> no no
[07:43] <jetsaredim> i'm still with ya
[07:43] <jetsaredim> so then
[07:43] <jetsaredim> we have this debconf "thing"
[07:44] <jetsaredim> and its getting set by the return code of the "ok" function?
[07:44] <evand> since our goal is to wrap ubiquity around your d-i component, we're trying to mimick what the d-i component would do, which would be to then store the data it's asking for in debconf...
[07:44] <evand> to do that we use preseed
[07:45] <evand> so right below the "color =" line we preseed the proper question with that data
[07:45] <jetsaredim> ok
[07:45] <jetsaredim> i see all that in usersetup
[07:45] <evand> so self.preseed('yourcomponent/favoritecolor', color)
[07:45] <jetsaredim> right
[07:45] <evand> which will take the value of color and stuff it in that specific debconf question
[07:46] <jetsaredim> ok
[07:46] <evand> I'm leaving out a lot, and this is by no means complete, but I really must be off to work
[07:46] <jetsaredim> so what actually happens to that data/
[07:46] <evand> I hope that at least gives you a better idea of whats going on
[07:46] <evand> jetsaredim: it gets stuffed into debconf until your _apply function looks for it during the actual install
[07:46] <jetsaredim> like - once that template item is preseeded
[07:46] <evand> _apply is another lesson :), good luck for now
[07:47] <jetsaredim> um
[07:47] <jetsaredim> well - so in the usersetup_apply.py
[07:47] <jetsaredim> that's where the information is getting "acted" upon?
[07:48] <jetsaredim> though in the prepare function I only see it calling the user-setup-apply d-i script...
[08:18] <cjwatson> the *_apply components are kind of hacks
[08:19] <cjwatson> the idea is that the regular components ask the questions up-front, and the *_apply ones are called after /target is set up and the live filesystem copied; they call d-i scripts to apply the results of the previous questions to the system
[08:19] <jetsaredim> so how is the data passed?
[08:20] <cjwatson> since applying the results of questions you've already asked typically doesn't involve asking any questions (unless something goes wrong), there's no need for the component to be very complicated
[08:20] <cjwatson> it's still in the debconf database from when the questions were asked earlier
[08:20] <jetsaredim> also - is the apply command run in the chroot?
[08:20] <cjwatson> no
[08:21] <jetsaredim> how do things get hooked into there?
[08:21] <cjwatson> d-i uses /target too, so scripts designed to run in d-i are typically set up to work with /target
[08:21] <jetsaredim> i c
[08:21] <cjwatson> they either put /target on the front of paths explicitly (if they're just writing out files or whatever), or they chroot
[08:21] <jetsaredim> but would that be the place to put such things?
[08:24] <cjwatson> what things?
[08:24] <jetsaredim> like if I needed to run something in the installed system chroot
[08:25] <jetsaredim> mythtv has a whole gui-based setup program
[08:25] <jetsaredim> and re-implementing it for the sake of fitting in with ubiquity or d-i would be a nightmare
[08:25] <cjwatson> right, though running a GUI will be an utter pain in the backside, as I said earlier
[08:25] <cjwatson> possible, but you'll have to mess with xauth and such to make it work
[08:26] <jetsaredim> sure
[08:26] <jetsaredim> ok - i gotta strip all of the evand posts out into a checklist or something and give this a go
[08:27] <jetsaredim> how do you guys normally test this stuff?
[08:29] <jetsaredim> i'm guessing that you don't build an entire iso every time and boot it in an emulator or something
[08:38] <evand> jetsaredim: no, I'll build a deb of my component, add it to my local repository, then do a make in ubiquity/d-i and then build the ubiquity package.  Then I'll scp ubiquity-frontend-gtk ubiquity-ubuntu-artwork and ubiqutity to an intermediate host, and scp it in from the virtual machine.  Then it's a simple matter of sudo dpkg -i *.deb and ubiquity -d.
[08:39] <evand> If you're making minor changes you can always edit the files inside the VM
[08:39] <evand> jetsaredim: there's a little more to including a component in the ubiquity build system than that though
[08:44] <evand> see debian/ubiquity.install-any and d-i/lists/any
[08:44] <evand> in the ubiquity package
[09:21] <jetsaredim> hmm
[09:21] <jetsaredim> i thought that i could just take a snapshot of the livecd
[09:21] <jetsaredim> and then modify the ubiquity src in there, no?
[09:21] <jetsaredim> doesn't rebuilding the livecd rebuild ubiquity as well?
[10:04] <cjwatson> I usually either rsync new source into the live session and build it in /tmp on the fly, or I scp over the changed source files, or I just hack stuff in place
[10:06] <jetsaredim> but does rebuilding the livecd work too?
[10:07] <jetsaredim> granted - its the long way around
[10:07] <cjwatson> if you  the filesystem, yes
[10:07] <cjwatson> if you modify the filesystem, yes
[10:07] <jetsaredim> so just changing the ubiquity source isn't enough?
[10:11] <cjwatson> er
[10:11] <cjwatson> where do you think the source is?
[10:14] <jetsaredim> i meant versus the livecd filesystem
[10:14] <jetsaredim> was just clarifying
[10:19] <cjwatson> I don't really understand you, sorry
[10:20] <cjwatson> changing the source is not enough unless you actually get it into the live session somehow, obviously :-)
[10:23] <jetsaredim> right
[10:23] <jetsaredim> what i meant was - I should be able to change the ubiquity source and then rebuild the livecd iso and see my changes
[10:23] <jetsaredim> right?
[10:24] <cjwatson> well, that would depend on how you rebuild the ISO, no?
[10:24] <cjwatson> there are multiple stages involved there
[10:24] <cjwatson> the ubiquity package build; the live filesystem; the actual ISO image itself
[10:25] <jetsaredim> isn't there a script at the top level of the livedisk directory?
[10:25] <cjwatson> no
[10:26] <jetsaredim> hmm
[10:26] <jetsaredim> must have been created by the mythbuntu project people
[10:42] <jetsaredim> evand: so where am I going to add this new page in the hierarchy of the ubiquity.glade layout?
[10:42] <jetsaredim> under wizard?
[10:56] <jetsaredim> i must really be dense cause I'm not getting how to add a new screen to the glade file