[12:19] Anyone know where the code to decide how big to make the partition when you chose to install side by side lives? [12:19] lamalex: partman-auto [12:20] well, also in ubiquity, since it's a slider ... [12:20] cjwatson: partman-auto is where it's initially set though? [12:23] let me double-check [12:24] thanks :) [12:26] yeah, I believe that still comes from partman-auto/automatically_partition/resize_use_free/do_option, which sets the default size midway between the minimum and maximum bounds [12:26] it's a bit twisty [12:27] for us it's /always/ getting set to 2.5gb [12:27] which is uh... too small [12:28] ubiquity --debug would leave logs that would help to investigate [12:28] cjwatson: is that a bit twisty in the same way that lead is a bit heavy ;) [12:34] cjwatson: ubiquity --debug gives me 0 output [12:34] asside from some murrine warnings [12:36] lamalex: too small as in it fails to resize to that size, or too small for your liking? [12:36] lamalex: not on stdout, but in log files. /var/log/syslog /var/log/installer/debug [12:36] (and /var/log/partman is useful too) [12:36] cjwatson: ahh [12:36] evand: the latter [12:36] okay [12:37] how much space is made available by resizing the other filesystem? [12:38] cjwatson: by default? [12:38] i mean i can resize to anything [12:41] sorry. I mean, what's the maximum space you could make available? you can only resize down as far as the amount of data in the other filesystem [12:42] put another way, what's the range of the slider you get? [12:46] I can resize it down to 2.1 gb [12:49] and the other way? [13:09] cjwatson: i can resize my old one down to 2.1, and my new down to 2.5. it's setting 2.5 by default, which is also the min [13:11] what I'm actually asking is, what are the minimum and maximum sizes it'll allow for your new partition? [13:11] 5.4gb and 2.5gb [13:12] ok, so that does sounds like ... I think ... a ubiquity bug - IMO it'd be better for it to use the midpoint rather than the minimum [13:12] s/sounds/sound/ [13:13] i agree [13:14] so I need to fix this in d-i? [13:14] probably in ubiquity actually [13:14] but this is more evand's code than mine :) [13:14] basically I *think* d-i is providing the correct information to ubiquity but ubiquity needs to make better use of it [13:15] doesn't d-i use the minimum by default? [13:15] cjwatson: if logs would help you guys determine where the issue is, im happy to provide them [13:16] evand: there might be a bug, but it's meant to use the midpoint [13:16] human_resize_range [13:16] prefsize="$(expr $ "$minsize" + "$maxsize" $ / 2)" [13:16] # ask_for_size will set the default size to $hcursize. [13:16] hcursize=$(longint2human $prefsize) [13:16] ? is that perl? [13:16] from d-i? [13:16] shell [13:16] ah [13:17] lamalex: syslog with --debug should help us quickly see what info's being passed through, yes [13:17] sure, one moment [13:18] fair enough, I'll add that to my TODO list [13:19] evand: if you guys can point me in the direction of the code, you wont have to because ill patch this for you [13:20] cjwatson: evand: syslog -> http://filebin.ca/uoybwx [13:23] * evand digs [13:23] /nick evandigs [13:23] :) [13:27] lamalex: bzr branch lp:ubiquity ubiquity.trunk; vim ubiquity.trunk/ubiquity/segmented_bar.py line 600 [13:31] k [13:33] evand: this does more than just draw the bar? [13:33] this does actual partitioner stuff? [13:34] lamalex: the value it returns is fed back into the partitioner [13:35] ah [13:43] cool, thanks [13:47] evand: in the SegmentedBar class? [13:51] lamalex: the partman.py ubiquity component runs the partman-auto d-i component, watching for certain information and then feeds that information to the GTK frontend, which feeds the size data to the SegmentedBarSlider object. Once the user hits next, it grabs the size to resize the partition to from the SegmentedBarSlider and feeds it back into the partman.py ubiquity component, which feeds it to the partman-auto d-i component [13:52] ah [13:54] lamalex: http://people.ubuntu.com/~evand/tmp/ubiquity-diagram.png [14:40] evand: cjwatson: Shouldn't I be able to edit the .py files in /usr/lib/ubiquity and rerun the installer? [14:41] does the python interpreter do caching? [14:41] yes, you should be fine in editing them [14:43] hmm [14:43] wonder why this isnt working [14:43] i put in a bunch of prints, in the constructor as well just for testing [14:43] not printing anything [14:52] evand: ping [14:53] rgreening: ah, I missed you coming online. I looked over 0.2.0, but there are lingering issues with the GTK frontend that I think can be best solved by moving it to devicekit-disks, so I'm moving that through as quick as I can. [14:53] evand: cool [14:53] evand: how does that effect the KDE version, if at all? [14:54] we should be able to keep both backends without issue [14:54] devicekit-disks and HAL [14:54] evand: hmm... I have the same issues I believe you have with HAL... [14:55] So, perhaps, we may be able to move to devicekit-disks for both? [14:55] sure, if you guys are okay with bringing in that dependency [14:55] HAL is effectively dead upstream [14:56] I assume it's not Gtk/Gnome/gobject based, correct? [14:56] evand: ^ [14:57] correct [14:57] there's already a kformat or some such project using it [14:58] cool. I think I'm ok with that. And it forces us to movde to policykit too, correct? [14:58] evand: I think it would be preferable to maintain one common backend. Less code to maintain long term. [15:15] cjwatson: does ubiquity fork? [15:19] lamalex: it has quite a few subprocesses; it doesn't actually run multiple copies of its own process image though [15:19] (so fork/exec but not fork) [15:22] could that be why im not seeing anything printed? [15:27] lamalex: check in /var/log/installer/debug [15:27] lamalex: it directs its output to log files ... as evand says [15:28] yah, i removed that from /usr/bin/ubiquity [15:28] oh, but it's still going there. cool [15:29] evand: thanks. === robbiew1 is now known as robbiew === nxvl_ is now known as nxvl [16:02] lamalex: probably redirected in /usr/lib/ubiquity/bin/ubiquity too [16:03] cjwatson: yah im just watching the log now [16:04] cjwatson: is there a trick to running it locally? [16:04] what do you mean? [16:05] actually im not sure... [16:07] we don't run ubiquity locally as it's dependent on some live CD bits and is potentially dangerous [16:08] oh, that sort of locally [16:08] yeah, use a vm or something [16:10] k === dpm is now known as dpm-afk [18:47] I am looking for a way to get the unicode cahracter for a keycode/keysym given a keyboard layout ... ideas? [19:06] shtylman_: for one approach, have a look at gfxboot-theme-ubuntu/scrape-console-setup line 273-281 [19:06] apparently requires root although it ought to be possible to make loadkeys not need that in this case [19:06] actually look at the bit below that as well [19:08] cjwatson: k... will do ... is that a separate project? or a branch of ubiquity? what I am trying to do is provide a graphical display of the selected keyboard layout :) [19:11] separate project, bzr get lp:gfxboot-theme-ubuntu [19:11] I've always thought graphical displays of keyboard layouts were a tempting but ultimately doomed idea [19:11] GNOME's didn't work out very well [19:12] (mainly because for the amount of screen space they use up it's remarkably hard to actually distinguish useful information using them) [19:12] for that, though, using xklavier or whatever it is might be a better idea [19:12] whatever library it is that GNOME's keyboard properties widget uses to render the image [19:13] oh, the other problem is that desktop keyboards and laptop keyboards really don't look much alike, but we configure both the same way because the differences aren't really interesting at the xkb level [19:14] be my guest if you want to try it out though :) [19:15] cjwatson: indeed... I want to see what result I can get from mostly just displaying the main part of the keyboard .. .teh stuff that is usually very similar [19:15] the idea being that it is much more intuitive than the "type random stuff here box" [19:25] cjwatson: well... on the good side... running without sudo seemed to work just fine... [19:25] on the downside... it outputs c code ... :( [19:26] and I have no idea what the indexes into the plain_map are :) [19:31] usb-creator: rgreening * r121 usb-creator/usbcreator/ (kde_about.py kde_frontend.py): [19:31] usb-creator: Update bug e-mail for about settings [19:31] usb-creator: Tighten up some of the import statememnts in kde_frontend [19:31] usb-creator: Connect the apps quit signal to kde_frontend's quit method [19:31] usb-creator: Cleanup/improve progress bar code for kde_frontend [19:31] usb-creator: Make sure we cleanup after finish is called in kde_frontend (causes D-Bus issue.. need to look into that) [20:28] ubiquity: cjwatson * r3305 ubiquity/debian/changelog: fix attribution [20:30] ubiquity: cjwatson * r3306 ubiquity/debian/ (changelog ubiquity.templates): [20:30] ubiquity: Clarify that "use the entire disk" really does mean erasing everything [20:30] ubiquity: on it (thanks, Jason Spiro; LP: #94382). [20:32] ubiquity: cjwatson * r3307 ubiquity/debian/po/ (80 files): debconf-updatepo === mcasadevall is now known as NCommander [22:27] cjwatson: I am trying to understand the output of loadkeys [22:27] as I understand it, it is the unicode for the character when that particular key is pressed... [22:27] but how do I know which key cooresponds to what index? [22:29] honestly, I forget, I would have to go and remember how that code works and you're probably already ahead of me if you have it in front of you :) [22:30] I think they might be scancodes or something? [22:31] they'll either be scancodes or keycodes, probably the former - http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html [22:31] or indeed http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html [22:32] * shtylman_ feels like this is some scary territory carried over from the 70's [22:33] yup [22:33] but scancodes actually map reasonably well to how physical keyboards are laid out ... [22:33] abandon all desires you may have for elegant hardware design if you're doing anything with keyboards, though [22:33] k... will read about it and hopefully it will make sense :) [22:33] hahahaha [22:33] you'd think that USB keyboards might offer some hope of autodetecting the keymap, for instance [22:34] but no, it's all smoke and mirrors backed up by little in the way of reality :-/ [22:34] great... [22:43] alright...I get the part about them being scancode indexes... but then when I look at some of the entries they are 0xfb71 ... that isn't even a character on my keyboard :) is there a mask that needs to be applied beforehand? .. [22:44] look at the map_keycode function in that scrape-console-setup program [22:44] k [22:45] * shtylman_ admits he has never touched perl ... so this is an adventure [22:45] though, err, I can't remember how accurate that is, it only leaves you with one byte so can't be quite right [22:45] the kbd source might be a better place to look [22:45] hehe [22:46] ok...I get the idea...I think [22:46] sorry, I last dealt with that level of stuff years ago [22:46] oh its ok...anything that gets me going in the right direction is something