[12:08] <mirkobuholzer> has some one testet the noui with feisty? I get the import error: no module named backend.part
[12:14] <cjwatson> Elwell: installation-guide
[12:14] <cjwatson> mirkobuholzer: noui is broken and removed from gutsy
[12:14] <cjwatson> mirkobuholzer: evand is working on a replacement, but you won't find anything that works in feisty
[12:15] <cjwatson> superm1: page navigation is still pretty nasty, but I guess we can tolerate that
[12:19] <superm1> cjwatson, ok.  I was thinking of just making a "derivative" directory at the top level of the package, with a "mythbuntu" directory within it.  That way any other groups that will want to do similar projects can use what we do as an example, and our work stays in its own area not to interfere with the regular ubiquity work
[12:20] <superm1> then in debian/control make another binary package that will include all of our things and depend on yours.  in our binary package have a binary produced called say ubiquity-mythbuntu which performs similar to the regular ubiquity binary
[12:20] <superm1> except that it will call things via our derived classes instead
[12:39] <mirkobuholzer> superm1, this would be great. I am planning to do some enhancements to so your concept could be applied as well ...
[12:39] <superm1> mirkobuholzer, atm our patch is very messy and invasive.  i should have a cleaner one within a few days that won't touch anything but that derivative/ directory and the debian/ directory hopefully :)
[12:48] <cjwatson> superm1: hmm, I think it might be clearer if it were in the normal locations with just clearly named files
[12:49] <cjwatson> I don't see how it would interfere any more than the way we would already be taking on the responsibility of updating it across major changes already does
[12:49] <cjwatson> if a derivative isn't easy to maintain, it should absolutely be a branch and there's no way we should be maintaining it in core
[12:49] <cjwatson> if it's easy to maintain, hiding it in a separate directory is only likely to make it harder
[12:51] <cjwatson> I think the right answer instead of a separate ubiquity-mythbuntu script is just 'ubiquity mythbuntu' or whatever you're calling the frontend
[12:51] <superm1> Ok.
[01:13] <cjwatson> evand: sftp://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/
[01:14] <evand> thanks!
[01:15] <superm1> evand, I saw that you merged in my changes this morning.  thanks :)
[01:16] <evand> superm1: thank you for taking care oft hat
[01:16] <cjwatson> evand: want to go ahead and merge in the modularisation stuff there?
[01:16] <cjwatson> it looks fine to me
[01:17] <evand> cjwatson: will do
[01:18] <cjwatson> I might move both the glade and qt-designer files to subdirectories at some point, but no rush
[01:20] <cjwatson> remember to do the cia setup thing for the new branch
[01:22] <superm1> cjwatson, is the entire ubiquity branch going to stay maintained on that URL rather than the core-dev one?
[01:22] <evand> ok
[01:22] <superm1> s/URL/bzr branch/
[01:23] <evand> superm1: it will still be synchronized with the old one, but yes
[01:23] <superm1> Ok.  i'll track that then to keep up with changes
[01:48] <CIA-19> ubiquity: evand * r2091 ubiquity/ (12 files in 2 dirs): Merged Mario's glade modularization changes from the ma branch.
[01:48] <evand> success!
[07:40] <jetsaredim> anyone know if the installer is broke in gutsy?
[07:43] <evand> define broken
[07:46] <btm_> hehe
[07:52] <jetsaredim> seg fault
[07:52] <evand> gah, please file a bug
[07:53] <jetsaredim> just trying to figure out if its something i/we did
[09:05] <superm1> evand, I caught what is happening to jetsaredim.  some bug with new glib memory allocation is hitting a lot of apps (thunderbird, vlc, and a few others)
[09:05] <superm1> the workaround is to run apps like this:
[09:05] <superm1> G_SLICE=always-malloc ubiquity
[10:25] <cjwatson_> superm1: I'm not sure about permanently, but at least until Evan gets into ubuntu-core-dev; it's mostly for his benefit at the moment
[10:25] <cjwatson_> beyond that, we'll see if it's relevant to anyone else :)
[10:26] <cjwatson_> gslice> I assume that's got to be a bug at a lower level; ubiquity wouldn't be capable of triggering that sort of bug even if it wanted to, I expect
[11:02] <CIA-19> ubiquity: cjwatson * r2092 ubiquity/ubiquity/frontend/gtk-ui.py: spacing nits
[11:04] <cjwatson> jetsaredim: bug 116870, but that's supposedly just an additional warning, so it's not clear that the crash is due to that
[11:08] <cjwatson> and, err, I didn't think ubiquity was threaded ;-)
[11:10] <cjwatson> jetsaredim: I would like to know where the crash happens
[11:16] <cjwatson> jetsaredim: does adding 'gobject.threads_init()' near the top of gtk-ui.__init__ help?
[11:19] <cjwatson> (see #ubuntu-devel, that may not be the right answer)
[11:27] <blackskad> cjwatson: I created a diff of the changes I made to fix bug #45690, but could you review them before I attach them to the bugreport?
[11:27] <blackskad> the diff is at http://pastebin.ubuntu-nl.org/25673/
[11:40] <Elwell> slightly OT - which is the best IRC channel for ubuntu server xen questions?
[11:48] <cjwatson> blackskad: also remove ubiquity/imported/quit from debian/ubiquity.templates-imported (leave ubiquity/imported/cancel there, as the gtk-cancel stock item is used elsewhere) and 'quit' from the list of stock items in translate_widgets; and I think you need to add warning_dialog_continue and warning_dialog_abort to ubiquity/i18n.py rather than just deleting cancelbutton and exitbutton
[11:48] <cjwatson> rest looks good to me
[11:48] <cjwatson> Elwell: if it's primarily about Xen, possibly #ubuntu-kernel
[11:48] <blackskad> ok, thank you, I'll change it
[11:48] <cjwatson> #ubuntu-server exists too I believe
[11:49] <Elwell> ta
[12:01] <CIA-19> ubiquity: cjwatson * r2093 ubiquity/ (debian/changelog scripts/install.py): * Save /var/log/casper.log to installed system (LP: #119993).
[12:28] <blackskad> cjwatson: I addressed your comments and attached the diff to the bugreport
[12:30] <cjwatson> thanks
[03:52] <jetsaredim> what's the default password for the ubuntu user?
[03:52] <cjwatson> unset
[03:52] <cjwatson> I tell a lie; blank
[03:52] <cjwatson> (not quite the same thing)
[03:52] <superm1> cjwatson, regarding the change that renamed gtkui.py to gtk-ui.py within the last few revisions, it appears that it's fairly difficult to import from gtk-ui.py and then base a class on it.  The __import__() function has to be used (because of the -), but i'm not sure how to base a class on this after imported.  MythbuntuWizard(ubiquity.frontend.gtk-ui.Wizard) doesn't appear to be possible
[04:01] <cjwatson> superm1: __import__ returns a module object so you can use getattr(mod, Wizard) on that and assign the result to a more convenient local name
[04:02] <cjwatson> but maybe gtk-ui and kde-ui should be renamed again
[04:02] <cjwatson> I wish Python's module system were slightly better designed :-/
[04:02] <superm1> i was poking in #python yesterday and they were saying the correct solution is to just rename the gtk-ui (and consequently kde-ui) since python is more friendly to names without dashes
[04:03] <superm1> but atm thats a solution .  Didn't realize __import__ actually returned something
[04:07] <cjwatson> superm1: the problem is that kdeui is (or used to be) another module we used and the names clashed
[04:07] <superm1> perhaps use kde_ui
[04:08] <superm1> and gtk_ui
[04:08] <cjwatson> and we use the gtk module too, and I wanted to name the frontends consistently
[04:08] <cjwatson> maybe
[04:08] <cjwatson> I have a phone call to make now, but will think about it later
[04:08] <superm1> okay sounds good ttyl