[00:39] <shtylman> so I never got an answer the first time to I will ask again
[00:39] <shtylman> 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] <cjwatson> shtylman: you had left when I was last around, so I didn't get to answer ;-)
[01:05] <cjwatson> shtylman: keyboard_names.py is autogenerated; see debian/rules
[01:06] <shtylman> cjwatson: understandable :)
[01:06] <cjwatson> 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] <cjwatson> (patch isn't installed on the live CD by default, but that's easy to rectify)
[01:07] <cjwatson> 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] <shtylman> and if you cahnge images or other items not code related you just copy them over manually?
[01:07] <cjwatson> aye
[01:08] <cjwatson> it's a bit tedious but perfectly doable
[01:08] <shtylman> gotcha
[01:08] <shtylman> right now, I have been running with just setting the paths in the files...basically it allows me to test it faster
[01:09] <cjwatson> I would echo evand's advice not to run ubiquity on a normal system that you care about
[01:09] <cjwatson> I wrote a lot of it and I don't do that :)
[01:09] <shtylman> is there a way to rebuild the deb without cleaning everything first? ... haha...I believe you there :)
[01:09] <cjwatson> debuild -nc
[01:09] <shtylman> cause every new build takes forever and seems to generate the same things over and over... ooooo
[01:09] <cjwatson> (noclean)
[01:10] <cjwatson> the make dependencies might not be perfect, you might need to remove the odd stamp file or something
[01:10] <shtylman> gotcha
[01:10] <shtylman> much appreciated...
[01:11] <cjwatson> no problem
[01:11] <shtylman> 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] <cjwatson> I'll let you work with Evan on that, I'm quite out of date on the timezone map implementation
[01:12] <shtylman> who whould I suggest the fixes to? or should I just do them myself and say where to find the changes?
[01:12] <shtylman> gotcha
[01:12] <cjwatson> ideally, do them yourself and point evand to a branch
[01:12] <cjwatson> then he can review and merge
[01:12] <cjwatson> bonus points if the branch changes only those things so that it can be merged easily
[01:13] <shtylman> 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] <cjwatson> we haven't implemented the backend for that yet
[01:13] <shtylman> (fix for the map: I will make the changes...they are pretty local...and tell evand)
[01:14] <shtylman> ahh ok, no prob
[01:14] <cjwatson> but I suppose if you're doing something that updates on the fly then a backend isn't necessary
[01:14] <cjwatson> translated strings either go in debian/ubiquity.templates, or come from backend code in d-i/source/*/debian/*templates*
[01:15] <cjwatson> 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] <shtylman> 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] <cjwatson> don't add translations yourself
[01:19] <cjwatson> (generally)
[01:20] <cjwatson> add the English text to the appropriate templates file and then we'll pull in translations en masse from Launchpad
[01:20] <cjwatson> it isn't a good idea to try to shortcut that, generally
[01:20] <shtylman> 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] <cjwatson> that is taken care of for you
[01:21] <cjwatson> we run debconf-updatepo upon changing templates, and that deals with it
[01:21] <shtylman> gotcha
[01:22] <cjwatson> there is a huge pile of complex software behind that that you may or may not want to look into :-)
[01:22] <cjwatson> it's a bit more clever than just diff
[01:24] <shtylman> heh...figured
[01:24] <shtylman> learning about the installer as I go...one giant piece of software...
[01:27] <shtylman> (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] <shtylman> thanks for the help
[03:17] <shtylman> 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] <TheMuso> cjwatson: FYI I've just pushed/uploaded d-i to move ports to 2.6.28 kernels. Seed change also done.
[07:29] <TheMuso> argh package breakage! :S
[07:34] <TheMuso> my local mirror i.e on my LAN must be out of date, although I thought it mirrored this morning.
[07:34] <TheMuso> as it built fine here...
[08:00] <cjwatson> 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] <cjwatson> TheMuso: thanks anyway
[08:16] <cjwatson> though glad to see it all built at last, obviously :)
[10:08] <TheMuso> 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] <TheMuso> 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] <cjwatson> sounds tolerable
[10:12] <TheMuso> 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] <CIA-3> console-setup: cjwatson * r94 ubuntu/debian/ (changelog config.proto):
[10:19] <CIA-3> console-setup: Don't escape '(' and ')' when decoding/encoding the codeset, as the
[10:19] <CIA-3> console-setup: pattern is passed to grep and this causes parentheses to be interpreted
[10:19] <CIA-3> console-setup: as regular expression groups (thanks to Dmitry Agafonov for pointing out
[10:19] <CIA-3> console-setup: the problem).
[10:26] <cjwatson> 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] <TheMuso> 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] <cjwatson> so maybe there's nothing to do in ubiquity after all?
[10:32] <TheMuso> 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] <TheMuso> But again, I am thinking we need to ask the user whether they want their arrays activated.
[10:32] <TheMuso> similar to what we do in d-i.
[10:35] <cjwatson> Hmm. Tricky. I suppose you could do it using a usplash prompt though interaction there is a bit unpleasant
[10:35] <TheMuso> 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] <cjwatson> and you might want to use your disks from the live CD other than via ubiquity
[10:36] <cjwatson> for instance recovery purposes
[10:36] <cjwatson> notifications with actions seem to be being deprecated by the desktop experience folks
[10:36] <evand> shtylman: I'm having a look at your timezone map changes now.
[10:37] <cjwatson> hmm. cdebconf-terminal failed to build, but worked on my system
[10:37]  * cjwatson upgrades
[10:38] <TheMuso> cjwatson: rIGHT.
[10:38] <cjwatson> 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] <cjwatson> I'd like to be able to reproduce before uploading though ...
[10:39] <TheMuso> 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] <cjwatson> it was more effort to ask the question in d-i than just to do it by default
[10:41] <cjwatson> I'm sure there was a reason?
[10:42] <TheMuso> 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] <TheMuso> Wth the live disks, you have several place and forms in which the question can be asked.
[10:43] <TheMuso> as far as I see things anyway.
[10:44] <cjwatson> I'm just worried that if we bring it up by default we might cause data corruption on some systems
[10:44] <cjwatson> 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] <cjwatson> I'll ask Frans
[10:44] <TheMuso> Ok.
[10:45] <TheMuso> I understand where you're coming from.
[10:59] <evand> 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] <cjwatson> 11:24 <fjp> cjwatson: 1) Because bootloader support is still flakey.
[11:42] <cjwatson> 11:24 <fjp> 2) Yes, it can break systems. See #433579.
[11:42] <cjwatson> TheMuso: ^-
[11:42] <TheMuso> right
[11:42] <cjwatson> 11:26 <fjp> 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] <cjwatson> which I argued about because I don't think that's our choice
[11:43] <TheMuso> 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] <cjwatson> well, not really, not for most things
[11:48] <TheMuso> Right.
[11:48] <TheMuso> I know dmraid is like that however, but I don't think we can expect users of Ubuntu to do that.
[11:51] <cjwatson> apparently there's a thread on debian-boot about dmraid at the moment, haven't read it yet
[11:53] <TheMuso> hrm ok. Might check it out in a bit.
[11:58] <TheMuso> hrm so maybe usplash is possibly the best option for now, but I'm still unsure about this
[12:02] <TheMuso> that thread covers what I know re dmraid already.
[12:50] <Kano> hi, how to enable the root pw question in the u installer?
[14:17] <superm1> cjwatson, what exactly is cdebconf? i've seen references to it in ~ubuntu-installer bug mail and uploads,
[14:20] <shtylman> quick google search says its an implementation of the debian configuration management system using C
[14:21] <superm1> 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] <shtylman> 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] <evand> 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] <evand> Of course just my $0.02, cjwatson would have a much more authoritative answer
[14:29] <davmor2> evand: would 2¢ of been quicker :)
[14:29] <superm1> ah okay.  that explains a bit evand
[14:30] <shtylman> ... no 'cent' key ...
[14:34] <cjwatson> superm1: in Debian, we do have a long-term plan to replace debconf with cdebconf, but emphasis on the "long"
[14:35] <davmor2> shtylman: Nor do I just press AltGR+c :)
[14:35] <cjwatson> 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] <superm1> cjwatson, so assumingly at some point after that happens there would be an evaluation to consider a similar thing in ubuntu
[14:36] <cjwatson> I co-maintain both debconf and cdebconf in Debian; if we switched in Debian then I would Just Do It in Ubuntu :-)
[14:36] <superm1> :)
[14:36] <cjwatson> there's a bit of a long tail of stuff to include in cdebconf first though
[14:37] <cjwatson> proper initialisation; weird backends that a small number of people use; that kind of thing
[14:38] <superm1> ah okay.  i understand a lot better now, thanks!
[14:39] <cjwatson> for the meantime, it does an excellent job of handling things for the installer
[14:42] <shtylman> what is emap?
[14:42] <shtylman> the gtk version requires it but a google search on it is useless
[14:42] <davmor2> shtylman: try e-map
[14:44] <cjwatson> it's a map widget extracted originally from Evolution
[14:44] <cjwatson> it's in the ubiquity source tree; don't know why you're googling for it given that :)
[14:44] <cjwatson> in src/
[14:45] <shtylman> ahh ok...I was just curious...is it actually used currently?
[14:46] <cjwatson> ubiquity/frontend/gtk_ui.py:2712:        self.tzmap = ubiquity.emap.EMap()
[14:46] <cjwatson> oh, only if you pass --old-tzmap
[14:48] <shtylman> 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] <cjwatson> we should probably get rid of the old one before jaunty; it bloats the package, introduces an architecture-specific requirement, etc.
[14:52] <cjwatson> IIRC ubiquity-frontend-gtk could be architecture: all if not for that
[14:56] <shtylman> yea...unless someone is really attached it it, I think the new one is far better
[14:57] <cjwatson> 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] <evand> indeed, I'm fine with removing it.
[15:04] <shtylman> 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] <evand> 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] <evand> That or we should start prepending gtk on things that are specific to that frontend.
[15:14] <shtylman> heh
[15:17] <davmor2> 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] <davmor2> 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] <cjwatson> davmor2: you have it correct, but it's not an installer problem :-) if packages are installable, the installer is just the messenger
[15:40] <cjwatson> so don't shoot it
[15:40] <cjwatson> davmor2: this sort of thing with daily builds normally clears itself up
[15:40]  * davmor2 uncocks gun
[15:41] <cjwatson> and we have reports for it, like http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html
[15:41] <davmor2> cool no probs At least I got the info right
[15:42] <davmor2> cjwatson: isn't that the reports that build on the daily iso page?
[15:42] <cjwatson> not sure I understand you?
[15:42] <davmor2> ah no different location
[15:43] <davmor2> I was thinking of this http://cdimages.ubuntu.com/daily/current/report.html which is empty
[15:43] <cjwatson> that's generated based on the CD contents
[15:43] <cjwatson> same basic report though; ~ubuntu-archive/testing/ is for the whole of main+restricted
[15:43] <cjwatson> and the one on cdimage.u.c is empty because apparently the CD build broke
[15:43] <davmor2> cjwatson: Cool
[15:44] <davmor2> :)
[15:44] <davmor2> hence the broken cd
[15:44] <cjwatson> no
[15:45] <cjwatson> the broken CD you're using is from yesterday or earlier
[15:45] <cjwatson> the CD build broke in such a way as to generate no CD at all
[15:45] <davmor2> MEH
[15:46] <cjwatson> Missing debootstrap-required belocs-locales-bin
[15:46] <cjwatson> I've fixed the archive override that was causing that
[15:46] <davmor2> oh well I'll try again tomorrow :)
[16:47] <shtylman> why doesn't python have a '+=' ?? ... I mean ... really?
[16:47] <shtylman> sorry just had to complain
[16:51] <evand> shtylman: it does, but do consider the warning: http://zephyrfalcon.org/labs/python_pitfalls.html
[16:52] <cjwatson> indeed. the thing that python lacks in that department is ++, not +=
[16:52] <shtylman> yea...that too
[16:53] <shtylman> actually... cjwatson, I think ++ is my biggest complaint over +=
[16:53] <cjwatson> as evand points out, python *does* have +=, so I'm not even sure why you have a complaint about the latter
[16:54] <cjwatson> I don't have a problem with the lack of ++ in practice given nice idioms like for i in range(10):
[16:54] <shtylman> (I think I tried it ... and my python complained)
[16:54] <shtylman> but that could have been a while back and I never tried it since
[19:30] <CIA-3> debian-installer: cjwatson * r1043 ubuntu/ (9 files in 9 dirs):
[19:30] <CIA-3> debian-installer: Add cdebconf-newt-terminal to most images that include
[19:30] <CIA-3> debian-installer: cdebconf-newt-udeb (although not floppies).