[00:39] so I never got an answer the first time to I will ask again [00:39] when you guys are developing on the installer how do you test changes you make while developing? I undetstand I can debuild but that takes forever...currently I run locally using python but the problem I have with that is some of the paths are hardcoded so I have to change them and then change back before I commit...is there a better solution? what is the common practice? thanks [01:05] shtylman: you had left when I was last around, so I didn't get to answer ;-) [01:05] shtylman: keyboard_names.py is autogenerated; see debian/rules [01:06] cjwatson: understandable :) [01:06] shtylman: I often extract the diff with bzr diff, copy that to the test system, and apply it on the fly with patch [01:06] (patch isn't installed on the live CD by default, but that's easy to rectify) [01:07] this is fine for anything except C code or modifications to imported code in d-i/, but I need to test either of those types of changes comparatively rarely and can cope with debuild for that [01:07] and if you cahnge images or other items not code related you just copy them over manually? [01:07] aye [01:08] it's a bit tedious but perfectly doable [01:08] gotcha [01:08] right now, I have been running with just setting the paths in the files...basically it allows me to test it faster [01:09] I would echo evand's advice not to run ubiquity on a normal system that you care about [01:09] I wrote a lot of it and I don't do that :) [01:09] is there a way to rebuild the deb without cleaning everything first? ... haha...I believe you there :) [01:09] debuild -nc [01:09] cause every new build takes forever and seems to generate the same things over and over... ooooo [01:09] (noclean) [01:10] the make dependencies might not be perfect, you might need to remove the odd stamp file or something [01:10] gotcha [01:10] much appreciated... [01:11] no problem [01:11] also, while making the kde guis I have found some fixes for the way things where done (city placement is a big one) [01:11] I'll let you work with Evan on that, I'm quite out of date on the timezone map implementation [01:12] who whould I suggest the fixes to? or should I just do them myself and say where to find the changes? [01:12] gotcha [01:12] ideally, do them yourself and point evand to a branch [01:12] then he can review and merge [01:12] bonus points if the branch changes only those things so that it can be merged easily [01:13] and the final thing...if you don't mind...the usability docs talk about a password strength bar..which is good and all, but I notice that labels often have translations that go with them..what do I do about that if I have to create a new label and want to generate the translations? do I make a note of that somewhere? [01:13] we haven't implemented the backend for that yet [01:13] (fix for the map: I will make the changes...they are pretty local...and tell evand) [01:14] ahh ok, no prob [01:14] but I suppose if you're doing something that updates on the fly then a backend isn't necessary [01:14] translated strings either go in debian/ubiquity.templates, or come from backend code in d-i/source/*/debian/*templates* [01:15] where possible we try to use strings in d-i to reduce translator workload, but ubiquity does have a decent collection of its own strings too [01:15] right..I was able to finally track those down...what is the best way for adding a new translation? cause clearly I don't know the other languages... [01:19] don't add translations yourself [01:19] (generally) [01:20] add the English text to the appropriate templates file and then we'll pull in translations en masse from Launchpad [01:20] it isn't a good idea to try to shortcut that, generally [01:20] that makes since...is there a good way to specify that the template file has been updated or particular text needs translating? or is that just checked manually later with diff? [01:21] that is taken care of for you [01:21] we run debconf-updatepo upon changing templates, and that deals with it [01:21] gotcha [01:22] there is a huge pile of complex software behind that that you may or may not want to look into :-) [01:22] it's a bit more clever than just diff [01:24] heh...figured [01:24] learning about the installer as I go...one giant piece of software... [01:27] (did the -nc flag...and sorting templates still takes forever...I think I will stick with the copying over to a test system as suggested) [01:28] thanks for the help === Daviey_ is now known as Daviey [03:17] evand: I made some changes to the gtk city location code and the zone offset code, they are in my branch lp:~shtylman/ubiquity/kdeui [07:21] cjwatson: FYI I've just pushed/uploaded d-i to move ports to 2.6.28 kernels. Seed change also done. [07:29] argh package breakage! :S [07:34] my local mirror i.e on my LAN must be out of date, although I thought it mirrored this morning. [07:34] as it built fine here... [08:00] TheMuso: oh :-( I was going to wait until I'd done cdebconf and cdebconf-terminal, since I was going to need to upload d-i right afterwards [08:00] TheMuso: thanks anyway [08:16] though glad to see it all built at last, obviously :) [10:08] cjwatson: On another note, I was playing with dmraid+ubiquity today. As previously discussed, ubiquity shows dmraid member disks, but doesn't if /var/lib/disk-detect/activate_dmraid is present. Would it be unreasonable to possibly touch that file in casper if dmraid happens to activate any arrays on live CD boot? [10:09] I also experienced a few failures trying to create ext3 filesystems on a standard disk partition with ubiquity today with latest dailies, however the livefs appears to be somewhat out of date, so far as I saw with some packages at least. [10:09] sounds tolerable [10:12] From the ubiquity code I've read so far, I am not sure how it would be possible to mangle UI code to not show member disks, without doing it to all frontend code. I may not have found all parts of that codd yet, so there still may be an option there. [10:19] console-setup: cjwatson * r94 ubuntu/debian/ (changelog config.proto): [10:19] console-setup: Don't escape '(' and ')' when decoding/encoding the codeset, as the [10:19] console-setup: pattern is passed to grep and this causes parentheses to be interpreted [10:19] console-setup: as regular expression groups (thanks to Dmitry Agafonov for pointing out [10:19] console-setup: the problem). [10:26] TheMuso: is it necessary to mangle the UI code in ubiquity, if partman is already not showing the member disks? (partman does exclude them, doesn't it?) [10:27] Yes. When it sets things up, it checks if a disk is a dmraid member, and if /var/lib/disk-detect/activate_dmraid is present, it excludes them. [10:28] so maybe there's nothing to do in ubiquity after all? [10:32] No, there isn't, if we can create /var/lib/disk-detect/activate_dmraid elsewhere, which was why I was thinking casper, dpeending on array activation. [10:32] But again, I am thinking we need to ask the user whether they want their arrays activated. [10:32] similar to what we do in d-i. [10:35] Hmm. Tricky. I suppose you could do it using a usplash prompt though interaction there is a bit unpleasant [10:35] Whether that be in ubiquity, or when the user gets to the desktop, I am not sure. The latter is much easier to implement, but may not be as UI friendly, unless we pop up a notification with an icon/button. Usplash feels ugly as you mention, but may be the cleanest. [10:36] and you might want to use your disks from the live CD other than via ubiquity [10:36] for instance recovery purposes [10:36] notifications with actions seem to be being deprecated by the desktop experience folks [10:36] shtylman: I'm having a look at your timezone map changes now. [10:37] hmm. cdebconf-terminal failed to build, but worked on my system [10:37] * cjwatson upgrades [10:38] cjwatson: rIGHT. [10:38] well, the missing debian-installer.h is a straightforward missing build-dep, but I can't actually reproduce the implicit declaration errors - although they're clearly bugs in the source, missing #includes [10:38] I'd like to be able to reproduce before uploading though ... [10:39] cjwatson: I think they will simply be activated by default, and if users complain, we can then consider the best course of action. D-i was unfortunately easy to ask a simple question like that. :) [10:41] it was more effort to ask the question in d-i than just to do it by default [10:41] I'm sure there was a reason? [10:42] Yeah someone asked for a question to be asked, because they didn't necessarily want to use dmraid arrays. I meant it was easier in terms of the UIII AND WHERE T WAS ASKED< AND CODED. [10:43] Wth the live disks, you have several place and forms in which the question can be asked. [10:43] as far as I see things anyway. [10:44] I'm just worried that if we bring it up by default we might cause data corruption on some systems [10:44] I don't much care if it's a preference thing, but I very much care if it's a data integrity thing [10:44] I'll ask Frans [10:44] Ok. [10:45] I understand where you're coming from. [10:59] shtylman: The positioning code seems to be more accurate, though still misses the correct locations of some points by a sizable distance (Sao Paulo, Brazil, for example) [10:59] * evand continues to dig [11:42] 11:24 cjwatson: 1) Because bootloader support is still flakey. [11:42] 11:24 2) Yes, it can break systems. See #433579. [11:42] TheMuso: ^- [11:42] right [11:42] 11:26 3) Because IMO it is something we'd prefer users not to use and asking the Q means we save the memory used by the dmraid udeb. [11:43] which I argued about because I don't think that's our choice [11:43] Yeah agreed. I know d-i in debian is all about "if you want this support, explicitly enable it on the kernel command-line etc" [11:48] well, not really, not for most things [11:48] Right. [11:48] I know dmraid is like that however, but I don't think we can expect users of Ubuntu to do that. [11:51] apparently there's a thread on debian-boot about dmraid at the moment, haven't read it yet [11:53] hrm ok. Might check it out in a bit. [11:58] hrm so maybe usplash is possibly the best option for now, but I'm still unsure about this [12:02] that thread covers what I know re dmraid already. [12:50] hi, how to enable the root pw question in the u installer? [14:17] cjwatson, what exactly is cdebconf? i've seen references to it in ~ubuntu-installer bug mail and uploads, [14:20] quick google search says its an implementation of the debian configuration management system using C [14:21] yeah that's what i had though about it, but is it eventually intended to replace debconf then in the installer? is it supposed to be faster? [14:22] that I have no idea about...it may be easier to tap into or might provide better api or something...maybe they just wanted to update the old system [14:24] It's a different implementation of the same underlying protocol, as I understand it. cdebconf supports things that debconf does not (the way it handles translations, plugins), but I don't think there's an intention to replace perl debconf on the live CD with it (though it is an option to ubiquity). [14:24] Of course just my $0.02, cjwatson would have a much more authoritative answer [14:29] evand: would 2¢ of been quicker :) [14:29] ah okay. that explains a bit evand [14:30] ... no 'cent' key ... [14:34] superm1: in Debian, we do have a long-term plan to replace debconf with cdebconf, but emphasis on the "long" [14:35] shtylman: Nor do I just press AltGR+c :) [14:35] superm1: the reimplementation was in order to avoid having to include perl in the stripped-down d-i environment, but it probably is a bit faster as a result; I've benchmarked it with ubiquity in the past and there wasn't a stunning difference though [14:36] cjwatson, so assumingly at some point after that happens there would be an evaluation to consider a similar thing in ubuntu [14:36] I co-maintain both debconf and cdebconf in Debian; if we switched in Debian then I would Just Do It in Ubuntu :-) [14:36] :) [14:36] there's a bit of a long tail of stuff to include in cdebconf first though [14:37] proper initialisation; weird backends that a small number of people use; that kind of thing [14:38] ah okay. i understand a lot better now, thanks! [14:39] for the meantime, it does an excellent job of handling things for the installer [14:42] what is emap? [14:42] the gtk version requires it but a google search on it is useless [14:42] shtylman: try e-map [14:44] it's a map widget extracted originally from Evolution [14:44] it's in the ubiquity source tree; don't know why you're googling for it given that :) [14:44] in src/ [14:45] ahh ok...I was just curious...is it actually used currently? [14:46] ubiquity/frontend/gtk_ui.py:2712: self.tzmap = ubiquity.emap.EMap() [14:46] oh, only if you pass --old-tzmap [14:48] gotcha, yea...I was deffinately under the impression the new map was used, but didn't realize you could opt for the old one [14:52] we should probably get rid of the old one before jaunty; it bloats the package, introduces an architecture-specific requirement, etc. [14:52] IIRC ubiquity-frontend-gtk could be architecture: all if not for that [14:56] yea...unless someone is really attached it it, I think the new one is far better [14:57] no attachment here, I'd rather only support one. I think it's just a fallback measure in case the new one has serious problems [15:00] indeed, I'm fine with removing it. [15:04] another question: I have noticed that some user interface stuff for the gtk side lives in the main ubiquity folder (like segmented bar and timezone map) was there a reason for putting that there instead of in the frontend folder in a gtk section? [15:12] Just a lack of organization on my part. I suppose it should live in a frontend-titled directory if you're using the same names for python modules. [15:13] That or we should start prepending gtk on things that are specific to that frontend. [15:14] heh [15:17] cjwatson: I've just checked the online logs and I can't see why but today's alt cd is crashing out I'm just grabbing the logs off the install [15:39] cjwatson: http://www.davmor2.co.uk/install the syslog says package conflicts lots of lib*-cil stuff. Now for a change do I have the info correct? [15:40] davmor2: you have it correct, but it's not an installer problem :-) if packages are installable, the installer is just the messenger [15:40] so don't shoot it [15:40] davmor2: this sort of thing with daily builds normally clears itself up [15:40] * davmor2 uncocks gun [15:41] and we have reports for it, like http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html [15:41] cool no probs At least I got the info right [15:42] cjwatson: isn't that the reports that build on the daily iso page? [15:42] not sure I understand you? [15:42] ah no different location [15:43] I was thinking of this http://cdimages.ubuntu.com/daily/current/report.html which is empty [15:43] that's generated based on the CD contents [15:43] same basic report though; ~ubuntu-archive/testing/ is for the whole of main+restricted [15:43] and the one on cdimage.u.c is empty because apparently the CD build broke [15:43] cjwatson: Cool [15:44] :) [15:44] hence the broken cd [15:44] no [15:45] the broken CD you're using is from yesterday or earlier [15:45] the CD build broke in such a way as to generate no CD at all [15:45] MEH [15:46] Missing debootstrap-required belocs-locales-bin [15:46] I've fixed the archive override that was causing that [15:46] oh well I'll try again tomorrow :) [16:47] why doesn't python have a '+=' ?? ... I mean ... really? [16:47] sorry just had to complain [16:51] shtylman: it does, but do consider the warning: http://zephyrfalcon.org/labs/python_pitfalls.html [16:52] indeed. the thing that python lacks in that department is ++, not += [16:52] yea...that too [16:53] actually... cjwatson, I think ++ is my biggest complaint over += [16:53] as evand points out, python *does* have +=, so I'm not even sure why you have a complaint about the latter [16:54] I don't have a problem with the lack of ++ in practice given nice idioms like for i in range(10): [16:54] (I think I tried it ... and my python complained) [16:54] but that could have been a while back and I never tried it since [19:30] debian-installer: cjwatson * r1043 ubuntu/ (9 files in 9 dirs): [19:30] debian-installer: Add cdebconf-newt-terminal to most images that include [19:30] debian-installer: cdebconf-newt-udeb (although not floppies).