[07:44] <CIA-44> partman-target: evand * r700 partman-target.ubuntu/debian/changelog: releasing version 52ubuntu6
[07:59] <TheMuso> evand: Are you going to be around for a while?
[08:00] <evand> TheMuso: I can be for a little while longer, but as it's 3am I would like to get to bed soonish.
[08:00] <evand> Still, if this is the best time for you, I can bite that bullet
[08:01] <TheMuso> evand: Ok, just quickly, you mentioned dmraid in your report. It turns out it has no way of notifying a user if the array is degraded, and still lets the system boot. It also has no way of rebuilding the array within Linux.
[08:01] <evand> oo, fantastic
[08:01] <TheMuso> I mentioned this in my activity report, which pitti asked me about. I said we shouldn't include it, but other opinions are welcome
[08:02] <TheMuso> If you and cjwatson could possibly have a look at the thread and reply with your thoughts.
[08:02] <evand> I could've sworn this was handled a while back -- but I definitely don't remember it not notifying the OS being an issue discussed
[08:02] <TheMuso> Well all that I noticed was a single error on VC1 during boot.
[08:02] <TheMuso> And, acording to upstream, rebuilding arrays is coming, but likely won't be here for hardy.
[08:03] <cjwatson> if Windows (say) is already installed on dmraid, can you even use the system properly at all without dmraid?
[08:03] <TheMuso> So... Basically I'm wondering whether I should still spend time fixing partman-dmraid bugs.
[08:03] <evand> well, cjwatson can speak on timelines better than I can, but my understanding was that the chances of getting this all done for Hardy was slim at best.
[08:04] <cjwatson> I haven't read the mail yet though
[08:04] <TheMuso> cjwatson: Dmraid tells the kernel devmapper to create the device nodes, according to what dmraid reads from the metadataat the end of the drive.
[08:04] <TheMuso> So unless you want to destroy your windows install, you have to use dmraid to boot and install the OS.
[08:04] <TheMuso> As well as preventing the destruction of RAID metadata at the end of the disk.
[08:05] <cjwatson> right, so my concern is that "completely broken" => "works although with some nasty bugs" may still be worthwhile
[08:05] <cjwatson> and we may just have to do our best to mitigate the nastiness
[08:05] <cjwatson> I don't think we have time to do much of significance with partman-dmraid
[08:05] <cjwatson> but may be able to do some initramfs checks to make dmraid work more smoothly?
[08:05] <TheMuso> One thing pitti asked me is how the user could rebuild the array, and afaik the only way is while in WIndows, or using the controller's BIOS, if it allows you to do so.
[08:06] <cjwatson> but, I should really read your mail and follow up to that
[08:06] <TheMuso> cjwatson: Probably not, but I'd like to at least fix the bug where if you init a partition table on a dmraid pair of disks, that it doesn't bomb out.
[08:07] <TheMuso> Yeah probably best taken there, as it will all depend on whether we have to ask for MIRs to be re-examined.
[08:07] <TheMuso> But it comes down to whether I should keep on working on it.
[08:08] <TheMuso> Anyway, thanks for both your time.
[08:08] <cjwatson> for the time being, I think yes, but if it's still outstanding next week we will need to revisit that
[08:08] <TheMuso> Ok.
[08:09] <TheMuso> I'll see what can be scraped out of dmraid to get some better error reporting.
[08:09] <TheMuso> Doesn't help that it only gives 2 error codes however.
[08:09] <TheMuso> 0 for success, or 1 for any error.
[08:10] <TheMuso> ANYWAY>
[08:10] <TheMuso> ?ME GOES TO GET DINNER>
[08:10] <TheMuso> ?C
[08:10] <TheMuso> UGH DAMN KEYBOARD
[08:10] <TheMuso> ?C
[08:11] <evand> haha
[14:04] <xivulon> Is there any intrinsic advantage in mounting the root device r/o in the initrd and then remounting it r/w at init?
[14:06] <cjwatson> yes, you can't mount read-write until you've fscked it
[14:06] <cjwatson> or at least shouldn't
[14:07] <xivulon> I am asking because at the moment loopinstallation host is mounterd rw to begin with (from gutsy)
[14:07] <xivulon> even though remounting should now work, I was wondering if it is worth changing that
[14:07] <xivulon> but ntfs fsck does not work anyway
[14:08] <xivulon> I'd guess we can leave it rw for the time being then
[14:21] <CIA-44> ubiquity: evand * r2472 ubiquity/debian/po/ (79 files): debconf-updatepo
[14:25] <CIA-44> ubiquity: evand * r2473 ubiquity/ (9 files in 6 dirs): Forgot to bump to 1.7.9
[14:27] <CIA-44> ubiquity: evand * r2474 ubiquity/ (d-i/manifest debian/changelog):
[14:27] <CIA-44> ubiquity: * Automatic update of included source packages: base-installer
[14:27] <CIA-44> ubiquity:  1.86ubuntu2, partman-target 52ubuntu6.
[14:41] <CIA-44> ubiquity: evand * r2475 ubiquity/debian/changelog: releasing version 1.7.9
[15:24] <CIA-44> ubiquity: evand * r2476 ubiquity/ (configure configure.ac): Bump to 1.7.10
[15:43] <CIA-44> oem-config: evand * r413 oem-config/ (7 files in 5 dirs):
[15:43] <CIA-44> oem-config: * Use new timezone widget from Ubiquity. oem-config now shrinks to a
[15:43] <CIA-44> oem-config:  much smaller size (LP: #191823).
[15:47] <CIA-44> oem-config: evand * r414 oem-config/ (8 files in 5 dirs): Forgot to bump to 1.28
[16:01] <CIA-44> oem-config: evand * r415 oem-config/debian/changelog: releasing version 1.28
[16:03] <CIA-44> oem-config: evand * r416 oem-config/ (configure configure.ac): bump to 1.29
[18:17] <mario_limonciell> evand, are you already aware of instability issues with the new tzmap, or would you like bugs filed on them?
[18:17] <evand> uh oh
[18:17] <evand> what instability issues?
[18:18] <mario_limonciell> keeps triggering apport when i try to pick locations
[18:18] <evand> oh hilarious
[18:18] <evand> I'll take a look in a minute
[18:18] <mario_limonciell> ubiquity doesn't go down hard or anything, but i'm guessing just an exception that's not being caught
[18:19] <evand> hrm
[18:19] <mario_limonciell> http://paste.ubuntu.com/4804
[18:19] <mario_limonciell> not just an exception it'd appear
[18:20] <xivulon> ah didn't know that the widget was actually being used...
[18:20] <evand> as of about an hour or two ago
[18:20] <mario_limonciell> xivulon, it's not in the dailies yet, evan just uploaded it
[18:20] <mario_limonciell> i grabbed the binaries and added them to a live env to test with
[18:20] <xivulon> ah
[18:21] <xivulon> one sec
[18:22] <xivulon> mario_limonciell: how you managed to trigger the error?
[18:22] <mario_limonciell> xivulon, trying to pick a timezone somewhere in CST
[18:23] <evand> it's a simple enough fix
[18:23] <mario_limonciell> just clicking several times
[18:23] <xivulon> ok
[18:23] <xivulon> is that using a small zoom window or in full zoom mode?
[18:24] <mario_limonciell> it went into full zoom when it happened
[18:24] <mario_limonciell> but its a small window?
[18:25] <evand> xivulon: we don't use the small zoom window in ubiquity, it's full zoom
[18:25] <evand> the code is still there, however
[18:25] <xivulon> ok
[18:27] <xivulon> hmm cannot trigger the error on the zoom-map-branch
[18:27] <evand> the code has diverged from that
[18:27] <xivulon> ah
[18:57] <CIA-44> ubiquity: evand * r2477 ubiquity/ (debian/changelog ubiquity/zoommap.py):
[18:57] <CIA-44> ubiquity: * Check for a valid cursor position in zoommap's hit_test and other minor
[18:57] <CIA-44> ubiquity:  fixes.
[18:57] <evand> mario_limonciell: thanks for catching that
[19:40] <mario_limonciell> no prob
[19:40] <evand> xivulon: problem
[19:40] <evand> it seems that running off the iso image extracted from the CD has not worked for some time
[19:41] <evand> the initramfs fails trying to find a live filesystem
[19:48] <evand> oh, why do I have the feeling this is lupin 0.12 stuff
[19:48] <evand> hrm
[19:59] <xivulon> hi
[19:59] <evand> ah, indeed it was
[19:59] <evand> sorry for the false alarm
[19:59] <xivulon> np
[20:00] <evand> I wasn't mentally accounting for the find_iso -> iso-scan/filename change
[20:00] <xivulon> ah yes
[20:00] <evand> I have the feeling I'm going to have a fun evening when the updated livefs lands
[20:07] <evand> xivulon: ok, I've pointed the stable symlink at 432
[20:11] <xivulon> good
[20:12] <xivulon> when will the iso be available?
[20:14] <evand> the new ubiquity hasn't hit the archive yet, but when it does plus two hours
[20:14] <evand> well, two and a half if you count the time it takes to build the CDs
[20:18] <evand> ah, slangasek is already working new ones through it seems:
[20:18] <evand> 15:15:31 < slangasek> livefs builds fixed; live CD builds following shortly
[20:52] <Jouva> Hey guys, I don't know if this is appropriate for this channel or if this isn't considered the installer portion or not: I have a Dell Dimension E310, which according to other reports of past versions of Ubuntu didn't work, but I think I got it working now. However, once the disk gets to the point of loading X, the CD keeps spinning and spinning and it takes FOREVER for it to even display the desktop. Wasn't sure if this is a known issue for s
[20:52] <Jouva> Wasn't sure if this is a known issue for some hardware configs
[20:55] <Jouva> The system only has 256 megs RAM so I'm unsure if this is common for something with that amount of memory
[20:58] <evand> Jouva: the desktop CD requires 320MB of RAM.
[20:58] <evand> well, the installer does
[20:58] <Jouva> ahhhh
[20:58] <evand> the alternate CD will let you install with far less
[20:58] <evand> but I'm not sure how much memory GNOME requires
[20:59] <Jouva> I hate that this system came with only 256 RAM. Free system mind you ;) but it's a P4 HT! You figure it'd have a gig or something
[21:00] <evand> haha
[21:07] <TheMuso> Jouva: You'd be surprised. In Australia, many machines were sold with 256MB RAM by default for many years.
[21:07] <Jouva> Whee.
[21:07] <TheMuso> Even my notebook only has 256MB as standard, and this was 2004.
[21:07] <Jouva> Youch.
[21:07] <TheMuso> I got 512MB, i.e another 256MB, but yeah, rather shameful. XP needs 512 to run well.
[21:09] <TheMuso> Hell most baseline notebooks here now only have 512MB, and they have Vista...
[21:09]  * TheMuso shudders.
[21:10] <Jouva> OW
[21:10] <Jouva> That's BAD
[21:10] <TheMuso> Yeah.
[21:10] <Jouva> That's like having 64 megs of ram with XP
[21:14] <TheMuso> Or even 128.
[21:21] <soren> I was just told about this: http://kvm.qumranet.com/kvmwiki/KVMTest
[21:22] <soren> Maybe you guys can use it to test the installer and stuff.. Just a thought.


