[00:48] <FireRabbit> What code in Ubiquity causes it to auto-advance if all questions for a page are answered?
[00:48] <FireRabbit> I'm having trouble understanding the structure
[02:23] <StevenK> FireRabbit: It's called preseeding
[02:27] <FireRabbit> StevenK: Yes I know, I'm wondering what actually causes the UI to advance
[03:12] <superm1> FireRabbit, see ubiquity/ubiquity/debconffilter.py.  search for the reference to UBIQUITY_AUTOMATIC
[03:13] <superm1> and similar references in gtk_ui.py
[03:15] <superm1> 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] <superm1> (more or less)
[08:52] <xivulon> hi davmor2
[08:53] <davmor2> hello
[08:53] <xivulon> missed part of the conversation yesterday, but followed up on the logs
[08:53] <davmor2> xivulon: didn't have time to get the logs last night in the end so I'm about to get them now
[08:53] <xivulon> so 'missing L', I think I didn't get that
[08:54] <xivulon> was the error about formatting the swap file?
[08:54] <davmor2> there is xivuon and xivulon :)  one missing L
[08:54] <xivulon> ah :)
[08:55] <xivulon> as for the swap that seems to be an old issue, due to fragmentation
[08:55] <xivulon> I believe that only happens on vfat these days
[08:56] <xivulon> try to defragment c:\ubuntu\disks\swap.disk with jkdefrag or similar before rebooting
[08:57] <davmor2> xivulon: will do
[09:58] <cjwatson> 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] <evand1> 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] <shtylman> evand1: thanks...will do :)
[16:39] <superm1> 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] <evand1> 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] <evand1> but if you have something you want to cover / discuss, please feel free to register it and propose it
[16:42] <cr3> does the preseed support: d-i apt-setup/proposed boolean true
[16:56] <cjwatson> yes
[17:00] <FireRabbit> 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] <FireRabbit> also, the language select comes back if ubiquity is canceled and then run a second time
[17:01] <cr3> 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] <cjwatson> cr3: you shouldn't set mirror/suite at all; just use the installer matching the release you want to install
[17:02] <cjwatson> it's only there to simplify code delta from Debian
[17:04] <cr3> cjwatson: excellent, thanks
[17:06] <cjwatson> 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] <cjwatson> FireRabbit: https://help.ubuntu.com/9.04/installation-guide/i386/preseed-contents.html#preseed-partman
[17:10] <superm1> 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] <cjwatson> superm1: yeah, it's entirely possible some of it is obsolete, I haven't rechecked it in a while
[17:14] <FireRabbit> cjwatson: okay thanks
[17:16] <FireRabbit> 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] <cjwatson> 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] <FireRabbit> ahh ok
[17:20] <FireRabbit> I saw the casper code for that but didnt put the pieces together, thanks
[18:23] <FireRabbit> cjwatson: do you know why the language page comes up the second time ubiquity is run? is that a bug?
[18:26] <cjwatson> 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] <cjwatson> FireRabbit: I more or less reckon that behaviour on the second run is not very well-defined
[18:27] <FireRabbit> okay fair enough
[18:27] <cjwatson> (or even in non-automated mode, come to that ...)
[18:27] <cjwatson> 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] <cjwatson> that's pretty much why automated mode exists, as an override to say "use all existing answers"
[18:29] <FireRabbit> 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] <cjwatson> FireRabbit: when you rerun, are you using the --automatic option?
[18:52] <FireRabbit> cjwatson: yes
[18:53] <cjwatson> ok, just checking
[18:53] <cjwatson> yes, I think it would involve less fighting to boot afresh each time, sorry
[18:53] <FireRabbit> okay that's good to know, thanks
[18:54] <cjwatson> that said, please do file a bug report about the fact that the language screen shows up again the second time
[18:54] <FireRabbit> okay
[18:54] <cjwatson> 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] <FireRabbit> it'll be good to have the behavor documented in launchpad at least, might save someone else some head banging :)
[18:56] <cjwatson> for those who read through all 700 bugs? :-)
[18:57] <FireRabbit> okay good point :)
[19:01] <FireRabbit> 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] <shtylman> evand1: https://code.launchpad.net/~shtylman/ubiquity/reorg <-- initial file reorganization, no install updates or source fixes...
[20:35] <cjwatson> 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] <cjwatson> shtylman: I'd really rather that all that stuff weren't moved under ubuntu-installer/
[20:37] <shtylman> cjwatson: where would you recommend it to go? higher level directory?
[20:37] <cjwatson> isn't the point of merging to try to get everything into common code?
[20:37] <cjwatson> I don't think it should involve everything moving down a directory level ...
[20:38] <shtylman> lib/ubuntu-installer is really the common codebase
[20:38] <shtylman> I havn't thought too much about merging the base wizard files
[20:38] <cjwatson> I would prefer the current ubiquity directory structure to be largely preserved
[20:39] <cjwatson> possibly with the top ubiquity directory renamed to lib
[20:39] <cjwatson> and then oem-config's files to be interspersed
[20:39] <shtylman> I see... the reason I did the ubuntu-installer move is because everything else seemed to be related to d-i
[20:39] <shtylman> but that could be my lack of understanding
[20:39] <cjwatson> not really
[20:40] <cjwatson> but in any case I'd rather not artificially separate things like that
[20:40] <shtylman> oh and the oem-config dir under ubuntu-installer shouldn't be there
[20:40] <cjwatson> everything directly related to d-i is already reasonably well demarcated
[20:40] <shtylman> k
[20:40] <shtylman> some of the directories I havn't cleaned up yet after moving things around..
[20:41] <cjwatson> 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] <shtylman> so you would prefer the doc, desktop, lib, and share directories to be one level higher?
[20:42] <cjwatson> I'd prefer the existing directory structure
[20:42] <shtylman> cjwatson: oh..thats not a problem...I will do that
[20:42] <shtylman> cjwatson: yea...that would be like before...excpet I think I would move pixmaps/gui into shared
[20:42] <shtylman> *share
[20:42] <cjwatson> I'm curious - why?
[20:43] <shtylman> (my thinking was it better represents where they lie on disk) ?
[20:43] <shtylman> buy maybe not..
[20:43] <shtylman> *but
[20:43] <cjwatson> 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] <shtylman> k
[20:43] <cjwatson> it'd be pretty unusual to edit pixmaps and gui at the same time
[20:43] <shtylman> true
[20:43] <cjwatson> 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] <cjwatson> 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] <cjwatson> if you remove/add, you sever history
[20:44] <cjwatson> bzr log won't know how to track across that
[20:44] <shtylman> 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] <shtylman> cjwatson: noted
[20:45] <cjwatson> 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] <cjwatson> some of lib/*.py should really be lib/frontend/gtk_ui/blah or something like that
[20:45] <shtylman> right
[20:46] <cjwatson> 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] <cjwatson> ubiquity-common would be a good package name for the common code, I think
[20:46] <shtylman> 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] <cjwatson> yes, I would, and the install files can continue to place it just where they do now
[20:46] <shtylman> ubiquity-common ... noted...
[20:47] <cjwatson> the components/frontend code are a bit harder
[20:48] <shtylman> 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] <cjwatson> it makes the python package names nasty
[20:48] <shtylman> I guess thats a tradeoff between adding another package or not...
[20:48] <shtylman> I see
[20:48] <cjwatson> 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] <cjwatson> so the python package names could be ubiquity.debconffilter, ubiquity.frontend.gtk_ui, oem_config.frontend.gtk_ui
[20:49] <shtylman> could they both be built on the same wizard base?
[20:49] <cjwatson> ubiquity has a much more distinctive identity anyway
[20:49] <cjwatson> and then the whole thing could just go under /usr/lib/ubiquity/
[20:50] <cjwatson> 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] <cjwatson> and then gradually merge common code from there
[20:50] <shtylman> ahh I see...are you saying to get rid of oem-config package alltogether? and have oem mode be a special runcase?
[20:50] <cjwatson> we'll still need the oem-config binary packages, I expect, although they can be built from the ubiquity source package
[20:51] <cjwatson> 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] <shtylman> k...also...do we need the cut and paste stuff stuff?
[20:51] <shtylman> that seems very very jegacy
[20:51] <shtylman> and is the only thing typing ubiquity to a specific architecture when binary packages are made
[20:51] <shtylman> *legacy
[20:51] <cjwatson> and yes, it would probably eventually be possible to merge the basefrontend implementations, although not yet
[20:52] <shtylman> k
[20:53] <cjwatson> 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] <cjwatson> it shouldn't be killed at the same time as the oem-config merge though - one thing at a time
[20:53] <shtylman> well...imma make another run at the re-org here soon with my new found knowledge :)
[20:53] <cjwatson> src/cut-and-paste/gdm-signal/ can't easily die yet
[20:53] <shtylman> k
[20:54] <cjwatson> (that was new in jaunty and is what lets us reboot cleanly on GNOME)
[20:54] <shtylman> I see
[20:54] <cjwatson> it's a workaround for problems elsewhere
[20:54] <cjwatson> the files in oem-config/desktop/ can be moved into ubiquity/desktop/, with some care to merge the Makefile.am files properly
[20:55] <cjwatson> oem-config/debian-installer-startup.d could just be moved to ubiquity's top level
[20:55] <cjwatson> the files in doc don't clash and can just be moved into ubiquity's doc directory
[20:55] <cjwatson> apport can be merged likewise
[20:56] <shtylman> main-menu.d moved
[20:56] <cjwatson> compat is mostly easy but apt-install is tricky; there are two genuinely and necessarily different implementations there
[20:56] <shtylman> oh..this one I had no clue on...the po files?
[20:58] <cjwatson> that'll take some care. those are based on the desktop directory
[20:58] <cjwatson> you can probably put the individual files together with msgcat to start with
[20:58] <cjwatson> i.e. there should be a single po/ubiquity.pot that contains all the messages, same for all the languages
[20:59] <shtylman> k
[20:59] <cjwatson> 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] <cjwatson> I recommend against editing the files manually unless and until you've read the gettext manual from cover to cover :-)
[21:00] <shtylman> haha... noted... will avoid....
[21:00] <cjwatson> for gui/, I think maybe ubiquity/ and oem-config/ subdirectories of each of glade and qt might make sense
[21:00] <cjwatson> or glade and qt subdirectories of each of ubiquity and oem-config, it doesn't much matter
[21:01] <cjwatson> for m4/, you should just be able to use ubiquity's copy
[21:01] <shtylman> k....can glade be gtk? or does glade make more sense in the gtk world?
[21:01] <shtylman> glade is the designer
[21:02] <cjwatson> well, the file extension is .glade and the xml top-level is <glade-interface> ...
[21:02] <shtylman> heh k
[21:02] <cjwatson> scripts/ is tricky, there are real clashes there
[21:03] <cjwatson> 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] <shtylman> k
[21:03] <cjwatson> 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] <cjwatson> 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] <shtylman> 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] <cjwatson> so some parameterisation is needed, but it would be best to do that after the main body of the merge IMO
[21:04] <shtylman> k
[21:05] <cjwatson> frontend> I think so, but I recommend doing that in a separate commit
[21:05] <shtylman> k, so first move over the oem-config stuff
[21:05] <shtylman> and then re-org ubiquity..
[21:05] <cjwatson> other way round I think
[21:05] <shtylman> k
[21:05] <cjwatson> try to keep it working at each step :)
[21:05] <shtylman> where should I dump the oem-config frontends?
[21:05] <cjwatson> it's easier when they're smaller
[21:05] <shtylman> k
[21:06] <shtylman> ahh I see, we already talked about it...
[21:06] <cjwatson> looks like just segmented_bar, timezone_map, and wrap_label that are essentially components of the gtk frontend
[21:06] <shtylman> yea
[21:07] <cjwatson> 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] <cjwatson> 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] <cjwatson> but not now :-)
[21:08] <shtylman> heh
[21:08] <shtylman> I would add make the template generation faster to that list :)
[21:08] <FireRabbit> 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] <cjwatson> 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] <cjwatson> shtylman: tricky to do anything much about unfortunately, there's quite a lot of po file data to munge around
[21:10] <cjwatson> several sets of translations maintained in different trees
[21:10] <shtylman> cjwatson: true there... maybe caching? seems like it generates it every time... even with -nc .. maybe I do something wrong :(
[21:11] <cjwatson> there may be some make dependency bugs
[21:11] <FireRabbit> cjwatson: ok thanks
[21:11] <cjwatson> though that's odd because choose-mirror uses a build-stamp file
[21:11] <cjwatson> which is kind of the great big hammer approach to make dependency problems
[21:12] <cjwatson> (crude and often wrong, but not in the direction that ought to cause repeated regeneration)
[21:12] <cjwatson> as does localechooser
[21:12] <cjwatson> anyway, I promised to go tidy the airing cupboard this evening :)
[21:13] <shtylman> hahah :)
[21:14] <shtylman> cjwatson: I actually had to look that up :)
[21:14] <shtylman> " This term is more widely used in Britain"
[21:15] <shtylman> http://www.wisegeek.com/what-is-an-airing-cupboard.htm <--- way more info than I wanted to know...
[21:15] <cjwatson> we called it a hotpress where I grew up, but the English look funny at you if you use that term *shrug*
[21:16] <shtylman> heh
[21:54] <sebas891> hi folks,
[21:55] <sebas891> can someone confirm that is possible to install hardy with the installer of intrepid or jaunty?
[21:55] <sebas891> I'm doing network install using preseed.
[22:26] <sebas891> I'll be back :)