[03:17] <jclark5093> I have a question about ubuntu vs debian - anyone with knowledge here?
[03:19] <persia> Better to just ask: if someone knows, you may get an answer.  Some folk may take 12-24 hours to get back to a question.
[09:30] <ev> okay, there appear to be two KDE bugs here.  The first is that the prepare page is trying to talk to upower over dbus, which doesn't exist on the KDE CDs.  The second is that adding a signal receiver is triggering a  segfault.
[10:25] <CIA-71> debian-installer: cjwatson * r1353 ubuntu/debian/changelog: releasing version 20100211ubuntu22
[10:32] <NCommander> cjwatson: do you want me to do test builds on armel for d-i for Beta since we now have alternates up and running (and failing on omap)? I saw the last d-i upload is FTBS :-/
[10:44] <cjwatson> that type of build failure in d-i is trivial, it's just kernel versions out of sync
[10:44] <cjwatson> I think I just never got round to retrying it once the armel kernel got round to building.  in general I don't necessarily wait for all architectures to become available before uploading d-i
[10:45] <cjwatson> I do test-builds on kakadu when I'm making non-trivial changes to armel things
[10:47] <CIA-71> ubiquity: evand * r4235 trunk/ubiquity/plugins/ubi-language.py: Remove superfluous glib import in KDE code.
[11:05] <ogra> NCommander, you are aware that alternates wont produce a proper install ?
[11:05] <ogra> on omap3
[11:07] <persia> On omap3, or on beagle?
[11:07] <ogra> on omap3
[11:07] <ogra> and indeed on beagle too
[11:07] <persia> Oh, I thought it was just beagle.  My bad.
[11:07] <ogra> we have no way to handle bootloaders in alternates sinc ethat would require some hardcoded partitioning stuff
[11:08] <ogra> either do preinstalled or dont do images for omap
[11:09] <ogra> (or invent a hardcoded partitonning scheme the user cant break during install)
[11:09] <persia> Well, stop making them if you think they cannot be useful.
[11:10] <ogra> they can but someone needs to work out a way for the bootloaders :) we're fully focused on preinstalled
[11:13] <persia> I doubt it will happen in time for maverick.
[11:13] <ogra> likely
[11:13] <persia> Could they conceivably be used by advanced users for hacking on their own projects?
[11:13] <ogra> they would end up without bootloader installation
[11:13] <ogra> i.e. *very* advanced users could do it
[11:14] <persia> Dunno then.
[11:15] <ogra> you need to stick to a certain partitioning scheme and need to set up and install flash-kernel manually
[11:19] <CIA-71> ubiquity: evand * r4236 trunk/ (4 files in 3 dirs):
[11:19] <CIA-71> ubiquity: Do not set up the Qt DBus main loop twice. This was crashing on the
[11:19] <CIA-71> ubiquity: prepare page.
[11:21] <cjwatson> you could write a /lib/partman/check.d script that fails if the partition is not as mandated, and tells the user what they need to do
[11:21] <cjwatson> i.e. the facilities to do what you want already exist
[11:22] <persia> Right.  The blocker is more that we haven't figured out what to mandate.
[11:41] <ogra> grrr
[11:41] <ogra> oem-config fails on armel
[11:42] <ogra> and worse, i dont get a shell now but get gdm
[11:44] <ogra> hitting shutdown in gdm i see the rootshell with the usual note that i need to set up a user manually
[11:44] <ogra> and a trace from ubiquity-dm
[11:47] <ev> ogra: can't you switch to a VT to get the logs?
[11:47] <ogra> will try (i just shot down, booting takes a bit on arm)
[11:50] <ev> sure thing, thanks
[11:54] <ogra> grmpf ... this boot it works
[11:58] <ev> fun
[11:58] <ogra> the slideshow being to big for the new window size is a known issue i guess ?
[11:59] <ogra> i have scrollbars around it even though the screen size is 1920x1200
[11:59] <ogra> i.e. the window has a fixed size, the slideshow is bigger
[12:00] <ogra> hmm, now it hangs after "getting time from a network server"
[12:00]  * ogra clicks on the expander arrow
[12:01] <ogra> "can not open /ver/log/installer/debug for reading, no such file or directory"
[12:01] <ogra> hmm, indeed, this is a preinstalled image
[12:01] <ogra> oh, it was just slow, it moves \o/
[12:02] <CIA-71> ubiquity: evand * r4237 trunk/ (3 files in 2 dirs):
[12:02] <CIA-71> ubiquity: Stop Qt callbacks on the prepare and language pages once we have a
[12:02] <CIA-71> ubiquity: result, matching the GTK behavior.
[12:22] <ev> can someone remind me of the common case for not installing grub with Ubuntu?
[12:23] <ogra> lilo users ?
[12:23] <ogra> do we still support them ?
[12:23] <cjwatson> yes, it's in main
[12:23] <cjwatson> or non-x86 architectures
[12:23] <ogra> right
[12:23] <cjwatson> do you mean not installing grub at all, though?
[12:23] <ev> correct
[12:23] <cjwatson> it's not a common case, it's a VOCAL case
[12:23] <ev> unchecking the box
[12:24] <cjwatson> for people who have seriously custom bootloader arrangements and don't want them broken
[12:25]  * cjwatson looks through bzr blame to check
[12:26] <michaelforrest> ev: my suggestion re: bootloader is make it a command line switch and add a row to the gfxboot screen with 'install without bootloader'
[12:26] <ev> cjwatson: ^ that sounds entirely reasonable to me, what do you think?
[12:26] <cjwatson> let me complete looking through bzr blame first
[12:26] <ev> it wouldn't handle picking a specific device to install it to, but is that even that necessary anymore, given that we've largely solved the USB disk issue?
[12:26] <ev> sure thing
[12:27] <cjwatson> picking a specific device to install to is actually more necessary
[12:27] <cjwatson> some people have custom bootloaders in the MBR that they don't want disturbed, and instead want to install grub to a partition
[12:27] <michaelforrest> so let's include that dropdown in the partitioning page
[12:27] <michaelforrest> 'bootloader will be installed to: [dropdown]' inline
[12:28] <cjwatson> failing to include that option has got us bad news publicity in the past
[12:28] <ev> okay, works for me, and understood
[12:28] <cjwatson> (we didn't let you select that in 6.06 LTS)
[12:29] <cjwatson> the bootloader checkbox was added in response to bug 130445
[12:29] <ubot2> Launchpad bug 130445 in ubiquity (Ubuntu) (and 1 other project) "grub failure with gpt formatted disk (heat: 3)" [Undecided,Fix released] https://launchpad.net/bugs/130445
[12:29] <cjwatson> I think that might be adequately handled by the bootloader installation failure dialog?
[12:29] <michaelforrest> ev: if we could get the more descriptive device description in that dropdown (instead of just '(hd0)')
[12:29] <ev> michaelforrest: we already have them, that screenshot is a bit old
[12:29] <cjwatson> though a command line option would be useful too
[12:30] <cjwatson> I don't think it needs to be exposed in gfxboot since the use case in 130445 is actually fairly limited
[12:30] <ev> awesome
[12:30] <ev> so you're happy making it a command line switch?
[12:30] <cjwatson> it's the install-to-partition crowd who are moderately numerous and extremely vocal, thinking about it
[12:30] <ev> and not present in the UI
[12:30] <cjwatson> yeah, given that the bootloader-install-failed dialog lets you continue without a boot loader
[12:31] <ev> right-o
[12:31] <ev> I'll make that change and file a freeze exception
[12:31] <ev> thanks guys
[12:31]  * persia has found that behaviour frustrating a couple times, ending up with an unbootable device post-install
[12:31] <cjwatson> BTW (noting your comment that the screenshot is old), any case where we show (hd0) nowadays is basically a bug
[12:31] <cjwatson> independent of design concerns
[12:31] <ev> michaelforrest: thoughts on where to put the rest of the dialog? (proxy options, popularity contest)
[12:32] <cjwatson> when we need to show device names, they should be OS-style device names, e.g. /dev/sda
[12:32] <ev> cjwatson: indeed, grub is sane now
[12:38] <cjwatson> NCommander: re armel: should I switch d-i over to the linaro mx51 build?
[12:38] <ogra> cjwatson, rather a linaro question
[12:39] <ogra> i think their way of image building is very different from ubuntus (tarballs etc)
[12:39] <cjwatson> ogra: it's relevant for Ubuntu because the imx51 flavour in linux has vanished.
[12:39] <cjwatson> linux-linaro delivers udebs
[12:39] <ogra> hmm
[12:40] <ogra> if linaro wants it ubuntu-arm wont stand in the way, we dont need it though
[12:41] <persia> Point of Order: linaro is a participant in Ubuntu.
[12:41] <ogra> and afaik their imx51 support is only what upstream has, very sparse
[12:41] <cjwatson> ogra: you aren't listening
[12:41] <cjwatson> my point was that there are no imx51 udebs in the archive from the main linux package right now
[12:41] <persia> cjwatson, If we want imx51 support, the linaro imx51 build is the only source of udebs.
[12:41] <cjwatson> the correct answer would have been "no, cjwatson, you idiot, they're just still building"
[12:42] <cjwatson> (and somebody NBSed out the old ones)
[12:42] <ogra> NBSing them was on purpose
[12:42] <ogra> simply because they were several versions behind on security updates
[12:43] <persia> But they had an rdep on d-i
[12:43] <cjwatson> anyone who NBSes kernels without checking d-i's status is not doing it properly
[12:44]  * ogra didnt NBS them but acked that we dont need them in ubuntu when he was asked about the existing packages
[12:45] <cjwatson> ok, so the linux-fsl-imx51 package is gone permanently?
[12:45] <ogra> yes
[12:45] <cjwatson> see, that's not a linaro question. :)
[12:45] <cjwatson> do we want to build d-i for imx51 in maverick?
[12:45] <ogra> no, but the new imx51 binaries are :)
[12:45] <cjwatson> again not a linaro question
[12:45] <persia> Rather, there was nobody currently interested in maintaining it.  This may not be truly permanent.
[12:46] <ogra> it is a linaro question since they a) maintain the kernel that would be used and b) would be the only user of it
[12:46] <cjwatson> does the ubuntu-arm team want to build d-i for imx51 in maverick?
[12:46] <ogra> no
[12:46]  * persia disagrees with b) based on various folks trying to get newer software on netwalkers
[12:47] <ev> actually, I can make the proxy option a command line parameter as well, and the popcon stuff you wanted to fold into that eventual "let me help make Ubuntu better by providing usage data" option.
[12:48] <cjwatson> ogra,persia: I'm finding the twenty-questions game kind of frustrating.  I've gone and asked #linaro in the hope that I can get a straight answer there.  If you want me to do things in d-i's build for ubuntu-arm, then I need straight answers
[12:49] <cjwatson> otherwise, those who give me straight answers are going to win. :)
[12:50] <persia> cjwatson, The only folks currently actively maintaining support for imx51 within Ubuntu are those maintaining the linaro imx51 build.
[12:50] <cjwatson> thank you, that is a straight answer
[12:50] <persia> Neither ogra nor I know of anyone who is actively testing i.mx51 images, but we suspect that the maintainers of the linaro imx51 build likely would know of such folk.
[12:51] <persia> There exist a number of interested parties external to Ubuntu who would like to see i.mx51 support, based on various trees, but I don't believe you can help them until they generate udebs you can use.
[12:52] <cjwatson> ok.  I'll nuke it.
[12:52] <persia> Note that none of the above is intended as an abrogation of support terms for any previously released images.
[12:53] <cjwatson> of course
[12:55] <cjwatson> ogra,persia: thanks for the answers.  ogra's answers above make more sense in retrospect given the later clarifications.  I apologise for being snappy
[12:56] <ogra> cjwatson, well, i could have expressed myself better
[12:56] <ogra> or could have taken the task to just ask linaro
[12:56] <cjwatson> well, no harm done, I'll try this test-build against linaro-mx51
[12:56] <cjwatson> if it just works then might as well use it
[12:57] <ogra> yep
[12:57] <persia> cjwatson, apologies for the confusion.  There's a bit of contention between Canonical's "Ubuntu ARM" team, Linaro's "Integration" team, and random folk who care about armel in terms of who "represents" Ubuntu's plans for ARM.  Please be patient as we develop an identity.
[14:04] <CIA-71> debian-installer: cjwatson * r1354 ubuntu/ (build/config/armel.cfg debian/changelog):
[14:04] <CIA-71> debian-installer: Disable imx51 armel flavour for now; linux-fsl-imx51 is no longer in the
[14:04] <CIA-71> debian-installer: archive, and linux-linaro's i.MX51 support is still quite minimal
[14:04] <CIA-71> debian-installer: according to Oliver Grawert and Loïc Minier.
[14:08] <ev> cjwatson: any objection to me moving the grub comboboxentry back to a regular combobox?  I'm concerned that if we're going to make this visible by default, showing a linux device file in the field, rather than the friendlier description used in the drop down, is a bit scary.
[14:08] <ev> Given that we don't support (hdX,X) anymore, I can't see what use case would require manual entry.
[14:14] <cjwatson> yes, that sounds probably ok
[14:14] <ev> okay, cool, thanks
[14:15] <CIA-71> debian-installer: cjwatson * r1355 ubuntu/debian/changelog: releasing version 20100211ubuntu23
[14:17] <davmor2> ev, cjwatson:  I'm going to try a wubi install in a bit if the images were okay this morning
[14:21] <ev> kde is broken, but ubuntu should be working
[14:25] <ev> gah, this is going to require considerable more thought.  Partitioning could completely invalidate the list of devices used for the grub drop down.
[14:26] <ev> I'll have to move it to both the automatic and advanced pages, and update it based on the choices made on those pages.  Ugh.
[14:30] <ev> are we sure we can't just relegate this to a command line option? ;)
[14:33] <cjwatson> devices?  I really don't think so
[14:33] <cjwatson> we'd be excoriated
[14:34]  * cjwatson went through this once already and has little desire to do it again
[14:39] <ev> fair enough, I'll get started on this.  I have a call at 4, so it will probably be a weekend thing.
[14:40] <ev> michaelforrest: I never got that generic operating system icon from Otto.  I don't suppose you have a local copy?
[14:40] <ev> get started> re-jig
[14:45] <michaelforrest> ev: I'll have to jump into photoshop
[14:47] <davmor2> ev, cjwatson:  Wubi still drops straight into grub shell on first reboot :(
[14:48] <cjwatson> I can't do anything about it right now, no current Windows system
[14:56] <ev> michaelforrest: thanks
[14:57] <ev> davmor2: if you can convince grub to print debugging information, that would be a helpful start, but I'm afraid I have 0 free time to look at this at the moment
[15:04] <davmor2> ev: unfortunately not it drops straight into grub shell from selecting Ubuntu and there is no useful info.  I've "set debug=all" on the top line of grub in /ubuntu/install/boot/grub/grub.cfg no difference I'm open to offers on advice though.
[15:41] <kirkland> what's the magic kernel parameter to tell the installer that i have a preseed file on a boot floppy?
[15:42] <kirkland> does url=file:///path/to/preseed ?
[15:43] <kirkland> cjwatson: ev: ^
[15:45] <ev> kirkland: file=/path/to/preseed
[15:45] <kirkland> ev: cool
[15:45] <kirkland> ev: thanks
[15:46] <ev> remember that if this is the alternate/server CD and you want to preseed the language and keyboard questions, you'll need to put the preseed file in the initrd.
[15:46] <ev> https://help.ubuntu.com/10.04/installation-guide/i386/preseed-using.html#preseed-loading
[15:46] <kirkland> ev: got it...  using: http://paste.ubuntu.com/484511/
[15:47] <kirkland> ev: I'm working with the kvm-autotest upstream community, to help them automate the testing of Ubuntu guests in KVM
[15:47] <ev> neat!
[15:47] <kirkland> ev: one more question ... is there a magic location, where if you put a preseed, it will magically be picked up?
[15:47] <kirkland> ev: without adding the url=... param?
[15:47] <ev>  /preseed.cfg in the root of the initrd
[15:48] <kirkland> ev: hmm, okay, let me get this straight ....
[15:48] <kirkland> ev: i want to boot a stock Ubuntu ISO with kvm -cdrom ...
[15:49] <kirkland> ev: and then i want to give another parameter to KVM, -hda, or something
[15:49] <kirkland> ev: that has a preseed
[15:49] <kirkland> ev: i'd like the ubuntu installer to just "find" this preseed in some magic location, and do its install automatically
[15:50] <kirkland> ev: to get it into the initrd, i would need to modify the iso, no?
[15:50] <ev> correct
[15:50] <kirkland> ev: okay, any way of avoiding rebuilding the iso?
[15:52] <ev> not that I can think of.  Perhaps through some magic with kvm's -kernel and -initrd options?
[15:59] <cjwatson> ev: are you still planning to look at bug 613008?
[15:59] <ubot2> Launchpad bug 613008 in ubiquity (Ubuntu Maverick) (and 1 other project) "failed to install oem-config from CD (affects: 1) (heat: 144)" [High,Confirmed] https://launchpad.net/bugs/613008
[15:59] <ev> ah, that fell off my radar.  Sorry.
[16:00] <ev> yes, I'll take a look at it on Monday.  I've added a note to my calendar.
[16:00] <ev> err tuesday
[16:01] <cjwatson> hm, Monday bank holiday
[16:01] <cjwatson> Tuesday may be too late for beta CDs; I wonder if I'll need to look this afternoon
[16:01] <cjwatson> I'll ask about it in the rel meeting
[16:15] <kirkland> ev: i have a bit more info, and another question
[16:16] <kirkland> ev: so let's say i do this ...  qemu-img create -f raw floppy.img 1M # create a 1M floppy image
[16:16] <kirkland> ev: mount -o loop floppy.img /mnt # mount up the floppy
[16:16] <kirkland> ev: cp preseed.cfg /mnt; umount /mnt # copy the preseed, unmount
[16:17] <kirkland> ev: and now i boot the server ISO
[16:17] <kirkland> ev: with kvm -cdrom ubunut.iso -fda floppy.img
[16:18] <kirkland> ev: doesn't look like that floppy is automounted or anything, so i can't really use url=/media/floppy/preseed.cfg
[16:18] <kirkland> ev: any ideas?
[16:22] <kirkland> ev: oh, i have another idea ....
[16:23] <cjwatson> you must only use url= with actual http or ftp urls
[16:23] <kirkland> cjwatson: ev: could we add a preseed/kvm-autotest.seed that does a completely automated, minimal install?
[16:23] <cjwatson> I'd prefer not, too many variables
[16:24] <cjwatson> I don't want to be responsible for automated disk overwrites
[16:24] <kirkland> cjwatson: okay, i'm working with the upstream kvm-autotest community
[16:25] <kirkland> cjwatson: they want an automated way of installing ubuntu, for the sake of doing automated regression testing against kvm, with ubuntu guests
[16:25] <kirkland> cjwatson: i have a preseed file that can do this, of course
[16:25] <kirkland> cjwatson: but i'm trying to marry that with their framework
[16:26] <kirkland> cjwatson: for fedora, they just add a kernel parameter, ks:floppy, which tells the redhat/fedora installer to look for a floppy, with a kickstart file of a certain name
[16:26] <kirkland> cjwatson: if found, use it
[16:26] <kirkland> cjwatson: since it's a floppy, it's easy to modify
[16:26] <kirkland> cjwatson: best i can tell, we support something similar, in the initrd, but that would mean modifying the initrd to insert my preseed, then remastering the iso
[16:26] <kirkland> cjwatson: a little heavy weight for their need
[16:27] <kirkland> cjwatson: can you advise me on a better step forward?
[16:32] <cjwatson> er, so you're comparing apples with oranges here
[16:32] <cjwatson> Fedora's allowed to add a kernel parameter
[16:32] <cjwatson> Ubuntu apparently isn't?
[16:33] <cjwatson> file=floppy://preseed.cfg should mount a floppy
[16:52] <cjwatson> ev: do today's daily desktop images work for you?  they just seem to hang at the desktop here
[16:52] <ev> cjwatson: Ubuntu works, Kubuntu is broken, though fixed in trunk
[16:52] <ev> well, mostly fixed
[16:52] <ev> I think there's an issue with Kubuntu at ubiquity-dm, which I'll tackle in a moment
[16:53] <ev> cjwatson: by hang at the desktop do you mean Ubiquity or something else?
[16:53] <cjwatson> shows ubiquity, mouse won't move
[16:53] <cjwatson> just curious whether it was happening to more than just me
[16:54] <cjwatson> same as bug 624930
[16:54] <ubot2> Launchpad bug 624930 in ubiquity (Ubuntu) "maverick desktop installer freezes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/624930
[16:58] <ev> cjwatson: can you get to a VT? magic sysrqs?
[16:58] <ev> I'm not seeing that at all
[16:58] <ev> sounds like you need a serial cable :)
[16:58] <cjwatson> VT> testing.  magic sysrq maybe hard given kvm
[16:59] <cjwatson> only thing odd was that I'm using -net none, trying without
[17:04] <ev> sendkey alt-sysrq-? should work, no?
[17:05] <cjwatson> hm, there's an invisible zenity process showing ubiquity/install_failed
[17:06] <cjwatson> and OOM errors in syslog (but 512MB RAM in this VM)
[17:07] <ev> perhaps we're doing something mental in the no-network case
[17:07] <cjwatson> happens without -net none too
[17:07] <ev> weird
[17:07] <cjwatson> kvm -monitor stdio -m 512 -cdrom maverick-desktop-i386.iso -hda oem-613008.img -boot d # oem-613008.img is a fresh 10G disk
[17:09] <ev> I'll give it a shot with 512
[17:09] <ev> I've been using 768
[17:12] <cjwatson> ubiquity is at virt 129m res 39m
[17:12] <cjwatson> however, bootchart is running
[17:12] <cjwatson> I just disabled that in the live-common seed and I think that will help
[17:12] <cjwatson> it was the top memory user, so I wonder if it just pushed the kernel into oom-killing ubiquity
[17:13] <cjwatson> trying with bootchart=disable
[17:18] <cjwatson> still really slow to draw the first page
[17:19] <cjwatson> this is just in "install Ubuntu" mode - at least I assume it's drawing, it has just "Welcome", the language list, and the action buttons up, and it's not responding when I hit Forward
[17:20] <cjwatson> it seems to be trying to talk to ibus and not getting very far?
[17:21] <cjwatson> it's sitting in localechooser at 'INPUT critical localechooser/languagelist', and the last four lines in the debug log are:
[17:21] <cjwatson> debconf (developer): <-- GET ubiquity/only-show-installable-languages
[17:21] <cjwatson> debconf (developer): --> 1 false
[17:21] <cjwatson> update_release_notes_label()
[17:21] <cjwatson> update_release_notes_label()
[17:21] <cjwatson> (yes, last line is twice)
[17:22] <cjwatson> ah, works better when I change language and then change back, maybe a focus bug
[17:23] <cjwatson> ok, so that's working
[17:25] <ev> 512 worked fine for me
[17:26] <ev> it was an am64 CD, but I don't see how that would make a difference here
[17:28] <cjwatson> hopefully the bootchart removal will basically clear it up
[17:32] <ogra> hmm, do we restart syslog after the hostname was set by ubiquity/oem-config ?
[17:32]  * ogra was just told the old name shows up in the logs all the time
[17:39] <superm1> cjwatson, what would your thoughts be on something like this to replace oem-config-remove (at least in the GTK case) http://pastebin.com/QSgyuW6H
[17:42] <cjwatson> superm1: I'm OK with it if it works
[17:43] <superm1> cjwatson, okay cool. yeah i did some brief tests with it yesterday.  probably needs a UI freeze exception or so
[17:43] <superm1> i'll wait until after beta to commit it and file the exception in  case there has to be any more ubiquity stuff committed before then
[17:44] <cjwatson> UI freeze is basically for stuff people might be taking screenshots of; seems unlikely in this case
[17:44] <superm1> Ok
[17:46] <ev> If Qt is creating files in ~ on load, I'm going to stab someone at Nokia in the face.
[17:47] <ev> err kdelibs, but my threat still stands
[19:02] <CIA-71> ubiquity: evand * r4238 trunk/ (bin/ubiquity-dm debian/changelog):
[19:02] <CIA-71> ubiquity: Drop privileges before setting the background in the Qt portion of
[19:02] <CIA-71> ubiquity: ubiquity-dm, otherwise .kde/share/config will be created as root.
[19:13] <CIA-71> ubiquity: evand * r4239 trunk/debian/changelog: Beta freeze exception (LP: #625472).