[11:02] <CIA-19> ubiquity: cjwatson * r2082 ubiquity/ (5 files in 3 dirs):
[11:02] <CIA-19> ubiquity: * Drop into pdb.post_mortem on non-SyntaxError exceptions if the --pdb
[11:02] <CIA-19> ubiquity:  option is given and ubiquity is running from a terminal.
[03:03] <jetsaredim> cjwatson: ping
[03:12] <evand> neat
[03:14] <jetsaredim> ?
[03:14] <evand> changes to ubiquity
[03:15] <cjwatson> jetsaredim: sorry, today's really hectic for me
[03:15] <jetsaredim> np
[03:16] <jetsaredim> just wondering if you gave any thought to the possibility of the mythbuntu stuff ever getting back into the main ubiquity tree
[03:16] <jetsaredim> after its fully reviewed and all that
[03:16] <jetsaredim> of coarse
[03:17] <cjwatson> if it's specific to mythtv, I think I would prefer that it remained separate until such time as ubiquity is much better prepared for plugins
[03:18] <jetsaredim> i was thinking of modeling after m-a
[03:18] <evand> I had explained to jetsaredim that you were waiting for the code to be more accepting extensions, but he wanted some clarification if that was on the horizon and what that entailed, as he brought up the idea of adding a --no-mythtv option
[03:18] <evand> to extensions*
[03:18] <jetsaredim> actually I was thinking more along the lines of an option to _enable_ myth
[03:19] <jetsaredim> and by default it would be off
[03:19] <evand> ah, my mistake
[03:19] <jetsaredim> we only talked about it for like 2 seconds
[03:19] <evand> indeed
[03:20] <jetsaredim> i suppose it doesn't make a difference either way - as long as its turn-off-able
[03:20] <cjwatson> jetsaredim: I think the UI changes are too difficult for us to maintain in the three at this point
[03:20] <jetsaredim> ;)
[03:20] <cjwatson> in the tree, I mean
[03:20] <cjwatson> m-a was acceptable because it was going to be on by default and thus tested
[03:20] <jetsaredim> ah
[03:21] <jetsaredim> good point
[03:22] <jetsaredim> so there's no point in bothering to put in the option
[03:25] <cjwatson> honestly, I think at the moment it will actually be easier for you guys to maintain it out of tree, as you'll be able to commit directly without fear of breaking the core
[03:26] <cjwatson> since right now the changes required to add extra pages are pretty intrusive
[03:27] <CIA-19> ubiquity: cjwatson * r2083 ubiquity/ (bin/ubiquity debian/changelog):
[03:27] <CIA-19> ubiquity: * Work around hang on PS3 by stopping various non-essential processes
[03:27] <CIA-19> ubiquity:  first (LP: #106683).
[03:27] <cjwatson> ^-- horrible
[03:27] <cjwatson> evand: re pdb, thanks for the idea :)
[03:27] <evand> cjwatson: re commit, thanks for making life easier on me :)
[03:35] <jetsaredim> cjwatson: we noticed
[03:35] <jetsaredim> its already pretty much working
[03:36] <jetsaredim> its mostly in the glade file since we added like 6 pages
[03:36] <jetsaredim> and there's a bunch of logic in gtkui
[03:36] <jetsaredim> but other than that its mostly a d-i script
[03:49] <CIA-19> ubiquity: cjwatson * r2084 ubiquity/bin/ubiquity: update bug number in comment
[03:56] <jetsaredim> any idea when ubiquity will be at a point where this integration would be possible
[03:56] <jetsaredim> i'm just dreading having to do merges on every ubiquity change
[08:23] <cr3> the installation-guide-i386 package in gutsy still refers to feisty. I tried to report a bug for the installation-guide project in launchpad but it says that bugs are being tracked upstream. is that right or should I be reporting a bug against another project?
[09:59] <cjwatson> don't worry, it's due for an update
[09:59] <cjwatson> it hasn't been merged yet
[09:59] <cjwatson> in any case, you don't report bugs about packages in Ubuntu against projects, you report them against source packages in Ubuntu ...
[11:17] <cjwatson> evand: any luck with bug 118967?
[11:18] <cjwatson> evand: it's worth noting that syslog messages vs. sys.stderr writes of the tracebacks might be out of order, so be careful about drawing inferences from that
[11:19] <evand> no luck yet, but I will keep that in mind
[11:19] <evand> I'll keep you posted on my progress
[11:19] <cjwatson> cool
[11:20] <cjwatson> could easily be just due to the excision of the old partitioner
[11:20] <cjwatson> and the complicated merge of partman_auto into partman
[11:21] <evand> hrm
[11:24] <cjwatson> (i.e. my foul-up)
[11:25] <evand> well, way to go cjwatson :)
[11:26] <cjwatson> hmm, it's also possible it's a change in qt
[11:27] <cjwatson> I note that the KDE frontend does .setModel() before populating the model
[11:27] <cjwatson> wonder if moving the .setModel() down to the end after population would fix it
[11:28] <cjwatson> I don't know what's calling PartitionTreeModel.index, but from the lack of traceback beyond that it must be something inside qt
[11:32] <cjwatson> I've resorted to reading Qt source in the past
[11:33] <evand> by the way, I agree with you on the odd nature of the pyqt bindings.
[11:33] <cjwatson> if you can reproduce it, it might be worth moving the traceback dumps to syslog temporarily to get better ordering
[11:34] <cjwatson> it's the seemingly random argument order that upsets me most, I think :)
[11:35] <evand> curious...now I can't reproduce the bug
[11:36] <cjwatson> but you could earlier?
[11:36] <cjwatson> could be racy ...
[11:36] <evand> oh, I'm working on a different VM
[11:36] <evand> as the other one was tied up in ubiquity-automation poking
[11:37] <evand> the only difference would be the partition table, afaik
[11:37] <evand> but I suppose that's enough :)
[11:37] <cjwatson> my first thought was that it might happen with blank partition tables, but that doesn't seem to be the case here
[11:37] <evand> it did for me
[11:37] <evand> when I tried a blank table
[11:37] <evand> lets see
[11:39] <evand> hrmm, nope, now it doesn't (still a different vm though)
[11:39] <cjwatson> it would be nice to know what the index being passed in is
[11:39] <cjwatson> whether it's zero or small-int or random-junk
[11:41] <evand> oh, I stand corrected.  It may be triggering it after all
[11:42] <evand> heh, sorry about that