[03:41] <CIA-34> ubiquity: superm1 * r4271 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): merge my maverick-post-beta-fixes branch
[05:57] <NCommander> bah, no evand :-/
[05:58] <NCommander> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/628582 - do you know who would be able to hack on ubi-partman the best? I think its evand2, but I'm not 100% sure.
[05:58] <ubot2> Launchpad bug 628582 in ubiquity (Ubuntu) "ubiquity attempts to use x86-specific methods on port architectures. (affects: 1) (heat: 10)" [High,Confirmed]
[06:10] <StevenK> NCommander: ev is here?
[06:24] <NCommander> StevenK: he shouldn't be?
[06:27] <StevenK> NCommander: Well, as in he's actually connected, I mean.
[06:28] <NCommander> StevenK: I have no idea :-/. The only thing I know he's not here
[07:09] <ev> you rang?
[07:09]  * ev looks into the bug
[07:14] <ev> NCommander: working on a fix now.
[07:38] <NCommander> ev: thanks
[07:40] <NCommander> ev: when you have a usable patch, I'll test it
[07:40] <ev> thanks!
[07:49] <CIA-34> ubiquity: evand * r4272 trunk/debian/changelog: Fix changelog.
[07:50] <ev> I tagged 4270 as 2.3.15
[07:50] <ev> my bad for not debcommit -r'ing
[07:52] <NCommander> ev: when did ubi-partman get rewritten? I don't remember it being so grub happy (so to speak)
[07:52] <ev> NCommander: the grub stuff wasn't added that long ago.  We needed some place to put setting the grub options after I got rid of the summary page.
[07:54] <NCommander> ev: ah. We haven't been using ubiquity on ARM until last week pretty mcuh which is why this sailed under the radar
[07:54] <NCommander> kinda suprising it didn't get caught by a powerpc tester (though I think they have grub2 now)
[07:58] <ev> indeed, yet another reason for me to lean on IS to give me space in the Millbank datacenter for my installer testing stuff.
[08:13] <ev> NCommander: give this a try - http://paste.ubuntu.com/487667/
[08:28] <NCommander> ev: well, considering our DC doesn't (or didn't) have anything we support w.r.t. to installation for a long time, access to the porting box might be of questionable use :-)
[08:30] <NCommander> ev: I can't do a full install ATM since I can't afford to wipe out my development environment, but hopefully I can at least make sure the manual partitioner starts
[08:30] <NCommander> ev: also, any idea why the ubiquity icon no longer shows up in UNE? :-0?
[08:30] <NCommander> *:-)?
[08:31] <ev> not sure
[08:31] <ev> someone touched casper in a bad way?
[08:38] <NCommander> ev: hrm. do we still pop up the installer at boot, which gives the option then to boot into the live enviornment?
[08:38]  * NCommander admits it might have been awhile since I last reinstalled on x86 :-)
[08:40] <ev> we boot into a stripped down environment with the installer running in greeter mode (maybe-ubiquity kernel command line option) by default
[08:40] <ev> you can either hit "try ubuntu" from there, or press a key at boot when you see the man = keyboard icon, then manually select "try ubuntu"
[08:42] <NCommander> ev: right, ok, I think somewhere along the line we forgot to implement this on ARM :-)
[08:42] <NCommander> ev: sounds like I need to take a cluebat to the kernel command line on d-cd
[08:43] <ev> oh, I spot a bug in this
[08:43] <ev> heh
[08:44] <ev> NCommander: updated - http://paste.ubuntu.com/487680/
[08:47] <NCommander> ev: bah, I already built the last patch
[08:47] <ev> sorry about that
[08:47] <NCommander> -p0 -R is handy though
[08:48] <ev> you can always just manually patch it once in the live environment, assuming you have network
[08:49] <NCommander> ev: you assume much :-/
[08:54]  * NCommander feels like ubiquity's build time has gotten longer than it used to be
[08:57] <ev> haha
[08:57] <ev> and yeah, that's mostly due to the keyboard page
[08:57] <ev> it needs to generate a decision tree for the keyboard guessing stuff
[08:57] <ev> and a few other additions, I'm sure
[08:59] <NCommander> ev: hr, how long until ubiquity becomes self-aware
[09:00] <ev> hahaha, don't worry, it uses GTK. It may become self-aware, but it can never be particularly smart.
[09:04] <NCommander> ev: but doesn't it also have a Qt GUI for KDE? It seems to me it has hybird viality, and thus might combine the traits frm both parents
[09:04] <ev> good point
[09:04] <ev> we're all screwed
[09:06] <NCommander> ev: hrm, maybe we can just add a Win32 backend, and hope the GTK and QT strains self-destruct.
[09:07] <ev> lol
[09:08]  * NCommander is vaguely reminded of the Andromeda Strain for some reason ...
[09:13] <NCommander> ev, ok built
[09:15] <ev> cool
[09:23] <NCommander> ev: bah, my image must be stale or something cause it can't resolve depends
[09:24] <NCommander> ev: *grumble*, I think this might be a case of merge blindly cause I can't test until Monday, but GrueMaster can
[09:29] <ev> okay
[09:30] <ev> well I've tested it in both the gtk and kde frontends, monkeypatching archdetect to return something non-x86 and it seems to work fine
[09:30] <ev> committing, but do give it a go when you can
[09:30] <rnewson> I'm having a problem with the display during a PXE boot of ubuntu server 10.04. Specifically, the screen is scrambled (I'm viewing it over HP's execrable iLo). the usual trick of fb=false works for a Debian 5.0 PXE boot, but not ubuntu. The menu portion is fine, but when it switches over to the first install question, it's unreadable. Is this the right channel for my question?
[09:57] <CIA-34> ubiquity: evand * r4273 trunk/ (4 files in 4 dirs):
[09:57] <CIA-34> ubiquity: Do not generate or show the bootloader options if we're on x86, or
[09:57] <CIA-34> ubiquity: bootloader installation is explicitly disabled (LP: #628582).
[10:41] <CIA-34> grub-installer: cjwatson * r860 ubuntu/ (debian/changelog grub-installer):
[10:41] <CIA-34> grub-installer: Don't ask for a boot device on EFI, and don't pass a boot device
[10:41] <CIA-34> grub-installer: argument to grub-install.
[10:49] <CIA-34> grub-installer: cjwatson * r861 ubuntu/ (10 files in 3 dirs): merge from Debian 1.55
[10:53] <CIA-34> grub-installer: cjwatson * r862 ubuntu/debian/po/te.po: debconf-updatepo
[10:59] <CIA-34> grub-installer: cjwatson * r863 ubuntu/debian/changelog: releasing version 1.55ubuntu1
[11:14] <CIA-34> ubiquity: cjwatson * r4274 ubiquity/ (18 files in 7 dirs): Remove a number of unused or duplicate imports.
[13:29] <CIA-34> partman-efi: cjwatson * r652 ubuntu/ (34 files in 3 dirs): merge from Debian 21
[13:42] <CIA-34> partman-efi: cjwatson * r653 ubuntu/ (fstab.d fstab.d/efi debian/changelog debian/install):
[13:42] <CIA-34> partman-efi: Automatically mount the first method=efi filesystem we see on /boot/efi.
[13:42] <CIA-34> partman-efi: (This replaces previous code in partman-basicfilesystems, which didn't
[13:42] <CIA-34> partman-efi: work since method=efi partitions don't have an acting_filesystem.)
[13:43] <CIA-34> partman-basicfilesystems: cjwatson * r589 ubuntu/ (debian/changelog fstab.d/basic):
[13:43] <CIA-34> partman-basicfilesystems: Revert changes in 63ubuntu6, since method=efi filesystems don't have an
[13:43] <CIA-34> partman-basicfilesystems: acting_filesystem. Responsibility for mounting /boot/efi now lies with
[13:43] <CIA-34> partman-basicfilesystems: partman-efi.
[13:45] <CIA-34> partman-efi: cjwatson * r654 ubuntu/debian/changelog: releasing version 21ubuntu1
[13:46] <CIA-34> partman-basicfilesystems: cjwatson * r590 ubuntu/debian/changelog: releasing version 63ubuntu7
=== bladernr__ is now known as bladernr_
[15:14] <tjaalton> cjwatson: there's a new kernel in lucid-proposed, and I'd like to see if it makes installations on ext4 faster. so it needs a rebuild of d-i for proposed?
[15:15] <cjwatson> yes, it would
[15:15] <cjwatson> give me a minute
[15:15] <tjaalton> no rush :)
[15:15] <tjaalton> next week is fine
[15:16] <tjaalton> i'm not sure if the kernel is accepted yet
[15:16] <cjwatson> 2.6.32-25.43?
[15:17] <tjaalton> yep
[15:17] <tjaalton> with the current one it takes roughly double the time to install, compared to ext3
[15:17] <CIA-34> debian-installer: cjwatson * r1304 lucid-proposed/ (8 files in 2 dirs): Move to 2.6.32-25 kernels.
[15:18] <tjaalton> wow
[15:18] <CIA-34> debian-installer: cjwatson * r1305 lucid-proposed/ (build/config/armel/dove.cfg debian/changelog): Move Dove images to 2.6.32-209 kernels.
[15:19] <CIA-34> debian-installer: cjwatson * r1306 lucid-proposed/debian/changelog: releasing version 20081029ubuntu102.4
[15:20] <tjaalton> great, thanks.. I'll test it first thing on monday
[16:27] <ScottK> cjwatson and ev: When there are ubiquit-kde changes that you'd like someone else to test, just let me know.  I've planned on using my netbook as a sacrifial lamb until release.
[16:27] <ev> lol, okay
[16:27] <ev> I've been doing the same, but always good to get another set of eyes on these things
[16:28] <ev> I'm working on the missing resize option and poor text now, by the way
[16:28] <ev> I don't think I'll have it done by end of day though
[16:29] <cjwatson> ev: is there a way to force usb-creator to treat a hard disk as a target USB stick?
[16:29] <cjwatson> for the purposes of installing within KVM
[16:32] <ev> cjwatson: it relies on udisks to make the determination of whether or not something is removable ('device-is-system-internal').  There's no command line option in usb-creator currently to override that check, but patches welcome.
[16:33] <ev> cjwatson: it's checked in bin/usb-creator-helper and usbcreator/backends/udisks/backend.py
[16:33] <cjwatson> system-internal.  thank you.  that was the keyword I was missing
[16:33] <cjwatson> I can just obliterate that check locally
[16:33] <superm1> so i'm considering moving the dell recovery and installation disks to GRUB for boot early, without a graphical menu to simplify the necessity for all sorts of other tools conffiles that explain how to boot when coming from a different scenario (linld, isolinux, syslinux).  cjwatson and ev could you let me know if https://code.launchpad.net/~superm1/usb-creator/grub-support/+merge/34504 looks sane for 10.10?
[16:33] <cjwatson> I replied to that merge
[16:34] <cjwatson> ... I swear I did
[16:34] <ev> cjwatson: feel free to commit directly to trunk, by the way.  I'd like to create the illusion of a team project here as much as possible ;)
[16:35] <cjwatson> superm1: I'll bounce you the mail I sent, since codehosting seems to be sitting on it.
[16:35] <superm1> okay works for me
[16:38] <ev> cjwatson: by the way, do you have any preferred approach to the 'teaching jockey about passthrough' problem?  I was thinking adding a -o option to make it pretend to be an apt frontend by accepting apt options, then passing them along.  It could then presumably be run under debconf-apt-progress.
[16:38] <cjwatson> could it just notice that it's running under a debconf frontend already
[16:38] <cjwatson> ?
[16:39] <cjwatson> oh, yeah, maybe debconf-apt-progress would be neater
[16:41] <ev> notice its running under a debconf frontend> I'm not sure how much flexibility we have there, as it uses python-apt to do the heavy lifting.
[16:41] <ev> but forgive me if I'm missing the obvious
[16:44] <cjwatson> ah
[16:48] <ara> one question, guys, it is just a simple, non-relevant, non-urgent... just  a simple question
[16:48] <ev> sure
[16:48] <ara> is there any reason why the installer logs are only root-readable after the installation?
[16:48] <ev> heh
[16:49] <ev> http://www.ubuntu.com/usn/usn-262-1
[16:50] <ara> wow, that's a good reason :D
[16:50] <ara> thanks!
[16:50] <ev> sure thing
[16:50] <ev> mind you, that's only /var/log/installer/debug
[16:52] <ev> oh, perhaps not
[16:52] <cjwatson> the original vulnerability leaked it to a saved copy of cdebconf/questions.dat
[16:53] <cjwatson> and now we err on the safe side because we never ever ever want to have to deal with that again :)
[16:54] <CIA-34> ubiquity: evand * r4275 trunk/ (debian/changelog ubiquity/plugins/ubi-timezone.py): Add correct URL for the Geonames service.
[16:58] <cjwatson> ev: also, why are you not allowed to make a USB stick from a real CD?
[16:58] <cjwatson> as in stype == SOURCE_CD
[17:00] <ev> you should be able to
[17:00] <ev> if it's not appearing it's a bug (most likely due to the fact that I don't have a working computer with a built-in CD-ROM)
[17:03] <cjwatson>         if status == CAN_USE and stype in (SOURCE_IMG, SOURCE_ISO):
[17:03]  * cjwatson adds SOURCE_CD to that tuple
[17:03] <ev> thanks
[17:04] <cjwatson> though can stype have any values other than those three?
[17:04] <cjwatson> i.e. should the and clause just be deleted?
[17:05] <ScottK> ev: Once you've renamed "Guided" in ubiquity-kde (or once you know what you are going to call it), please let me know so I can work on getting a test case for it with QA.
[17:05] <ev> sure thing
[17:06] <ScottK> Thanks.
[17:06] <ev> cjwatson: indeed, not sure why that was done
[17:07] <cjwatson> I'll drop it then
[17:07] <ev> much appreciated
[17:09] <cjwatson> oddly, I don't see any bugs about this
[17:11] <CIA-34> usb-creator: cjwatson * r319 trunk/ (debian/changelog usbcreator/frontends/gtk/frontend.py):
[17:11] <CIA-34> usb-creator: GTK frontend: don't grey out "Make Startup Disk" when the source is a
[17:11] <CIA-34> usb-creator: physical CD.
[17:14] <cjwatson> ev: built-in CD> I was actually using 'kvm -monitor stdio -m 512 -hda oem-usb-20100903.img -cdrom maverick-desktop-i386.iso -boot d'
[17:14] <cjwatson> then 'kvm -monitor stdio -m 512 -hda oem-usb-20100903.img -hdb oem-20100903.img -boot c' to boot using it
[17:15] <ev> ah cool, I'll give that a shot
[17:15] <cjwatson> first time I've tried this approach, but it seems to be working
[17:15] <ev> thanks for the tip
[17:15] <ev> I take it that's why you wanted to write to regular disks
[17:15] <cjwatson> and indeed you can then 'kvm-img snapshot -c created oem-usb-20100903.img' and revert to that snapshot at any time
[17:15] <cjwatson> right
[17:16] <cjwatson> I think you *can* use -usb -usbdevice disk:oem-usb-20100903.img or some such
[17:16] <cjwatson> but I seem to remember having problems with that last time I tried; maybe it was just that you can't boot from it that way
[17:24] <ev> oo, that would be fantastic if it works
[17:25] <ev> historically, kvm's usb support has not met my expectations though
[17:25] <cjwatson> this disk-to-disk support seems fine
[17:26] <cjwatson> what the heck is this "Message: useQuirks" stuff coming from?
[17:27] <cjwatson> seems to be libwebkit?
[17:27] <superm1> libwebkit I think
[17:28] <cjwatson> and a Debian patch at that ...
[17:29] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592670
[17:29] <ubot2> Debian bug 592670 in libwebkit-1.0-2 "libwebkit-1.0-2: useQuirks message spamming" [Normal,Open]
[17:30] <cjwatson> I think I'll cherry-pick that
[17:31] <cjwatson> reproduced the oem bug this way, at least!
=== bladernr_ is now known as fader__
=== fader__ is now known as bladernr_
[17:53] <cjwatson> webkit uploaded to kill the useQuirks junk
[18:01] <ev> hooray
[22:14] <CIA-34> usb-creator: superm1 * r321 grub-support/debian/ (changelog control): Add a dependency on one of the grubs to be able to use grub-setup.
[22:15] <CIA-34> usb-creator: superm1 * r320 grub-support/ (bin/usb-creator-helper usbcreator/install.py): don't use any components from grub on the current system; assume that boot.img and core.img are in the target image and just use grub-setup to lodge them on the drive
[22:19] <cjwatson> superm1: please don't use grub-setup, use dd
[22:19] <cjwatson> it does make a difference
[22:19] <cjwatson> grub-setup fills in data at certain offsets in the core image, and those offsets are subject to change
[22:20] <superm1> Oh
[22:20] <cjwatson> the defaults for the data at those offsets should be good enough for your purposes though and you shouldn't need to do that
[22:21] <cjwatson> as long as you put boot.img at sector 0 and core.img at sector 1
[22:22] <cjwatson> and as long as the core.img is built to search for the stick rather than needing a hardcoded prefix
[22:22] <cjwatson> (which wouldn't work in this case anyway)
[22:23] <superm1> well just the first 446 of boot.img though, to avoid nuking the partition table
[22:23] <cjwatson> right
[22:24] <cjwatson> maybe in the future we should have grub-setup options that guarantee not to modify core.img
[22:24] <cjwatson> but you won't be able to rely on that for a while anyway
[22:25] <superm1> I didn't look that much at grub-setup source, here I thought it didn't touch it
[22:30] <cjwatson> there are three things it changes at the moment: the blocklist at the end of the first sector of core.img, pointing to the rest of it; sometimes information on the partition numbers corresponding to the prefix; and the prefix
[22:30] <cjwatson> the reason I mention this in particular is that a change just went in upstream to move the prefix into the compressed region, so that much is basically guaranteed to change between maverick and natty
[22:30] <superm1> ah
[22:45] <CIA-34> usb-creator: superm1 * r322 grub-support/ (bin/usb-creator-helper debian/changelog debian/control): use dd rather than grub-setup