[09:46] anyone know why there is a casper directory in the server images now [09:46] ? [09:49] brendand: it's a buglet that it's called casper; but the server images now install the base system by unpacking a squashfs rather than by running debootstrap [09:49] I'll fix the naming at some point [09:50] cjwatson, okay - it might be confusing one of our tools. hopefully we can sort it out on our side [09:52] If you're going to build tooling around it, maybe I should fix it sooner rather than later [09:55] I'll move it to /install/filesystem.* [09:58] cjwatson, apparently we need to be able to discern whether a system is being installed via d-i or casper [10:06] brendand: Should be fixed in tomorrow's images [10:57] xnox, hi, I think the RAID design is functionally complete now [10:58] * xnox \0/ [10:59] i will read the document soon. [10:59] It's not my best work. Partly I'm hamstrung by starting from the current advanced partitioner, but still, when creating an array it's opening two dialogs in succession, which is not cool. [11:00] And then going through N "Choose a security key" screens for however many LUKS-encrypted arrays you set up. [11:04] It's also highly suspicious that the way someone would choose which disks/partitions go into a volume group, and the way they'd choose which disks/partitions go into a Raid array, are completely different [11:04] They seem like similar operations [11:06] Are there any stats (or, failing that, guesswork) on (a) the distribution of how many Raid arrays real-world systems have (e.g. 0 = 99%, 1 = 0.7%, 2 = 0.2%...), and (b) the distribution of how many volume groups real-world systems have? [11:09] My guesswork would be that RAID is bimodal between (a) two (one for boot loader bits, one for LVM) and (b) lots (one corresponding to each mounted filesystem), but I have no stats [11:10] I don't think I've ever seen a system with more than one volume group, although my experience is fairly narrow and I can imagine needs for it [11:17] I guess (a) and (b) are both examples of "give me an array of each of these partitions" [11:18] Like the use case xnox gave me: "You want to use multiple devices in an encrypted RAID array, but the bootloader needs to be on a small unencrypted partition, so you want to partition all those devices in exactly the same way. The result will be two RAID arrays, one unencrypted and one encrypted, sharing the same set of disks." [11:18] That's (a) [11:22] I'll mark this as done now, but when I come back to the installer this week or next, I'll see how RAID would fit into the new advanced partitioner design, and maybe that will show me how to make the old-partitioner-based design less modal (if xnox hasn't started implementing that design by then). [11:40] cjwatson: i am adding an extra page in the automatic partitionaire for LUKS key setup. While the UI correctly switches to the new page, the debconf plows away and actually starts partitioning. Am I missing something to pause run() answering debconf questions? [11:41] What are you returning from run? [11:42] i only changed plugin_on_next_clicked() to return false. [11:44] cjwatson: good point. let me quickly double check. [12:02] mpt: =) "using the Unicode multiplication symbol" [12:02] xnox, you got me, that's ambiguous [12:03] xnox: So, each backend script has to correspond to one page - you can't have multiple pages for a single script [12:04] Well, I should probably check that, I forget how it works for the autopartitioner ... [12:04] (phone) [12:04] xnox, because there is not one but two multiplication symbols, U+00D7 and U+2715 [12:05] mpt: i was giggling at the 'unicode'. I will make it work with unicode ;-) [12:06] * xnox ponders what's wrong with good old ASCII * symbol.... [12:06] * xnox hides [12:07] cjwatson: well yes, it's a single page, but we swap the widgets in and out. E.g. the "ask, choose device/resize, manual" sub-pages. plus manual has dialogs as well. [12:07] Yeah, dialogs are different though because those are called in run() and it blocks on them returning [12:11] run normally shouldn't return until it's either preseeded the question that was asked or decided that it can carry on with the default value without explicitly preseeding it [12:11] cjwatson: excellent! i'll do that, but block on the function which validates passwords, waits for user to click 'install now' [12:12] i have been preseeding the luks password too early, before the users gets to type it in, resulting in empty password preseed =( [12:12] ok. thanks a lot. [12:13] OK. As I think I said, it might well be worth splitting up the giant run method to try to make it a bit more comprehensible (and maybe testable too) [12:13] ..... yeah [12:14] cjwatson: some of run is easy to refactor, other bits (autopartitioning) do a lot of sniffing and changing state, such that the same questions do different things depending on the state. [12:15] Right, I think the bulk of that stores state in the instance rather than in local vars though [12:15] i tried to map out a DAG for it, but moved on to adding more stuff on top to implement new features. [12:16] you'd think that, but options are derived from OS count and extra_options pretty much in the UI already. [12:16] and options are not incrementally stored in the instance for example. [12:16] I got bitten by that. [12:16] well they are, but very late, when everything is done already. [12:16] sounds like a bug :) [12:17] anyway, don't need to split it all up to the finest granularity in one go - I was thinking one method per question asked [12:17] a quirk [12:17] ok. [12:17] and I'm pretty sure that *is* almost entirely self-contained at that level [12:17] at least, that would gain a level of indentation, which would help on its own :) [12:17] * xnox mentally highlights "almost" [12:17] =)))) [12:17] ok. [12:18] let me sort this last bug, push auto-crypto out, then refactor, then continue with the other designs. [12:18] s/designs/features/ [12:27] ubiquity: cjwatson * r5578 trunk/ (debian/changelog ubiquity/debconffilter.py): Simplify DebconfFilter.process_line slightly. [12:29] ubiquity: cjwatson * r5579 trunk/ (debian/changelog ubiquity/keyboard_names.py): Simplify KeyboardNames._load_file using collections.defaultdict. === babyface_ is now known as baby_face === baby_face is now known as babyface_ [19:49] Is it kopts when booting the live system to install before the double dash or after the double dash that get copied over to the installed system? [22:58] ubiquity crypt installation is very slow.....