[03:09] <timClicks> what's the easiest way to debug the apiserver? I want to know what's on the other side of the facade call
[03:39] <timClicks> ended up using this: juju debug-log -m controller --replay --include-module juju
[03:59] <babbageclunk> timClicks: for more detail you can turn logging in the apiserver up to trace using `juju model-config -m controller logging-config="juju.apiserver=TRACE"`
[04:20] <timClicks> anastasiamac: I think that this change might be harder than expected
[04:21] <timClicks> the code is all fine on the server-side, but the client-side API is lossy
[04:21] <timClicks> (c *Client) FindTools(majorVersion, minorVersion int, series, arch, agentStream string) (result params.FindToolsResult, err error)
[04:21] <timClicks> we loose the alpha/beta/rc and build number when we look for tools
[04:22] <timClicks> because c.AgentStream is "", the server defaults to released
[04:58] <hpidcock> If I'm adding a new field to a facade request params struct, should I bump the facade version?
[05:00] <babbageclunk> hpidcock: yes, particularly for a client facade (where there are other clients than just the juju CLI)
[05:01] <timClicks> hpidcock: in particular, the juju gui and pylibjuju also rely on that version number
[05:04] <timClicks> babbageclunk: btw your panic debugging method is pretty effective
[05:04] <hpidcock> +1 panic is great for debugging
[05:10] <babbageclunk> cheers! even more fun than printf debugging
[05:15] <hpidcock> more fun because it yields better results ;)
[05:16] <babbageclunk> who doesn't love a stack trace?
[05:52] <anastasiamac> timClicks: m happy to discuss further ur monday since m guessing u r eod now
[05:53] <anastasiamac> at eow even :D
[14:22] <hml> manadart: there’s something odd about what we’re doing with providerID for spaces.    will look more.
[14:23] <hml> manadart:  we’re adding spaces with an undefined name and -1 providerID.
[14:25] <rick_h> hml:  so I think that's the MAAS "undefined" space
[14:25] <manadart> hml: Got a ref in code? We have the default space + MAAS undefined space.
[14:25] <manadart> What rick_h said.
[14:26] <rick_h> hml:  manadart just for reference https://bugs.launchpad.net/juju/+bug/1785314
[14:26] <hml> manadart:  no code ref, i was looking at the DB
[14:26] <mup_> Bug #1785314: maas spaces are mis-translated <track> <juju:Incomplete> <MAAS:Incomplete> <MAAS 2.3:Incomplete> <MAAS 2.4:Incomplete> <https://launchpad.net/bugs/1785314>
[14:28] <hml> rick_h: is the “undefined” space the default or something?
[14:28] <hml> there can be only 1?
[14:28] <rick_h> hml:  yea, I think so. I have to refresh my brain
[14:28] <rick_h> hml:  +1 to there being only 1
[14:28] <rick_h> highlander space
[14:28] <hml> :-D
[14:29] <hml> rick_h: time to play queen
[14:29] <rick_h> wfm!
[14:33] <manadart> rick_h hml: I am leaning towards ignoring "undefined" when loading spaces and making the juju default space the unifying concept for the no/default/undefined/whocares space.
[18:36] <pmatulis> is not providing accurate information by default for the 'controllers' command really a good thing (need --refresh option to do that)? don't people always want to ensure they are getting accurate information?
[18:38] <rick_h> pmatulis:  the issue is that controllers pulls a list and that info doesn't change much so a cache is usually ok
[18:38] <rick_h> pmatulis:  otherwise calling each one (and timing out on ones you can't reach for say behind a vpn/etc) makes controllers risky to use
[18:41] <pmatulis> rick_h, if a client has a controller registered shouldn't we assume the client can reach it? anyway, implementing a short timeout doesn't seem too bad
[18:42] <pmatulis> anyway, i just upgraded a controller model and couldn't see the results. until i finally reached for the --refresh option. seemed like an odd UX moment is all
[18:44] <rick_h> pmatulis:  no, again because it could be over a vpn, on a user's laptop and they can only reach it on the work network, etc
[18:45] <rick_h> pmatulis:  yea, I wish we had a way to push from controller to clients like "you've just connected, I've got news for you"
[18:45] <rick_h> that would be a nicer way to handle stuff like that
[18:51] <pmatulis> rick_h, i see, ok