[04:14] <shtylman> cjwatson: how much heat have you gotten over the grub2 move?
[04:14] <shtylman> bug report after bug report it seems :/
[04:16] <cjwatson> way too much
[04:16] <cjwatson> I still think it's the right decision but there is clearly lots of work to do
[04:17] <shtylman> cjwatson: I agree with you... I think standing in one place esp. with legacy stuff will just hurt the longer you put it off
[04:17] <shtylman> cjwatson: I think too many people have the wrong attitude about the grub2 move
[04:18] <shtylman> at least that is impression I get from some of the bug reports
[04:18] <shtylman> they are using alpha software and seem to treat it like a finished product...
[04:20] <cjwatson> I understand people's frustration, but the level of abuse in many cases is out of order, and I'm doing my best to disregard it
[04:20] <shtylman> :)
[04:21] <cjwatson> the receptiveness I've had from upstream has been amazing
[04:21] <cjwatson> it's definitely worth being in on the ground floor sometimes
[04:21] <shtylman> thats good
[04:21] <cjwatson> they're going "finally, users"
[04:22] <shtylman> I think all will turn out just fine...the major stuff will be ironed out and then it will be better for everyone
[04:22] <shtylman> hahaha
[04:22] <cjwatson> well, if you fancy helping with the ironing ... ;-)
[04:23] <shtylman> I do fancy helping...just don't know where I would be able to help without getting in the way...unfortunately my experience in booting the system is limited...and that is an overstatement...
[04:24] <cjwatson> it is not the easiest thing to get into
[04:24] <shtylman> I bet
[04:24] <cjwatson> various bits of installer integration still need work, such as dmraid handling
[04:25] <cjwatson> and kirkland reported that degraded raid support has regressed
[04:25] <shtylman> oh yea...I remember that request...
[04:25] <cjwatson> I don't mean dmraid in ubiquity or anything
[04:25] <cjwatson> it's a regression from grub1 handling
[04:26] <shtylman> so does that mean grub2 can't boot dmraid currently?
[04:28] <cjwatson> bug 420992
[04:29] <shtylman> oh boy...
[04:30] <shtylman> man...I would love to tackle that...I have a dmraid setup...but I don't even have the slightest clue of where to start...
[04:31] <shtylman> I can at least test potential fixes...that is a start I suppose
[04:31] <TheMuso> shtylman: I hope that the dmraid box is a dual boot with Windows on the same array. :)
[04:32] <shtylman> TheMuso: nope...I do all my windows stuff through virtual machines cause I rarely ever use it
[04:32] <shtylman> mostly need it to compile a few apps in windows for others
[04:39] <TheMuso> shtylman: Then why are you using dmraid? Its totally inferior to Linux Software RAID.
[04:40] <shtylman> TheMuso: how/why inferior? ... also... because it is bios supported raid basically cheap hardware raid...although still done on the cpu
[04:45] <TheMuso> shtylman: Because there is no real method to rebuild/monitor dmraid arrays from Linux for a start.
[04:46] <shtylman> dmraid does rebuild...
[04:46] <TheMuso> Only for intel software RAID.
[04:46] <shtylman> I see
[04:47] <shtylman> well...another nice thing about dmraid was that once activated...the graphical installer works with it..
[04:47] <shtylman> cause it sees it as a regular drive
[04:47] <shtylman> and can install onto it
[04:47] <TheMuso> Dmraid also acitvates degraded arrays, without even checking things. I.e it will activate an array even if there is only one drive in a RAID 1 array for example.
[04:47] <shtylman> versus no raid in ubiquity otherwide..
[04:47] <shtylman> I see
[04:47] <TheMuso> Ubuntu/debian now has a wrapper script to attempt to take care of it, but its less than ideal.
[04:47] <shtylman> didn't know that...cause i use raid0
[04:48] <TheMuso> right, then thats not really raid. :)
[04:48] <shtylman> well..right... :)
[04:48] <shtylman> but I still gotta call it raid...
[04:48] <shtylman> at least it still falls into that category
[04:54] <TheMuso> right
[04:54]  * shtylman loves his raid0 setup
[05:05] <TheMuso> I hope you keep your data backed up.
[07:20] <CIA-33> usb-creator: rgreening * r140 usb-creator/ (7 files in 5 dirs): (log message trimmed)
[07:20] <CIA-33> usb-creator: * Update KDE TODO
[07:20] <CIA-33> usb-creator: * Bump version in setup.py, kde_about.py, usb-creator-gtk to 0.2.4
[07:20] <CIA-33> usb-creator: * General clean-up in usb-creator-kde to mirror current usb-creator-gtk
[07:20] <CIA-33> usb-creator:  - remove _fail, excepthook def's as not needed
[07:20] <CIA-33> usb-creator:  - remove trace options
[07:20] <CIA-33> usb-creator:  - remove safe command line option
[08:04] <CIA-33> usb-creator: rgreening * r141 usb-creator/ (TODO debian/changelog usbcreator/frontends/kde/frontend.py):
[08:04] <CIA-33> usb-creator: * General clean-up in kde/frontend.py
[08:04] <CIA-33> usb-creator:  - remove unused setup_sources_treeview and setup_targets_treeview
[08:04] <CIA-33> usb-creator:  - temporarily disable format and other buttons as they are currently broken
[08:04] <CIA-33> usb-creator: * Update TODO for some broken items to fix
[08:44] <davmor2> cjwatson: morning this is the wubi/ubiquity bug that is causing all the wubi tests to fail https://bugs.launchpad.net/bugs/421873.  Apparently it's a copy of another bug but I kept it separate being as it is only on the wubi install that I'm having the issues.
[09:33] <davmor2> xivulon: morning dude do you have 5 minutes?
[09:33] <xivulon> yes davmor2
[09:33] <xivulon> morning
[09:34] <xivulon> cjwatson, by the way yesterday reinstalled XP inside of kvm and now grub2 works :)
[09:34] <davmor2> bug 421873 and bug 421909
[09:34] <xivulon> I wouldn't be overly concerned about it, the previous vm has been heavily tortured
[09:35] <davmor2> xivulon: both found yesterday testing wubi
[09:38] <xivulon> 421909 is probably due to the size check again, patch 144 compensates for free space but that is not enough
[09:39] <xivulon> let me have a chat with evand, we might enable DVD's altogether and be done with it
[09:40] <xivulon> 421873 I haven't reached that far yesterday, was able to boot again only this morning :)
[09:42] <davmor2> xivulon: 421909 I ran on a standard machine thinking it might be down to space but it still didn't show up
[09:44] <xivulon> There are 2 items in the log:  umount: /host: device is busy ;  and /lib/partman/choose_partition/Finish: not found
[09:45] <xivulon> does 421909 happen with a CD? If so can you pastebin the wubi log?
[09:50] <davmor2> xivulon: no the cds have been fine it is only on unr and kne on pendrives
[09:53] <xivulon> What is the size of the pendrive you are using? Should be less than max_iso_size
[09:53] <xivulon> try to edit data/isolist.ini and change max_iso_size, recompule wubi and see if it works
[09:57] <davmor2> xivulon: 4GB and an 8GB but I restrict it to iso size plus 128kb persist
[09:57] <davmor2> I'll have a look at it
[09:58] <davmor2> xivulon: I just pulled version 148
[10:04] <davmor2> bugger I don't have grub2 on my jaunty box meh
[10:10] <xivulon> davmor2: install these 2 packages:
[10:10] <xivulon> http://packages.ubuntu.com/karmic/grub-common
[10:10] <xivulon> http://packages.ubuntu.com/karmic/grub-pc
[10:10] <xivulon> it will work from jaunty
[10:14] <davmor2> xivulon: building
[10:19] <davmor2> xivulon: right I change the 9 at the begining to a 20 and now it is showing up again :)
[10:20] <davmor2> 20 is probably too big but I wanted to be on the safe side :)
[10:20] <xivulon> yes so that confirms it is a size check issue, please comment on bug report
[10:29] <davmor2> xivulon: will do :)
[10:33] <davmor2> xivulon: any chance of getting that in today as evand isn't in and it would be nice to be able to test wubi on unr and kne properly although I'll have a little play with it, with my local build and see if it dies at the same point as the others which will at least mean that all the wubi's are on an even playing field :)
[10:46] <xivulon> I can do that tonight, but it's my wedding anniversary, so low chance
[10:46] <xivulon> most likely by tomorro night
[10:48] <davmor2> :) happy anniversary :)
[11:41] <cjwatson> I have no idea what's causing 421873; the log is uninformative :(
[11:47] <davmor2> cjwatson: I don't suppose it's something daft like devicekit-disks mounting all the drives it sees or something is it?
[11:48] <cjwatson> unrelated
[11:49] <cjwatson> exit code 127 suggests that grub-installer is falling over for lack of some tool, but there's nothing in the log to say what
[11:49] <cjwatson> and that's just a guess ...
[11:49] <cjwatson> davmor2: can you manage to arrange for the installer to run with the --debug option somehow?
[11:53] <davmor2> cjwatson: that's in the kernel line yes?  I'll see what I can do
[11:54] <cjwatson> no
[11:54] <davmor2> oh
[11:54] <cjwatson> try debug-ubiquity in the kernel line, maybe
[11:55] <davmor2> right
[12:01] <CIA-33> console-setup: cjwatson * r111 ubuntu/ (Keyboard/KeyboardNames.pl debian/changelog): releasing version 1.34ubuntu2
[12:01] <davmor2> cjwatson: just dropping vista back on to install against so might take a bit
[12:34] <davmor2> cjwatson: where will the debug info be? in the standard logs or somewhere else?
[12:37] <cjwatson> standard
[12:37] <cjwatson> specifically in /var/log/installer/debug
[12:38] <davmor2> I'll post all the logs to the bug report then
[12:45] <davmor2> cjwatson: right added debug and new syslog
[12:55] <cjwatson> I can't see how that code *ever* worked
[12:55] <CIA-33> grub-installer: cjwatson * r799 ubuntu/ (debian/changelog grub-installer):
[12:55] <CIA-33> grub-installer: Restrict code to generate device.map for loop installations to GRUB
[12:55] <CIA-33> grub-installer: Legacy (LP: #421873).
[12:58] <CIA-33> grub-installer: cjwatson * r800 ubuntu/ (debian/changelog grub-installer): Fix said code to run grub chrooted into /target.
[12:58] <cjwatson> oh, I suppose it would have worked in ubiquity
[13:00] <davmor2> cjwatson: I'm guessing that the debug log was a bit more useful then :)
[13:00] <cjwatson> yeah
[13:01] <cjwatson> of course it may still fail somewhere else, that just fixed the immediate problem
[13:02] <davmor2> cjwatson: cool any chance of a respin I'd like to know if it works today rather than finding out during main testing tomorrow
[13:05] <cjwatson> well, bear with me, I need to get some other grub-installer changes in too
[13:07] <davmor2> cjwatson: yeah np's any time today will do I'd just hate to find something else now wubi is this close to working :)
[13:07] <cjwatson> oh, and a bunch of installer translation updates for a5, argh
[13:13] <CIA-33> cdrom-detect: cjwatson * r448 ubuntu/debian/changelog: releasing version 1.31ubuntu2
[13:17] <AnAnt> Hello, can someone see this bug LP 416949 please ?
[13:18] <CIA-33> partman-auto-lvm: cjwatson * r226 ubuntu/debian/changelog: releasing version 33ubuntu2
[13:18] <cjwatson> AnAnt: queued for when I have a moment
[13:21] <CIA-33> partman-auto: cjwatson * r300 ubuntu/debian/changelog: releasing version 87ubuntu2
[13:22] <CIA-33> partman-base: cjwatson * r167 ubuntu/debian/changelog: releasing version 133ubuntu2
[13:22] <AnAnt> cjwatson: you mean the backport for scancodes bug ?
[13:23] <CIA-33> partman-crypto: cjwatson * r688 ubuntu/debian/changelog: releasing version 37ubuntu3
[13:23] <AnAnt> cjwatson: or the layout toggle issue ?
[13:24] <cjwatson> AnAnt: no, I mean I'll look at your layout toggle bug when I have a moment. I already backported the scancodes thing, which is purely cosmetic and nothing whatsoever to do with your bug
[13:24] <AnAnt> cjwatson: ok
[13:24] <AnAnt> thanks
[13:24] <cjwatson> all the Debian change does is silence a warning, nothing mnore
[13:24] <cjwatson> more
[13:25] <AnAnt> yeah
[13:25] <CIA-33> partman-lvm: cjwatson * r1229 ubuntu/debian/changelog: releasing version 66ubuntu3
[13:26] <CIA-33> partman-md: cjwatson * r942 ubuntu/debian/changelog: releasing version 46ubuntu2
[13:28] <CIA-33> partman-target: cjwatson * r773 ubuntu/debian/changelog: releasing version 62ubuntu2
[13:29] <CIA-33> pkgsel: cjwatson * r149 ubuntu/debian/changelog: releasing version 0.25ubuntu2
[13:31] <CIA-33> user-setup: cjwatson * r205 ubuntu/debian/changelog: releasing version 1.27ubuntu10
[13:34] <mterry> cjwatson, heyo.  I don't know if it's worth trying to push the plugin work in for Alpha5, but if you have extra time (har), the FFE bug for it (bug 419989) is blocked on your review.  But, I don't really think it matters if it goes in before a5.  Just giving you a heads up
[13:40] <cjwatson> davmor2: if it's using grub2, I rather suspect that the bootdev_directory stuff won't work
[13:40] <cjwatson> davmor2: nobody has taken the time to update that to grub2 yet
[13:41] <davmor2> cjwatson: I'm assuming it is as I couldn't build it earlier
[13:42] <davmor2> due to the lack of grub2 deps
[13:43] <cjwatson> xivulon: should I just force wubi installations to use grub1 for now? this is surely going to take a certain amount of work
[13:44] <CIA-33> grub-installer: cjwatson * r801 ubuntu/ (10 files in 3 dirs): merge from Debian 1.42
[13:45] <cjwatson> hmm, wubi trunk has grub2 bits in it ...
[13:47] <cjwatson> but only for booting the installer, if I'm reading this right?
[13:51] <CIA-33> grub-installer: cjwatson * r802 ubuntu/grub-installer: merge typo: missing fi
[13:53] <CIA-33> grub-installer: cjwatson * r803 ubuntu/debian/changelog: releasing version 1.42ubuntu1
[13:58] <NCommander> cjwatson, do you have plans for one more d-i upload before A5 or is it all done?
[14:17] <davmor2> cjwatson: so is that a fix then, crosses fingers
[14:27] <AnAnt> I'll have to go now
[14:27] <AnAnt> bye
[14:33] <cjwatson> NCommander: planning one more
[14:33] <cjwatson> davmor2: with luck, though it'll need a ubiquity upload
[14:33] <cjwatson> mterry: you have a review in LP now
[14:34] <davmor2> cjwatson: Cool nice one :)
[14:36] <CIA-33> debian-installer: cjwatson * r1144 ubuntu/ (10 files in 3 dirs): Move to 2.6.31-9 kernels.
[14:36] <mterry> cjwatson, cool, will respond
[15:02] <NCommander> cjwatson, I'm hoping to have installable dove images for A5 if possible, but I need one kernel upload which may happen today (bjf is working on it, but most of the kernel team is scrambling to get to St. Lois)
[15:02] <NCommander> cjwatson, I need the partman-auto changes, and flash-kernel changes (the later which is dep-wait on the kernel) merged, I dunno if thats possible for A5 though
[15:04] <cjwatson> bug# for those?
[15:08] <NCommander> cjwatson, https://bugs.edge.launchpad.net/ubuntu/+source/partman-auto/+bug/409238
[15:14] <CIA-33> partman-auto: cjwatson * r301 ubuntu/ (6 files in 3 dirs): merge lp:~mcasadevall/partman-auto/dove_soc
[15:14] <cjwatson> NCommander: what does "a udev partition type" mean? is that a typo?
[15:15] <NCommander> cjwatson, I'd like to add a partman-udev similiar to partman-efi in the future, instead of simply having a separate boot
[15:15] <cjwatson> udev?
[15:15] <NCommander> er
[15:15] <NCommander> uboot
[15:15] <NCommander> wow
[15:15] <NCommander> Not only did I typo, I managed to read the wrong thing
[15:15] <cjwatson> that makes more sense :)
[15:15] <NCommander> *sighs*
[15:15] <NCommander> I've been working on this too many days without a sanity break
[15:15] <CIA-33> partman-auto: cjwatson * r302 ubuntu/debian/changelog: typos
[15:21] <NCommander> cjwatson, thanks
[15:27] <CIA-33> partman-auto: cjwatson * r303 ubuntu/debian/changelog: releasing version 87ubuntu3
[15:30] <NCommander> cjwatson, \o/
[15:31] <cjwatson> no flash-kernel patch to review?
[15:40] <NCommander> cjwatson, not yet, waiting for the next kernel upload to adjust my patch. I don't want to give you something untested
[15:40] <NCommander> cjwatson, the kernel going from uImages to zImages so my patch isn't 100% valid anymore :-)
[16:04] <CIA-33> ubiquity: mterry * r3361 plugins2/ (26 files in 6 dirs): fixups from colin's review; add a PluginUI base class, use a debug() method in it, use plugins/ instead of plugins.d/, some style cleanup
[16:22] <AnAnt> cjwatson: Hello, did you have time for the console-setup bug ?
[16:23] <CIA-33> ubiquity: superm1 * r3414 ubiquity/ (debian/changelog gui/gtk/mythbuntu_stepDrivers.ui):
[16:23] <CIA-33> ubiquity: * Mythbuntu frontend:
[16:23] <CIA-33> ubiquity:  - Fix a crash caused by two GtkCellRendererText's having the same
[16:23] <CIA-33> ubiquity:  id. A recent upload of gtk is less forgiving of this error.
[16:23] <CIA-33> ubiquity:  (LP: #422621)
[16:24] <cjwatson> AnAnt: not yet, no
[16:24] <AnAnt> ok
[16:35] <CIA-33> usb-creator: rgreening * r144 usb-creator/ (7 files in 5 dirs):
[16:35] <CIA-33> usb-creator: * Updated TODO list and added some comments for items to fix
[16:35] <CIA-33> usb-creator: * Updated man pages
[16:35] <CIA-33> usb-creator: * Updated some licence info in kde frontend to GPLv3+
[16:42] <rgreening> cjwatson: any idea when evand will be back?
[16:42] <superm1> cjwatson, given pitti's ack, were you thinking to merge mterry's plugins branch pre a5 or shortly thereafter?
[16:43] <cjwatson> rgreening: tomorrow I think
[16:44] <cjwatson> superm1: post, I think - it's a pretty huge branch and I'd be worried about screwing over a5
[16:44] <rgreening> ok. cool. lots of stuff to fix in usb-creator :)
[16:44] <mterry> superm1, cjwatson: Agreed, especially since I'm making some API changes post-cjwatson-review.  Wouldn't want those last minute changes to screw something up
[16:46] <superm1> cjwatson, mterry, ok.  well, will need to do another ubiquity upload before a5 because of that above bug that crept up i just fixed. anything else others would like to get in then?
[16:47] <cjwatson> also need a ubiquity upload for all the d-i bits I uploaded earlier
[16:47] <rgreening> shtylman: ubiquity under kubuntu looks sweet. just fully tested last night on my netbook
[16:47] <cjwatson> partman-auto 87ubuntu3 should become available for update in about an hour
[16:47] <mterry> cjwatson, speaking of, I'm looking at making the non-API-namespace change, and I think it would be far less intrusive and easier to write plugins if we namespace API members instead.  Something like 'plugin_'.  By far, most members are internal to the plugins.  Any objection?
[16:48] <rgreening> shtylman: only things was noticeable "slowness" from timezone onward... pages seemed to take quite a while. COuld be my issue. but just wanted to let you know in case it wasn't.
[16:48] <cjwatson> just to clarify terminology - is 'optional_widgets', say, API or non-API?
[16:48] <superm1> cjwatson, okay i'll hold off until partman-auto clears to upload then
[16:48] <CIA-33> usb-creator: rgreening * r145 usb-creator/TODO: Another TODO/Fix item
[16:51] <mterry> cjwatson, it's API (anything the frontend would use)
[16:52] <cjwatson> mterry: no objections, then; it matters more that we stick to it
[16:53] <mterry> cjwatson, agreed  :)
[16:58] <xivulon> cjwatson, yes grub2 should be ok for booting
[16:58] <xivulon> I expect that the linux side of things should be manageable
[16:58] <xivulon> I wouldn't go back to grub 1
[16:59] <xivulon> I didn't do much work (on the liunux side) so far because I could not have grub2 to boot at all within vb
[17:00] <xivulon> but now I can boot via kvm so I will try to make this thing work in the coming days
[17:01] <cjwatson> xivulon: what takes care of telling the installed grub how to get at the /boot directory?
[17:02] <xivulon> cjawston by finding a file
[17:02] <xivulon> there is an embedded grub.cfg inside of wubildr
[17:02] <CIA-33> usb-creator: rgreening * r146 usb-creator/ (debian/changelog desktop/usb-creator-kde.desktop.in): * Remove settings categories to de-clutter the KDE menu (settings doesn't make all that much sense for KDE)
[17:03] <xivulon> that  sets the root to the partition containing /ubuntu/boot/grub/grub.cfg
[17:03] <xivulon> I knwow, I should have used UUIDs...
[17:04] <xivulon> the above embedded config then loads  /ubuntu/boot/grub/grub.cfg
[17:04] <cjwatson> ok
[17:06] <xivulon> data/wubildr.cfg is the embedded config
[17:07] <xivulon> In /ubuntu/boot/grub/grub.cfg there is therefore no need to set the grub root device
[17:07] <xivulon> Only the relative path
[17:09] <xivulon> So we had something like: root=()/ubuntu/boot
[17:13] <xivulon> I haven't looked at the new update-grub, but I'd assume we should be able to put the required modifications in a dedicated grub script, possibly installed by lupin-grub or something like that
[17:16] <xivulon> cjwatson ^
[17:18] <CIA-33> ubiquity: superm1 * r3415 ubiquity/ (debian/changelog scripts/mythbuntu/mythbuntu_install.py):
[17:18] <CIA-33> ubiquity: Reconfigure mysql-server-5.1 rather than 5.0 since 5.1 is what's
[17:18] <CIA-33> ubiquity: now in main.
[17:21] <cjwatson> xivulon: yes, that's what I was thinking
[17:21] <cjwatson> xivulon: or just lupin-support, I don't think it needs a new package
[17:32] <kirkland> cjwatson: arethe fsck failures on first boot after install understood?
[17:40] <cjwatson> first I've heard
[17:48] <CIA-33> ubiquity: cjwatson * r3416 ubiquity/ (5 files in 4 dirs):
[17:48] <CIA-33> ubiquity: Re-enable encrypted home option; apparently all the dependencies are in
[17:48] <CIA-33> ubiquity: place now.
[18:19] <CIA-33> usb-creator: rgreening * r147 usb-creator/ (3 files in 3 dirs):
[18:19] <CIA-33> usb-creator: Disable persistence - it's currently broken, and if user is able to select persistence, it will
[18:19] <CIA-33> usb-creator: yield a non-functional startup disk. So, disabled until can be fixed.
[18:21] <rgreening> cjwatson: we may want to bump a new version of usb-creator based on above commit I have made.
[18:22] <rgreening> currently any attempt to use persistence causes a nonfunctional startup disk to be made (for the gtk and kde version)
[18:24] <rgreening> cjwatson: let me bump the version strings first though...
[18:25] <superm1> why is it breaking now?
[18:25] <CIA-33> usb-creator: rgreening * r148 usb-creator/ (4 files in 4 dirs): Bump version strings for new release
[18:26] <rgreening> superm1: I have no idea when it last worked.. just that it isn't...
[18:26] <rgreening> and possibly hasn't for a while
[18:27] <rgreening> and I've done some exptensive testing on Karmic for both frontends... all end in the same result - b0rked with persistence
[18:28] <superm1> well here's a better question then; how is it broke? what is visibly broke about it?
[18:28] <superm1> have you gotten any of this in a bug report yet?
[18:28] <rgreening> maybe the current kernel is at fault and unable to load the casper file
[18:28] <rgreening> superm1: umm. I develop it
[18:28] <rgreening> lol
[18:28] <rgreening> I'm noting and fixing as I go.
[18:28] <rgreening> unless you want to take the reins?
[18:29]  * rgreening is feeling evil atm
[18:29] <superm1> rgreening, i know, you work on it :).  i was just wondering if there was a bunch of debug information around what was borked with persistence in the first place
[18:29] <rgreening> not that I know of... Never saw any reports.
[18:30] <rgreening> I am just testing the kde version since evand swapped out the Hal backend for devicekit disks and I never had a chance to see what the changes were.
[18:30] <rgreening> Now that I have, and I am testing, these are the things I have found and either fixed or implemented work arounds fo r
[18:30] <rgreening> all noted in bzr, changelog and comments in the code :)
[18:31] <rgreening> Hopefully when evan gets back, I can address the outstranding issues
[18:31] <superm1> well before you go and disable persistence in the code, it would be a good idea to have a bug report to indicate how/why it's broken, so when that bug gets fixed, know to re-enable it in the code
[18:31] <rgreening> at least we have a functional gtk/kde version with these changes (even if somewhat crippled intentionally)
[18:33] <rgreening> true enuff... I'm just in triage help-me-god mode :)
[18:33]  * rgreening launches launchpad...
[18:38] <rgreening> superm1: hmm bug #276822 seems to be relevant (missed that one)
[18:39] <rgreening> possibly... or at least may hint me a direction for a fix
[18:40] <superm1> lots of mixed feedback there
[18:40] <superm1> especially since people are testing all over different versions
[18:40] <superm1> and persistence didn't work in 8.04.1 and maybe 8.04.2
[18:43] <rgreening> true, but at this point I had no idea where to start looking for a fix... getting the casper.log for eample :)
[18:43] <CIA-33> ubiquity: superm1 * r3417 ubiquity/ (d-i/manifest debian/changelog debian/control):
[18:43] <CIA-33> ubiquity: Automatic update of included source packages: console-setup
[18:43] <CIA-33> ubiquity: 1.34ubuntu2, grub-installer 1.42ubuntu1, partman-auto 87ubuntu3,
[18:43] <CIA-33> ubiquity: partman-base 133ubuntu2, partman-target 62ubuntu2, user-setup
[18:43] <CIA-33> ubiquity: 1.27ubuntu10.
[18:43]  * rgreening grabs the file to look at
[18:46]  * rgreening b0rked the ubs key
[18:46] <rgreening> :(
[18:47] <CIA-33> ubiquity: superm1 * r3418 ubiquity/debian/changelog: release 1.99.15 into karmic
[19:21] <CIA-33> ubiquity: mterry * r3362 plugins/ (24 files in 4 dirs): drop get_ui(), instead use namespaced members of the UI class
[19:45] <ogra> cjwatson, hmm, looking at Bug 422101 and at my own installation logs on imx51, we seem to have a logging issue
[22:24] <cjwatson> ogra: logs aren't copied until the very last step. if the installer crashes, logs may be lost.
[22:25] <cjwatson> ogra: but if that's not what's happening (i.e. the syslog is useless before rebooting), then ... I think you may be in a much better position to debug this than I am
[22:27] <JanC> this sounds like an important usability problem of the ubiquity installer: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/421407
[22:27]  * cjwatson reassigns that to the proper place
[22:27] <cjwatson> 10GB> absolutely not
[22:28] <cjwatson> that's far too big for a minimum, which is what that number is
[22:28] <cjwatson> the *default* is meant to be midway in between the minimum (currently 2.5GB) and whatever's available for resizing
[22:29] <cjwatson> and there's a load of uninformed speculation in that bug, so I'll look at it some other time when I have more temper to spare
[22:30] <cjwatson> thanks for mentioning it
[22:30] <davmor2> cjwatson: sweet answer :)
[22:31] <cjwatson> not really, I'm just fresh from stressful children-bedtime and so my background state is annoyed, sorry
[22:32] <davmor2> you forgot just move the chuffin' slider it's what it's there for :)
[22:33] <cjwatson> well, no, defaults should be reasonable
[22:33] <JanC> davmor2: one problem is that it's not obvious that it is a slider to start with
[22:35] <davmor2> cjwatson: I'm attempting a wubi install from 2009091.1 and just noticed that the initial disk setup went to 112%
[22:36] <davmor2> JanC: It's about as obvious as it can be.  The only thing I can think of to add is a piece of text that says move the slider to adjust partition size
[22:39] <cjwatson> davmor2: that'll have to wait for Evan to get back
[22:39] <cjwatson> I'm so far out of date with wubi it isn't funny :(
[22:44] <CIA-33> debian-installer: cjwatson * r1145 ubuntu/debian/changelog: releasing version 20081029ubuntu56
[23:16] <davmor2> cjwatson: on slide show in ubiquity firefox page is missing an image I have reported it, it is minor but it's just incase it's brought up
[23:17] <cjwatson> -> evand :-)
[23:22] <davmor2> cjwatson: I figured it would be but I thought a heads up would be good :)