[00:12] <ev> Putting the bootloader drop down on the manual partitioning page was easy, but now that I'm trying to work it into the automatic partitioning page as well, I'm struggling to think of something clever.
[00:12] <ev> I could just show the disk block devices in that case, or I could go the educated guess approach and show just /dev/sda1 for format and /dev/sdaN+1 for resize.  I'm leaning towards the latter and as yet cannot think of a case where that breaks.  Anyone have thoughts on this, or know a case that this would break?
[00:12] <ev> cjwatson: ^ ?
[00:16] <ev> (partman autopartitioning recipes don't expose what the state of the disk would be once the recipe is applied)
[00:21] <superm1> ev, the primary case I think that breaks is multidisk, bootloader on one disk partitions on the other
[00:21] <superm1> or if they had an abundance of free space before the current partition in use for some reason
[00:26] <ev> sorry, I should be more clear.  Any case where the assumption that ubiquity will create a new partition and a block device will be created for it of the form /dev/sdXN+1.  I don't care if installing the bootloader there is silly, just that the block device exists.  I'm trying to create the list of possible targets for GRUB.
[00:26] <ev> roughly this:
[00:26] <ev> dev, partnum = re.search(r'(.*\D)(\d+)$', resize_path).groups()
[00:26] <ev> dev = '%s%d' % (dev, int(partnum) + 1)
[00:27] <superm1> so is the list going to be fully inclusive then of all possible targets?
[00:27] <ev> that's the intention
[00:27] <ev> because I'd prefer to make it not editable as it was before
[00:27] <ev> just a combobox rather than a comboboxentry
[00:28] <ev> unless people see that as a Really Bad Idea(tm), but I have concerns that having this actually on the automatic partitioning page means people will play with it, and I'm fearful that they'll put something silly in it.
[00:29] <superm1> well first thing that comes to mind with your sdXN+1 is you'll need to count out primary partitions on the disk if it's not gpt
[00:29] <ev> ah, but partman does that for us
[00:29] <ev> it wont offer resizing if there are not enough primary partitions available
[00:30] <superm1> ah, that's swell of it
[00:30] <ev> or it's not resizing an extended partition
[00:30] <superm1> personally i feel like bootloader selection really shouldn't be on the automatic page
[00:31] <superm1> as you say, it's an extra knob to play with
[00:31] <superm1> so even if you give out all the valid targets, they can still end up with a non-bootable install
[00:33] <ev> so just keep it on the advanced partitioning page, or put it somewhere else entirely?
[00:33] <superm1> well i think optimally - if you could leave it on advanced partitioning page, and fill in the advanced partitioning with the recipe that was figured out on auto partitioning
[00:34] <superm1> that gets you best of both worlds, and leaves the extra knob on advanced
[00:34] <ev> indeed, that would be ideal
[00:34] <ev> but not something I think we can manage for 10.10
[00:34] <ev> but perhaps we could leave it on the advanced page with the stated intention of fixing that UI issue
[00:35] <superm1> that sounds good to me
[00:35] <ev> I should note that michaelforrest initially wanted it on the advanced page, but I raised this concern over the disconnect between the pages
[00:35] <ev> but yeah, the more that I think about it, the more I agree
[00:35] <ev> okay
[00:35] <ev> that makes my life much easier
[00:36] <superm1> which means more time for bug fixing :)
[00:36] <ev> exactly
[00:37] <superm1> speaking of which, when you get a chance, can you look over the usb-creator patch i proposed for that whole wrong syslinux version for the content on CD?
[00:38] <ev> sure thing, I've added an item to my calendar to tomorrow for it
[00:40] <superm1> thanks, okay i'm off - have a  nice night
[00:43] <ev> you too
[10:55] <CIA-71> ubiquity: evand * r4246 trunk/ (4 files in 4 dirs): Add the grub target device combobox to the KDE advanced partitioning page as well.
[11:04] <CIA-71> ubiquity: evand * r4247 trunk/ (debian/changelog ubiquity/components/plugininstall.py):
[11:04] <CIA-71> ubiquity: Bootloader handling is now done in ubi-partman. Do not overwrite it
[11:04] <CIA-71> ubiquity: with the default selection in plugininstall.
[11:08] <CIA-71> ubiquity: evand * r4248 trunk/gui/qt/advanceddialog.ui: Remove unused QT advanced dialog.
[11:08] <CIA-71> ubiquity: evand * r4249 trunk/ubiquity/frontend/ (base.py noninteractive.py): Remove references to no longer used summary_device.
[12:00] <CIA-71> ubiquity: evand * r4250 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py):
[12:00] <CIA-71> ubiquity: Get rid of the quitting state variable and use the existing
[12:00] <CIA-71> ubiquity: current_page construct (LP: #627284).
[12:33] <Riddell> ev: do you have any idea on bug 625586 ?
[12:33] <ubot2> Launchpad bug 625586 in ubiquity (Ubuntu) "ubiquity killed by OOM killer (affects: 2) (heat: 1154)" [High,New] https://launchpad.net/bugs/625586
[12:33] <ev> yes, I suspect I fixed that with this upload
[12:34] <Riddell> ooh nice
[12:35] <ev> basically, nothing was setting a bootloader target device, so plugininstall was trying to do it, but since parted_server was no longer running, it crashed.  Because there was no crash handling for plugins running on the parallel debconffilter, it respawned -- a lot.
[12:35] <ev> at least, that's what I think was happening
[12:35] <ev> if it still persists with this new ubiquity, then it's definitely something else
[12:37] <ev> the new ubuntu slideshow (yet-to-be uploaded) looks brilliant.
[12:37] <Riddell> screenshot screenshot!
[12:37] <cjwatson> are we going to get it for beta too?
[12:39] <ev> cjwatson: I can squeeze it in, though I must warn you that the first page says "TODO" with no other text content and it's still scrolling as I haven't set the dimensions for the webkit window properly yet.
[12:39] <ev> but this is what it looks like...
[12:39] <cjwatson> if it's still rough in parts, maybe we shouldn't try?  dunno
[12:40] <ev> http://people.canonical.com/~evand/tmp/new-slideshow-10.10.png
[12:41] <ev> it seemingly looks better, but yeah, not sure
[12:41] <ev> dylan's thoughts on the matter: http://paste.ubuntu.com/486268/
[12:41] <cjwatson> I hate to be a pain but is it OK to reproduce Facebook's front page like that?
[12:42] <ev> this is mostly ripped from ubuntu.com
[12:42] <cjwatson> hm, ok
[12:42] <ev> http://www.ubuntu.com/desktop/features
[12:42] <cjwatson> Dylan may have a point, land it when they're happy
[12:42] <ev> indeed
[12:42] <ev> lets leave it for now
[12:43] <ev> Riddell: ^ not sure if you or someone else in Kubuntu wants to do something similar for the Kubuntu slideshow, but that's what we're aiming for on the Ubuntu side.
[12:45] <Riddell> ev: where can I find the source?
[12:46] <ev> Riddell: the update currently lives in lp:~dylanmccall/ubiquity-slideshow-ubuntu/maverick-ubuntu-design/ and lp:ubiquity-slideshow-ubuntu is trunk.
[12:55] <CIA-71> ubiquity: evand * r4251 trunk/debian/changelog: releasing version 2.3.10
[12:57] <ev> yay bug spam (bug 441904)
[12:57] <ubot2> Launchpad bug 441904 in ubiquity (Ubuntu) (and 1 other project) "ubiquity-dm crashed with XStartupError in run() (affects: 269) (heat: 1049)" [High,Incomplete] https://launchpad.net/bugs/441904
[15:03] <ara> cjwatson, is it normal that an alternate i386 installation LVM encrypted in a dell mini 9 is taking over 2 hours? (and it is not near from finishing)
[15:05] <cjwatson> at what stage?
[15:05] <cjwatson> doesn't sound desperately unusual though, I'd assume encryption would be slow and that if it is it isn't the installer's fault ...
[15:05] <cjwatson> suppose it could be a variant of dpkg syncing all the time
[15:10] <ara> cjwatson, installing packages (the stage)
[15:16] <cjwatson> ara: probably yet another thing due to dpkg syncing then
[15:46] <cjwatson> superm1: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/441941 indicates that "Dell Recovery Tool" and "Dell DataSafe Local Backup" write to sectors between the MBR and the first partition.  I would like to find a way to identify data they've written so that GRUB can avoid those sectors.  Do you have any way to find out if they have some kind of unique signature, for example if the first eight bytes or something ...
[15:46] <ubot2> Launchpad bug 441941 in grub2 (Debian) (and 4 other projects) "grub fails after running Windows (affects: 51) (dups: 2) (heat: 266)" [Unknown,New]
[15:46] <cjwatson> ... are always the same?
[15:51] <superm1> the thing stored there is license information, but by now there should have been an update pushed out to prevent that, i'll ping my contact about it.
[15:55] <cjwatson> I'm guessing there'll be old versions around for a while though
[15:55] <superm1> true.  i'll try to see if the license information always has a consistent signature to it as well then.
[15:57] <cjwatson> that would be lovely, thanks
[17:57] <ScottK> ev: If you need any more data for the ubiquity KDE problems let me know.  I've got a current Kubuntu live on a USB stick and a netbook I need to reinstall ready.
[18:04] <ScottK> Actually it doesn't even boot.  I get "Unknown keyword in configuration file".
[18:04] <superm1> ScottK, did you burn that to usb from 10.04 or 10.10?
[18:04] <ScottK> 10.04
[18:05] <superm1> there's an open bug for burning 10.10 images on 10.04 using usb-creator.
[18:05] <superm1> bug 608382
[18:05] <ubot2> Launchpad bug 608382 in usb-creator (Ubuntu Lucid) (and 3 other projects) "Maverick images burned to usb key on lucid fail to boot - different syslinux version (affects: 50) (dups: 6) (heat: 264)" [High,Triaged] https://launchpad.net/bugs/608382
[18:05] <superm1> i've got a proposed patch for usb-creator on 10.04 for it
[18:06] <ScottK> Sigh.
[18:06] <ScottK> That would explain it.
[18:06] <ScottK> Any "Please test 10.10 beta" messaging should warn about that I think.
[18:07] <ScottK> superm1: Is the fixed package available anywhere?
[18:07] <superm1> ScottK, i just proposed the patch yesterday
[18:07] <cjwatson> it's in the maverick technical overview FWIW
[18:08] <cjwatson> I think
[18:31] <ScottK> superm1: Do you have a version of that patch that applies to 0.2.22?
[18:31] <ScottK> Actually it looks like I just need to apply it right.
[18:31] <ScottK> Nevermind
[18:57] <CIA-71> ubiquity: evand * r4252 trunk/ (debian/changelog ubiquity/plugins/ubi-usersetup.py):
[18:57] <CIA-71> ubiquity: Fix hostname error in KDE frontend (LP: #627489). Guard against
[18:57] <CIA-71> ubiquity: invalid hostnames in the GTK frontend.
[19:00] <CIA-71> ubiquity: evand * r4253 trunk/ (debian/changelog scripts/install.py): Create a new pipe for update-apt-cache.
[19:02] <ev> Riddell: did you have the "download updates" box checked when you hit this infinite plugininstall.py issue?
[19:07] <ev> Riddell: also, did it pop up any kind of "install failed" dialog?
[19:31] <ScottK> superm1: That worked.  Thanks (I also commented in the bug).
[19:32] <ScottK> It would be nice to at least get it into lucid-proposed before Thursday.
[19:33] <CIA-71> usb-creator: evand * r318 usb-creator/ (debian/changelog usbcreator/install.py):
[19:33] <CIA-71> usb-creator: Mangle whether the 'ui' keyword is in syslinux.cfg based on the OS version.
[19:33] <CIA-71> usb-creator: (LP: #608382)
[19:33] <ev> superm1: ^ looks good
[19:45] <ScottK> Trying to do an erase disk install with the current Kubuntu live and get http://paste.ubuntu.com/486433/
[19:47] <ev> interesting
[19:47] <ev> do you have full logs from that attempt?
[19:57] <ScottK> I still have the live session up.
[19:57] <ScottK> Also, when I tried to cancel out of it, I got http://paste.ubuntu.com/486441/
[19:57] <ScottK> ev: What logs do you need?
[19:57] <ScottK> I'll need to go find wired internet to get the log files off.
[19:57] <ev> ScottK: /var/log/syslog, /var/log/partman, and /var/log/installer/debug
[19:57] <ev> thanks
[20:06] <cjwatson> superm1: as future work, I think treating version strings as floats is very shady
[20:06] <cjwatson> they should be compared with something like deb822, really
[20:06] <cjwatson> or debian_support.Version or whatever it is, I forget exactly, it's in python-debian
[20:07] <cjwatson> accepting for now though
[20:09] <ScottK> ev: Bug #627614 has the logs.  The logs also show the installer crash.
[20:09] <ubot2> Launchpad bug 627614 in ubiquity (Ubuntu) "File system busy error on full disk install (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/627614
[20:10] <ScottK> Riddell: ^^^ for when you're back.
[20:11]  * ev would really like to know what's eating up all that memory
[20:12] <superm1> sorry i was hungry :)
[20:13] <superm1> cjwatson, ah i wasn't aware of any infrastructure for doing that sort of thing
[20:14] <ScottK> ev: Anything else useful I can do for you with the current attempt?
[20:15] <ev> ScottK: if you run ubiquity again up to that point, how much memory is it using?
[20:18] <ScottK> Checking
[20:18] <ev> thanks
[20:18] <ev> something is eating up all your memory and invoking the oom killer
[20:22] <ScottK> The actual ubiquity process doesn't seem to be it.  It's using a ~steady 153/63/27m for virt/res/shr
[20:22] <ScottK> ev: ^^^
[20:23] <ev> huh
[20:23] <ev> anything else going crazy?
[20:23] <ScottK> Let me run it again while watching top
[20:23] <ScottK> I just did top |grep ubiquity this last time
[20:24] <ev> might want to see if hald is still running, if not start it and run ubiquity, as the oom killer got it before
[20:25] <ScottK> It's running
[20:26] <cjwatson> http://www.debian.org/News/2010/20100831, for those who've worked with upstream d-i folks
[20:27] <ev> whoa
[20:27] <ev> my condolences
[20:27] <cjwatson> yes, he'll be sorely missed
[20:28] <ScottK> ev: memory went down to ~0 so I can confirm it's getting eaten.  I don't see by what though.
[20:28] <ScottK> ev: Suggestions on how to see which process is eating the ram?
[20:28] <ev> ScottK: one of ubiquity's child processes?
[20:28] <ev> top; M
[20:29] <ScottK> Trying again
[20:34] <ScottK> ev: I still didn't see it.  I need to go pick up a kid from school.  I'll try some more in ~45 minutes.
[20:34] <ev> okay, thanks
[20:37] <ev> okay, I've got to go walk the dog.
[20:38] <ScottK> ev: In the mean time, is there anything that top; M wouldn't show that could eat memory and how could I check?
[20:38] <ev> Riddell: if you get back before I do.  If you're still able to reproduce that crash, and you did so using the "download updates" checkbox, can you try to do an install without it checked?  My running theory given your logs is that we're not killing the apt-get update process before we hit apt-setup.
[20:39] <ev> ScottK: not offhand
[20:39] <ev> that is, I don't know of anything offhand
[20:41] <ev> ScottK: what are you running this on? VM or real hardware?  How much memory?
[20:41] <ev> right, back in a bit
[21:11] <ScottK> ev: Real hardware 1GB RAM
[21:11] <ScottK> (Dell mini 10v)
[21:12]  * ev bangs head on desk
[21:12] <ev> cjwatson: in my haste I screwed up that ubiquity upload
[21:13] <ev> it's missing an import statement
[21:13] <ScottK> ev: "<cjwatson> dinnertime; will likely be at least an hour until more spins are usefully possible" ~45 minutes ago.
[21:13] <CIA-71> ubiquity: evand * r4254 trunk/debian/changelog: releasing version 2.3.11
[21:14] <ev> indeed
[21:14]  * ev sets to work fixing things
[21:14] <ScottK> New installer looks very nice FWIW.
[21:14] <ev> thanks!
[21:14] <ev> though thanks to Riddell (who did lots of the last minute KDE stuff) and michaelforrest (who conceived the UI) as well
[21:15] <ScottK> Any thoughts on how to figure out what's eating my RAM?
[21:15] <ev> ScottK: I take it top isn't showing you the offending process
[21:16] <ScottK> Not that I noticed.
[21:16]  * ScottK can try again.
[21:18] <ev> ScottK: is it continuing to crash, and are you sure it's due to insufficient memory still?  ksysguard should give you an idea of the timeline of your memory usage via the graph, but it wont give you any more detailed of a process listing than top or htop would.
[21:19] <ScottK> I can see the amount of free memory go to 0 briefly.
[21:19]  * ev runs pyflakes and pychecker over ubiquity
[21:20] <ev> ah, that would do it
[21:23] <CIA-71> ubiquity: evand * r4255 trunk/ (debian/changelog ubiquity/plugins/ubi-usersetup.py): Argh. Missing import.
[21:26] <ScottK> ev: I can see in /var/log/syslog that the oom killer is being invoked. "ubiquity invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0"
[21:27] <ScottK> Don't see a thing with top; M though
[21:30] <CIA-71> ubiquity: evand * r4256 trunk/ubiquity/qtwidgets.py: missing import
[21:41] <CIA-71> ubiquity: evand * r4257 trunk/debian/changelog: releasing version 2.3.12
[21:42] <ev> cjwatson: ^
[21:42] <ev> note that we don't need to respin for kubuntu
[21:42] <Riddell> evening
[21:42] <Riddell> ev: what's the status?
[21:42] <ev> as the missing re import is only needed by GTK
[21:42] <ScottK> Riddell: Something is still eating memory and killing the installer for me.
[21:42] <ev> ScottK: not sure, short of appending the output of ps aux | grep ubiquity in a loop to a file
[21:43] <ev> that will eat up the disk space in aufs pretty quick though
[21:43] <cjwatson> ev: I thought there was a Kubuntu respin needed anyway?
[21:43] <ev> oh, perhaps
[21:44] <ev> I haven't been following closely enough it seems
[21:44] <Riddell> ScottK: bug 625586 no?
[21:44] <ubot2> Launchpad bug 625586 in ubiquity (Ubuntu) "ubiquity killed by OOM killer (affects: 2) (heat: 1154)" [High,New] https://launchpad.net/bugs/625586
[21:44] <cjwatson> well, I mean I thought the Kubuntu guys had this RC bug with OOM in the installer ...
[21:44] <ScottK> Riddell: Yes.
[21:45] <ScottK> cjwatson: I think it's not fixed yet though.
[21:45] <ev> yeah, but we haven't tracked that down yet, as far as I'm aware
[21:45]  * ScottK can reproduce at will, just can't figure out what process is eating the memory.
[21:45] <ev> I thought it was due to the crash due to parted_server not running and there being no error handling on parallel debconffilters
[21:45] <ev> but I fixed that
[21:45] <ev> and ScottK still has it
[21:46] <ScottK> ev: Which upload fixed that?
[21:46] <ScottK> (let's make sure I have the fixed one)
[21:46] <ev> 2.3.10
[21:47] <ScottK> That's what I have
[21:49] <ev> damn
[21:50] <ev> I've got to go get ready for dinner.  I'll be back at this in another two hours or so.  Riddell, if you can respond to my questions in the scrollback when you get a chance, hopefully that will get me closer to solving this.
[21:50] <ev> thanks all
[21:53] <Riddell> I don't think I had download updates on for the one I gave you logs for but I'll do another install to check
[22:07] <ScottK> Riddell and ev: One additional data point: Whatever is grabbing RAM, it's not infinite.  I tried killing everything off I could to maximize free RAM and running ubiquity again and it didn't OOM.
[22:13] <Riddell> ScottK: you killed everything and ran ubiquity from the start?
[22:13] <ScottK> Yes.
[22:13] <ScottK> I re-ran it serveral times before with no luck.
[22:22] <Riddell> ev: same problem with updates box not ticked
[22:24] <Riddell> ev: the "OSError: [Errno 9] Bad file descriptor
[22:25] <Riddell> that happens early on
[22:25] <Riddell> and my reading of the logs suggests that's the cause of it
[22:29] <ScottK> Also even though I asked for restricted stuff to be installed, the bcmwl wifi stuf wasn't installed.
[22:29] <ScottK> Do we need a bug for that too?
[22:30] <Riddell> yes
[22:30] <Riddell> well, actually, it installs kubuntu-restricted-addons
[22:30] <Riddell> and runs jockey
[22:30] <Riddell> so maybe it's jockey's fault
[22:33] <ScottK> Riddell: I'm trying to do it by hand and we are lacking libc6-dev on the ISO AFAICT.
[22:38] <ScottK> Actually it's there
[22:40] <ScottK> Fiddle /etc/apt/sources.list to point at the USB stick and apt-get install bcmwl-kernel-source seems to be working.
[22:41] <cjwatson> ev: is 627672 a regression / of concern?  looks bad
[22:41] <cjwatson> bug 627672
[22:41] <ubot2> Launchpad bug 627672 in ubiquity (Ubuntu) (and 1 other project) "[Maverick Beta] install from USB stuck retrieving files 2/6 Hp Mini (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/627672
[22:46] <ScottK> Riddell: I got wireless just from what's on the ISO, so I know we have all the needed bits there.
[23:02] <ev> cjwatson: most certainly of concern
[23:02] <ev> this is the first I've seen it
[23:03] <ev> and very odd, it's clearly mounted and apt-cdrom detect works
[23:39] <Riddell> ev: are you able to recreate the out of memory issue?
[23:45] <superm1> ScottK, re wireless, try running 'jockey-text -a' from a live session and see if it DTRT, that's what ubiquity is doing
[23:45] <ScottK> superm1: Thanks.  Will try that.