| === 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 | ||
| CIA-16 | migration-assistant: evand * r46 migration-assistant/ (ma-ask ma-script-utils registry.c): order of operations fix. | 06:16 |
|---|---|---|
| CIA-16 | migration-assistant: evand * r47 migration-assistant/debian/changelog: Releasing 0.4.3 | 06:17 |
| 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. | 06:18 |
| === 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 | ||
| cjwatson | evand: done | 10:45 |
| === pkt [n=knoppix@85.75.170.118] has joined #ubuntu-installer | ||
| evand | thanks! | 01:34 |
| 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:49 |
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer | ||
| evand | ah, you beat me to updating those bugs | 01:56 |
| 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). | 02:18 |
| === 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 | ||
| jetsaredim | anyone around to have their brain picked? | 04:57 |
| jetsaredim | I guess that's a no | 05:04 |
| === mpt [n=mpt@121-72-130-40.dsl.telstraclear.net] has joined #ubuntu-installer | ||
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-installer | ||
| jetsaredim | anyone alive? | 05:36 |
| cjwatson | always best to ask rather than ask-to-ask | 05:47 |
| 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:51 |
| 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:52 |
| jetsaredim | maybe i should put a storyboard together and that would better illustrate what i'm trying to do | 05:53 |
| 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:54 |
| 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:55 |
| cjwatson | once db_input returns successfully, it continues and retrieves the answers to the various questions from debconf | 05:56 |
| 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:57 |
| cjwatson | UserSetup just uses the default run method, which goes "wait for the user to hit Forward" | 05:58 |
| jetsaredim | hmm | 06:02 |
| cjwatson | (phone) | 06:03 |
| jetsaredim | so which packages are affected by debconf when the usersettings are set? | 06:03 |
| 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:04 |
| jetsaredim | i mean basically, there are three system configurations we want to provide access for | 06:32 |
| 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:33 |
| jetsaredim | its not a lot of configuration, maybe like 5 or 6 packages difference either way | 06:34 |
| 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:35 |
| cjwatson | usersetup is about the simplest of the components | 06:38 |
| 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:39 |
| evand | gotta run though, I can explain further later if you'd like to take that route | 06:40 |
| jetsaredim | hmm | 06:42 |
| jetsaredim | interesting thought | 06:42 |
| jetsaredim | is there more documentation on setting up a debian-installer script? | 06:42 |
| evand | jetsaredim: http://people.debian.org/~fjp/talks/debconf6/paper/ | 06:52 |
| evand | there's also a video floating around the internet | 06:52 |
| === evand departs for real this time | ||
| jetsaredim | thx | 06:54 |
| jetsaredim | are there any examples of ubiquity calling out to debian-installer scripts? | 07:11 |
| cjwatson | er, yeah, that's how most of ubiquity works ... | 07:13 |
| cjwatson | e.g. user-setup | 07:14 |
| cjwatson | migration-assistant will be the one that Evan was thinking of, though | 07:14 |
| jetsaredim | so the component piece that's under the ubiquity tree is just calling the d-i piece? | 07:25 |
| 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:30 |
| === jetsaredim feels a wiki/howto coming on | ||
| 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:31 |
| 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:32 |
| 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:33 |
| cjwatson | "component" is a somewhat dodgy term meaning "interface to backend [usually d-i] script" | 07:34 |
| === jetsaredim lightbulb dimly-lit | ||
| 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:34 |
| 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:35 |
| === cjwatson -> dinner | ||
| 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:36 |
| 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:37 |
| 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:38 |
| jetsaredim | k | 07:39 |
| === jetsaredim is still stuck with glade issues, but ok | ||
| 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:39 |
| 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:40 |
| === jetsaredim is sorta following | ||
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| jetsaredim | though in the prepare function I only see it calling the user-setup-apply d-i script... | 07:48 |
| === rrittenhouse [n=tad@unaffiliated/rrittenhouse] has joined #ubuntu-installer | ||
| cjwatson | the *_apply components are kind of hacks | 08:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| cjwatson | what things? | 08:24 |
| jetsaredim | like if I needed to run something in the installed system chroot | 08:24 |
| 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:25 |
| 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:26 |
| jetsaredim | how do you guys normally test this stuff? | 08:27 |
| jetsaredim | i'm guessing that you don't build an entire iso every time and boot it in an emulator or something | 08:29 |
| 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:38 |
| 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:39 |
| evand | see debian/ubiquity.install-any and d-i/lists/any | 08:44 |
| evand | in the ubiquity package | 08:44 |
| 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? | 09:21 |
| 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:04 |
| jetsaredim | but does rebuilding the livecd work too? | 10:06 |
| 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:07 |
| cjwatson | er | 10:11 |
| cjwatson | where do you think the source is? | 10:11 |
| jetsaredim | i meant versus the livecd filesystem | 10:14 |
| jetsaredim | was just clarifying | 10:14 |
| cjwatson | I don't really understand you, sorry | 10:19 |
| cjwatson | changing the source is not enough unless you actually get it into the live session somehow, obviously :-) | 10:20 |
| 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:23 |
| 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:24 |
| jetsaredim | isn't there a script at the top level of the livedisk directory? | 10:25 |
| cjwatson | no | 10:25 |
| jetsaredim | hmm | 10:26 |
| === pkt__ [n=knoppix@85.73.129.9] has joined #ubuntu-installer | ||
| jetsaredim | must have been created by the mythbuntu project people | 10:26 |
| 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:42 |
| === jetsaredim wishes there were more resources explaining glade on the interweb | ||
| jetsaredim | i must really be dense cause I'm not getting how to add a new screen to the glade file | 10:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!