| 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 | 00:39 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| cjwatson | don't add translations yourself | 01:19 |
| cjwatson | (generally) | 01:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| shtylman | heh...figured | 01:24 |
| shtylman | learning about the installer as I go...one giant piece of software... | 01:24 |
| 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:27 |
| shtylman | thanks for the help | 01:28 |
| === Daviey_ is now known as Daviey | ||
| 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 | 03:17 |
| TheMuso | cjwatson: FYI I've just pushed/uploaded d-i to move ports to 2.6.28 kernels. Seed change also done. | 07:21 |
| TheMuso | argh package breakage! :S | 07:29 |
| 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... | 07:34 |
| 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:00 |
| cjwatson | though glad to see it all built at last, obviously :) | 08:16 |
| 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:08 |
| 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:09 |
| 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:12 |
| 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:19 |
| 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:26 |
| 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:27 |
| cjwatson | so maybe there's nothing to do in ubiquity after all? | 10:28 |
| 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:32 |
| 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:35 |
| 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:36 |
| cjwatson | hmm. cdebconf-terminal failed to build, but worked on my system | 10:37 |
| * cjwatson upgrades | 10:37 | |
| 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:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| TheMuso | I understand where you're coming from. | 10:45 |
| 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 | 10:59 | |
| 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:42 |
| 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:43 |
| 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:48 |
| cjwatson | apparently there's a thread on debian-boot about dmraid at the moment, haven't read it yet | 11:51 |
| TheMuso | hrm ok. Might check it out in a bit. | 11:53 |
| TheMuso | hrm so maybe usplash is possibly the best option for now, but I'm still unsure about this | 11:58 |
| TheMuso | that thread covers what I know re dmraid already. | 12:02 |
| Kano | hi, how to enable the root pw question in the u installer? | 12:50 |
| superm1 | cjwatson, what exactly is cdebconf? i've seen references to it in ~ubuntu-installer bug mail and uploads, | 14:17 |
| shtylman | quick google search says its an implementation of the debian configuration management system using C | 14:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| davmor2 | evand: would 2ยข of been quicker :) | 14:29 |
| superm1 | ah okay. that explains a bit evand | 14:29 |
| shtylman | ... no 'cent' key ... | 14:30 |
| cjwatson | superm1: in Debian, we do have a long-term plan to replace debconf with cdebconf, but emphasis on the "long" | 14:34 |
| 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:35 |
| 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:36 |
| cjwatson | proper initialisation; weird backends that a small number of people use; that kind of thing | 14:37 |
| superm1 | ah okay. i understand a lot better now, thanks! | 14:38 |
| cjwatson | for the meantime, it does an excellent job of handling things for the installer | 14:39 |
| 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:42 |
| 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:44 |
| shtylman | ahh ok...I was just curious...is it actually used currently? | 14:45 |
| cjwatson | ubiquity/frontend/gtk_ui.py:2712: self.tzmap = ubiquity.emap.EMap() | 14:46 |
| cjwatson | oh, only if you pass --old-tzmap | 14:46 |
| 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:48 |
| 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:52 |
| shtylman | yea...unless someone is really attached it it, I think the new one is far better | 14:56 |
| 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 | 14:57 |
| evand | indeed, I'm fine with removing it. | 15:00 |
| 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:04 |
| 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:12 |
| evand | That or we should start prepending gtk on things that are specific to that frontend. | 15:13 |
| shtylman | heh | 15:14 |
| 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:17 |
| 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:39 |
| 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:40 | |
| 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:41 |
| 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:42 |
| 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:43 |
| davmor2 | :) | 15:44 |
| davmor2 | hence the broken cd | 15:44 |
| cjwatson | no | 15:44 |
| 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:45 |
| 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 :) | 15:46 |
| shtylman | why doesn't python have a '+=' ?? ... I mean ... really? | 16:47 |
| shtylman | sorry just had to complain | 16:47 |
| evand | shtylman: it does, but do consider the warning: http://zephyrfalcon.org/labs/python_pitfalls.html | 16:51 |
| cjwatson | indeed. the thing that python lacks in that department is ++, not += | 16:52 |
| shtylman | yea...that too | 16:52 |
| 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:53 |
| 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 | 16:54 |
| 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). | 19:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!