=== rrittenhouse [n=tad@unaffiliated/rrittenhouse] has joined #ubuntu-installer === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer === cr3 [n=marc@pdpc/supporter/bronze/cr3] has joined #ubuntu-installer === avoine [n=avoine@modemcable056.3-203-24.mc.videotron.ca] has joined #ubuntu-installer === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer [06:16] migration-assistant: evand * r46 migration-assistant/ (ma-ask ma-script-utils registry.c): order of operations fix. [06:17] migration-assistant: evand * r47 migration-assistant/debian/changelog: Releasing 0.4.3 [06:18] 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] 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. === jetsaredim [n=jgreenwa@inet-netcache2-o.oracle.com] has joined #ubuntu-installer === jetsaredim still cannot get glade working properly under kubuntu === pkt_ [n=knoppix@85.73.168.46] has joined #ubuntu-installer === pkt [n=knoppix@85.73.168.46] has joined #ubuntu-installer === pkt [n=knoppix@85.73.168.46] has joined #ubuntu-installer [10:45] evand: done === pkt [n=knoppix@85.75.170.118] has joined #ubuntu-installer [01:34] thanks! [01:49] ubiquity: cjwatson * r1990 ubiquity/ (3 files in 2 dirs): [01:49] ubiquity: * Don't crash if Install exits due to SIGINT, SIGTERM, or SIGKILL, since [01:49] ubiquity: these are probably user-generated. === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer [01:56] ah, you beat me to updating those bugs [02:18] ubiquity: cjwatson * r1991 ubiquity/ (3 files in 2 dirs): [02:18] ubiquity: * Prepare for partman-partitioning/confirm_resize being asked during [02:18] ubiquity: autopartitioning (partman-auto 62ubuntu9). === cr3 [n=marc@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-installer === evand [n=evand@ubuntu/member/evand] has joined #ubuntu-installer === pkt_ [n=knoppix@athedsl-160472.home.otenet.gr] has joined #ubuntu-installer === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer === jetsaredim [n=jgreenwa@inet-netcache2-o.oracle.com] has joined #ubuntu-installer [04:57] anyone around to have their brain picked? [05:04] I guess that's a no === mpt [n=mpt@121-72-130-40.dsl.telstraclear.net] has joined #ubuntu-installer === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer [05:36] anyone alive? [05:47] always best to ask rather than ask-to-ask [05:51] good point [05:51] so, i'm still having issues with glade [05:51] I tried to upgrade to feisty, but that didn't help [05:52] in any case, I was looking some more at the code [05:52] in the components like user info [05:52] what happens with the data once it is processed with the ok action? [05:53] maybe i should put a storyboard together and that would better illustrate what i'm trying to do [05:54] self.preseed tells debconf about it and then the script on the other side (see the prepare method) responds to that [05:54] you really need to understand debconf before any of this makes any sense at all [05:55] so e.g. UserSetup.ok_handler does self.preseed('passwd/user-fullname', fullname), and the backend script is user-setup-ask [05:55] 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] once db_input returns successfully, it continues and retrieves the answers to the various questions from debconf [05:57] 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] UserSetup just uses the default run method, which goes "wait for the user to hit Forward" [06:02] hmm [06:03] (phone) [06:03] so which packages are affected by debconf when the usersettings are set? [06:04] 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] maybe usersettings is a bad example based on what I'm looking to do [06:32] i mean basically, there are three system configurations we want to provide access for [06:33] mythtv frontend-only, backend-only and a frontend/backend combo [06:33] and there are configuration settings for each type, some are common to all, some are specific [06:34] its not a lot of configuration, maybe like 5 or 6 packages difference either way [06:35] 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] err superm1 [06:38] usersetup is about the simplest of the components [06:39] 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] 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] 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] gotta run though, I can explain further later if you'd like to take that route [06:42] hmm [06:42] interesting thought [06:42] is there more documentation on setting up a debian-installer script? [06:52] jetsaredim: http://people.debian.org/~fjp/talks/debconf6/paper/ [06:52] there's also a video floating around the internet === evand departs for real this time [06:54] thx [07:11] are there any examples of ubiquity calling out to debian-installer scripts? [07:13] er, yeah, that's how most of ubiquity works ... [07:14] e.g. user-setup [07:14] migration-assistant will be the one that Evan was thinking of, though [07:25] so the component piece that's under the ubiquity tree is just calling the d-i piece? [07:30] 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] ok === jetsaredim feels a wiki/howto coming on [07:31] you would create a d-i component that has a script that simply does a "db_input yourcomponent/favoritecolor" [07:31] (assuming that yourcomponent/favoritecolor is in your templates file) [07:31] (and is a string type) [07:32] ok - so that was my next question [07:32] this would have the effect in the alternative installer of presenting an input box to the user [07:32] asking for their favorite color [07:32] right [07:32] when they fill out this input box, the value they type is inserted into the debconf question yourcomponent/favoritecolor [07:32] when you say template file, do you mean the glade thing? [07:33] jetsaredim: no, not at all. See the debconf guide for information about templates [07:33] 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] "component" is a somewhat dodgy term meaning "interface to backend [usually d-i] script" === jetsaredim lightbulb dimly-lit [07:34] sure [07:34] debconf guide> that's the debconf-devel(7) man page [07:34] which is required reading [07:34] you'd probably be best served taking usersetup.py and stripping the code out of the functions [07:35] 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] and pass that questions thing [07:35] list [07:35] the questions object is a list of the questions that you care about [07:35] one of these days I will make the interface a bit more rational :-) === cjwatson -> dinner [07:36] so in your case, questions = ['mycomponent/favoritecolor'] [07:36] ubiquity/debconffilter.py is the core of all of this, btw - everything else is conceptually layered on top of that [07:36] ok [07:37] so - where are these templates stored? [07:37] if it helps, ubiquity is an intercepting proxy for the debconf protocol. If that is a confusing statement, ignore it. :-) [07:37] no it makes sense [07:37] now, you'd want to map that text input to an actual gtk/qt input box [07:37] so we step away from mycomponent.py for a second [07:37] (I used to write web servers for a living; sometimes it shows) [07:37] heh [07:38] so [07:38] 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] k === jetsaredim is still stuck with glade issues, but ok [07:39] that's a topic for Riddell and the kubuntu peeps [07:39] we then go into gtkui/kdeui and create a get_favorite_color function. In that we simply return self.mycomponent_color [07:40] 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] ok === jetsaredim is sorta following [07:41] sounds like I should try all of this and write it up [07:41] 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] this function will be called when the user presses the "next" button [07:42] right [07:42] so we'll say something like color = self.frontend.get_favorite_color() [07:43] 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] err object [07:43] ignore my poor terminology [07:43] no no [07:43] i'm still with ya [07:43] so then [07:43] we have this debconf "thing" [07:44] and its getting set by the return code of the "ok" function? [07:44] 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] to do that we use preseed [07:45] so right below the "color =" line we preseed the proper question with that data [07:45] ok [07:45] i see all that in usersetup [07:45] so self.preseed('yourcomponent/favoritecolor', color) [07:45] right [07:45] which will take the value of color and stuff it in that specific debconf question [07:46] ok [07:46] I'm leaving out a lot, and this is by no means complete, but I really must be off to work [07:46] so what actually happens to that data/ [07:46] I hope that at least gives you a better idea of whats going on [07:46] jetsaredim: it gets stuffed into debconf until your _apply function looks for it during the actual install [07:46] like - once that template item is preseeded [07:46] _apply is another lesson :), good luck for now [07:47] um [07:47] well - so in the usersetup_apply.py [07:47] that's where the information is getting "acted" upon? [07:48] though in the prepare function I only see it calling the user-setup-apply d-i script... === rrittenhouse [n=tad@unaffiliated/rrittenhouse] has joined #ubuntu-installer [08:18] the *_apply components are kind of hacks [08:19] 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] so how is the data passed? [08:20] 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] it's still in the debconf database from when the questions were asked earlier [08:20] also - is the apply command run in the chroot? [08:20] no [08:21] how do things get hooked into there? [08:21] d-i uses /target too, so scripts designed to run in d-i are typically set up to work with /target [08:21] i c [08:21] they either put /target on the front of paths explicitly (if they're just writing out files or whatever), or they chroot [08:21] but would that be the place to put such things? [08:24] what things? [08:24] like if I needed to run something in the installed system chroot [08:25] mythtv has a whole gui-based setup program [08:25] and re-implementing it for the sake of fitting in with ubiquity or d-i would be a nightmare [08:25] right, though running a GUI will be an utter pain in the backside, as I said earlier [08:25] possible, but you'll have to mess with xauth and such to make it work [08:26] sure [08:26] ok - i gotta strip all of the evand posts out into a checklist or something and give this a go [08:27] how do you guys normally test this stuff? [08:29] i'm guessing that you don't build an entire iso every time and boot it in an emulator or something [08:38] 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] If you're making minor changes you can always edit the files inside the VM [08:39] jetsaredim: there's a little more to including a component in the ubiquity build system than that though [08:44] see debian/ubiquity.install-any and d-i/lists/any [08:44] in the ubiquity package [09:21] hmm [09:21] i thought that i could just take a snapshot of the livecd [09:21] and then modify the ubiquity src in there, no? [09:21] doesn't rebuilding the livecd rebuild ubiquity as well? [10:04] 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] but does rebuilding the livecd work too? [10:07] granted - its the long way around [10:07] if you the filesystem, yes [10:07] if you modify the filesystem, yes [10:07] so just changing the ubiquity source isn't enough? [10:11] er [10:11] where do you think the source is? [10:14] i meant versus the livecd filesystem [10:14] was just clarifying [10:19] I don't really understand you, sorry [10:20] changing the source is not enough unless you actually get it into the live session somehow, obviously :-) [10:23] right [10:23] 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] right? [10:24] well, that would depend on how you rebuild the ISO, no? [10:24] there are multiple stages involved there [10:24] the ubiquity package build; the live filesystem; the actual ISO image itself [10:25] isn't there a script at the top level of the livedisk directory? [10:25] no [10:26] hmm === pkt__ [n=knoppix@85.73.129.9] has joined #ubuntu-installer [10:26] must have been created by the mythbuntu project people [10:42] evand: so where am I going to add this new page in the hierarchy of the ubiquity.glade layout? [10:42] under wizard? === jetsaredim wishes there were more resources explaining glade on the interweb [10:56] i must really be dense cause I'm not getting how to add a new screen to the glade file