[01:03] <CIA-3> ubiquity: cjwatson * r3082 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[01:03] <CIA-3> ubiquity: * GTK frontend:
[01:03] <CIA-3> ubiquity:  - Fix suggested keymap handling so that selecting that option after
[01:03] <CIA-3> ubiquity:  selecting a custom keymap applies the suggested keymap (LP: #337998).
[01:52] <CIA-3> ubiquity: cjwatson * r3083 ubiquity/ (debian/changelog partman/check.d/03partition_too_small):
[01:52] <CIA-3> ubiquity: Add a fudge of 20% to the size of each tree on the live filesystem
[01:52] <CIA-3> ubiquity: (other than / and /boot, which already have their own fudge factors) for
[01:52] <CIA-3> ubiquity: the purposes of the partition-too-small check (LP: #298318).
[02:10] <Haegin> Hey, I have just installed jaunty (twice) and noticed that certain parts of the installer don't seem to honour the keyboard layout chosen at the start of the install process
[02:11] <Haegin> In particular the user name and password fields were qwerty when the previous screens had been in dvorak (though I might not have actually checked that come to think of it)
[02:14] <cjwatson> not bug 337998 by any chance?
[02:14] <cjwatson> Haegin: if it's not that bug, please run the installer with 'ubiquity -d' and get us /var/log/installer/debug
[02:14] <cjwatson> and /var/log/syslog too
[02:16] <Haegin> Ok, it isn't that bug as far as I can tell
[02:17] <Haegin> I also had the same old problem with grub that seems to have plagued the last 3 or 4 releases
[02:20] <Haegin> and I doubt I will be able to get those bug reports as it now boots to a blank screen
[02:20] <cjwatson> you mean multiple disks?
[02:20] <Haegin> yup
[02:21] <cjwatson> yes, we now believe that to be unfixable except by adding UI to let you control it :-(
[02:21] <cjwatson> which is a right pain
[02:21] <Haegin> somehow it gets confused about where grub should install to and I have to reboot and rerun grub-install manually :(
[02:21] <cjwatson> Haegin: did you select the dvorak keyboard layout at the CD boot menu, or did you select it in the installer?
[02:21] <cjwatson> Haegin: and what CD boot menu option did you use - "Try Ubuntu" or "Install Ubuntu"?
[02:22] <Haegin> I was using the alternate CD and selected it in the installer. I didn't realise there was a keyboard layout option at the menue
[02:22] <Haegin> s/e^//
[02:22] <Haegin> *$
[02:23] <cjwatson> ... alternate? oh. ok
[02:23] <Haegin> Old habits die hard
[02:23] <cjwatson> I wonder if the keyboard layout is getting reset when console-setup is installed into the chroot
[02:23] <cjwatson> that would be annoying
[02:24] <Haegin> I'll check it again as it looks like it needs reinstalling a third time...
[02:24] <cjwatson> no, I wasn't objecting to you using alternate, I was just in ubiquity mode tonight and therefore had to adjust
[02:24] <Haegin> ah ok, sorry - I should have said
[02:24] <cjwatson> if the keyboard layout is changed at that point, that could explain some other slight weirdness I've encountered lately
[02:25] <cjwatson> that said, even if it pokes the keyboard layout into the kernel again, the installer integration is supposed to arrange that it pokes in the *same* layout
[02:25] <cjwatson> Haegin: perhaps you could file a bug on /ubuntu/+source/console-setup just quoting this IRC conversation?
[02:26] <cjwatson> maybe minus the unrelated bits about grub
[02:26] <Haegin> sure, I'll just double check it actually does set it to dvorak in the first place...
[02:28] <Haegin> does console-setup get run before or after the hostname is set?
[02:28] <cjwatson> before
[02:28] <cjwatson> specifically, before any point when you might need to type anything non-trivial
[02:29] <Haegin> it was in dvorak mode when I set the hostname and when I labelled a few partitions
[02:29] <Haegin> but it certainly switches to qwerty when I enter the username and a password
[02:32] <cjwatson> that's after base system installation, at which stage console-setup gets installed into /target
[02:32] <cjwatson> this is without proof, but that's overwhelmingly likely to be the point when it breaks
[02:32] <cjwatson> very little else messes with the keyboard layout in any way
[02:33] <cjwatson> Haegin: which layout specifically - US Dvorak?
[02:36] <Haegin> I selected UK dvorak (but not the one with UK punctuation)
[02:38] <cjwatson> reproduced
[02:40] <cjwatson> oh, bah
[02:40] <cjwatson> base-installer (1.92) unstable; urgency=low
[02:40] <cjwatson>   * Call base-installer.d hooks after running debootstrap, for consistency
[02:40] <cjwatson>     with live-installer. (So, pre_install_hooks is run after bootstrap, but
[02:40] <cjwatson>     before anything is installed with apt. So the name still makes a kind
[02:40] <cjwatson>     of sense, if you squint..)
[02:41] <cjwatson> I knew that would break something
[02:43] <Haegin> was it that fix that caused the issue?
[02:45] <cjwatson> yes
[02:45] <cjwatson> do please file a bug, I'll fix it in the morning
[02:45] <cjwatson> (the above wasn't written by me BTW)
[02:46] <Haegin> I might have to file it tomorrow - I'll need to gather the info and I'm going to be crashing as soon as this install is setup updating and installing while I sleep
[02:46] <cjwatson> no need to gather any information
[02:46] <Haegin> oh ok then
[02:46] <cjwatson> just a summary of the above discussion will be entirely fine
[02:47] <cjwatson> "keyboard layout gets reset when console-setup is installed during base system installation" or some such
[02:47] <Haegin> ok, what project is it?
[02:47] <charlie-tca> cjwatson: still got the error with the suggested change to /lib/partman/commit.d/30parted
[02:47] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/console-setup/+filebug
[02:47] <cjwatson> (I might reassign it, but that will do)
[02:48] <cjwatson> charlie-tca: bah, ok, thanks for trying. I can't dive into it now since I need to sleep
[02:48] <charlie-tca> Sorry for being gone so long.
[02:48] <charlie-tca> Okay, I am going to try to get the monitor log yet
[02:49] <cjwatson> charlie-tca: what you could also try instead of running the monitor is: find the udevd process; kill it (yes, really; just make sure nothing else is happening); run 'UDEV_LOG=err udevd --debug >udev.log 2>&1'; run through partitioning as before; extract udev.log
[02:49] <cjwatson> (using the same scp technique as before)
[02:50] <charlie-tca> Okay, I'll try to get that.
[02:50] <cjwatson> charlie-tca: that's a bit more effort, but it will get us information about what udevd is running as well as what messages it received (which is basically what monitor tells us)
[02:50] <cjwatson> I'd be surprised if Keybuk couldn't figure it out given that
[02:50] <charlie-tca> I got a couple of hours, so I'll do what I can then
[02:52] <cjwatson> thanks
[02:52]  * cjwatson goes to snooze
[02:56] <Haegin> cjwatson: reported as bug 340308
[04:36] <CIA-3> casper: TheMuso * r585 trunk/ (3 files in 3 dirs):
[04:36] <CIA-3> casper: * scripts/casper-bottom/30accessibility && ubiquity-hooks/30accessibility:
[04:36] <CIA-3> casper:  - Adjust sudoers file to allow ORBIT_SOCKET_DIR, XDG_SESSION_COOKIE and
[04:36] <CIA-3> casper:  GTK_MODULES environment variables through to root, for v2, v3, and
[04:36] <CIA-3> casper:  braille profiles. This allows users to use administrative GTK/GNOME
[04:36] <CIA-3> casper:  applications executed by gksudo with accessibility tools like orca.
[04:39] <CIA-3> casper: TheMuso * r586 trunk/debian/changelog: releasing version 1.160
[09:19] <juanje> hi guys
[09:21] <evand> hello
[09:23] <cjwatson> Haegin: thanks
[09:24] <juanje> I'm working with a frontend for Ubiquity on Guadalinex (actually a wrapper of the gtk_ui) and I was working on earlier versions of Ubiquity (at least for Guadalienx editions) is there anything I can help with the Ubiquity? If I can give a hand on anything just tell me :-)
[09:27] <cjwatson> send patches for bugs :-)
[09:27]  * evand indeed, was just typing that :)
[09:27] <juanje> cjwatson:  is there any channel about casper?
[09:28] <cjwatson> this one is the best there is
[09:28] <juanje> cjwatson: hehe, ok, I was checking (and I will)
[09:29] <juanje> cjwatson: ok, because I woking in some things about casper and I like to know if there is any posibility yet to have any in jaunty
[09:30] <juanje> cjwatson: for ejample the bug #337723 (The SSL certificate is the same in any Live box) which has branch with proposed solution
[09:32] <cjwatson> any reason it's private? I can't even see it myself
[09:32] <juanje> ups
[09:32] <juanje> I don't know exactly why. I guess is because I put the check for a securrity issue
[09:33] <juanje> now is public
[09:33] <juanje> sorry
[09:33] <cjwatson> thanks
[09:34] <juanje> cjwatson: other are things like having some English path fixed (/home/$USERNAME/Destktop) so in other languages mess with the XDG names
[09:34] <juanje> I'm working on that right now (I was about to put the bug, but I didn't yet...)
[09:35] <cjwatson> 337723 should definitely be fixed; I'm looking at your branch right now
[09:35] <cjwatson> as for /Desktop I'm less sure about that. I think for the Ubuntu live CD it's always /Desktop regardless of language, and xdg-user-dirs might move translated directories around at login
[09:36] <cjwatson> I'm be OK with merging a patch for that if it were careful to deal with both possibilities
[09:36] <davmor2> cjwatson: after you've sorted that did you have any joy reproducing the "races" issue?
[09:36] <cjwatson> davmor2: no :-(
[09:36] <cjwatson> 02:49 <cjwatson> charlie-tca: what you could also try instead of running the monitor is: find the udevd process; kill it (yes, really; just make sure nothing else is happening); run 'UDEV_LOG=err udevd --debug
[09:36] <cjwatson>                  >udev.log 2>&1'; run through partitioning as before; extract udev.log
[09:36] <cjwatson> 02:49 <cjwatson> (using the same scp technique as before)
[09:36] <cjwatson> davmor2: if you can manage that, it'd help
[09:38] <davmor2> cjwatson: I'll have a look at it in a bit as soon as I know I got todays images, hopefully they'll install this time :)
[09:39] <davmor2> I'm guessing the bits between quotes should all be on one line
[09:39] <juanje> cjwatson: I was working with xdg-dirs-update to have the right final XDG-* vars avaibles in casper so we can use them. We (in Guadalinex) had before to change by hand the directory because the xdg-user-dirs moving thing wasn't working. But I'll check again before keep working
[09:39] <cjwatson> yes
[09:40] <CIA-3> casper: cjwatson * r587 trunk/ (scripts/casper-bottom/22sslcert debian/changelog):
[09:40] <CIA-3> casper: Regenerate SSL certificate at boot so that it isn't the same for all
[09:40] <CIA-3> casper: live CD users (LP: #337723).
[09:40] <cjwatson> that merges your branch, thanks; I'll just tweak it a little
[09:40] <juanje> cjwatson: great :-) Thanks
[09:41] <CIA-3> casper: cjwatson * r588 trunk/scripts/casper-bottom/22sslcert: use sentence case for progress messages
[09:43] <CIA-3> casper: cjwatson * r589 trunk/scripts/casper-bottom/22sslcert: don't break if ssl-cert is not installed in /root
[09:45] <evand> yay, autorun.inf on the latest daily-live is fixed.
[09:45] <davmor2> evand: :) Yay \o/
[09:47] <CIA-3> base-installer: cjwatson * r354 ubuntu/debian/ (bootstrap-base.postinst changelog):
[09:47] <CIA-3> base-installer: Revert Joey's patch to call base-installer.d hooks after running
[09:47] <CIA-3> base-installer: debootstrap, which broke console-setup's expectation of being able to
[09:47] <CIA-3> base-installer: insert its configuration file into /target before console-setup is
[09:47] <CIA-3> base-installer: installed by debootstrap (LP: #340308).
[09:54] <CIA-3> base-installer: cjwatson * r355 ubuntu/debian/changelog: releasing version 1.98ubuntu3
[09:57] <juanje> cjwatson: Well, seens xgd-user-dirs makes its job, but in Spanish enviroment you have then "Escritorio" pointing to "~/Desktop" in nautilus, it is not moved, just virtualy liked, so in some views you see "Escritorio" and in others "Desktop" and in the terminal you have just "~/Desktop". I'll fill a bug about it, ok?
[10:09] <cjwatson> juanje: well, that sounds more or less as desired actually. It's much *easier* when the filesystem paths stay the same.
[10:10] <cjwatson> I've been trying to campaign against having the filesystem paths changed for some time; it's better when they stay the same but the presentation layer takes care of it (I don't count terminals among presentation layers)
[10:11] <cjwatson> if I had my way it would be called ~/dsk/ or ~/.desktop/ or something so that it was out of the way and not expected to have an intelligible name
[10:12] <juanje> cjwatson: well, then the problem it's the layers, because nautilus itself get lost some times with those paths. I can see in Jaunty in one view Desktop instead of Escritorio and then Escritorio in other...
[10:15] <cjwatson> bug in nautilus, but not in the directory name, imo
[10:15] <cjwatson> changing those directory names just breaks things
[10:15] <juanje> cjwatson: yeah, probably....
[10:19] <cjwatson> evand: OK if I do a quick ubiquity upload for alpha-6?
[10:19] <CIA-3> ubiquity: cjwatson * r3084 ubiquity/ (d-i/manifest debian/changelog):
[10:19] <CIA-3> ubiquity: Automatic update of included source packages: choose-mirror 2.27ubuntu4,
[10:19] <CIA-3> ubiquity: clock-setup 0.97ubuntu3, partman-partitioning 64ubuntu5.
[10:20] <evand> sure thing
[10:20] <cjwatson> righto
[10:20] <CIA-3> usb-creator: evand * r85 usb-creator/setup.cfg: Re-enable i18n.
[10:20] <cjwatson> installer translations should be imported into Rosetta fairly soon for jaunty, BTW
[10:20] <cjwatson> (belatedly, but ...)
[10:21] <evand> indeed, I saw that LP Answers request.  Thanks for the heads up though.
[10:26] <CIA-3> ubiquity: cjwatson * r3085 ubiquity/debian/changelog: releasing version 1.11.16
[10:29] <davmor2> evand: did you manage to fix the map from install?
[10:30] <evand> davmor2: not completely yet.  Still working on it.
[10:30] <davmor2> np's I was gonna test it if you had :)
[10:31] <davmor2> cjwatson: should I run the udev-debug as earlies as possibly?
[10:31] <davmor2> possible even?
[10:32] <cjwatson> davmor2: no, when the first partitioner question appears, switch to tty2 and follow the steps I gave
[10:32] <davmor2> right so not before then
[10:32] <davmor2> no probs
[10:32] <cjwatson> no, it'll just produce vast quantities of junk if you do :-)
[10:34] <davmor2> cjwatson: so you don't want it running from host name then, like last time?
[10:36] <cjwatson> nope
[10:36] <cjwatson> won't hurt if you do, but it's more than we need
[10:37] <davmor2> cjwatson: it a relatively safe place to kill udev though I'd of thought :)
[10:37] <davmor2> installing alt now
[10:39] <cjwatson> it doesn't make a difference since you're starting it back up again immediately, and nothing will happen while the UI's waiting for input from you
[10:39] <davmor2> true :)
[10:40]  * davmor2 scrolls back up to find command
[10:40] <CIA-3> casper: cjwatson * r590 trunk/debian/changelog: releasing version 1.161
[10:53]  * davmor2 slaps self on head for hitting the wrong install method :( and starts again
[11:06] <CIA-3> usb-creator: evand * r86 usb-creator/ (debian/changelog usbcreator/backend.py): Support SD cards and other removable devices. Thanks Eric Butler!
[11:06] <evand> FireRabbit: ^ Thanks for your patch.  I reworked it a bit.
[11:08] <lool> Hi folks, Xorg crashed during an install of UNR on an EeePC701SD here; gdm restarted a session; I'd like to collect enough debug info for a bug
[11:09] <lool> I'm checking /var/log/installer/debug and it has various warnings, an assertion error in the gtk frontend, and then "ubiquity: Fatal IO error 104"
[11:09] <lool> Which I think is gtk failing to talk to Xorg
[11:10] <lool> It crashed just after setting the time from NTP during install
[11:10] <lool> Oh I wonder whether the time changed confused Xorg
[11:10] <lool> I see negative times in the Xorg.0.log.old
[11:11] <lool> [626609.129118] (EE) PreInit returned NULL for "Video Bus"
[11:11] <lool> Sorry "[-26609.129118]" not "[626609.129118]"
[11:21] <lool> I think it boils down to Xorg crashing when time goes back, albeit I'm not sure which part of Xorg
[11:33] <lool> Is there a way to resume the install?
[11:33] <cjwatson> sounds like you're right about Xorg; you should be able to restart the installer by just running ubiquity
[11:37] <lool> BTW folks the new timezone selection is nice
[11:41] <evand> thanks.  Just trying to fix the plotting of the timezone points on that.
[11:45] <davmor2> hey evand when does the new colour scheme go in is that a pre ui freeze job?
[11:48] <evand> davmor2: it just went in with cjwatson's ubiquity upload.  I'll have to shoot an email to the documentation team.
[11:54] <davmor2> cjwatson: http://www.davmor2.co.uk/udev.log
[11:54] <cjwatson> thanks, Scott and I are in the process of figuring out a fix
[11:55] <davmor2> for some unknown reason though it doesn't lock up when you restart udev or is that the debug bit?
[11:56] <cjwatson> it's a race condition
[11:56] <cjwatson> debugging slows one side of the race down and therefore can easily have the result of making it "go away"
[11:56] <cjwatson> doesn't make the data invalid though; indeed it confirms what we'd seen from another log
[11:57] <cjwatson> the remove is racing with a change event that runs vol_id on the same device
[11:59] <davmor2> cjwatson: Okay.   So what's happening in laymen's terms then is udev is running vol_id and therefore accessing the partition you're trying to write too so it fails, is that about right-ish?
[12:00] <davmor2> just trying to understand things better :)
[12:02] <davmor2> install fails anyway do too compiz :( meh
[12:08] <cjwatson> that's correct except "accessing the partition you're trying to remove" not write to
[12:08] <cjwatson> libparted needs to tell the kernel to reread the partition table
[12:09] <cjwatson> it does this by telling the kernel to remove its internal memory of all the old partitions, and then telling it to add the new ones
[12:09] <cjwatson> (some of these partitions may of course be identical to ones that were there before)
[12:11] <tjaalton> cjwatson: I attached the logs to bug 334278, but looks like you already know what's happening
[12:11] <cjwatson> well, we think so
[12:11] <cjwatson> although we've thought that before :)
[12:12] <lool> persia: I filed a bug for the syslinux main menu on the UNR images: "Check disc for defects" should also be fixed like the usplash shutdown prompt to press enter
[12:12] <cjwatson> yours is the first confirmation on LVM
[12:12] <lool> persia: 309396; you're sub-ed
[12:12] <lool> Err no, that's not the right id
[12:14] <davmor2> cjwatson:  Ah okay I'm with you now :)
[12:15] <davmor2> cjwatson: if you get a fix and can respin before say 2 I can retest it for you :)  However I'm off to oxford at about 3
[12:16] <persia> lool, 309396 is currently waiting on the SRU process.  The fixed syslinux is in -proposed.
[12:17] <cjwatson> davmor2: we're still exploring, so I think before 2 is unlikely
[12:17] <persia> lool, Oh, you mean the text change for USB/SD/CD/DVD/etc. ?
[12:17] <davmor2> cjwatson: no probs
[12:19] <lool> persia: Yes
[12:20] <lool> Grmpf the wifi here ate my bug report
[12:20] <persia> lool, I'm not sure it's really the same bug.  Maybe part of 290696, or maybe a new bug.
[12:20] <lool> ah no
[12:20] <cjwatson> beware that that text is translated in gfxboot
[12:21] <lool> persia: 340440
[12:21] <lool> persia: I think it's the same type of bug, but in a different place
[12:21] <cjwatson> so common text suitable across the board would be nice; if not, be careful to change translations
[12:21] <persia> Right.  New bug is probably best.
[12:21] <cjwatson> err, add translatable messages
[12:21] <cjwatson> "install media" => "installation media" but that might be getting quite long
[12:21] <cjwatson> if it fits, that could work
[12:23] <lool> persia: I also filed #340438, I don't know whether we simply miss stuff in the image or whether it's some bug with my hw TBH
[12:23] <lool> It's the language prompting appearing briefly, but disappearing immediately
[12:23] <cjwatson> for the record such bugs should be filed on the gfxboot-theme-ubuntu package in Ubuntu
[12:24] <lool> cjwatson: Aha, thanks
[12:24] <persia> And that looks suspiciously like a dup of 309396
[12:24] <lool> persia: So you see the menu with the fix?
[12:24] <persia> lool, Can you try running any of hardy-proposed, intrepid, or jaunty syslinux on the image pre-dd?
[12:25] <persia> Yes.
[12:25] <lool> persia: Let's recheck when the update is installed and the next daily is built
[12:25] <persia> Well, then you get an incomplete :)
[12:25] <lool> persia: Hmm sure, Tobin has it, will ask him
[12:26] <lool> persia: Tobin is running intrepid; it's working fine in intrepid's syslinux you say?  I'll ask him
[12:26] <StevenK> Just re-syslinux the .img
[12:26] <persia> No, it needs to be re-syslinux'd.  See the updated description in 309396
[12:30] <lool> persia: I told him to re-syslinux the USB key or the image
[12:30] <lool> and to join here
[12:31] <cjwatson> it should be possible to tell the difference visually between "language menu disappeared mysteriously but gfxboot is still running" and "gfxboot crashed, back to syslinux"
[12:31] <cjwatson> if you show me a photograph I can tell you which is which straight off
[12:31] <persia> Indeed.  The easy way is whether the first menu option is truncated.
[12:31] <persia> (especially for the long string "Ubuntu Netbook Remix".
[12:32] <persia> cjwatson, Now that it doesn't serve as a reminder anymore, where ought the string truncation when we aren't using gfxboot be fixed?
[12:32] <persia> Is that in syslinux itself?
[12:33] <cjwatson> no, debian-installer (build/boot/x86/menu.cfg)
[12:34] <cjwatson> or possibly stdmenu.cfg or one of the others
[12:34] <lool> So I also have another bug, Advanced Options menu is empty, but I'm waiting to see it after the syslinux update
[12:34] <persia> Thanks for the pointer.  I'll take a look about (although given that it's typically masked, I'll not be in a hurry).
[12:34] <persia> lool, That's also 309396.
[12:35] <cjwatson> masked?
[12:35] <cjwatson> oh, gotcha
[12:35] <persia> Because under normal circumstances we *are* using gfxboot
[12:35] <lool> persia: aha
[12:35] <cjwatson> if you're seeing an Advanced Options menu, you are *definitely* encountering 309396
[12:35]  * persia dupes 340348
[12:37] <lool> persia: Yes, new syslinux fixes both bugs; thanks
[12:38] <lool> Ah dupped already
[12:38] <persia> lool, If you happen to have used the hardy-proposed syslinux, please add a note to 309396.  Otherwise, just remember to run syslinux until that hits the infrastructure.
[12:38] <lool> cjwatson: Yes exactly, no advanced options anymore after running sysliniux
[12:38] <lool> persia: No, the intrepid one
[12:38] <persia> Oh well.  We knew that worked :)
[12:38] <lool> So I had another bug
[12:38] <lool> Which is likely fixed as well
[12:39] <lool> When I press "enter" on this syslinux screen, I wouldn't get any feedback for a while
[12:39] <lool> I think it's the same bug
[12:40] <persia> That's related to oddities between keymappings and the base syslinux menu.  I've encountered it sporadically, but nothing I could track down or reliably reproduce on alternate HW/alternate environments.  Given that we typically use gfxboot, it's not usually visible.
[12:40] <persia> Note that the things you've found *are* bugs, they just aren't supposed to be end-user visible, so aren't considered very important (although 309396 makes them visible today).
[12:41] <lool> Understood
[12:41] <lool> So otherwise, I had relatively simple bugs
[12:42] <lool> The installer part was fine except for screen size issues, an issue with simple passwords, and a focus issue
[12:43] <persia> Issue with simple passwords?  Which image?
[12:45] <lool> persia: UNR
[12:45] <persia> What sort of issue?  There's an intentional change to expect strong passwords, and the UNR image oughtn't have any preseeding that affects password choice.
[12:45] <lool> persia: So if you enter a too simple password, you get a dialog
[12:46] <StevenK> Then pick a better password?
[12:46] <StevenK> That strikes me as a feature
[12:46] <lool> persia: if you agree you need to change it and go changing it, you get *another* red warning near the password field
[12:46] <lool> StevenK: I wasn't done explaining the bug
[12:46] <persia> evand, Is that intentional behaviour?
[12:47] <lool> It's not because what red warning says is "You entered an empty password, which is not allowed."
[12:47] <lool> And it was certainly not a blank password
[12:47]  * StevenK regenerates the UNR daily
[12:47]  * lool lunch &
[12:53] <persia> Oh.  I see.  That's because passwd/user-password is set to "" when it's weak, and triggers it that way.
[12:54] <persia> Not sure how to get back to STATE=6 in a sane way without a blank password, but perhaps there's something that needs tweaking in the UI?  Maybe a new error state?
[12:55] <persia> Ah.  "# TODO would be better to extend state machine" :)
[12:56] <persia> lool, ^ Your bug is known, but needs more thought as part of the password-strength implementation.
[12:56] <cjwatson> err, not known, I hadn't thought about the empty password interaction
[12:57] <persia> Sorry then.  I thought the TODO was because it could cause issues.
[12:57] <cjwatson> just inelegant
[12:59] <cjwatson> it's pretty weird that you get another warning there
[12:59] <cjwatson> lool: can you file a bug on ubiquity about this?
[13:01] <persia> Won't it just bounce to STATE=6, and then hig user-setup/password-empty, or should it be catching on the request for passwd/user-password?  (I'm a little unclear how many times d-i components can loop behind ubiquity)
[13:01] <persia> s/hig/hit/
[13:02] <cjwatson> but state 6 should then sit and wait for the password to be entered
[13:02] <cjwatson> actually the problem may be that ubiquity thinks it's finished
[13:03] <cjwatson> http://paste.ubuntu.com/129287/ might do it
[13:05] <persia> Quite likely, yes.
[13:06]  * persia tries
[13:25] <persia> cjwatson, Confirmed that your patch fixes this: the "You entered an empty password ..." text no longer appears with manual addition of the change to /usr/lib/ubiquity/ubiquity/components/usersetup.py on an image.
[13:25] <persia> (and I can reproduce without the change)
[14:00] <davmor2> charlie-tca: morning dude
[14:00] <charlie-tca> good morning
[14:04] <kirkland> cjwatson: i have updated https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/327348 with some new information for you
[14:14] <cjwatson> kirkland: ok, will try. vnc is a lot less convenient for my typical use, which is why I don't generally use it
[14:15] <persia> kirkland, I wonder which is the correct behaviour.  While I also nearly always use SDL, I notice that with vinagre, alt-tab doesn't let one switch easily to other windows on one's local desktop.
[14:15] <kirkland> cjwatson: understood, and I agree
[14:15] <kirkland> cjwatson: persia: i don't use vinagre/vnc either
[14:15] <kirkland> it's an issue that upstream is aware of
[14:16] <persia> kirkland, Could perhaps SDL clear all currently active pressed keys on focus loss?
[14:16] <kirkland> it's a fairly complex operation, trying to determine when the guest "should have received" an alt/shift/ctl up event and the focus has already been shifted away
[14:17] <persia> Is it ever harmful to send an extra alt/shift/ctrl/meta/super up?
[14:17] <kirkland> persia: cjwatson: as I said in the bug, they are working on heuristics to help determine this
[14:17] <kirkland> as you might imagine, caps-lock/num-lock/scroll-lock present the same problems
[14:17] <persia> Most apps don't respond too carefully to key release events.
[14:18] <persia> Well, similar, but I think it's less intuitive that one needs to press "Alt" to get the release than that one needs to toggle the locks separately.
[14:19] <kirkland> persia: i'm curious....
[14:19] <kirkland> persia: you're saying that vinagre does not work well for you, on alt-tab?
[14:20] <persia> Right.  When I press Alt-Tab with focus on vinagre, it absorbs the key event, and passes to the guest.
[14:20] <persia> This makes sense, and might even be correct, but it makes it hard to, say, do parallel editing of a file, or similar.
[14:31] <evand> cjwatson: Can you please review this when you have a moment: http://pastebin.ubuntu.com/129337/
[14:33] <cjwatson> evand: looks plausible if -w /cdrom works as a test
[14:35] <evand> indeed, it appears to.
[14:35] <evand> ok, will commit and upload then
[14:36] <CIA-3> casper: evand * r591 casper/ (2 files in 2 dirs):
[14:36] <CIA-3> casper: If /cdrom is writable, call the diverted update-initramfs and copy
[14:36] <CIA-3> casper: the resulting kernel and initrd to /cdrom/casper (LP: #292159).
[14:39] <persia> On the VFAT images, the initrd.gz seems to be in the root directory, rather than in casper.  Is this an image construction bug, or should the logic verify the target file exists before copying?
[14:44] <CIA-3> casper: evand * r592 casper/debian/changelog: releasing version 1.162
[15:12] <lool> cjwatson: Yup, I had in mind to file a bug anyway, just got distracted by lunch and other discussions
[15:15] <lool> 340549
[16:17] <cjwatson> tjaalton,charlie-tca: I'd hugely appreciate it if you could try the image at http://cdimage.ubuntu.com/tmp/20090310/ (when it arrives; it seems to be taking its own sweet time)
[16:17] <cjwatson> tjaalton,charlie-tca: it should rsync well against the current server image. Sorry I can't do amd64 easily
[16:17] <CIA-3> ubiquity: evand * r3086 ubiquity/ (3 files in 3 dirs):
[16:17] <CIA-3> ubiquity: * Pack the timezone_map in an AspectFrame instead of a regular Gtk Frame.
[16:17] <CIA-3> ubiquity: * Plot the time zone cities using a Miller cylindrical map projection with
[16:17] <CIA-3> ubiquity:  adjustments for the shifted left edge and missing arctic region of the
[16:17] <CIA-3> ubiquity:  map.
[16:18] <cjwatson> tjaalton,charlie-tca: this contains an extra udev patch from Scott to make udevadm settle work a bit harder
[16:19] <evand> ^ That doesn't solve the time zone city placement bug, but the change at least makes the placement more accurate and doesn't worsen as the map grows anymore.
[16:20] <evand> Suggestions welcome on further refinement.  That bug is definitely doing my head in.
[16:23] <cjwatson> http://cdimage.ubuntu.com/tmp/20090310/jaunty-server-i386.iso exists now
[16:25] <cjwatson> evand: you seem to have added the changelog entries to an existing release rather than creating a new one
[16:26] <evand> arrr, my mistake
[16:26] <evand> I'll fix that now
[16:28] <charlie-tca> I'm downloading the image now.
[16:28] <cjwatson> charlie-tca: thanks!
[16:29] <charlie-tca> no problem
[16:29] <cjwatson> 16:00 <cjwatson> slangasek: yes :-( if you care about the details, it's because udevd has inotify watches on devices so that it can update uuids/labels/etc. when they change, so when libparted opens (writably)
[16:29] <cjwatson>                  a block device and closes it later this causes a change event to be scheduled; udevadm settle doesn't make sure that the inotify queue is flushed so if you happen to call udevadm settle before
[16:29] <cjwatson>                  udevd gets round to processing the ...
[16:29] <cjwatson> 16:00 <cjwatson> ... inotify then it won't necessarily wait for udev to be finished, so change events race with rereading the partition table
[16:29] <cjwatson> 16:00 <cjwatson> if you call udevadm settle once udevd has processed the inotify queue and scheduled a change event, it all works fine because *that*'s something that udevadm settle will wait for
[16:29] <cjwatson> 16:01 <cjwatson> Scott has a patch for this which I'm testing
[16:29] <cjwatson> 16:01 <slangasek> you are in a maze of twisty races
[16:29] <cjwatson> 16:03 <cjwatson> some of which, but not all, may sometimes appear to be alike
[16:29] <cjwatson> (from #ubuntu-release)
[16:29] <cjwatson> what I am now hoping is that this is in fact the race you were encountering
[16:29] <charlie-tca> I see. Thanks for that info
[16:30] <cjwatson> it's entirely possible that we spent the day fixing yet another race
[16:30] <cjwatson> that isn't actually the one you're hitting :-/
[16:30] <cjwatson> but hopefully that isn't the case
[16:31] <CIA-3> ubiquity: evand * r3087 ubiquity/debian/changelog: Whoops. Create a new version for the changelog entry.
[16:35] <charlie-tca> I hope you are right.
[16:41] <CIA-3> ubiquity: cjwatson * r3088 ubiquity/ (debian/changelog ubiquity/components/usersetup.py):
[16:41] <CIA-3> ubiquity: Stop the user-setup component from believing it's done after the user
[16:41] <CIA-3> ubiquity: selects "go back" at a weak password dialog (LP: #340549).
[16:41] <cjwatson> evand: I'm sure that timezone map change must have closed some bugs :-)
[16:44] <evand> cjwatson: It's not accurate enough yet (London is sitting in the English channel), so I'm hesitant to close any bugs. :/
[16:45] <evand> It's just technically accurate for the projection and adjustments for the map position and missing arctic section, unless I'm missing something.
[16:46] <evand> I'll have to further refine it without making some points accurate and others wildly inaccurate somehow.
[16:47] <FireRabbit> evand: glad i was able to help, thanks for finishing it.
[16:47] <evand> sure thing :)
[16:51] <FireRabbit> evand: quick question, i see you removed the storage.removable check, does that mean any usb hard drive will show up?
[16:53] <evand> Possibly.  But it's the only way to get full SD card support as built in readers apparently show up with storage.removable = False
[16:54] <evand> Actually, we could just say if bus == usb and storage.removable
[16:55] <FireRabbit> i was thinking it might actually be useful, but perhaps not a good thing to enable by default without a big warning
[16:58] <evand> my concern has always been that people accidentally use it on the wrong drive, but I guess enough people would want to install to external USB drives and we provide enough information to the user to discern between drives that it's probably ok as-is.
[17:00] <charlie-tca> cjwatson: same error on partitioning
[17:00] <cjwatson> ARGH
[17:00] <charlie-tca> device or resource busy
[17:00] <cjwatson> oh, hang on
[17:00] <charlie-tca> I did add the logs from another install to the bug, including the udev log
[17:00] <cjwatson> I bet you didn't have the settle before commit, since that was something I asked you to apply by hand
[17:01] <charlie-tca> aw, crap
[17:01] <charlie-tca> I just ran the cd
[17:01] <cjwatson> this time round, could you edit /lib/partman/commit.d/30parted before the partitioner starts and put 'update-dev --settle' right above 'open_dialog COMMIT'?
[17:01] <cjwatson> not your fault, I should have remembered to say that
[17:01] <cjwatson> tjaalton: ^- same goes for you if you're testing this
[17:02] <charlie-tca> Well, sure. I will have to set it up and do it again.
[17:02] <cjwatson> my apologies
[17:04] <charlie-tca> no problem, I probably just made a mistake, myself
[17:09] <FireRabbit> evand: oh was wondering, will this be in Jaunty or is it too late for that?
[17:12] <evand> FireRabbit: I'll speak with the release manager about it and see what he says
[17:13] <FireRabbit> okay
[17:53] <cjwatson> charlie-tca: any luck?
[17:54] <charlie-tca> Just adding the commit line
[17:56] <charlie-tca> error again
[17:57] <charlie-tca> added 'update-dev --settle' to /lib/partman/commit.d/30parted ; no luck
[17:57] <cjwatson> is it *exactly* the same error?
[17:58] <charlie-tca> Let me look at the logs
[17:58] <cjwatson> charlie-tca: I think what I'll need is a repetition with the same hack, plus a log after killing and restarting udevd in the previously prescribed manner
[17:59] <charlie-tca> Apparently not, hitting ignore let it keep going, and it only gave the error on the extended partition, sdc2
[17:59] <charlie-tca> It never gave any error for sdc1 or sdc5 or sdc6
[18:00] <CIA-3> ubiquity: evand * r3089 ubiquity/ (debian/changelog ubiquity/timezone_map.py ubiquity/tz.py):
[18:00] <CIA-3> ubiquity: Account for daylight savings when highlighting a region in the
[18:00] <CIA-3> ubiquity: timezone_map (LP: #335355).
[18:01] <charlie-tca> okay, I'll do it again, and get the udevd log with the rest
[18:01] <cjwatson> charlie-tca: sure, I'm not surprised that it only affects one partition
[18:01] <cjwatson> once this error occurs we have lost
[18:02] <charlie-tca> It was giving the errors on all the partitions. Is that progress?
[18:07] <cjwatson> no, it's luck ;-)
[18:08] <cjwatson> you can't compare two instances of a race condition and say that one has improved because it was a little less serious
[18:08] <cjwatson> of course it's possible that this means there are two races and we fixed one of them
[18:10] <charlie-tca> okay, I'll just get it set and run it all again
[18:27] <cjwatson> this is going to be a long night, I can tell :-/
[18:29] <tjaalton> cjwatson: ok, I'll try it out tomorrow
[18:47] <cjwatson> charlie-tca: any luck?
[18:48] <charlie-tca> Got the warning, and it is continuing. Can I interupt the install to get the logs?
[18:49] <cjwatson> just switch to tty2 and copy stuff out
[18:49] <cjwatson> there's no need to wait for it to complete
[18:49] <charlie-tca> It went right to "Installing the base system" after the warning
[18:50] <cjwatson> actually it's really easier if you just stop at the warning and copy the logs out right then, rather than continuing
[18:50] <cjwatson> continuing doesn't tell us anything new
[18:50] <cjwatson> and it makes the logs bigger and noisier :)
[18:51] <charlie-tca> Trying to scp now
[18:54] <charlie-tca> attaching to the bug
[18:55] <charlie-tca> bug 340188
[18:55]  * cjwatson adds a section on partition table problems to Installer/FAQ
[18:55] <charlie-tca> last three attachments
[18:55] <cjwatson> thanks
[18:57] <charlie-tca> Sorry it takes so long.
[18:58] <cjwatson> charlie-tca: can you confirm exactly when you restarted udev?
[18:59] <charlie-tca> Partition disk screen came up, kill udevd, then select guided partitions
[18:59] <charlie-tca> It is the very first partition screen
[19:00] <cjwatson> ok
[19:00]  * cjwatson tries to figure out why there's only one 'remove' event showing up
[19:10] <cjwatson> oh, of course it wouldn't if the remove *failed*
[19:11] <charlie-tca> Did I screw up again?
[19:11] <cjwatson> not to my knowledge ;-)
[19:12] <charlie-tca> I keep trying to get it right.
[19:20] <cjwatson> I have a theory
[19:21] <cjwatson> (it could be bunnies)
[19:21]  * cjwatson moves to #ubuntu-devel for a wider audience
[19:24] <_MMA_> cjwatson: Any luck on the GTK installer front? Has directfb been fixed up?
[19:25] <cjwatson> not to my knowledge. Somebody was working on it in Debian
[19:25] <cjwatson> it is not a priority for me this cycle
[19:26] <_MMA_> cjwatson: Ok. I'll hope for next cycle. :)
[21:40] <CIA-3> debian-installer: cjwatson * r1059 ubuntu/ (5 files in 2 dirs): Move mainline architectures to 2.6.28-9 kernels.
[21:46] <btm> What generates the initial /target/etc/passwd before user-setup runs?
[21:47] <cjwatson> base-passwd
[21:50] <CIA-3> debian-installer: cjwatson * r1060 ubuntu/ (5 files in 2 dirs): Move ports architectures to 2.6.28-4 kernels.
[21:52] <CIA-3> debian-installer: cjwatson * r1061 ubuntu/debian/changelog: releasing version 20081029ubuntu24
[23:55] <btm> is there a way to pass a udeb into a network install without putting it in the repository (it's mirrored)?
[23:56] <cjwatson> btm: you can fetch it at run-time and install it with udpkg -i, e.g. from a preseed/early_command hook
[23:57] <cjwatson> that might be a viable approach