| === robbiew is now known as robbiew_ | ||
| twb | Debian's fork of casper (now called live-boot/live-config) appears to have some neat new features in the works, like support for serving the filesystem.squashfs over iSCSI. | 05:30 |
|---|---|---|
| twb | It's in my interests to get that kind of functionality on top of Ubuntu; what kind of interaction is there between casper and Debian Live? Do they snarf each others' code regularly? | 05:32 |
| ev | komputes: awesome, thanks | 08:53 |
| ev | weird, I thought I merged the testing branch ages ago | 08:56 |
| CIA-4 | ubiquity: evand * r4123 ubiquity/ (17 files in 6 dirs): Merge testing branch. Ubiquity now has a test harness in tests/ | 08:58 |
| ev | cjwatson: On "Intel Macs should not EFI boot", given that they cannot boot from an MBR on a USB disk, and given that we only need to prevent the installed system from using EFI, is it possible to get rid of this condition? | 12:08 |
| ev | granted, you'd be taking a different path to bring up the live CD as you would the installed system. | 12:09 |
| ev | though I'm a bit unclear as to how you'd be preventing them from using the EFI bootloader on a multi-catalog disc. | 12:10 |
| cjwatson | *do* we only need to prevent the installed system from EFI-booting? I think that probably depends on the kernel team's investigations | 12:10 |
| cjwatson | if that can be the case I agree it's simpler, though it's a pretty radically different path | 12:11 |
| ev | eh? I thought we definitely do thanks to NVIDIA being full of evil and not supporting EFI in nvidia.ko at all. | 12:11 |
| cjwatson | "only" was the key word :) | 12:12 |
| cjwatson | i.e. is it only nvidia.ko, or are there other problems too | 12:12 |
| ev | ah | 12:12 |
| cjwatson | that might break the live CD | 12:12 |
| ev | my understanding was just nvidia.ko, but I'd be quite keen to figure out if the kernel team finds anything | 12:12 |
| cjwatson | I thought I heard Intel from somewhere | 12:13 |
| ev | is there a discussion about this occurring somewhere? Dmitrijs has "get a Mac frontend/backend working in USB creator" as one of his tasks for summer of code, so I'd like to make sure he's aware of what the plans are. | 12:13 |
| ev | interesting | 12:13 |
| cjwatson | could be just poor memory though | 12:13 |
| cjwatson | not an active one as far as I know, yet | 12:13 |
| ev | okay | 12:14 |
| ev | so assuming that the kernel team finds that nvidia is the only problem (and thus not a problem for the live environment), would you be okay with that delta between the live CD and installed system boot? | 12:17 |
| ev | And if not (though do make that clear), or if the kernel team finds that there is a whole host of problems, am I correct in assuming that it doesn't make sense to slot in an EFI bootloader onto the USB disk as part of usb-creator (since we've just established that it will break) and thus it should be assumed that the Mac frontend, for the time being, is for creating usb disks to boot on netbooks, not Intel Macs. | 12:17 |
| ev | cjwatson: ^ | 12:17 |
| ev | frontend to usb-creator, that is | 12:20 |
| ev | just want to make sure my understanding of the problem lines up with everyone elses :) | 12:20 |
| cjwatson | I *think* so. I'm still not certain I have my head around all the facets of the problem, but it seems OK as a working assumption. However, we will need an EFI bootloader on the USB disk for real EFI systems. | 12:25 |
| ev | indeed | 12:26 |
| ev | and I guess in that case we just don't bless it for Macs, so they go straight to syslinux | 12:28 |
| ev | right, I think I understand the state of things a lot better now | 12:29 |
| ev | thanks a bunch! | 12:29 |
| cjwatson | well, depending on whether some models happen to understand /efi/boot/bootia32.efi | 12:31 |
| ev | oh yeah, ick | 12:31 |
| shtylman | ev: anything new with installer dev? | 14:36 |
| ev | shtylman: I merged the plugins branch today. If you can find a way around the problems I mention in tests/run-frontend for KDE, then we'll be able to create tests for that as well. | 15:29 |
| shtylman | ev: what plugins branch? | 15:31 |
| ev | errr sorry, testing branch | 15:31 |
| shtylman | ahh | 15:32 |
| shtylman | and what about installer overhaul? | 15:33 |
| ev | in progress, but nothing in a public branch yet | 15:35 |
| ev | I'm working on the necessary support for simultaneous debconfcommunicators | 15:36 |
| ev | and some other bits and pieces | 15:36 |
| ev | while michaelforrest finishes up the design | 15:37 |
| shtylman | k | 15:38 |
| shtylman | sounds good.. just wanted to make sure I wasn't too behind :) | 15:38 |
| ev | surely | 15:39 |
| ev | the spec as it stands is here: http://docs.google.com/View?id=dfkkjjcj_101gnkrpg5v | 15:39 |
| shtylman | ahh very nice | 15:39 |
| superm1 | ev, so with those changes to be running some of the plugins 'while' install is running, are you going to be adding extra support to plugins for them to declare which portion of the install they are running? | 16:23 |
| superm1 | (if you've thought that far out) | 16:23 |
| ev | my thought was any plugin post-partitioning would be run in parallel automagically | 16:24 |
| superm1 | Hm, so that plugin would be able to block install completing then after files are done if it's questions weren't necessarily answered then? | 16:25 |
| ev | where post-partitioning is everything but language, prepare (check for disk space, power, internet), and partitioning | 16:25 |
| ev | the install wont reboot until all pages have been completed, correct | 16:26 |
| ev | if I understand your question | 16:26 |
| superm1 | i think you did, but i'll rephrase it to confirm; for example the user setup page contains a class to query the questions and a class to apply the questions it answered. if the class to query the questions hasn't been resolved yet, then the installer will block waiting for those questions to be answered so that it can run the install class | 16:28 |
| ev | correct | 16:29 |
| superm1 | Ok, that sounds sensible then | 16:29 |
| superm1 | it sounds like oem-config will have to be special cased to avoid that behavior still since there isn't any partitioning step | 16:30 |
| ev | yeah, I'd like to make that as clean as possible, but I'll admit that I haven't given it much thought yet | 16:30 |
| ev | first step is just being able to do partitioning and installation using a separate db (both require SET and INPUT) | 16:32 |
| ev | then onward to not breaking things :) | 16:32 |
| superm1 | hehe | 16:35 |
| ev | I also realized today that being able to do the install in parallel wouldn't look much different than doing the install as a separate page, so I should be able to work on the parallel debconf and individual pages in parallel | 16:39 |
| superm1 | that certainly should help | 16:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!