[10:10]  * evand sighs at livefs build failures
[10:13] <davmor2> evand: should wubi be working on unr and kne?
[10:14] <evand> davmor2: I think wubi is currently broken across the board
[10:14] <evand> issues with grub2, according to xivulon
[10:14] <evand> it should at least run though
[10:16] <davmor2> evand: unr only shows 2 options one of which wasn't install inside windows and kne didn't install when I tried it on alpha4 I think it was trying to find the cd and could but I could be wrong.  I installed xp on my netbook yesterday so I could try it out properly.  So I might take another look at it today
[10:17] <davmor2> first could should be couldn't
[10:17] <evand> yeah, we were working through that the other day
[10:17] <evand> it's a known issue
[10:17] <evand> apologies, I had forgotten about that
[10:18] <davmor2> evand: Ah okay cool.
[10:19] <davmor2> evand: I'm back under contract with canonical now so any time you have a build you'd like trying just fire me a request :)
[10:19] <evand> good deal
[10:19] <evand> will do
[11:34] <davmor2> shtylman: on the disk setup page you get the disc partition % and I'm assuming a number under it.  The number you only see maybe the top third of the digits is this something your working on or should I bug it?
[13:05] <shp> does anybody know how to uninstall a program installed from a .bin file?
[13:05] <shp> thanks in advance
[13:07] <shp> guys...have any idea?
[14:09] <CIA-33> ubiquity: mterry * r3387 trunk/ (debian/changelog ubiquity/frontend/gtk_ui.py): gtk: Remove separators from hand-crafted dialogs
[14:31] <evand> mterry: how goes the plugins branch?
[14:31] <mterry> evand, just synced it with trunk
[14:32] <mterry> evand, I've been off doing OEM stuff, but next step is to get the install/progress-bar bits working for plugins
[14:32] <evand> good deal
[14:32] <mterry> evand, is the plugin branch something that needs to go in before feature freeze?
[14:32] <evand> mterry: Steve's call to make.  I imagine so, unless you can beg an exception out of him :)
[14:33] <mterry> evand, yar.  Then, the urgency of a review increases
[14:34] <evand> okay, well just let me know when you're ready to merge into trunk and I'll take a look at it
[14:35] <mterry> evand, well.  So I won't be done-done with plugins by feature freeze.  But in terms of feature freeze, I just need to make sure the API is basically done?
[14:35] <mterry> The rest is just internal porting to the API, eh?
[14:36] <mterry> evand, the current branch as is, is ready to merge.  It's just not complete
[14:36] <evand> that would be my understanding, but I don't want to speak for how Steve will interpret such changes post-FF.  I image that is a suitable approach, but I would just run things by him to be sure.
[14:36] <evand> mterry: okay, I'll take a look at it today
[14:36] <mterry> evand, yar
[14:57] <mterry> evand, OK, Steve says both the public API bits and the internal porting to plugins are covered by FF
[14:58] <evand> okay, noted
[14:58] <mterry> evand, so my new plan is to finish up that last bit (installing/progress) in time and maybe one other fix for helping third parties.  I may not make it, given OEM demands
[14:58] <evand> okay
=== robbiew-away is now known as robbiew
[14:58] <evand> you can always apply for a FF exception once we hit FF, if you think that you need just a little more time
[15:15] <davmor2> evand: quick query on the ubiquity reboot dialog.  In xubuntu when you hit restart now it fails to do so,  is this going to be the way that xubuntu handles the reboot as Ubuntu does and they both seem to use gdm
[15:19] <evand> I think there's already an outstanding bug for this
[15:19]  * evand digs
[15:21] <evand> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/412825
[15:21] <ubottu> Ubuntu bug 412825 in upstart "Clicking reboot doesn't actually reboot the system" [Undecided,Invalid]
[15:29] <mterry> Hmm, evand.  Here's the strategy.  I put in some structural bugs in my plugins branch.  You approve the branch.  Post-FF I fix the bugs by completing the work.  No one has to know
[15:30] <evand> hahaha, sure
[16:36] <superm1> evand, did you have any ideas on that bug 412825? I tried following scott's suggestions and mastered an ISO with some debugging output in /etc/init.d/rc but couldn't seem to find out much more
[16:36] <ubottu> Launchpad bug 412825 in upstart "Clicking reboot doesn't actually reboot the system" [Undecided,Invalid] https://launchpad.net/bugs/412825
[17:17] <evand> hrm
[17:18] <evand> let me pull down an iso and see what I can come up with
[17:52] <evand> superm1: got it.  Pretty sure it's rsyslog
[17:52] <evand> If you install sysklogd the problem magically disappears
[17:52] <evand> not sure why it's not affecting the desktop CD though
[17:52] <evand> so perhaps I'm down the wrong path
[17:53] <superm1> evand, wow, that is quite crazyness
[17:53] <superm1> particularly because in only-ubiquity mode rsyslog is still used..
[17:57] <evand> hrm, actually, removing ubiquity allows a reboot as well, so it's deeper than that
[17:59] <evand> so yeah, any call to update-rc.d probably unwedges it
[18:02] <evand> hrm, nevermind
[18:02] <evand> I suddenly cannot reproduce the bug
[20:51] <vectra> I downloaded antivir_workstation-Pers.tar.gz and extracted it on HDD, but dont know haow to install.
[20:53] <CIA-33> ubiquity: mterry * r3352 plugins/ (12 files in 5 dirs): support running install code from plugins
[20:57]  * mterry is glad that the reboot thing isn't rsyslog's (and thus, indirectly, my) fault
[21:14] <superm1> mterry, what happened in rsyslog?
[21:15] <superm1> that was indirectly your fault possibly?
[21:15] <mterry> superm1, nothing, just that I owned the spec that made it the default syslog
[21:15] <superm1> mterry,
[21:15] <superm1> ah
[21:16] <superm1> well the next logical question, is there anything related to rsyslog that might be pulled in by standard desktop that's missing from xubuntu and mythbuntu?
[21:16] <superm1> or was it a flat out change the seed to pull rsyslog instead and call it a day?
[21:17] <mterry> superm1, basically yeah.  Ported some patches from old sysklogd to rsyslog, but that wouldn't affect this case I don't think
[21:17] <superm1> i know at least two or three weeks ago I noticed rsyslog wasn't workign properly, it basically got a HUP signal and anything after that didn't get logged
[21:17] <superm1> not sure if that plays into this at all though, and haven't looked if it's fixed yet
[21:18] <superm1> ah that's bug 407862 it looks like though
[21:18] <ubottu> Launchpad bug 407862 in rsyslog "[karmic] Messages not being sent to system logs" [Undecided,In progress] https://launchpad.net/bugs/407862
[21:19] <mterry> superm1, yeah, I have to update it to basically ignore HUPs.  But I'm waiting until I finish my FF-affected work before doing that purely bug-related fix.  :)
[21:20] <superm1> mterry, right.  well would anticipate there is any liklihood these two are related?
[21:20] <mterry> superm1, huh?  Let me read bug description above again.
[21:21] <superm1> if so, i suppose that would explain evand's empirical evidence that switching to sysklogd it was fixed
[21:22] <mterry> superm1, but he said same for ubiquity etc.  He posited that any update-rc change fixed it
[21:22] <superm1> oh
=== robbiew is now known as robbiew_away
[23:14] <evand> I'm really not sure where the problem lies.  In my testing if I tried to just sudo reboot straight away, it would reboot.  If I let ubiquity run its course and then pressed reboot in the dialog, it wouldn't, but then a sudo reboot in a terminal would work just fine.  Equally, I could have sworn it wasn't rebooting the first few times I tried sudo reboot from a terminal (though the second attempt always worked).
[23:15] <evand> I'll take another look at it tomorrow.