[01:39] partman-base: cjwatson * r181 ubuntu/ (debian/changelog lib/base.sh): [01:39] partman-base: Fix regression from calling sed outside debconf_select's inner loop: [01:39] partman-base: remove empty choices, which confused cdebconf. This notably happened [01:39] partman-base: when asking partman-auto/choose_recipe with a trailing newline on the [01:39] partman-base: choices list (LP: #507059). [10:40] hey ev, I have one small question about usb-creator, may I? [10:40] ara: absolutely [10:43] ev, is there any reason why I can't create a disk with my 4gb usb stick? [10:44] No, there shouldn't be. What happens when you try? [10:48] ev, in the list of disk to sue, you know that normally appears /dev/sdb (that cannot be used), and /dev/sdb1 that can. in the 4gb usb stick /dev/sdb1 never appears [10:48] ev, btw, the distinction between /dev/sdb (that can never be used) and /dev/sdb1 lacks a bit of usability [10:49] ev, and the Format button does not seem to be working either [10:49] ev, (I am using the gtk version, btw) [10:59] ara: can you pastebin the output of devkit-disks --dump [10:59] ara: distinction> indeed, there's an outstanding bug or two for that [11:00] ara: format> very odd. Can you also pastebin your ~/.usbcreator.log? [11:01] ev, http://paste.ubuntu.com/356506/ [11:03] ara: was there nothing in devkit-disks --dump for /dev/sdb1? [11:03] ev, no [11:03] ah, then as far as usb-creator is concerned, it doesn't exist :). I suspect this is a bug a big lower down, assuming you have a /dev/sdb1 device node. [11:03] ev, looking at the log, I have seen that format was not working because it was mounted (but the gtk application did not give me any error) [11:04] ev, so that's a bug (I'll file that one) [11:04] ara: much appreciated, thanks! [11:04] ev, and when I unmounted it, and clicked format, sdb1 appeared, so I guess now I can use it [11:05] lovely [11:08] ev, bug 507420 [11:08] Launchpad bug 507420 in usb-creator "If you try to format a mounted device, the application does not give you any error" [Undecided,New] https://launchpad.net/bugs/507420 [11:09] cool, thanks [11:33] cjwatson: (bug 506585) looking over r3643, I don't see how that can work. You preseed the name of the script, but ask_user only accepts responses of the form "80script" or "80script________script", not "script". [11:33] Launchpad bug 506585 in ubiquity "[Lucid Xubuntu] Manual partitioning using Desktop image can not be done" [Undecided,In progress] https://launchpad.net/bugs/506585 [11:36] if [ "$default" = "$plugin" ] || [11:36] [ "$default" = "${plugin#[0-9][0-9]}" ]; then [11:36] default="$key" [11:36] fi [11:36] ought to arrange for "script" to work ... [11:36] (in debconf_select) [11:36] I did test that change, I guess not well enough, sorry :-( [11:41] ah, sorry about that. Didn't go far enough down into the rabbit hole, it seems. [11:41] completely missed that substitution [11:42] * ev digs further [11:44] odd [11:44] I think I'd suggest the 'set -x' hammer to investigate ... [11:50] indeed, thanks [12:50] cjwatson: ah! It doesn't work because that processing (debconf_select) is done just before the question is actually asked, and partman.py only preseeds 'delete' as the question is being asked. [12:56] meh [12:56] so how do we fix this? the core problem in the original bug is that with the perf optimisation partman.py doesn't necessarily have the list of scripts in hand [12:56] I think perhaps we need to add something to debconf_select to let that kind of preseeding work ... [12:57] ... which is tricky 'cos debconf_select doesn't know either, if choices are frozen [12:57] maybe this whole frozen choices thing was a bad idea, but it does make things so much faster :-/ [12:58] I suppose we could have ask_user look for [0-9][0-9]$RET or something ... [12:58] in $dir [13:59] sorry, had stepped out for lucnh [13:59] hrm [14:38] ev, regarding removing oem-config post install, perhaps should you be removing 'ubiquity' instead of 'oem-config'? removing ubiquity should knock out all of oem-config too === robbiew_ is now known as robbiew [15:02] cjwatson: I take it the choices being frozen prevents us from using must_find_one_script on menu_options? If so, I'll agree for lack of a better solution. [15:02] cjwatson: something like this http://pastebin.ubuntu.com/356601/ ? [15:02] so the point of freezing choices was to avoid spending so much time listing out the choices when we already knew what we were going to do [15:02] err, just written properly, with $RET [15:03] the problem is a fencepost error [15:03] we thaw the choices one step too late [15:03] it might be possible to work out that we're about to return to the top level and return control to the user, and thaw choices then, maybe [15:04] that sort of thing was what I was thinking of, although be careful with what test(1) will do if there's more than one match; you might have to use a for loop and break [15:11] possibly something like http://paste.ubuntu.com/356608/, not that that makes things any less ridiculously complicated in there [15:11] does that make any sense? [15:12] either we need to handle bare preseeding as your paste, or we need to arrange to thaw choose_partition choices just before we get to the point where we currently realise that we've finished building the cache [15:15] that seems significantly cleaner [15:17] as usual the partman component state machine could do with some kind of diagram :-( I'm not entirely confident that that's the only possible transition back to choose_partition when choices are frozen [15:17] although I *think* it is [15:18] superm1: good call [15:19] indeed, my eyes are slightly sore, having dug through this [16:06] ubiquity: superm1 * r3655 ubiquity/ (bin/oem-config-firstboot debian/changelog): Adjust previous commit to remove ubiquity rather than oem-config (ubiquity will knock out of all oem-config too) === ubottu is now known as ubott2 === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew_