[02:28] ubiquity: superm1 * r4286 ubiquity/ (debian/changelog ubiquity/plugins/ubi-language.py): [02:28] ubiquity: Adjust the fudge factor for showing languages on oem-config page [02:28] ubiquity: due to the changes to the default window size being much bigger. [02:37] cjwatson, re the fix for bug 627672, wouldn't it be better to test if the filesystem was read only or read write? [02:37] Launchpad bug 627672 in ubiquity (Ubuntu Maverick) (and 2 other projects) "[Maverick Beta] install from USB stuck retrieving files 2/6 Hp Mini (affects: 3) (dups: 1) (heat: 28)" [High,Fix released] https://launchpad.net/bugs/627672 [03:16] ubiquity: superm1 * r4287 ubiquity/ (3 files in 2 dirs): [03:16] ubiquity: During oem-config's removal of ubiquity, remove other ubiquity [03:16] ubiquity: related items that might have potentially still been on the system [03:16] ubiquity: from a live-helper generated image. [07:00] superm1: probably, but I don't think you necessarily get a mount option saying that? [07:01] cjwatson, isn't the 4th thing (the mount options) in the output of /proc/mounts going to say that? [07:01] for everything i see listed it's always starting with 'ro' or 'rw' [07:04] I thought that was what you asked for, not necessarily what you got ... [07:07] the only thing I can think of that isn't true for that is bind mounts [07:11] at least when booted from a CD, requesting it remount,rw doesn't change /proc/mounts to show [07:21] ok, feel free to refactor or else I will at some point [07:21] unless there's a case where it matters more urgently? [07:22] well i was noticing the workaround was breaking recovery partitions for me which is what got me thinking about it [07:22] it's not too urgent though, i've just got a workaround to remove that file before install_extras is getting ran for now [07:23] wonder why it broke - and remove which file? [07:24] oh, identcdrom? [07:24] yeah [07:25] which perplexes me, but i've not figured out why that fixes it [07:55] ubiquity: superm1 * r4288 ubiquity/ (debian/changelog scripts/plugininstall.py ubiquity/misc.py): [07:55] ubiquity: Refactor mount_info to also report ro/rw, and let plugininstall [07:55] ubiquity: key off that instead. [09:33] ubiquity: evand * r4289 trunk/ (debian/changelog ubiquity/plugins/ubi-usersetup.py): [09:33] ubiquity: If the username only contains non-alphanumeric characters, set the [09:33] ubiquity: hostname to ubuntu-{laptop,desktop}. [10:40] ev: mind if I upload usb-creator? [10:41] cjwatson: by all means [10:41] thanks [10:41] and thanks so much for your fixes. It's really nice to get another set of eyes on that code. [10:41] another set> in addition to the wonderful people that already hack on it [10:43] very much a means to an end :) [10:43] * cjwatson is about three or four levels deep in yak-shaving [10:43] usb-creator: cjwatson * r322 trunk/debian/changelog: releasing version 0.2.24 [10:45] heh [10:53] ev: is it intentional that "Log in automatically" is the default radio button choice? That's quite a change in behaviour ... [10:58] As I understand it, yes. Unfortunately, Michael is on holiday, otherwise I could clarify [10:59] it might be worth discussing that more widely (e.g. ubuntu-devel) [10:59] as certainly I'd managed to forget about it and I'm not sure others are aware [10:59] for starters the desktop team ought to have a chance to weigh in as it will result in many more people using autologin [11:00] mm, TB? I'm afraid ubuntu-devel would instantly bikeshed with opinions focused inward, rather than with our target audience in mind. [11:01] I think it needs a wider audience than the TB, honestly [11:01] ubuntu-devel has a restricted-posting policy anyway, which tends to keep things on-topic [11:01] fair enough [11:01] will do [11:03] I also think it's the sort of thing that rates a mention in the release notes, which would be a useful opportunity to clarify rationale [11:06] hm, the install design spec is actually vague on this [11:07] it doesn't mention which should be the default in the text, and while the original image has "log in automatically" set, another, later image has "require my password to log in" [11:11] sounds to me like we should stick with the previous default then? [11:11] if in doubt ... [11:11] I'll check with Ivanka and co to be sure. [11:11] I don't want to stomp all over Michael's toes just because he's away [11:55] ev, oh ! i thought you said during beta the hostname field would come back [11:55] ubiquity: evand * r4290 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py): [11:55] ubiquity: Replace RELEASE with the release name in the KDE UI finished dialog [11:55] ubiquity: (LP: #628964). [11:55] * ogra just saw the bug comment :((( [11:56] well yeah, I had contemplated it, but I want to be able to give the design team a chance to try new things. So I want to leave it up to them, assuming this is actually what they want. [11:56] I'm trying to grab a moment from Iain or Ivanka to confirm. [11:56] * ogra really really wants it back :'-( [11:58] i'm doing install tests with my mom from time to time ... she always gets that she hest to give her computer a name ... she never gets why she has to give *herself* an additional name (login) [12:02] right, I talked to Iain and John about it and they say to switch it back to 'require my password' [12:03] * ogra wonders if it wouldnt make sense to have it conditional ... netbook seems like a good candidate for having autologin by default [12:05] The reasoning was that having an automatic login discourages users to create additional accounts, it removes a layer of security that they're somewhat dependant on for things they want to pursue in the future (I did make the point that this is only for physical log ins, thus we can assume they can just boot=/bin/sh), and that the later mock up has 'require my password to log in' checked. [12:10] ok, that's a relief :) [12:10] ev: did you get my message from yesterday that I tested your patch successfully and it was likely my VM that was buggy? [12:20] Riddell: indeed [12:20] thanks for the follow up [12:20] Heads up on another possible point of contention: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/631943 [12:20] Launchpad bug 631943 in ubiquity (Ubuntu) "No bootloader location option available for "use entire disk" install method (affects: 1) (heat: 6)" [Undecided,Won't fix] [12:21] ev: should the forward button really read "Install Now" on partitioner options that have an extra page before installation? [12:22] Riddell: no, that was just a stop-gap until we had a way of elegantly setting the button text on an individual page level, not just at the plugin level. [12:22] I'm OK with the rationale in 631943 myself [12:23] cjwatson: as in the user's rational, or mine (and superm1's)? [12:23] yours [12:23] lovely [12:31] https://lists.ubuntu.com/archives/ubuntu-installer/2010-September/000697.html head hurts. [12:32] would anyone here be upset if I made it so that if there aren't any disks present, or if the minimum disk size check fails, it wont let you proceed past the prepare page? Currently you get to an empty manual partitioner page, which is seemingly poor UI. [12:34] ok by me [13:05] What was the resolution on the question of not being able to set the machine name in the installer? [13:11] cjwatson: ok [13:11] (redirected from #debian-boot) [13:11] update-initramfs is diverted by casper when booting from a live CD [13:12] er, from a live USB stick [13:12] it's part of an attempt to make upgrades of a live USB stick work [13:12] re bugs: apport arranges to prompt to file bugs whenever an upgrade fails [13:12] ok [13:12] we know that live USB upgrades are broken right now (there's a proper bug somewhere), so that could be the cause of some of it [13:12] many of them are either hardware failures [13:12] or no space left. [13:13] sure, IME it has not been worth my time to go through them all :-/ [13:13] the flow is too much [13:13] if you're feeling enthusiastic, feel free to close things that are hardware issues initramfs-tools can't deal with [13:14] haven't got yet my lp account, didn't send my account details to d.o it seems. [13:14] will retry. [13:18] fwiw the casper update-initramfs diversion is a wrapper that calls the real one and then fiddles with the initramfs in /cdrom/casper/ [13:18] I think ev was going to look at what was wrong with it, at some point ... [13:24] ok thanks for the info, will wait for my LP confirmation code and see if i have a bored pause. :) [13:25] ev, may I ask you again to export translations for ubiquity? After the Ubuntu Global Jam two weekends ago people have done a lot of translations and are eager to test them. Thanks! [13:28] maks_: :) [13:41] dpm: will do [13:41] ScottK: we're waiting to hear back from the design team [13:42] cjwatson: is there a bug for this? [13:43] ev: Thanks. [13:43] Thanks a lot ev [13:49] ubiquity: evand * r4291 trunk/ (debian/changelog ubiquity/plugins/ubi-partman.py): [13:49] ubiquity: Do not look for a full path on non-paths when getting the default [13:49] ubiquity: grub target. [13:56] ev: start with /~sabdfl/+reportedbugs ;-) [13:57] * ev bookmarks [13:57] hm, maybe not [13:57] * cjwatson hunts [13:59] ev: bug 591207 [13:59] Launchpad bug 591207 in casper (Ubuntu Lucid) (and 1 other project) "Casper's USB update-initramfs shim should look for initrd.img in /boot (affects: 3) (dups: 2) (heat: 60)" [High,Confirmed] https://launchpad.net/bugs/591207 [13:59] also possibly related to bug 557023? [13:59] Launchpad bug 557023 in usb-creator (Ubuntu) (and 1 other project) "update-initramfs: deferring update (trigger activated) / cp: cannot stat `/vmlinuz': No such file or directory (affects: 96) (dups: 48) (heat: 436)" [High,Triaged] https://launchpad.net/bugs/557023 [14:00] ubiquity: evand * r4292 trunk/ (debian/changelog ubiquity/plugins/ubi-prepare.py): [14:00] ubiquity: * Fix a crash when there are no disks present on the system [14:00] ubiquity: (LP: #631766). [14:00] ubiquity: * Don't let the user continue if there are no disks present, or if [14:00] ubiquity: there isn't enough free space on any of them to install. === mpt_ is now known as mpt [17:05] ev, cjwatson any other thoughts on my (updated) grub-support merge request for usb-creator? i'd like to move a few other tools over, but wanted to make sure this was good first [17:13] superm1: it looks basically ok now. I think maybe drop the count= on the dd of core.img, and just only copy however much exists, maybe with a check that it isn't bigger than 62 sectors [17:13] but this is just me being paranoid about other stuff in that region based on recent experience, and it probably doesn't matter that much [17:14] have you been able to construct a test for this? [17:14] i did a short test with it yes [17:14] on usb sticks, you would hope there isn't much in that region to start... [17:16] the test was a little bit ugly though, generating core.img with a grub.cfg set to search, and then manually hex editing boot.img for the HDD hack that grub-setup did [17:19] isn't much> true [18:41] ubiquity: evand * r4293 trunk/ (debian/changelog ubiquity/plugins/ubi-partman.py): [18:41] ubiquity: Fix UI bugs in the automatic partitioner page. Better handle [18:41] ubiquity: determining what the desired partitioning recipe is (LP: #630450). [18:57] I remember there being a spec to use grub to boot the live cd instead of isolinux. Did that get implemented in Maverick? [18:57] cody-somerville: nope [18:59] Does grub and syslinux both get installed now? [19:01] grub is there just for EFI [19:01] huh, I cannot find the spec now [19:01] https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-cd-boot [19:01] thanks [19:01] blame the release cycle being three weeks shorter than it should have been :P [19:04] cjwatson: no excuses! Just switch to the pre-Constantine Roman calendar (8 day weeks). [19:04] :-P [19:04] right-o, home