| 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 | 00:48 |
| StevenK | FireRabbit: It's called preseeding | 02:23 |
| FireRabbit | StevenK: Yes I know, I'm wondering what actually causes the UI to advance | 02:27 |
| superm1 | FireRabbit, see ubiquity/ubiquity/debconffilter.py. search for the reference to UBIQUITY_AUTOMATIC | 03:12 |
| superm1 | and similar references in gtk_ui.py | 03:13 |
| 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) | 03:15 |
| xivulon | hi davmor2 | 08:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| xivulon | try to defragment c:\ubuntu\disks\swap.disk with jkdefrag or similar before rebooting | 08:56 |
| davmor2 | xivulon: will do | 08:57 |
| === dpm_ is now known as dpm | ||
| 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 | 09:58 |
| 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 | 10:32 |
| shtylman | evand1: thanks...will do :) | 16:06 |
| 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:39 |
| 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:41 |
| cr3 | does the preseed support: d-i apt-setup/proposed boolean true | 16:42 |
| cjwatson | yes | 16:56 |
| 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:00 |
| 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:01 |
| 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:02 |
| cr3 | cjwatson: excellent, thanks | 17:04 |
| === dpm is now known as dpm-afk | ||
| 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:06 |
| 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:10 |
| cjwatson | superm1: yeah, it's entirely possible some of it is obsolete, I haven't rechecked it in a while | 17:11 |
| FireRabbit | cjwatson: okay thanks | 17:14 |
| 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:16 |
| 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:19 |
| FireRabbit | I saw the casper code for that but didnt put the pieces together, thanks | 17:20 |
| FireRabbit | cjwatson: do you know why the language page comes up the second time ubiquity is run? is that a bug? | 18:23 |
| 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:26 |
| 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:27 |
| cjwatson | that's pretty much why automated mode exists, as an override to say "use all existing answers" | 18:28 |
| 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:29 |
| cjwatson | FireRabbit: when you rerun, are you using the --automatic option? | 18:52 |
| FireRabbit | cjwatson: yes | 18:52 |
| 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:53 |
| 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:54 |
| 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:56 |
| FireRabbit | okay good point :) | 18:57 |
| 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? | 19:01 |
| shtylman | evand1: https://code.launchpad.net/~shtylman/ubiquity/reorg <-- initial file reorganization, no install updates or source fixes... | 20:22 |
| 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:35 |
| cjwatson | shtylman: I'd really rather that all that stuff weren't moved under ubuntu-installer/ | 20:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| cjwatson | the components/frontend code are a bit harder | 20:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| shtylman | k | 20:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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 :-) | 20:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| shtylman | hahah :) | 21:13 |
| shtylman | cjwatson: I actually had to look that up :) | 21:14 |
| shtylman | " This term is more widely used in Britain" | 21:14 |
| 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:15 |
| shtylman | heh | 21:16 |
| sebas891 | hi folks, | 21:54 |
| 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. | 21:55 |
| sebas891 | I'll be back :) | 22:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!