| === mirkobuholzer [n=mirko@c-67-170-232-232.hsd1.ca.comcast.net] has joined #ubuntu-installer | ||
| === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #ubuntu-installer | ||
| === Topic for #ubuntu-installer: Development of d-i and ubiquity in Ubuntu | http://wiki.ubuntu.com/InstallerDevelopment | ||
| === Topic (#ubuntu-installer): set by cjwatson at Fri Jan 5 15:12:40 2007 | ||
| === Starting logfile irclogs/ubuntu-installer.log | ||
| === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #ubuntu-installer | ||
| === Topic for #ubuntu-installer: Development of d-i and ubiquity in Ubuntu | http://wiki.ubuntu.com/InstallerDevelopment | ||
| === Topic (#ubuntu-installer): set by cjwatson at Fri Jan 5 15:12:40 2007 | ||
| (cjwatson/#ubuntu-installer) tepsipakki: you might be interested to hear that I think I've fixed that old pkgsel hand | 04:34 | |
| (cjwatson/#ubuntu-installer) hang | 04:34 | |
| === superm1 [i=malimonc@ubuntu/member/superm1] has joined #ubuntu-installer | ||
| superm1 | evand, over the weekend i caught some unfortunate ramifications of cjwatson's changes on the mythbuntu files to True/False from "yes"/"no". I just pushed up the resolutions to it. Would you be able to merge them back in? | 04:41 |
|---|---|---|
| evand | superm1: those were my changes | 04:49 |
| evand | but I shall take a look momentarily | 04:49 |
| superm1 | oh, i didn't look at the parent for it closely | 04:51 |
| superm1 | well irregardless, i had to make one minor change to filteredcommand.py, but it shouldn't break anything else. | 04:52 |
| evand | yes, I'm looking at that now. Why wouldn't you want the data to be UTF-8 encoded? | 04:54 |
| cjwatson | blink, please be careful messing with the UTF-8 stuff there :) | 04:55 |
| evand | indeed | 04:55 |
| cjwatson | that's the product of a lot of tedious bug-fixing related to Kubuntu | 04:55 |
| cjwatson | (Qt is insanely picky about encoding) | 04:55 |
| superm1 | well if its bool | 04:55 |
| superm1 | you can't UTF-8 encode it | 04:55 |
| evand | superm1: you can only preseed strings | 04:56 |
| cjwatson | you should turn it into a string | 04:56 |
| cjwatson | snap | 04:56 |
| superm1 | well that was the original thing I had with the "yes"/"no", which was because i thought you could only preseed strings | 04:56 |
| cjwatson | internally in python stuff should be True/False | 04:57 |
| superm1 | things appear to work correctly with the bool though | 04:57 |
| superm1 | with that change on filteredcommand.py | 04:57 |
| cjwatson | when interacting with debconf, you should turn it into "true"/"false" (debconf booleans) or whatever else is appropriate | 04:57 |
| cjwatson | where's this branch? | 04:58 |
| superm1 | one sec i'll grab a link | 04:58 |
| superm1 | here is the LP page: https://code.launchpad.net/~mythbuntu/mythbuntu/ubiquity | 04:59 |
| cjwatson | oh, that's right, it's not flagged as a branch of ubiquity so it doesn't show up on code.lp.net/ubiquity | 05:00 |
| superm1 | oh, how do i flag it as a branch of ubiquity? | 05:00 |
| evand | superm1: I'd prefer to avoid modifying the core bits of Ubiquity when unnecessary. Changing your code to preseed "true" in the case of True, and "false" in the case of False should be relatively straightforward anyway. | 05:00 |
| superm1 | will debconf convert a string that is "true" to a boolean True then? | 05:01 |
| cjwatson | btw, you should make your own changes in separate commits to merges | 05:01 |
| cjwatson | browsing history is painful when you violate that rule | 05:01 |
| superm1 | i'll make sure to do that in the future | 05:02 |
| cjwatson | I agree with evand - I think that change is a mistake and it's not how the rest of ubiquity does it | 05:02 |
| cjwatson | no, debconf won't convert it, frequent idioms are things like value = (db.get("foo/bar") == "true") | 05:02 |
| cjwatson | (the confmodule doesn't really know the type, you see) | 05:03 |
| superm1 | right | 05:03 |
| cjwatson | and nor does filteredcommand for that matter, at least not without inefficiency | 05:03 |
| superm1 | well is the only reason that boolean types couldn't be preseeded because of that UTF-8 encoding? | 05:03 |
| superm1 | or is there more to that | 05:04 |
| cjwatson | there's more to it | 05:04 |
| evand | superm1: debconf doesn't understand datatypes, just plain old strings. | 05:04 |
| cjwatson | True won't be automatically converted to "true" by anything | 05:04 |
| cjwatson | I think I would say rather that there is no mapping from Python data types to debconf data types other than strings. | 05:04 |
| cjwatson | other than via strings | 05:05 |
| superm1 | which would explain why there was a difference for True/true by what debconf got | 05:05 |
| cjwatson | and since boolean is the only case where there could even really be a convenient mapping, it's not really worth the infrastructure it would take to do it right | 05:05 |
| superm1 | when i thought there was a bool "datatype" | 05:05 |
| cjwatson | at the level of language bindings ("confmodules"), type isn't known unless you do another round trip to the debconf frontend to ask it | 05:06 |
| cjwatson | all it sees is <-- GET foo/bar --> 0 true | 05:06 |
| cjwatson | but foo/bar could be a string for all it knows ... | 05:06 |
| cjwatson | or select or whatever | 05:06 |
| superm1 | right. so the type described in a template is only used when you present the user the question | 05:07 |
| cjwatson | in order to find out the type you need to do METAGET foo/bar Type | 05:07 |
| superm1 | that makes more sense | 05:07 |
| cjwatson | pretty much, yeah | 05:07 |
| cjwatson | ubiquity looks up the type when it needs to do "frontend-like" logic | 05:08 |
| cjwatson | so for instance in the Partman component it looks up the question type and has default handling for boolean questions that get asked | 05:08 |
| cjwatson | (pop up dialog with go back / continue buttons) | 05:08 |
| cjwatson | but note that to get the answer back it just does: | 05:09 |
| cjwatson | if answer: | 05:09 |
| cjwatson | self.preseed(question, 'true') | 05:09 |
| cjwatson | else: | 05:09 |
| cjwatson | self.preseed(question, 'false') | 05:09 |
| superm1 | which makes more sense for that area | 05:09 |
| cjwatson | now, if you want that to be more convenient, I wouldn't object to a preseed_boolean method in filteredcommand | 05:09 |
| cjwatson | I think that would probably make sense | 05:09 |
| superm1 | what else would need to be done to enable that preseed_boolean method to work then? | 05:10 |
| cjwatson | nothing, just use it | 05:10 |
| cjwatson | so instead of the above: | 05:10 |
| cjwatson | self.preseed_boolean(question, answer) | 05:10 |
| superm1 | and then the True/False are used and stored to debconf | 05:10 |
| cjwatson | would just be a convenience wrapper | 05:10 |
| superm1 | well that's a pretty easy change for me to make then | 05:11 |
| cjwatson | it would turn its argument into 'true' or 'false' as appropriate and preseed that | 05:11 |
| superm1 | well to True/False, not 'true'/'false' though | 05:11 |
| cjwatson | no] | 05:11 |
| cjwatson | that would be wrong | 05:11 |
| superm1 | oh you mean in the wrapper, it should preseed the string 'true' or 'false' | 05:12 |
| evand | correct | 05:12 |
| superm1 | gotcha. that sounds like a good consensus to settle upon. | 05:12 |
| evand | hrm, the gobuntu community grew from nothing to being more active than plenty of other MLs pretty quickly. | 05:12 |
| cjwatson | similarly a value_boolean method would be OK to translate in the other direction, if there's call for it | 05:13 |
| superm1 | i'll ping you guys later tonight or tomorrow when i rework it and test it | 05:13 |
| evand | thanks superm1 | 05:13 |
| cjwatson | there are no other users for that as yet though | 05:13 |
| cjwatson | correction, one other potential user | 05:14 |
| cjwatson | (summary.py, the popcon bit) | 05:14 |
| evand | wow...so I'm banging my head against a wall trying to figure out why the interface never shows any of the pages when using --automatic mode and testing its interaction with my graceful page skipping work. And then it hits me. I answered all of the questions. | 06:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!