[04:31] <Amacidia> So I guess I'm already to start contributing, I have test drive installed and synced the latest version of raring.
[04:32] <Amacidia> Do I just work on Week 3 tests ?
[04:32] <Amacidia> Orca perhaps?
[04:53] <balloons> Amacidia, hello
[04:53] <Amacidia> Hi balloons
[04:53] <Amacidia> How are you?
[04:54] <balloons> not too bad.. About to shut down for the evening, but let me answer your questions quickly if I can
[04:54] <balloons> one of the was you can contribute is by writing/running tests..
[04:55] <Amacidia> Thanks balloons. I'm thinking of starting off by work on week 3 tasks as indicated by the schedule. Am I correct ?
[04:55] <balloons> Amacidia, yes, indeed go for it
[04:55] <Amacidia> I do some programming at work, however I don't work directly with python.
[04:55] <balloons> this is the close of the cadence week for week 3
[04:56] <balloons> Amacidia, ahh.. well, if your willing to give it a try, we can help.. the python isnt too bad
[04:57] <Amacidia> I can definitely look into this week for sure. I'm not sure if the classes being planned for this month cover writing tests do they?
[04:57] <balloons> anyways, hopefully the iso tracker makes sense to you.. I'm generally around 1400-2200 UTC so feel free to ping, or email
[04:57] <balloons> Amacidia, no, but we have hackfests
[04:58] <balloons> there are some planned for this month
[04:58] <balloons> it does cover this stuff :-)
[04:58] <Amacidia> Oh well that would be awesome
[04:58] <balloons> I don't have the dates handy, I think 3 are scheduled right now
[04:58] <balloons> it was sent to the list in an email
[04:58] <balloons> if you don't find the dates, just ask.. ;-_)
[04:58] <Amacidia> I didn't join the lists too long ago...
[04:59] <balloons> I'll be on my proper pc again tomorrow, so we can chat more then
[04:59] <balloons> its night for me here at least.. so good night!
[04:59] <Amacidia> Take care, nice chatting with you.
[04:59] <balloons> nice meeting you! happy testing!
[05:01] <pitti> Good morning
[05:06] <Amacidia> Hey pitti
[05:08] <Amacidia> I'm new to testing, so this might be a dumb question, but I'm looking at the daily iso tracker for raring and it doesn't seem like a lot of people have submitted test results, is that normal?
[05:11] <pitti> Amacidia: yes, it is; we have some intense testing around milestones and regularly over the cycle, but not every day
[05:12] <Amacidia> Thanks pitti, so would you say I'm wasting my time working on daily iso testing?
[05:12] <pitti> no, feedback on those is always welcome
[05:12] <pitti> we have some automatic tests to ensure that they install at all, but there are a lot of problems only humans can see
[05:13] <Amacidia> sounds good
[08:08] <jibel> Good morning
[12:10] <pitti> jibel: FYI, restarting ubiquity autopkgtest; that's supposed to work again, right?
[12:38] <jibel> pitti, thanks, it's back to normal
[13:35] <dkessel> hello :)
[13:36] <dkessel> has anybody got time to look at my file-roller autopilot branch ? it is not listed and executed by autopilot, and I can't find my mistake
[13:37] <dkessel> my branch is here: lp:~d-kessel/ubuntu-autopilot-tests/file-roller
[15:16] <zyga> roadmr: how are lp:ubuntu/$series/checkbox repositories related to the ubuntu source package for checkbox?
[15:17] <roadmr> zyga: awesome question
[15:18] <roadmr> zyga: I don't think there's anything that auto-packages the bzr branch and generates the package; from what I've read, uploaders are still required to build and dput the package in addition to uploading the branch
[15:18] <zyga> roadmr: so they are related in theory but in practice that's just smoke and mirrors?
[15:19] <zyga> roadmr: can we upload to lp:ubuntu/$whatever/checkbox ourselves?
[15:19] <roadmr> zyga: yes to the smoke and mirrors (if I understand the material correctly)
[15:19] <roadmr> zyga: and we should be able to upload there ourselves, yes
[15:21] <zyga> roadmr: ok
[15:21] <zyga> roadmr: that's pretty good actually
[15:22] <roadmr> zyga: yes, it'll be quite useful
[15:22] <roadmr> zyga: of course if we want to upload to non-development releases (i.e. SRU) we need to get approvals first anyway
[15:23] <zyga> roadmr: wait, how does that work?
[15:24] <zyga> roadmr: if there was a can_upload(package, repo) function, how would you specialize it for package=='checkbox'
[15:24] <roadmr> zyga: I *think* packages are held in some sort of queue and someone has to approve them moving to the actual archive
[15:25] <zyga> hmm
[15:25] <zyga> at all times?
[15:25] <zyga> or only during freezes?
[15:25] <roadmr> zyga: I'm not 100% sure really, I need to read up on it a bit
[15:26] <zyga> roadmr: ok, it would be good to get that understood
[15:26] <roadmr> zyga: for the development release, there's no queue/approval needed if there's no freeze
[15:26] <zyga> roadmr: and I'd like to get plainbox into ubuntu as well
[15:26] <roadmr> zyga: after ff, of course, all uploads need some sort of approval
[15:26] <zyga> roadmr: having plainbox in the archive would simplify some stuff for me
[15:31] <roadmr> zyga: yay, we can go the debian route but I'm sure there's a way to upload to ubuntu first/only, man, so much stuff to read and so little time..
[15:32] <zyga> roadmr: I'd rather just get it to ubuntu now
[15:32] <zyga> roadmr: then if needed push to debian
[15:32] <roadmr> zyga: makes sense
[15:36] <zyga> roadmr: I got access to the QA lab btw
[15:36] <roadmr> zyga: yay! I also got the vpn keys, haven't configured them though
[15:37] <zyga> roadmr: we should sync this week to understand how to use that stuff
[15:43] <zyga> spineau: did you have the time to look at https://code.launchpad.net/~zkrynicki/checkbox/zyga/+merge/141865
[15:44] <spineau> zyga: I've started. Need a closer look to the tests now
[15:44] <zyga> spineau: thanks
[15:45] <zyga> spineau: I'd like to get it landed to unblock the next branch which does a few big changes
[15:46] <spineau> zyga: I understand
[15:46] <zyga> spineau: also if there is anything that I can do to make such changes easier to review, tell me please
[15:52] <balloons> dkessel, I'll have a look
[16:04] <dkessel> balloons, thanks
[16:06] <dkessel> balloons, i will be back later
[16:06] <balloons> kk
[17:12] <zyga> https://code.launchpad.net/~zkrynicki/checkbox/zyga/+merge/142164
[17:16]  * zyga takes a look at all the merge requests
[17:17] <balloons> dkessel, hmm.. not sure what's going on with your tests
[17:17] <dkessel> that makes two then :)
[17:17] <balloons> ohh
[17:17] <balloons> lol , I see it
[17:18] <dkessel> btw it would seem logical to name tests by the executables or packages. which is not the case for terminal, for example
[17:19] <balloons> hmm.. yes, something to think about
[17:19] <balloons> what did we do for gnome-terminal?
[17:19] <balloons> ahh.. just terminal
[17:20] <balloons> ok, so kill the '-' in the name, then it works.. also you have some non-ascii quotes in there
[17:20] <balloons> '
[17:21] <balloons> dkessel, the reason is you can't have a dash in the python module name
[17:21] <dkessel> oh :) lol
[17:22] <balloons> yes, hence my lol when I saw it
[17:22] <balloons> I looked at your filename and it clicked
[17:22] <dkessel> meh :) but the folder naming would be ok?
[17:23] <balloons> it should align
[17:23] <balloons> so you should drop the dash there also..
[17:24] <balloons> you could leave it and it would work, but it would be confusing
[17:24] <balloons> and there goes your naming convention dkessel :-(
[17:24] <dkessel> yup....
[17:24] <balloons> underscores are allowed though
[17:24] <balloons> potentially you could use that instead
[17:24]  * zyga is unappy about https://code.launchpad.net/~sylvain-pineau/checkbox/bug1091633/+merge/141054
[17:25] <dkessel> i've never seen an underscore in a package name, so it might work to replace dashes with underscores.
[17:25] <balloons> I believe it should.. I'm not sure I'm a fan, heh
[17:25] <balloons> but yea, it should work
[17:26] <h01ger> underscore in package name will not work
[17:27] <balloons> h01ger, why do you say that? I did a quick change and it seems to recognize the module still
[17:28] <h01ger> because underscores in package names are forbidden by debian policy as they seperate the package name from the version
[17:30] <balloons> h01ger, ohh yes yes.. I was speaking about python module names
[17:30] <balloons> I think we crossed some terminology dkessel
[17:30] <h01ger> ah, ok
[17:30] <balloons> :-)
[17:33] <dkessel> so using underscores would enable automation of stuff - a script could replace underscores by dashes and then know which package is tested
[17:34]  * zyga looks at roadmr's patches
[17:36] <roadmr> :)
[17:37] <roadmr> thanx
[17:38] <balloons> dkessel, hmm.. we could look to have a 1 for 1 replacement
[17:38] <balloons> undersocre probably not a good idea as a character, as it's used validly for other things
[17:39] <dkessel> hmm ok - i'll wait before i commit my renames :)
[17:48] <dkessel> hmm python identifiers seem quite limited
[17:48] <dkessel> and *_* is a valid unrestricted identifier
[17:49] <dkessel> http://docs.python.org/2/reference/lexical_analysis.html#identifiers
[18:12]  * zyga is back from dinner
[18:15] <dkessel> is there an autopilot helper method to select a specific value in a combobox? if not, how would i do that given the item i want to select may not be at the same position in different program versions?
[18:18] <balloons> dkessel, I've been working with alesage and thomi on getting introspection and gtk apps going.
[18:18] <balloons> that I believe would be your solution
[18:18] <balloons> for the moment, you have to assume the positionj
[18:21] <zyga> roadmr: https://code.launchpad.net/~roadmr/checkbox/1084986-report-missing-dependencies/+merge/137702 commented but not marked as needs fixing as nothing here is really a deal-breaker
[18:21] <roadmr> zyga: let's see
[18:22] <roadmr> zyga: thanks! I'll fix all that stuff :)
[18:29] <zyga> roadmr: don't feel required to test everything I comment on
[18:29] <zyga> roadmr: I want to keep fluid coding possible
[18:29] <zyga> roadmr: only when you also agree that something is better otherwise
[18:30] <roadmr> zyga: the defaultdict suggestion looks good to me, what I'm doing is indeed kludgy
[18:30] <zyga> roadmr: looking at it just now, typically I add a space after # but PEP8 won't complain if you don't do that
[18:30] <roadmr> zyga: I didn't know += was that much slower, definitely good to change to join
[18:30] <zyga> roadmr: it's great to see the comments BTW, they make understanding the 'why' part much easier
[18:31] <roadmr> zyga: as for the formatting thing, I think it was for it to fit in 80-columns (otherwise pep8 tears me a new one) but I'll try to prettify it, and thanks for catching the lack of i18n
[18:31] <zyga> roadmr: yeah, += in a for loop is quadractic while the same "" join is not, basically python does not overallocate string buffers since strings are immutable
[18:32] <zyga> roadmr: yeah, I assumed as much, maybe you can put it ine a separate variable so that it's got more space
[18:32] <roadmr> zyga: oh that sounds good, that way I'm not constrained by the surrounding indentation
[19:54] <letozaf_> Hi guys!
[20:04] <Amacidia> hey leozaf
[20:05] <Amacidia> I'm new around here, submitted my first test result last night actually
[20:06] <dkessel> good evening
[20:09] <letozaf_> hello all
[20:10] <letozaf_> Amacidia, welcome, well I'm not a "guru" in testing but I can try to help you :)
[20:11] <letozaf_> dkessel, did you try autopilot?
[20:11] <dkessel> yup i did. i started with the file-roller test conversion. i have converted the first steps, but then i got stuck.
[20:12] <dkessel> now i know i used the wrong syntax :) don't use a '-' in a test file name :)
[20:12] <letozaf_> :)
[20:13] <letozaf_> so what do you think about it ?
[20:14] <dkessel> i think it is nice. but it need some polishing and extensions to be more useful.
[20:16] <dkessel> but they are working on it i heard
[20:21] <letozaf_> that's great news
[20:25] <Noskcaj> morning everyone
[20:26] <letozaf_> good morning (well in Italy it's night  :D  )
[20:26] <balloons> hello
[20:27] <letozaf_> hello balloons
[20:37] <balloons> hello, so let's see if thomi is about and see if he made any progress on the autopilot stuff we asked about :-)
[20:38] <thomi> Hi
[20:38] <thomi> I'm about
[20:38] <dkessel> hehe :)
[20:38] <balloons> Happy Tuesday!
[20:38] <thomi> Thanks :)
[20:38] <letozaf_> :D
[20:38] <thomi> we just decided a few minutes ago to add a new feature to ap, which should help you guys a lot. We'll add a new command, probabvly something like this:
[20:39] <thomi> 'autopilot launch gedit' -> will launch gedit with introspection enabled, so you can use 'autopilot vis' to look at it's internals.
[20:39] <dkessel> =)
[20:39] <Noskcaj> balloons knows its Tuesday, yay
[20:39] <thomi> regarding the gedit introspection, there was an issue with the autopilot-gtk package in raring, which I'm told has now been fixed
[20:39] <balloons> excellent.. so have you been able to get a successful example?
[20:40] <thomi> so I should be able to push that branch now...
[20:40] <balloons> :-)
[20:40] <thomi> alesage: do you have your gedit example handy?
[20:40] <balloons> Noskcaj, lol.. yes, Tuesday and summer
[20:40] <balloons> I can be taught
[20:40] <Noskcaj> :)
[20:40] <alesage> hi thomi, yes you can find it at lp:~allanlesage/+junk/UDS_AP_session
[20:42] <zyga> roadmr: as for UEFI, I'll make a small efi image for netboot testing tomorrow, do you think we could try spending a few hours on pair programming?
[20:43] <roadmr> zyga: sure!
[20:43] <roadmr> zyga: I didn't get anything uefi-related done today :/ so tomorrow we can certainly work for that
[20:44] <zyga> roadmr: have a look at that email I've sent on tuesday last week please
[20:44] <zyga> roadmr: the one with a few links to the wiki on how to get this up
[20:44] <zyga> roadmr: I'd like to try that on a real machine
[20:44] <roadmr> uefi + netboot notes
[20:44] <zyga> roadmr: ok, till tomorrow then :)
[20:45] <zyga> roadmr: if you can look at the rather big MP, feel free: https://code.launchpad.net/~zkrynicki/checkbox/zyga/+merge/142164
[20:45] <zyga> roadmr: no need to review it entirely, just post your notes
[20:45] <zyga> roadmr: most of the diff is code motion
[20:45] <thomi> balloons: this is what you want: http://bazaar.launchpad.net/~allanlesage/+junk/UDS_AP_session/view/head:/tests/test_gedit.py
[20:45] <roadmr> zyga: excellent, I'll have a look
[20:46] <thomi> balloons: the two key things are: 1 - derive from GtkIntrospectionTestMixin and 2 - use self.launch_test_application(...)
[20:51] <roadmr> zyga: for pxe netboot, we usually extract the iso and then patch the initrd on the fly. As I understand it, for UEFI we'd have to then reassemble the ISO with the initrd hacks, right?
[20:51] <balloons> hmm
[20:51] <balloons> doesn't seem to blow up
[20:52] <roadmr> zyga: just some preliminary asking around, I'd have to review the initrd patches we apply, they may be unnecessary if a full iso (rather than nfs) is used
[20:53] <zyga> roadmr: I honestly don't know
[20:53] <zyga> roadmr: the way we boot today, we netboot the old-school installer, right
[20:54] <roadmr> zyga: yep
[20:54] <zyga> roadmr: but I really don't even know how that works, I understand how we pxe boot the kernel but what is after that is a mystery to me really
[20:54] <roadmr> zyga: we also need a way to load our custom preseed
[20:54] <zyga> roadmr: I could try to mimick that locally but raring still has no driver for my new laptop's eth
[20:55] <roadmr> zyga: actually feel free to ignore me, I may be talking out of my ass since I haven't read the uefi page fully
[20:55] <zyga> roadmr: preseeds are a part of the installer but how do we get there is something I don't yet understand
[20:55] <zyga> roadmr: I think you are right in describing what works now
[20:55] <zyga> roadmr: how efi affects that is unsure
[20:55] <zyga> roadmr: from what I read efi netbooting is very primitive with free tools so far
[20:55] <roadmr> zyga: I imagine something like building a custom iso with our preseed, but an alternative would be passing a kernel parameter, which may be easier than doing the meccano thing with isos
[20:55] <balloons> cool stuff
[20:55] <zyga> roadmr: and grub 2 has none of it
[20:56] <zyga> roadmr: so grub somehow gets mixed with a mini iso
[20:56] <balloons> ok, so things are working ;-) now just have to talk about using autopilot vis and looking at your dbus session
[20:56] <balloons> dkessel, you still about?
[20:56] <zyga> roadmr: so that a few stacks of tools get to a point where you basically do what you did in bios (after booting)
[20:56] <dkessel> yes balloons
[20:56] <roadmr> zyga: well last time I tried any form of uefi netbooting, I didn't get past the mini iso thing (felt too kludgy back then)
[20:57] <zyga> roadmr: native-aware boot would be better but is not implemented by grub, efilinux (IIRC) has some code for that but it's still far cry from working
[20:57] <roadmr> zyga: since it now seems to be the recommended way, I guess we will have to do it that way :)
[20:57] <zyga> roadmr: we should ping cjwatson to know if there's some movement there
[20:57] <balloons> so, want to try doing some introspection on fileroller?
[20:57] <balloons> you needed it for something yes>
[20:57] <zyga> roadmr: yeah, unless there's a more "native" solution that's what was recommended last time I've checked
[20:57] <roadmr> zyga: yep. It's not even that late so I may have time to do a bit of experimentation today
[20:57] <zyga> roadmr: ok, I'll take a break now
[20:57] <dkessel> i wanted to manipulate a combobox, yes
[20:58] <zyga> roadmr: I'll talk to you tomorrow :)
[20:58] <roadmr> zyga: enjoy, we can continue this tomorrow
[20:58] <zyga> roadmr: have a good evening :)
[20:58] <dkessel> is a new autopilot version up?
[20:58] <roadmr> zyga: enjoy your rosca :)
[21:00] <balloons> alesage, the fix is also in the ppa right?
[21:00] <balloons> If I remember your not on raring dkessel
[21:00] <alesage> balloons, correct--please ping if you find different :)
[21:00] <dkessel> balloons, i have setup a quantal vm
[21:03] <dkessel> alesage, autopilot-gtk_0.1-0ubuntu0 is the old version, right?
[21:04] <balloons> apt-cache show libautopilot-gtk0
[21:04] <alesage> dkessel, yes--
[21:04] <balloons> I have Version: 0.4-0ubuntu1+bzr14pkg0raring1
[21:04] <alesage> dkessel, install libautopilot-gtk-dev
[21:04] <dkessel> got that
[21:04] <alesage> and actually dkessel you may want to remove autopilot-gtk_0.1bla
[21:05] <alesage> as it's from before a renaming
[21:05] <dkessel> oh ok
[21:07] <dkessel> bug: autopilot is missing --version ;)
[21:07] <dkessel> ok got the same version as balloons now
[21:09] <balloons> :-)
[21:11] <dkessel> now how do i run file-roller with introspection?
[21:12] <balloons> ok, so autopilot has this tool called autopilot vis
[21:12] <dkessel> yeah, i tried that
[21:12] <thomi> dkessel: very soon you'll be able to do 'autopilot launch file-roller'
[21:12] <balloons> you can try running it now.. by default, you'll see unity as a connection
[21:13] <thomi> dkessel: right now you need this:
[21:13] <thomi> alesage: I forgot what the env variable is... remind us please?
[21:14] <balloons> thomi types faster than me ;-)
[21:14] <alesage> thomi GTK_MODULES=autopilot-gtk:$GTK_MODULES file-roller, I believe
[21:14] <alesage> dkessel ^^
[21:14]  * dkessel tries
[21:15] <dkessel> alesage, aaah :) and there is a new "Root" connection
[21:16] <alesage> dkessel, and a pile of GTK+ widgets underneath :)
[21:16] <thomi> dkessel: yeah, that's the one
[21:16] <balloons> all sorts of stuff
[21:16]  * dkessel spends the next day poking around in gtk stuff :)
[21:16] <thomi> dkessel: please let us know if you find problems
[21:17]  * thomi writes 'autopilot launch' now
[21:17] <thomi> shouldn't take too long
[21:18] <dkessel> hmm - hard to identify a program. both name and title of the gtkwindows are empty ?
[21:19] <thomi> dkessel: Gtk seems to create a lot of garbage in it's widget tree
[21:19] <thomi> dkessel: the bits you're looking for will be in there somewhere
[21:19] <alesage> dkessel, it takes some digging
[21:19] <dkessel> ok
[21:19] <thomi> but it's a lot less clean that a Qt app for sure
[21:20] <thomi> the standard practise is to write a class called an 'emulator' that retrieves the useful bits from the introspection tree for your tests
[21:21] <balloons> you have some unity emulators in this way
[21:21] <balloons> but it would be good to get some gtk examples.. so we can work on that know
[21:22] <balloons> thomi, actually does it make sense to have emuators for us?
[21:22] <balloons> would we be able to avoid writing one for each app?
[21:23] <thomi> balloons: it makes sense to have functions that get commonly used components.... so if the component chsanges it's position in the introspection tree you don't need to update all your tests
[21:23] <thomi> 'emulator' is a terrible term for non-unity tests I realise
[21:24] <thomi> so yeah, I think it makes sense
[21:33] <dkessel> ok, it is a start. i have the dialog and i have identified some of the components in it. however, for the test, i guess the "id" attribute values are generated at runtime? so i would have to guess and write some code like "get the first combobox in this dialog and select entry xyz in there"
[21:37] <thomi> dkessel: alesage: the way to do this is to find something unique to that widget. If the app is well written, you can say "select the ComboBox with the name 'someUniqueName'"
[21:38] <balloons> dkessel, Im also having a look around
[21:38] <thomi> if that's not possible, you may need to get a bit more creative - select the dialog box, then iterate over it's children or something similar
[21:38] <thomi> pro tip: autopilot's select_single, select_many and get_children_by_type are all very powerful - you can specify several filters...
[21:38] <dkessel> thomi, balloons : i guess the real thing would be submitting patches upstream to get some real names in there...
[21:38] <thomi> for example:
[21:39] <thomi> combo_box_widget = app.select_single('ComboBox', name='foobar', someOtherProperty=123)
[21:39] <alesage> dkessel is this bug relevant? https://bugs.launchpad.net/autopilot-gtk/+bug/1082391
[21:39] <thomi> the first parameter is the type name. The other parameters are filters to apply to the selection
[21:40] <thomi> I guess having the widget ids visible would certainly help
[21:41] <thomi> alesage: did ted come back to you with anything useful WRT that?
[21:41] <alesage> thomi yes I got a brief intro, we'd have to decide how to expose 'em
[21:41] <dkessel> yes, alesage - i guess that "affects me" ;)
[21:42] <thomi> alesage: easy to do?
[21:42] <alesage> thomi unknown, I'll have to review :/
[21:43] <alesage> thomi will study for AWG and discuss then?
[21:44] <balloons> a search would be helpful :-)
[21:45] <thomi> balloons: in the vis tool?
[21:46] <balloons> yea, that would work around the annoying widget spam
[21:46] <balloons> in the interim
[21:47] <dkessel> hm autopilot -h says: "Opens visualisation in xdot when not passed an output path to write file to. is it still possible to dump the entire tree to a file?
[21:47] <dkessel> oops... missing " after "to."
[21:48] <thomi> dkessel: oops, that's a bug
[21:48] <thomi> dkessel: we haven't used xdot for a while, I'll clean up the help string
[21:49] <dkessel> ok :)
[21:49] <dkessel> i don't like dot files anyway
[21:49] <thomi> graphvis can't handle trees of that size anyway
[21:49] <thomi> ...which is why we stopped using it
[21:50] <dkessel> yup - it crashed when i handled it a graph of our producation software once too....
[21:51] <dkessel> thanks for your work so far guys!
[22:16] <dkessel> ...and i'm off
[22:58] <balloons> bah.. I cannot find the popup in the tree ;-(
[22:59] <balloons> any thoughts on finding a pop-up window.. in this case, the gedit prefs window?
[23:01] <balloons> I'm guessing it's a child somewhere.. hmm
[23:13] <balloons> sadface.. I simply can't find it..
[23:16] <alesage> balloons, yeah this can be quite frustrating :(
[23:16] <balloons> I thought I had it.. maybe spawning under the gtkmenu tree.. but nope
[23:19] <alesage> balloons beware having to 'refresh' the autopilot vis tree--thomi sez it's possible to do so by clicking on a root node, then the child nodes are refreshed
[23:20] <alesage> balloons, if you're looking at a modal dialog then it's probably all the way up the tree
[23:20] <balloons> alesage, ok.. not sure what you mean
[23:20] <thomi> that's another feature we need. balloons if you file a bug I'll try and get around to doing it...
[23:20] <balloons> I have to click the top level root node perhaps
[23:20] <balloons> thomi, a search you mean? It would make this much easier
[23:20] <balloons> and I could ignore the nonsense spawning
[23:21] <thomi> balloons: both a search function, and a way to explicitly refresh the tree
[23:21] <balloons> alesage, lol.. I'm not going to look through it again, but I'm noting it
[23:21] <balloons> thomi, ok, let me file request
[23:22] <balloons> I'll go through it again tomorrow
[23:22] <balloons> I want to see if what I've got works without that
[23:26] <balloons> AttributeError: 'BamfWindow' object has no attribute 'select_single'
[23:27] <balloons> alright.. good night all.. good stuff, glad this is working now..
[23:27] <balloons> have to parse through it a bit, and the enhancements your making will clean this up nicely
[23:27] <balloons> thanks again