[06:03] <pitti> Good morning
[06:03] <pitti> thomi: still online? got a few mins to discuss autopilot property notifications?
[06:03] <thomi> pitti: yes, and yes :)
[06:04] <pitti> thomi: still remember, I signed up for investigating whether we can have some textual "property change monitor" in AP so that you can immediately see which properties change when you do stuff
[06:04] <thomi> yup
[06:05] <pitti> thomi: I have a PoC in https://code.launchpad.net/~pitti/autopilot-gtk/property-monitor/ which just statically turns this on at startup, and it's working very well
[06:05] <pitti> I haven't tested it with 10.000 widgets yet, want to measure the overhead; although that's hardly relevant
[06:05] <pitti> in a real case, I suppose you want to temporarily enable it for some window or even widget group only
[06:05] <thomi> pitti: can you create a MP that's WIP so I can get an easy diff? I'm so lazy...
[06:05] <pitti> as otherwise there are a lot of changes
[06:05] <pitti> thomi: nah, too early
[06:06] <thomi> heh, ok
[06:06] <pitti> thomi: so, for GTK it works in general
[06:06] <pitti> thomi: I also investigated Qt, and there it won't
[06:06] <pitti> there is no general "property change" signal; properties can specify a signal when they change, but most don't
[06:06] <thomi> oh :(
[06:06] <thomi> hmmmm
[06:06] <thomi> that surprises me
[06:06] <pitti> and we of course can't poll each widget and each property 10 times a second
[06:07] <pitti> they are implemented differently in Qt
[06:07] <pitti> in GObject it's all dynamic, more or less a hashmap and a defined interface (g_set_property, etc.)
[06:07] <pitti> in Qt it's baked into the class, moc seems to turn property access into direct object member changing
[06:08] <pitti> and just seems to wire the explicitly specified signals around them
[06:08] <pitti> so, that's much faster of course, but prevents us from doing things like that
[06:08] <pitti> thomi: so that's the status of the investigation
[06:09] <pitti> thomi: now, my question is how to expose that to/in AP; right now the PoC doesn't change any API
[06:09] <thomi> so... QMetaProperty::notifySignal doesn't exist for most properties?
[06:09] <pitti> correct, I checked
[06:09] <thomi> :(
[06:09] <pitti> thomi: added a summary to https://blueprints.launchpad.net/ubuntu/+spec/community-t-testing-technologies
[06:09] <pitti> "only 81 out of the 626 defined widget properties have notifiers, and *none* of QWidget's properties have them, so it's not worth the effort; you would miss almost all of the interesting ones."
[06:10] <thomi> ugh
[06:10] <pitti> thomi: so I guess for Qt we need to think about alternatives
[06:10] <pitti> thomi: but quite frankly, for Qt my personal experience is that it's not that hard to see which property changed, but which widget I'm talking to
[06:11] <pitti> if you have widget object names, all is well, but if you don't, then clicking through vis is a pain
[06:11] <pitti> thomi: so for Qt I think the next best thing is to implement search
[06:11] <thomi> I guess at least search would work for both UI toolkits
[06:11] <pitti> i. e. search for a string you see in the UI, that should lead you to the corresponding widget
[06:12] <pitti> yes; it's expensive as you have to traverse the whole widget tree, but that's fine of course
[06:12] <pitti> right now you have to manually traverse it, which is much more expensive (human-wise) :)
[06:12] <pitti> thomi: so, for the prop mon, my current idea is:
[06:13] <pitti> add a "MonitorProperties" method to the D-BUS interface with a boolean (on/off)
[06:13] <pitti> which would enable/disable the prop monitoring for that widget and all its current and future children
[06:13] <pitti> then in AP we have to add a method call around that, which checks whether that D-BUS method exists and fails with some "not supported" error if it doesn't
[06:14] <pitti> or we add that to -qt as well and make it return a D-BUS error; but that would tightly bind the backend and AP versions together, so I think AP needs to get along with the method not existing either way
[06:15] <thomi> we already expose qt-only extensions, I think we can follow the same pattern for gtk-only extensions
[06:16] <thomi> but yeah.. that plan sounds OK. I'd like to see support for it in vis as well, because I suspect that's going to be more useful
[06:16] <pitti> thomi: oh, you mean not just sending the log to stdout, but over D-BUS and show it in vis?
[06:17] <thomi> indeed
[06:17] <pitti> thomi: ok, that sounds like another argument then; often stdout is just what you want, much easier to grep and copy&paste from
[06:17] <pitti> method call argument, I mean
[06:19] <thomi> right, but 1) what happens when the app you're running is on the phone, and you're on a laptop, and 2) what will you be copy/pasting? Seems like having the widgets show up in vis is going to be a more useful way to get data to your test. finally, i'd rather improve vis as the tool of choice for inspecting apps running under introspection than introduce a second tool
[06:20] <pitti> thomi: MonitorProperties(u) with 0 = off, 1 = stdout, 2 = dbus?
[06:20] <pitti> thomi: oh, it's not a second tool, it's the launched app itself which prints it (it's in libap-{qt,gtk}.so)
[06:21] <pitti> thomi: it's much harder to run viz on a phone than to watch stdout..
[06:21] <pitti> vis needs to go through X forwarding on your desktop
[06:21] <thomi> vis would run on your laptop, I'd imagine
[06:21] <pitti> thomi: you'd grep for property values or widget names, and copy&paste widget paths mostly (or complicated values maybe)
[06:22] <pitti> thomi: right
[06:22] <pitti> thomi: I'm not against sending it to vis, to the contrary; but I'd also like a simple stdout monitor
[06:22] <thomi> yeah, ok
[06:23] <pitti> so vis would call MonitorProperties(2), or MonitorProperties("signal"), and some other method in AP to enable to stdout would call (1) or ("stdout")
[06:23] <pitti> enum vs. string, no strong preference
[06:24] <thomi> string would be my mild preference
[06:24] <pitti> *nod*
[06:27] <pitti> thomi: ok, thanks; I'll keep this as a side project (I guess it's not that urgent)
[07:52] <jibel> Good morning
[08:18] <pitti> jibel: can you reach d-jenkins.ubuntu-ci:808 ?
[08:19] <pitti> ..."0"
[08:19] <pitti> jibel: it worked this morning, but seems to have went AWOL about half an hour ago
[08:19] <jibel> pitti, I was 20min ago
[08:19] <jibel> let me check
[08:20] <jibel> pitti, if works.
[08:20] <jibel> s/if/it
[08:20] <pitti> hm; /me restarts openvpn
[08:21] <pitti> still no luck
[08:24] <jibel> pitti, can you resolve its name? is 10.98 in the routes when the vpn is up? can you ssh to it or another host in the lab?
[08:24] <pitti> $ host d-jenkins.ubuntu-ci
[08:24] <pitti> d-jenkins.ubuntu-ci has address 10.98.3.6
[08:25]  * pitti updates his old IPs in .ssh/config
[08:26] <pitti> jibel: I can ssh to alderamin, yes
[08:26] <jibel> pitti, only tachash is unreachable?
[08:26] <pitti> jibel: I meant, can you reach http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-python3.3 ?
[08:26] <jibel> pitti, yes, amd64 failed
[08:26] <pitti> jibel: whatever tachash is, it pings
[08:27] <pitti> jibel: I get a "connection was reset" error in firefox
[08:27] <jibel> tachash = d-jenkins
[08:28] <pitti> jibel: WTH, it works with wget, but not with firefox
[08:28] <pitti> ... and now it works again in ffox, too
[08:28] <pitti> NFC
[08:28] <pitti> anyway, thanks!
[08:28] <jibel> pitti, yw, new lab's magic
[08:32] <jibel> and apparently network is still terribly slow
[08:55] <sigurd> Hi, im writing for a norwegian technincal magazine. Is there any Norwegian developers for ubuntu mobile apps?
[10:41] <jibel> pitti, I'll stop apport test on amd64 and re-run it. It downloaded 2.12.6 instead of 2.12.7.
[10:41] <jibel> I don't know what's going on with the lab :/
[10:41] <pitti> jibel: ah, thanks;  2.12.6 is indeed broken with dpkg
[10:41] <pitti> but britney ought to have requested a test for .7, right?
[10:42] <jibel> pitti, right and that's what has been tested on i386
[10:44] <jibel> and it takes nearly 1.5h to run the tests instead of 20min
[11:09] <DanChapman> Good morning all
[11:16] <DanChapman> jibel, just looking at your pep8 MP. what is the pep8 line length now?, so i can change it, my editor seems to say that the line lengths are ok after running its internal pep8 code insepection.
[11:17] <pitti> hey DanChapman
[11:17] <pitti> DanChapman: ah, fighting with this annoying antiquated 79 char limit? :/
[11:17] <jibel> DanChapman, I think it's the default 79 characters for ubiquity
[11:17] <pitti> TBH I run most of my tests with --ignore E501
[11:17] <jibel> xnox, do you confirm? ^
[11:18] <xnox> jibel: yeah, it's the stock 79.
[11:18] <jibel> tests/run-pep8 doesn't exclude any rule
[11:18] <DanChapman> good morning pitti, I am indeed, Wow 79 my editor warns at 120, i'll change that
[11:18] <DanChapman> jibel, xnox thanks :-)
[11:19] <pitti> breaking lines at 79 chars makes some stuff really hard to read IMHO
[11:20] <xnox> pitti: imho 79 is still good for doing split buffer vertically.
[11:20] <xnox> maybe when I get high-resolution displays..... =)
[11:20] <pitti> xnox: I agree that it's nice for most stuff, to avoid putting too many constructs into one line
[11:20] <pitti> but I really hate pointless string splitting just because it makes the line 85 chars or so
[11:21] <xnox> true.
[11:21] <pitti> it's harder to read, breaks grep and similar tools, and is error prone
[11:21] <xnox> hm, my computer doesn't like my usb webcam. let's see if notebook works.
[11:21] <DanChapman> i thought it had recently been extended in pep8??
[11:23] <jibel> with 79 I can open 3 editors side by side :)
[11:51] <pitti> jibel: ah, wazn is back on?
[11:51] <pitti> jibel: python-glanceclient/amd64 failed again on the dreaded marshalling error on python package import
[11:52] <pitti> somehow this node is cursed
[11:59] <DanChapman> jibel, just a quick one when you get a chance https://code.launchpad.net/~dpniel/ubiquity/fix_1252215/+merge/195756 :-)
[12:14] <DanChapman> xnox, when creating a partition say 200MB when closing the partition dialog it drops to 199MB in the treeview (which there is bug 1164783 for it), but if you actually look in gparted after the install its down to 190MB. Should i expand that current bug or create a new one?
[12:25] <xnox> DanChapman: there could be a bug in rouding and units.
[12:25] <xnox> DanChapman: the partitions are rounded up to nearest cillinder and one view is done in base10 and the other view is done in base2.
[12:25] <xnox> DanChapman: the treeview should match the dialog, sans rounding.
[12:26] <xnox> DanChapman: so the off by one is a bug. the 200 -> 190 sounds more like base10/base2 conversion.
[12:27] <DanChapman> xnox, ok thanks that makes more sense, it did seem a rather large difference :-) thanks
[12:27] <pitti> jibel: for bug 1137763, WDYT about http://paste.ubuntu.com/6442541/ ? does that look like what you had in mind?
[12:28] <pitti> (and yay for alioth still being down -- I'm sitting on 14 commits now which I can't push..)
[12:34] <jibel> pitti, access to ftpmaster is fixed and I brought it back. it is also running dkms tests and it cannot stay offline too long
[12:34] <jibel> it could be a bug in saucy? kernel or qemu?
[12:34] <pitti> jibel: ah, thanks; so wazn is still saucy, while the others are precise?
[12:35] <jibel> pitti, yes it is. I asked to upgrade it from Raring, because raring is EOL in 2 month and it would be a bad timing for an upgrade
[12:35] <jibel> it's better to do it early in the cycle
[12:36] <jibel> upgrading to raring while others are on Precise was a mistake IMO
[12:39] <jibel> DanChapman, Looks good, thanks
[12:43] <jibel> pitti, Excellent. It's similar to what I did for Firefox which only works because host and guest are the same host. Thanks!
[12:58] <jibel> grrr "Hash Sum mismatch" again, this network problem in the lab is killing me.
[12:58] <jibel> pitti, apport failed again, but this time on i386, I'll force the results to pass
[12:58] <jibel> since it passed on both arch but separately
[13:00] <pitti> jibel: hm, it already propagated to trusty
[13:01] <pitti> jibel: I thought the tests passed, but it forgot to send me mail about "jenkins fixed"
[13:01] <jibel> pitti, uh
[13:01] <jibel> it didn't send you an email because it never passed
[13:01] <pitti> jibel: I ripped out the whole AutoFile magic and replaced it with something much simpler to understand and maintain, so I can now say I understand most of what adt-run is doing :)
[13:02] <jibel> pitti, that's good news, really sad for AutoFile, it was such a nice piece of magic :)
[13:38] <balloons> morning chilicuil
[13:39]  * DanChapman waves to balloons
[13:42] <elfy> balloons: have fun with uds - shall catch up this evening with what's happened
[13:45]  * balloons waves to DanChapman and elfy 
[13:47]  * elfy goes back to work 
[13:47] <chilicuil> morning balloons and everyone =)
[13:47] <balloons> chilicuil, I'm not on the map :-( http://people.ubuntu.com/~chilicuil/ubuntuqamembers.html
[13:48] <balloons> nor is nz?
[13:48] <balloons> looks very cool though
[13:48]  * elfy wonders who it is that's in London 
[13:49] <chilicuil> lol balloons it seems the google api also hates you xD, the true is that the script makes the marks from the Time Zone data in lp, so it's far from being exact, not sute if you have a tz configured in you lp account
[13:50] <balloons> ahh! gotcha
[13:55] <chilicuil> also, if more than one member is in the same tz it will only print the last one, I know it's really bad as it's now, if you know from a better place from taking initial data I'd like to hear from it
[13:57] <balloons> right.. timezones make sense.. how else would you have any idea where we are from :-)
[14:33] <DanChapman> balloons, i will be a little late to the community workflow session, but i will be there asap I want to get in on that session
[14:33] <balloons> DanChapman, no worries.. Jump in the hangout whenever you pop up :-)
[14:33] <DanChapman> balloons, will do :-)
[14:39] <knome> balloons, i'll be around, but not in the hangout itself.
[14:40] <balloons> participation in any capacity is most appreciated ;-)
[14:40] <balloons> so ty knome
[14:40] <knome> np
[14:58] <knome> balloons, boo for not having the youtube link ready :)
[14:58] <knome> (i don't like the uds. -page too much, waiting to get rid of that ASAP)
[15:00] <balloons> knome, the link is up now :-)
[15:00]  * knome bows
[15:11] <pitti> jibel: meh, hash sum mismatch again on http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-apport/21/ARCH=i386,label=adt/console ; worth trying again?
[15:13] <jibel> pitti, doko uploaded a new gcc and it is retesting the world. I'll check failures afterwards and retrigger what is necessary
[15:13] <pitti> jibel: ah, ok (not sure apport would trigger on gcc, but let's wait)
[15:13] <jibel> or force when required
[15:13] <pitti> jibel: I'm not blocked on it, it already migrated
[15:14] <pitti> (although it shouldn't really have)
[15:54] <senan> DanChapman, Hi
[15:55] <senan> DanChapman, Can you review my code..I just pushed the new changes
[16:14] <senan> DanChapman, Hello
[17:10] <balloons> ugh.. what a morning.. how's uds or everyone/
[17:11] <TheLordOfTime> balloons: apparently people are having issues with the hangouts
[17:12] <TheLordOfTime> judging from what i've seen in -uds-community-1
[17:12] <TheLordOfTime> (i'm lurking in prep for the one session i'm showing up in)
[17:16] <balloons> TheLordOfTime, that's why I was saying ugh, heh
[17:16] <TheLordOfTime> balloons: heh.
[17:16] <balloons> I think it's sorted for the merger hangout
[17:16] <TheLordOfTime> balloons: i think everything will work for me, chrome seems to behave on linux with hangouts :P
[17:16] <TheLordOfTime> but as the merger hangout is all i'm attending i haven't actually "tested" yet
[17:19] <elfy> balloons: I should manage to lurk for that one
[17:25] <balloons> elfy, k
[17:31] <balloons> hello Letozaf_
[17:32] <Letozaf_> balloons, hi
[17:32] <Letozaf_> balloons, I saw the first UDS QA session about roles, the registered one, couldn't make it on time
[17:33] <balloons> Letozaf_, yea, no worries. Hangout troubles this morning, most everything is in IRC :-)
[17:33] <balloons> the irc log I should say
[17:34] <Letozaf_> balloons, yeah saw that
[18:29] <dkessel> good evening :)
[18:40] <elfy> hi dkessel
[20:02] <balloons> ty everyone who came out to the sessions today :-)
[20:07] <elfy> balloons: useful stuff
[20:14] <balloons> elfy, glad you thought so
[20:14] <knome> all was just bollocks
[20:14] <knome> especially everything those knome and balloons guys said
[20:14] <knome> :<
[20:16] <balloons> haha.. it was a crazy day for me.. I'm sure I sounded like a maniac
[20:17] <knome> it was fine, and the background noise wasn't really *too* bad
[20:17] <knome> except when some guy laughed near you, but luckily he wasn't having too fun
[20:17] <balloons> I couldn't decide if inside or outside was better
[20:18] <knome> is your internet working now?
[20:19] <elfy> outside is best if you spend your day inside
[20:20] <knome> it's dangerous to take balloons outside, they will fly far if you lose your grip of them
[20:20] <knome> aharharhar.
[20:26] <balloons> I stayed outside mostly
[20:26] <balloons> but it was windy and I was fearful