[00:48] What code in Ubiquity causes it to auto-advance if all questions for a page are answered? [00:48] I'm having trouble understanding the structure [02:23] FireRabbit: It's called preseeding [02:27] StevenK: Yes I know, I'm wondering what actually causes the UI to advance [03:12] FireRabbit, see ubiquity/ubiquity/debconffilter.py. search for the reference to UBIQUITY_AUTOMATIC [03:13] and similar references in gtk_ui.py [03:15] in gtk_ui, the dbfilter gets started at the beginning of a page. if all of the questions get answered by debconffilter, the page gets advanced [03:15] (more or less) [08:52] hi davmor2 [08:53] hello [08:53] missed part of the conversation yesterday, but followed up on the logs [08:53] xivulon: didn't have time to get the logs last night in the end so I'm about to get them now [08:53] so 'missing L', I think I didn't get that [08:54] was the error about formatting the swap file? [08:54] there is xivuon and xivulon :) one missing L [08:54] ah :) [08:55] as for the swap that seems to be an old issue, due to fragmentation [08:55] I believe that only happens on vfat these days [08:56] try to defragment c:\ubuntu\disks\swap.disk with jkdefrag or similar before rebooting [08:57] xivulon: will do === dpm_ is now known as dpm [09:58] FireRabbit: it may be easier to think of it the other way round - the way it works is that the page is advanced *unless* an unanswered debconf question causes it to stop and wait for input [10:32] shtylman: Just a heads up, I imagine you'll want to subscribe to and mark yourself as participation essential for https://blueprints.edge.launchpad.net/ubuntu/+spec/kubuntu-karmic-ubiquity [16:06] evand1: thanks...will do :) [16:39] evand1, it looks like https://blueprints.edge.launchpad.net/sprints/uds-karmic?searchtext=ubiquity is a bit light as compared to last couple UDS'. are you having less ubiquity sessions, or just haven't registered more specs yet? [16:41] less sessions. Desktop experience has been looking at ubiquity and I'm fearful that they'll give us more than enough to do in 9.10 [16:41] but if you have something you want to cover / discuss, please feel free to register it and propose it [16:42] does the preseed support: d-i apt-setup/proposed boolean true [16:56] yes [17:00] superm1: cjwatson: I'll take a look when I get back into the office in about 45 mins. Basically I'm trying to figure out exactly what I need to preseed for each page. Other than timezone, I don't want any other pages to be displayed. I've managed to hide language and keyboard, but not the partition manager so far. [17:00] also, the language select comes back if ubiquity is canceled and then run a second time [17:01] what is the "mirror/suite"? if this is where I should specify the series, ie "karmic", how does this work if it's commented out by default? [17:02] cr3: you shouldn't set mirror/suite at all; just use the installer matching the release you want to install [17:02] it's only there to simplify code delta from Debian [17:04] cjwatson: excellent, thanks === dpm is now known as dpm-afk [17:06] FireRabbit: the installation guide is probably the best reference - you need to preseed partman-auto/method and partman-auto/disk at minimum but there are a few others [17:06] FireRabbit: https://help.ubuntu.com/9.04/installation-guide/i386/preseed-contents.html#preseed-partman [17:10] cjwatson, is that "X configuration" still valid? I thought the postinst for xserver-xorg didn't allow for most of those options in more current releases [17:11] superm1: yeah, it's entirely possible some of it is obsolete, I haven't rechecked it in a while [17:14] cjwatson: okay thanks [17:16] also I was wondering, what prevents the livecd 'ubuntu' user from being copied to the installed system if the entire fs is copied over? [17:19] FireRabbit: we copy the read-only squashfs rather than the running live session - the 'ubuntu' user is added only at boot time, so isn't in the squashfs [17:19] ahh ok [17:20] I saw the casper code for that but didnt put the pieces together, thanks [18:23] cjwatson: do you know why the language page comes up the second time ubiquity is run? is that a bug? [18:26] FireRabbit: it's very difficult to come up with a consistent set of semantics for what should happen when you rerun ubiquity in automated mode [18:27] FireRabbit: I more or less reckon that behaviour on the second run is not very well-defined [18:27] okay fair enough [18:27] (or even in non-automated mode, come to that ...) [18:27] there's a conflict between "this question is already answered, just use the answer" and "well, hey, the user ran ubiquity a second time, maybe there was a reason for that" [18:28] that's pretty much why automated mode exists, as an override to say "use all existing answers" [18:29] ok, in the case of what im doing it wont be possible to cancel ubiqutiy / re-run it.. i was just wondering because it was confusing while trying to test preseed options [18:52] FireRabbit: when you rerun, are you using the --automatic option? [18:52] cjwatson: yes [18:53] ok, just checking [18:53] yes, I think it would involve less fighting to boot afresh each time, sorry [18:53] okay that's good to know, thanks [18:54] that said, please do file a bug report about the fact that the language screen shows up again the second time [18:54] okay [18:54] it's probably due to the slightly odd way localechooser's innards work, and I'm not promising we can fix it easily, but it is a bug that it shows up like that in automatic mode [18:56] it'll be good to have the behavor documented in launchpad at least, might save someone else some head banging :) [18:56] for those who read through all 700 bugs? :-) [18:57] okay good point :) [19:01] so i set 'd-i passwd/make-user boolean false' but its still showing the account setup page, do i need to specify blank values for all the other fields too? [20:22] evand1: https://code.launchpad.net/~shtylman/ubiquity/reorg <-- initial file reorganization, no install updates or source fixes... [20:35] FireRabbit: it'll only allow passwd/make-user to be set to false if passwd/root-login is set to true; the installer doesn't like to create a system with no valid logins [20:36] shtylman: I'd really rather that all that stuff weren't moved under ubuntu-installer/ [20:37] cjwatson: where would you recommend it to go? higher level directory? [20:37] isn't the point of merging to try to get everything into common code? [20:37] I don't think it should involve everything moving down a directory level ... [20:38] lib/ubuntu-installer is really the common codebase [20:38] I havn't thought too much about merging the base wizard files [20:38] I would prefer the current ubiquity directory structure to be largely preserved [20:39] possibly with the top ubiquity directory renamed to lib [20:39] and then oem-config's files to be interspersed [20:39] I see... the reason I did the ubuntu-installer move is because everything else seemed to be related to d-i [20:39] but that could be my lack of understanding [20:39] not really [20:40] but in any case I'd rather not artificially separate things like that [20:40] oh and the oem-config dir under ubuntu-installer shouldn't be there [20:40] everything directly related to d-i is already reasonably well demarcated [20:40] k [20:40] some of the directories I havn't cleaned up yet after moving things around.. [20:41] sorry, I know it's annoying, but I'd really prefer you started again without all this heavy directory reorganisation - just because it's going to make history very confusing [20:41] so you would prefer the doc, desktop, lib, and share directories to be one level higher? [20:42] I'd prefer the existing directory structure [20:42] cjwatson: oh..thats not a problem...I will do that [20:42] cjwatson: yea...that would be like before...excpet I think I would move pixmaps/gui into shared [20:42] *share [20:42] I'm curious - why? [20:43] (my thinking was it better represents where they lie on disk) ? [20:43] buy maybe not.. [20:43] *but [20:43] I know that's how the target filesystem is laid out, but usually it's better for the source tree to reflect development [20:43] k [20:43] it'd be pretty unusual to edit pixmaps and gui at the same time [20:43] true [20:43] they're really just both in /usr/share due to the demands of the FHS - which are fine for a user filesystem, but ... [20:44] by the way, when you're moving files around, you *have* to use 'bzr mv' - don't remove and add files when moving them [20:44] if you remove/add, you sever history [20:44] bzr log won't know how to track across that [20:44] also...would lib/ubuntu-installer lib/ubiquity lib/oem-config be a good way to separate the codebases? I was thinking that the ubuntu-installer would be a new package with common code for both oem and ubiquity...? [20:44] cjwatson: noted [20:45] most of the lib/*.py code is already pretty common to both, or could be made to be common without too much effort [20:45] some of lib/*.py should really be lib/frontend/gtk_ui/blah or something like that [20:45] right [20:46] I don't want the name ubuntu-installer to exist at all - it's too confusing because people already sometimes refer to the Ubuntu branch of debian-installer like that (although I don't) [20:46] ubiquity-common would be a good package name for the common code, I think [20:46] that gui separation I know about.. but you would prefer that the common code just be under /lib ? and let the install files place it correcrly? [20:46] yes, I would, and the install files can continue to place it just where they do now [20:46] ubiquity-common ... noted... [20:47] the components/frontend code are a bit harder [20:48] would it not make sense to have a /usr/lib/ubiquity-common directory where the common code goes...instead of placing it in /usr/lib/ubiquity and /usr/lib/oem-config depending on which packge is installed? [20:48] it makes the python package names nasty [20:48] I guess thats a tradeoff between adding another package or not... [20:48] I see [20:48] although it doesn't reflect the history, I think nowadays we could regard oem-config as a sort of custom implementation using ubiquity code [20:49] so the python package names could be ubiquity.debconffilter, ubiquity.frontend.gtk_ui, oem_config.frontend.gtk_ui [20:49] could they both be built on the same wizard base? [20:49] ubiquity has a much more distinctive identity anyway [20:49] and then the whole thing could just go under /usr/lib/ubiquity/ [20:50] so we have /usr/lib/ubiquity/ubiquity/debconffilter.py, /usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py, /usr/lib/ubiquity/oem_config/frontend/gtk_ui.py [20:50] and then gradually merge common code from there [20:50] ahh I see...are you saying to get rid of oem-config package alltogether? and have oem mode be a special runcase? [20:50] we'll still need the oem-config binary packages, I expect, although they can be built from the ubiquity source package [20:51] having separate binary packages isn't really a maintenance burden - it's having to merge changes across different source packages that's a pain [20:51] k...also...do we need the cut and paste stuff stuff? [20:51] that seems very very jegacy [20:51] and is the only thing typing ubiquity to a specific architecture when binary packages are made [20:51] *legacy [20:51] and yes, it would probably eventually be possible to merge the basefrontend implementations, although not yet [20:52] k [20:53] src/cut-and-paste/e-map/ is still used in the UBIQUITY_OLD_TZMAP case, although we can probably kill that off in karmic [20:53] it shouldn't be killed at the same time as the oem-config merge though - one thing at a time [20:53] well...imma make another run at the re-org here soon with my new found knowledge :) [20:53] src/cut-and-paste/gdm-signal/ can't easily die yet [20:53] k [20:54] (that was new in jaunty and is what lets us reboot cleanly on GNOME) [20:54] I see [20:54] it's a workaround for problems elsewhere [20:54] the files in oem-config/desktop/ can be moved into ubiquity/desktop/, with some care to merge the Makefile.am files properly [20:55] oem-config/debian-installer-startup.d could just be moved to ubiquity's top level [20:55] the files in doc don't clash and can just be moved into ubiquity's doc directory [20:55] apport can be merged likewise [20:56] main-menu.d moved [20:56] compat is mostly easy but apt-install is tricky; there are two genuinely and necessarily different implementations there [20:56] oh..this one I had no clue on...the po files? [20:58] that'll take some care. those are based on the desktop directory [20:58] you can probably put the individual files together with msgcat to start with [20:58] i.e. there should be a single po/ubiquity.pot that contains all the messages, same for all the languages [20:59] k [20:59] once you get to the point of being able to run configure, you can run 'make ubiquity.pot && make update-po' in po/, or something similar [20:59] I recommend against editing the files manually unless and until you've read the gettext manual from cover to cover :-) [21:00] haha... noted... will avoid.... [21:00] for gui/, I think maybe ubiquity/ and oem-config/ subdirectories of each of glade and qt might make sense [21:00] or glade and qt subdirectories of each of ubiquity and oem-config, it doesn't much matter [21:01] for m4/, you should just be able to use ubiquity's copy [21:01] k....can glade be gtk? or does glade make more sense in the gtk world? [21:01] glade is the designer [21:02] well, the file extension is .glade and the xml top-level is ... [21:02] heh k [21:02] scripts/ is tricky, there are real clashes there [21:03] maybe move the oem-config ones into scripts/oem-config/ for now and we'll figure out what and how to merge later [21:03] k [21:03] generally, my strong preference is to leave the ubiquity structure alone and tastefully merge the oem-config stuff around it - should mostly be possible although there are definitely a few quirks [21:04] one obvious difference is that, when ubiquity is running stuff on the target system, it needs to chroot; oem-config is already in the target system [21:04] makes sense... with the ubiquity structure, I will still section off the frontend stuff into the proper folder... like segmented bar and timezone stuff? [21:04] so some parameterisation is needed, but it would be best to do that after the main body of the merge IMO [21:04] k [21:05] frontend> I think so, but I recommend doing that in a separate commit [21:05] k, so first move over the oem-config stuff [21:05] and then re-org ubiquity.. [21:05] other way round I think [21:05] k [21:05] try to keep it working at each step :) [21:05] where should I dump the oem-config frontends? [21:05] it's easier when they're smaller [21:05] k [21:06] ahh I see, we already talked about it... [21:06] looks like just segmented_bar, timezone_map, and wrap_label that are essentially components of the gtk frontend [21:06] yea [21:07] component/frontend code that's genuinely oem-config-specific can probably go in a top-level oem-config directory with components and frontend subdirectories [21:07] I do want to try to automakeify the whole thing at some point - people keep getting confused and trying to install it with ./configure && make && sudo make install and it's a bit embarrassing that it's halfway autotooled but only halfway [21:07] but not now :-) [21:08] heh [21:08] I would add make the template generation faster to that list :) [21:08] cjwatson: ah... in this case i already have a user created, any way around it? actually it seems if i give it an existing username it fails silently.. [21:09] FireRabbit: yeah, that might be a plausible workaround. I can't think of any other way around it short of creating a dummy user [21:09] shtylman: tricky to do anything much about unfortunately, there's quite a lot of po file data to munge around [21:10] several sets of translations maintained in different trees [21:10] cjwatson: true there... maybe caching? seems like it generates it every time... even with -nc .. maybe I do something wrong :( [21:11] there may be some make dependency bugs [21:11] cjwatson: ok thanks [21:11] though that's odd because choose-mirror uses a build-stamp file [21:11] which is kind of the great big hammer approach to make dependency problems [21:12] (crude and often wrong, but not in the direction that ought to cause repeated regeneration) [21:12] as does localechooser [21:12] anyway, I promised to go tidy the airing cupboard this evening :) [21:13] hahah :) [21:14] cjwatson: I actually had to look that up :) [21:14] " This term is more widely used in Britain" [21:15] http://www.wisegeek.com/what-is-an-airing-cupboard.htm <--- way more info than I wanted to know... [21:15] we called it a hotpress where I grew up, but the English look funny at you if you use that term *shrug* [21:16] heh [21:54] hi folks, [21:55] can someone confirm that is possible to install hardy with the installer of intrepid or jaunty? [21:55] I'm doing network install using preseed. [22:26] I'll be back :)