[00:27] <arellanosac> hello everybody
[07:31] <SteevyX> Can someone tells me if Android Apps will be able to be installed on unbuntu mobile phone coming up end this year?
[07:31] <SteevyX> inbox me the ANSWER<EMAIL_ADDRESS>[07:43] <dholbach> good morning
[13:35] <linuxdude> hello
[13:37] <Guest83978> hi
[13:39] <linuxdude> it should be starting soon, right?
[13:39] <danieltdt> 1h20min left
[13:42] <linuxdude> Damn it! I don't get this UTC time thing. lol, 15:00 for eastern time should be 10:00am, right?
[13:59] <commandoline> linuxdude: add UTC to your 'alternate locations' in the time indicator (right top of the screen). Works great :)
[13:59] <Guest83978> if you didn't found it yet just click on the link upwards and you will see the convertion to your location
[14:04] <linuxdude> lol, I think I've figured it out. I must not be taken the daylight saving time into consideration.
[14:58] <linuxdude> tic toc
[14:58] <Guest999> *-*
[15:02] <UbuPhillup> *______*
[15:02] <ecto> Yes!
[15:05] <linuxdude> I'm on that now
[15:26] <jake___> ? are we live?
[15:26] <linuxdude> yes
[15:26] <mhall119> jake___: yes
[15:26] <mhall119> can you see us?
[15:26] <jake___> thx
[15:27] <linuxdude> mhall119: Yes, we can see you.
[15:27] <mhall119> :)
[15:27] <elbuntu> See you and hear you loud and clear :P
[15:28] <linuxdude> We can see you earthlings
[15:28] <elbuntu> Earthlings, what does that make us then?
[15:29] <mhall119> take me to your app devs
[15:36] <mhall119> http://developer.ubuntu.com/api/ubuntu-12.10/qml/mobile/overview-ubuntu-sdk.html are the API docs
[15:39] <mhall119> https://launchpad.net/ubuntu-phone-coreapps
[15:42] <mhall119> https://wiki.ubuntu.com/Touch/CoreApps
[15:43] <mhall119> QUESTION: like this
[15:50] <linuxdude> QUESTION: Can you guys describe a bit about QML? Is it only use to design the user interface?
[15:53] <FlyingPig> linuxdude: you can ask questions in #ubuntu-app-devel
[15:57] <UbuPhillup> FlyingPig: You are in every ubuntu on air session :) in see and your name always
[15:57] <FlyingPig> UbuPhillup: yeah, I am a big Ubuntu fan :D
[15:58] <UbuPhillup> ;)
[20:30] <redtape-renegade> ::: http://is.gd/G6RdVp #sdkmaintainers #days


[00:58] <Sarvatt> hmm, about radeontool, I dont see it in a VCS anywhere in debian to merge with? can we just make a release based off the upstream 1.6.0 tarball?
[01:00] <Sarvatt> ah I should have read Bug #490052 better, guess tormod's going to try to get it in a vcs in debian. I was just packaging one up for edgers
[01:02] <Sarvatt> looks like theres been some important updates post 1.6.0 too even though its like a week old, darn
[01:06] <Sarvatt> i'll wait to talk to him about it, lessee about intel-gpu-tools updates, just noticed lucid still has the old git checkout from june when I was getting some dumps
[01:08] <M25> Hey, I'm on Karmic with ATI free drivers, I have a problem with suspending/resuming X, from VT switches, logouts, or suspend/hibernate.   Everything in the logs points to memory corruption.  Are there any settings I can change or should I just file a bug report and hope?
[01:12] <Sarvatt> M25: you might want to try the xorg-edgers PPA to see if things are any different, if your problem is fixed there it would help narrow down where your problem is. I would recommend trying out a newer kernel to see if that fixes things first though because that's most likely where the fix will be
[01:14] <Sarvatt> what ATI card is it?
[01:15] <Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[01:15] <Sarvatt> <IP_ADDRESS> would be a good one to try from there, unless its an r600 or newer card because there's a bug with those in <IP_ADDRESS>
[01:16] <Sarvatt> (aka HD2xxx or newer)
[01:22] <Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa -- thats the xorg-edgers PPA, note it says latest crack but we tend to be somewhat conservative outside of the development releases so it's not a huge risk of breaking things :D I would try the kernel first though, and if that doesn't fix things try that PPA with both the new and older kernels to see if any of the problems are fixed. xserver-xorg-video-ati had a few fixes post karmic that mig
[01:22] <Sarvatt> ht be relevant.. there is a package called ppa-purge in there that you can install to remove all the packages in the PPA and go back to stock karmic ones after
[02:09] <Sarvatt> shouldnt intel-gpu-tools have been synced from debian testing automatically?
[02:27] <M25> Sarvatt: it's a RS4XX series
[02:28] <M25> the bugs I'm getting aren't related to the drivers, they happen on my desktop with an Intel card
[02:28] <Sarvatt> ah yeah 200M, I see a fix in xserver-xorg-video-ati regarding VT problems in the past few days
[02:29] <M25> :D how soon would that be pushed to Ubuntu?
[02:29] <Sarvatt> does it freeze when you switch to a VT?
[02:30] <M25> Sarvatt: no, it doesn't even always freeze when switching back.  It'll do it the second or third or somethingth try, rarely ever the first, and only when switching back.  It also has by far the weirdest resume-from-suspend bug ever
[02:30] <Sarvatt> is it a constant problem or just sometimes? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=3a30210d50b27f8772fc5045133940246764fce9
[02:30] <Sarvatt> yeah that sounds like what that commit fixes
[02:30] <Sarvatt> theres a VT switch on suspend/resume too
[02:31] <M25> Sarvatt: if I suspend/resume X enough times, it always happens... oh really now
[02:32] <M25> on suspend-resume I get a different crash.  It's not immediate, it can be anywhere from 3 minutes to half an hour, but eventually one of my programs will stop responding, either taking 0 or 100% cpu.  then every program I touch crashes instantly, one after the other.  When they're all crashed, X crashes, and even a REISUB won't reset it, I have to hard boot
[02:33] <M25> this is new with Ubuntu Karmic, never seen anything like it before. only ever happens after a suspend (this is computer suspend, although I assume there's an X suspend associated with it)
[02:33] <Sarvatt> does it happen without KMS enabled as well?
[02:33] <M25> I don't think I have KMS enabled
[02:33] <M25> what's the default?  I've heard enough bug reports about it not to mess with it yet
[02:34] <Sarvatt> not positive but I thought it was enabled by default, you can edit the grub boot line to have radeon.modeset=0 after the quiet splash part if you want to try disabled
[02:34] <M25> I'll try that, what do I lose by disabling it?
[02:34] <Sarvatt> dmesg | grep radeondrmfb -- if theres anything there its enabled
[02:34] <M25> nope, nothing back from that
[02:35] <M25> yeah, says it's disabled already
[02:37] <M25> so, before I go installing the edgers ppa, exactly how would I remove the packages it installs, preferably from console.  With my luck, X will refuse to run entirely :p
[02:38] <Sarvatt> sudo apt-get install ppa-purge after you enable the repo, then you would sudo ppa-purge xorg-edgers to switch back to karmic
[02:39] <Sarvatt> i was going to throw a newer ati driver in the drivers-only ppa but i just remembered it needs libdrm 2.4.17+ to build now :(
[02:39] <M25> thanks, I'll see how this goes, would the VT thing that's just been committed to the git above be in the PPA yet?
[02:39] <Sarvatt> yeah it is
[02:43] <Sarvatt> I would actually give KMS a try and see if it works any better
[02:51] <Sarvatt> M25: the problem after suspend/resume sounds different for sure though, sounds more like a kernel issue there
[02:51] <M25> Sarvatt: it's been duplicated by somebody else, on Intel drivers, he said the new kernel didn't fix it, neither did disabling compiz
[02:55] <M25> alright, rebooting, hope this fixes something and breaks nothing
[03:02] <M25> Sarvatt: appears to work, I still get glitchy screens of flickering lines on occasion when switching back to an X session, but I can keep switching around and they disappear
[03:02] <M25> that's been the case for ages, thanks for the help!
[03:03] <M25> Sarvatt: so where would I try the latest kernel to see if it fixes my suspend/resume issues?
[03:04] <Sarvatt> things should be better when ya upgrade to lucid if that's the case, if you want I can try adding that one commit as a patch to karmic's ati ddx so you can see if it fixes it and try for an SRU if so.
[03:04] <Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[03:04] <Sarvatt> i'd recommend trying <IP_ADDRESS> from there
[03:05] <M25> Ok, I'm a linux user of two years, what's ddx and what's an SRU?
[03:05] <M25> Sarvatt: that's the one the other guy tried with no effect, rc6 if I remember correctly
[03:06] <Sarvatt> xserver-xorg-video-ati is the ddx, SRU is a stable release update which is how you get fixes like that into already released series
[03:07] <Sarvatt> well <IP_ADDRESS> is 5 versions newer than rc6, might be worth trying out :D
[03:07] <M25> right, I'd say go for it, I can do a ppa-purge once it's in and see if the fix stays.  I like being on cutting edge of development, but not for core utilities, I'd like to get off the PPA if possible
[03:08] <Sarvatt> his problem could be different even though it seems similar too, never know
[03:09] <M25> Sarvatt: that link takes me to a list of directories... I found the one I want, should I just install the .deb manually?
[03:10] <Sarvatt> yep, 	linux-image-2.6.32-02063202-generic_2.6.32-02063202_(whatever your architecture is).deb
[03:10] <M25> I won't need the headers?
[03:10] <Sarvatt> not unless you have something else installed that needs them, like virtualbox or something
[03:10] <M25> nope
[03:11] <M25> wait
[03:12] <M25> I've got them installed, methinks it'd be a bad idea to have headers for the wrong version of my kernel
[03:13] <Sarvatt> theres no linux-libc-dev where the important headers are for those anyhow, should only need those headers if you need to build an external kernel module or something
[03:14] <M25> I'll take your word for it
[03:15] <Sarvatt> i only install the headers on my box i use nvidia binary drivers on
[03:15] <M25> right, new kernel installed, rebooting
[03:45] <M25> Sarvatt: new kernel is weird, the first suspend I tried left me with no X, had to REISUB, but when I rebooted and tried it again, it worked fine
[03:49] <M25> except now my panel is using 100% cpu and isn't being killed by kill-9
[04:01] <M25> Sarvatt: well, I'm never trying THAT kernel again
[04:01] <M25> 3 boots, 3 completely separate things breaking, all after suspend
[04:03] <Sarvatt> suspend/resume doesnt work for me on 2.6.32 either if I ever mount an SD card, kind of stinks because thats whats going into lucid
[04:13] <M25> they've got 4 months, they'll fix it
[04:15] <superm1> no, it's been broke for a few releases
[04:15] <superm1> doesnt necessarily mean it will be fixed...
[04:22] <hyperair> Sarvatt: what's going into lucid?
[04:23] <Sarvatt> hmm, 2.6.33 needs external firmware to work right for r600 KMS with those mainline kernel builds
[04:24] <hyperair> O_o
[04:24] <Sarvatt> whatcha mean hyperair?
[04:24] <hyperair> nevermind
[04:24] <Sarvatt> oh I was saying 2.6.32 was going into lucid and has some problems for me
[04:24] <hyperair> i see
[04:25] <hyperair> but i haven't heard of a single kernel that supported susend/resume with an SD card mounted
[04:26] <Sarvatt> 2.6.31 and under always worked fine here, i dont mean anything important on an SD but they all refuse to suspend if I have ever mounted an SD card now, the controller isnt shutting down right or something
[04:26] <Sarvatt> maybe if I compile my own with unsafe suspend enabled it might work, gotta try that
[04:27] <Sarvatt> oh wait no it doesnt, i did that at 2.6.32-rc6
[04:28] <Sarvatt> its not just having one mounted that blocks suspend here though, even if i mount one then unmount it it'll freeze trying to suspend
[04:29] <Sarvatt> or mount/unmount/remove all modules completely
[04:34] <Sarvatt> wonder why  R600_rlc.bin isnt getting included with 2.6.33-999
[04:34] <hyperair> O_o
[04:36] <hyperair> Sarvatt: by the way, is xserver-xorg-video-intel safe to upgrade yet?
[04:37] <Sarvatt> I dunno, it's not on my system but could be fine for you :D
[04:37] <hyperair> heh
[04:37] <hyperair> last i recall, it sucked on my system as bad as yours
[04:37] <Sarvatt> havent seen any i965 people having the problem i'm having
[04:37] <hyperair> hmmm
[04:38] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=25475
[04:38] <Sarvatt> i think 965 can recover from that hang anyway
[04:39] <hyperair> hmmm
[04:39] <hyperair> dunno about that
[04:39] <hyperair> i was having a lot of artifacts
[04:42] <Sarvatt> yah i had lots of those problems from 11-11 till 12-06 or so
[04:42] <Sarvatt> well i think the last artifact problem (corrupted glyphs after resume) was fixed about a week after that
[04:44] <Sarvatt> oh ok theres no R600_rlc firmware even in the upstream kernel yet, no wonder
[05:01] <Sarvatt> hyperair: if you do try it and it works i'd like to hear about it :D
[05:39] <hyperair> Sarvatt: heh okay, i'll give it a go
[12:13] <unggnu> hi all
[12:14] <unggnu> I tried 10.04 on an old laptop with a Geforce 440 Go an nv was used.
[12:14] <unggnu> It seems that nouveau isn't installed at all. Is there a change of plan?
[12:17] <unggnu> Ok, I guess I ask another time. :)
[12:17] <unggnu> Merry Christmas or whatever you celebrate :D
[14:56] <hyperair> Sarvatt: i've had no issues with the new xserver-xorg-video-intel so far, except for one compiz crash a few seconds ago
[14:56] <hyperair> xserver-xorg-video-intel: Installed: 2:<IP_ADDRESS>2~git20091222.2c142e42-0ubuntu0sarvatt2~karmic
[19:05] <Sarvatt> well, down to just these 2 bugs with libdrm 2.4.16+ on my aspire one - https://bugs.freedesktop.org/show_bug.cgi?id=25598 https://bugs.freedesktop.org/show_bug.cgi?id=25475
[19:06] <Sarvatt> still have this bug with 2.6.32+ kernels but at least thats fixed already in drm-intel-next https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/492392
[19:07] <Sarvatt> ahh just noticed that bug reporter is on my exact netbook even
[19:16] <Sarvatt> hmm maybe intel_reg_dumper moving to intel-gpu-tools instead of the ddx might be blocking syncing the new version. should we be installing the udev rule with intel-gpu-tools instead of xserver-xorg-video-intel because intel-gpu-tools is only a recommends?
[19:39] <Duke`> are you saying that in 2.6.33 (or 2.6.34?) the execbuf bug is fixed? or is it just the suspend/resume issue?
[19:47] <Duke`_> I just got this bug :/
[19:56] <Sarvatt> suspend/resume
[19:57] <Sarvatt> and just in drm-intel-next, they havent pushed it to linus in a long time
[19:59] <jcristau> Sarvatt: fwiw the submitter for fd.o 24928 says he still gets the issue with drm-intel after resume
[20:03] <Sarvatt> hmmmm
[20:04] <Sarvatt> i've got 3 days uptime post resume here since updating the kernel to drm-intel-next with that commit with nothing out of the ordinary
[20:05] <Sarvatt> his picture looks very different than what happens to me
[20:06] <Sarvatt> oh i'm looking at old posts, I did get the corruption he got from the intel ddx back then, hes still getting the solid color freezes
[20:06] <jcristau> not sure when i'll get a chance to try a newer kernel on the 945 at the office...
[20:09] <Sarvatt> sounds like theres another commit in drm-intel-next above and beyond that then if it really didnt fix it for him :(
[20:11] <Sarvatt> actually, I'm using the powersave=0 module parameter on top of that commit
[20:11] <Sarvatt> going to try without that now
[21:03] <Sarvatt> jcristau: thanks for getting me to look into that more, powersave=0 is indeed required as well to fix it on top of that patch :(
[21:03] <jcristau> damn
[21:03] <Sarvatt> i froze up just starting xchat after a resume without it
[21:04] <jcristau> well at least you get consistent results..
[21:04] <Sarvatt> got a bunch of gpu and reg dumps and logs from it at least, that one only liked to crash me when i was out of the house and actually needed suspend :D
[21:08] <Sarvatt> RAOF: hmm nouveau-firmware didnt get removed when i removed nouveau-kernel-source? dunno if you care about that
[21:09] <Sarvatt> its too unstable for me right now, every time i open the lid after having it closed for a day or two the screens corrupted and gpu hung
[21:12] <Sarvatt> oh scratch that, didnt show up in the autoremove list after but now it is
[21:13] <Sarvatt> gotta figure out what bug to put that powersave=0 needed comment on now
[21:38] <Sarvatt> when it hangs after resume intel_gpu_top says its spending 100% of the time in framebuffer compression


[05:13] <Cheri703> I am trying to get my brain wrapped back around android rooting and doing things with adb shell...got a new phone for my mom and I'm getting it rooted and set up
[05:13] <Cheri703> it has been a long time since I've messed with it much
[05:13] <Cheri703> my phone is old and my nook was easy to root
[05:13] <paultag> canthus13: :D
[05:13] <paultag> damnit
[05:13] <paultag> Cheri703: :D
[05:13] <canthus13> :D
[05:13] <paultag> canthus13: :)
[05:13] <canthus13> :P
[05:13] <paultag> oh hey gilbert, around?
[05:14] <paultag> Cheri703: you can do awesome stuff from the shell via adb
[05:14] <paultag> Cheri703: launching intents, looking like a l337 h4x0r, etc
[05:14] <Cheri703> yeah, my mom's phone is going to be set up as simply as I can, buuut *rubs hands together* soon I hope to have a galaxy s 2 (the sprint version) of my own to play with. this is an lg optimus s
[05:15] <Cheri703> got my mom on www.ting.com and I'm headed there as soon as I can afford a phone
[05:17] <canthus13> Cheri703: My Motorola Photon was amazingly easy to root.
[05:17] <canthus13> one click, pretty much.
[05:17] <Cheri703> I have been debating between the s2 and the photon
[05:17] <Cheri703> I got a one click thing for the optimus, we'll see how it does
[05:17] <canthus13> Cheri703: aside from the touch screen, I *LOVE* it.
[05:18] <Cheri703> well...the touch screen is a slightly important part >.>
[05:18] <paultag> gilbert: just applied to NM, advocation pending :)
[05:18] <canthus13> Cheri703: I just don't like typing on touch screens. I want a keyboard. :/
[05:18] <canthus13> Cheri703: it's a nice touch screen, though.
[05:18] <Cheri703> ah
[05:19] <Cheri703> it is bulky compared to the s2
[05:19] <canthus13> Cheri703: It's not as bulky as I thought it would be.
[05:19] <canthus13> the S2 is crap.
[05:19] <canthus13> my wife has it. no SD card slot.
[05:19] <Cheri703> I like the idea of the sim card slot, but it is ~$100 more than the s2 with ting
[05:19] <Cheri703> hmm...I thought it had one? at least the sprint one does
[05:19] <canthus13> The S2 also has weird issues hanging.
[05:19]  * Cheri703 checks
[05:19] <canthus13> ...I don't think so.
[05:20] <canthus13> Just the internal 16GB.
[05:20] <Cheri703> at least from ting "Memory    16GB ROM, 1GB RAM, up to 32GB with MicroSD "
[05:20]  * Cheri703 goes to check sprint site
[05:21] <Cheri703> it may be under the back cover, lots of phones are like that
[05:21] <canthus13> Never mind. SHe's got the Nexus S.
[05:21] <Cheri703> ah, ok, and that one is crappy?
[05:22] <Cheri703> I need to get into a store and play with *actual* phones, not demos, yay mansfield, they're not easy to find :/
[05:23] <canthus13> The Nexus S gets really, really slow when there are a lot of pictures on it.
[05:23] <Cheri703> :/
[05:24] <Cheri703> I got a 16gb class 4 microsd on amazon for <$15...
[05:24] <Cheri703> WAY more than my mom will ever need, but it means she'll never have to worry about running out of space
[05:25] <Cheri703> my old cdma hero is getting glitchier and glitchier these days :/ it is well over 2 years old
[05:25] <Cheri703> which, for cell phones....ancient
[05:27] <Cheri703> canthus13: have you checked out dice.com for jobs? I was poking at it the other day, no idea how it compares to other sites
[05:28] <canthus13> Not in years.  I really should.
[05:28] <Cheri703> worth a look
[05:28] <canthus13> Last time I looked at it, it was very poorly organized.
[05:28] <Cheri703> has a pretty reasonable search function now
[05:28] <Cheri703> you can choose multiple areas to search
[05:28] <Cheri703> or by metro area
[05:29] <canthus13> I just found it a bit weird to use an IT focused site with such crappy web design.
[05:29] <Cheri703> heh, yeah
[05:29] <Cheri703> "we don't hire it folks, we just help them find other jobs"
[05:31] <Cheri703> paultag: you mess with arduinos and such, right?
[05:31] <Cheri703> (or anyone?)
[05:32] <paultag> Cheri703: yeah sure
[05:32] <paultag> totally
[05:32] <Cheri703> I want to find something like this: http://www.adafruit.com/products/170 without the arduino (friend sent me one, but a. I have no idea where to start, and b. I have no bits and pieces to play with)
[05:33] <Cheri703> do you know of any sources for something like that?
[05:33] <Cheri703> adafruit does not have them
[05:33] <Cheri703> from what I could find
[05:33] <Cheri703> I really want to play with it, but it has been sitting in a drawer for months :/
[05:33] <paultag> damn
[05:33] <paultag> Cheri703: I get most of my stuff from sparkfun and radioshack
[05:33] <paultag> also old computers from the dump
[05:34] <Cheri703> ok, do they have any kits and such?
[05:34] <paultag> yep, I think so
[05:34] <paultag> sparkfun that is
[05:35] <Cheri703> yeah, I don't want to hassle with teardowns at this point, low effort entry point is the goal. I have SO MUCH CRAP that I am behind on, and so little free time, I think this would be a good "after work" hobby to mess with. I have to do quiet things because husband is asleep when I get home
[05:35] <Cheri703> ok, will check it out
[05:37] <Cheri703> thanks paultag :)
[05:37] <paultag> yep :)
[05:40] <Cheri703> looks like their primary "here's a ton of stuff to use WITH arduino" kits come with them :/
[13:29] <Therion87> Good morning Ohio
[13:30] <Therion87> Morning fellas
[16:04] <paultag> Therion87: good morning :)
[16:04] <Therion87> Hello
[16:05] <Therion87> What's up?
[16:05] <paultag> nada man. how are you?
[16:06] <Therion87> Good
[16:06] <Therion87> Excited to be part of the LoCo
[16:06] <Therion87> Just joined
[16:06] <paultag> woo!
[16:06] <Therion87> Thinking about going to the Akron meeting Friday if I can
[16:08] <paultag> I think that's the one thafreak runs
[16:09] <Therion87> Ok
[16:09] <Therion87> I made a post ont he forums asking about it hoping to get a reply before Friday
[16:11] <Therion87> I gotta go for a bit
[16:11] <Therion87> I'll be back


[01:47] <thenoob> Hello!
[01:48] <thenoob> Someone here speak Brazilian Portuguese?
[04:54] <Kernal> hello
[04:54] <Kernal> i just pulished my app.. can someone help me find it in the software center?
[04:54] <Kernal> the games name is Ghosts Of Quabbin
[04:55] <qwertzui11> hi
[04:57] <qwertzui11> Kernal: ah the one for 2.99? :)
[04:57] <qwertzui11> conrats
[04:58] <Kernal> yes where is it
[04:58] <Kernal> why cant i find it when i look for it in the software center?
[04:59] <Kernal> its still in beta...
[04:59] <Kernal> can someone post a link for me?
[05:25] <Kernal> if u wanna check out the beta for free qwertz go to http://www.sourceforge.net/projects/ghostsofquabbin/
[13:44] <odraencode> O__O
[13:44] <odraencode> OMG I can't edit a menu in glade D:
[13:44] <odraencode> This is just to cumbersome
[13:46] <odraencode> Quickly is too difficult for me to use :|
[14:02] <stqn> Is Quickly just Qt Designer renamed?
[14:02] <stqn> or…err…
[14:02] <stqn> The screenshots looked like it but maybe I’m mistaken :)
[14:02] <tsimpson> they are completely different things
[14:03] <tsimpson> not related in any way actually
[14:03] <stqn> Ok, I had this in my head… But I see it’s using Gtk+.
[14:50] <odraencode> :/
[14:51] <odraencode> This is troublesome
[14:52] <odraencode> How do people usually go about using the FHS while in development
[14:52] <odraencode> ?


[09:13] <duflu> greyback: I think I love you right now. INTEL_DEBUG=perf was a great suggestion
[09:13] <duflu> (love you more than usual)
[09:13] <greyback> :)
[09:14] <greyback> duflu: I bestow http://mesa3d.org/envvars.html upon you, use it with care!
[09:14] <duflu> greyback: I know. Still never used that variable before
[09:14] <greyback> I had to read through the i915 mesa code to figure out what env vars actually returned some debugging info
[09:14] <duflu> Arguably perf issues are errors to us... but if you ask only for errors you'd never see it
[09:15] <greyback> what did you learn?
[09:17] <duflu> greyback: Old and new(!) Intel GPUs fall back to software rendering regularly
[09:17] <duflu> But Atoms moreso
[09:18] <duflu> Possibly caused by ES/non-ES confusion
[09:18] <duflu> The Atom issue seems to be that our shaders are 18% longer than the hardware limit
[09:21] <greyback> that's interesting
[09:21] <duflu> It's a big deal
[09:21] <duflu> And exciting to imagine after we fix it
[09:21] <greyback> indeed
[09:23] <duflu> greyback: The offending function seems to only be in qtubuntu and qtquick but maybe I missed more
[09:24] <greyback> qtubuntu is just a glue between mirclient/platform-api and Qt - aside from setting up GL context, it has no other impact on GL
[09:24] <greyback> qtquick most likely
[09:24] <duflu> I logged bugs. You will find them...
[09:24] <greyback> nice
[09:26] <greyback> duflu: fyi, here are the shaders QtQuick has: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/shaders
[09:26] <greyback> that is trunk (5.7 pre-release), we're using 5.5, but I don't see the shaders changing in some time
[09:27] <duflu> greyback: One thing at a time. The first issue seems to be bad format args to glCopyTexSubImage
[09:27] <greyback> ah, that was what you were referring to
[09:27] <greyback> yes
[09:27] <greyback> I had hoped a proper OpenGL context would have resolved that
[09:27] <duflu> Which I found one instance of that switches behaviour for ES
[09:27] <duflu> Yep
[09:36] <greyback> http://pastebin.ubuntu.com/16518134/ <- qt only uses it for the font distance field
[09:36] <greyback> uitk doesn't
[15:42] <alan_g> kdub: you're probably not looking at it yet. But you had an MP that got the titlebars wrong. I've just seen a similar behavior in code I'm working on and it looks like a deeper issue that may also have caused the problem on your branch. Will update if I figure it out.
[16:11] <kdub> alan_g, ack, yeah got stuck on that one because i couldnt get the terminal to start
[16:38] <alan_g> kdub: I bottomed my problem - unfortunately, it was new code so it fix yours.
[16:38] <kdub> *it doesnt fix?
[16:41] <alan_g> yes doesn't
[16:41] <alan_g> /sigh
[16:43] <alan_g> Oh well, 20min of week left and code is in a stable intermediate form. Might as well MP it and start looking forward to xp2016


[02:02] <ArneGoetje> kenvandine: FYI, language-selector always sets .utf8 as encoding for any locale as it should be. Even if the locale information leaves away the .utf8, because there is only one locale for that language-country combination, it doesn't mean that that it wouldn't be possible to add another encoding in future. And if that happens, the encoding must be specified. Therefor to be sure, always set the encoding.
[02:14] <ArneGoetje> jbache: The problem you describe is, because gnome store its font settings in it's own registry, while KDE uses fontconfig. Ideally, Gnome should just switch to use fontconfig to store the rendering settings. Then the discrepancy would be gone. What Riddell mentions with qtcurve is probably the same thing. The application stores it's rendering settings somewhere else instead of just using fontconfig like KDE does.
[03:11] <kenvandine> hey ArneGoetje
[03:11] <kenvandine> thx
[03:12] <kenvandine> so yeah, my install has en_US.UTF-8 in /etc/default/locale
[03:12] <kenvandine> but vish's has en_IN
[03:12] <kenvandine> which breaks locale.setlocale in python
[03:12] <kenvandine> at least in gwibber
[03:13] <kenvandine> there is a place where gwibber sets the locale to C before parsing a time string then tries to restore the old locale
[03:13] <ArneGoetje> kenvandine: correct. A lot of software expects the encoding to be specified. Therefor the installer really should append .utf8 to any locale which doesn't have it.
[03:13] <kenvandine> ok, so that is a bug in the installer
[03:13] <kenvandine> however, gwibber didn't really need to do that
[03:14] <ArneGoetje> kenvandine: seems so, since gdm and language-selector behave correctly.
[03:14] <kenvandine> setting the locale to C then setting it to '' does the right thing
[03:14] <kenvandine> locale.setlocale(locale.LC_TIME, '')
[03:14] <kenvandine> sets it back to whatever is in the env
[03:14] <kenvandine> at least afaict
[03:14] <ArneGoetje> that's strange... maybe also a bug in gwibber then?
[03:15] <kenvandine> yeah
[03:15] <kenvandine> gwibber just was doing something it didn't need to do
[03:15] <kenvandine> so i removed that, and all is good again
[03:15] <ArneGoetje> okay
[03:15] <kenvandine> but it worries me that it is effecting lots of users
[03:15] <kenvandine> since apparently this was happening in lucid too
[03:15] <kenvandine> so i guess i need to SRU that
[03:16] <ArneGoetje> yep
[03:16] <kenvandine> what i was really trying to figure out was if the installer really needs to be fixed too
[03:16] <kenvandine> ArneGoetje, could you please comment on bug 653259 ?
[03:16] <ubot2> Launchpad bug 653259 in ubiquity (Ubuntu) "Choosing India as location sets locale as en_IN and not en_IN.utf8 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/653259
[03:17] <ArneGoetje> kenvandine: yep
[03:17] <kenvandine> thx
[03:20] <ArneGoetje> kenvandine: done
[03:21] <kenvandine> thx ArneGoetje
[03:24] <ArneGoetje> kenvandine: btw, who i running the langpack generation right now?
[03:24] <kenvandine> ArneGoetje, i don't know... maybe dpm?
[03:24] <ArneGoetje> okay... will send him a mesage
[03:25] <kenvandine> if he isn't doing it, he surely knows who is
[15:56] <devildante> is the ubuntu font default as of now or simply included in the CD?
[15:57] <nigelb> Needs FFE, I mot sure what happeneed of that.
[15:59] <devildante> hmm...
[16:46] <kklimonda> it is default
[16:46] <kklimonda> it got FFe
[16:47] <kklimonda> or rather - it's installed by the default and the idea has been to enable it for interface but I'm not sure if it's done yet.
[16:47] <kklimonda> it should be
[20:47] <sense> Are the Jockey maintainers aware that when you disable the proprietary Nvidia drivers, Jockey wrongly sets the driver to 'nv' in /etc/X11/xorg.conf? The driver 'nv' isn't available anymore and Jockey should change the driver to 'nouveau' or remove the xorg.conf file altogether.
[21:49] <Riddell> sense: best to report a bug
[21:50] <sense> Riddell: Just did that after I didn't find a bug reporting the issue.
[21:50] <Riddell> groovy
[21:50] <sense> I was just curious if it was already known here.
[21:50] <sense> but it wasn't!


[08:11] <mandel> good morning!
[08:34] <duanedesign> morning mr mandel
[08:36] <mandel> duanedesign: mornng
[08:36] <mandel> morning!
[08:43] <rye> mornings
[08:45] <duanedesign> o/
[09:28] <fagan> morning
[10:47] <ralsina> mandel: approved provide_credentials_management
[10:47] <ralsina> morning fagan
[10:47] <mandel> ralsina: superb :)
[10:47] <mandel> I'll ask nessita to take a second look.. as soonas I'm done upgrade I'll fix the lint issue with the reactor
[10:47] <ralsina> mandel: cool
[10:47] <fagan> morning ralsina
[10:47] <mandel> ralsina: although on linux we do not need the reactor
[10:48] <ralsina> mandel: there's also a missing docstring
[10:48] <fagan> voidspace was looking for you yesterday to suggest a person for the team
[10:48] <mandel> ralsina: I dont know why we should even use it.. we do not need twisted at all on linux, it is a Windows detail...
[10:48] <fagan> ralsina: he said he would send a mail
[10:48] <ralsina> fagan: yes, will talk to him today
[10:49] <fagan> ralsina: nice im blocked by the keyring bug thats fixed in trunk
[10:49] <fagan> ralsina: thats the bug that was stopping me from logging in
[10:50] <ralsina> fagan: hmmmm ok? ;-)
[10:50] <fagan> ralsina: hah well im just going to install trunk and get back to it
[10:51] <ralsina> fagan: ok. BTW, sent feedback to your college today. I really want to make you do more developer-ish stuff, but I am swamped. Will try harder on sprint
[10:52] <fagan> ralsina: its cool, did you cc me on the email or would you prefer to keep it between you and them
[10:52] <ralsina> fagan: I am not sure what the etiquette here is, but it was nothing substantial ("our codebase is difficult, he has been doing this and that")
[10:53] <fagan> ralsina: ah ok then
[10:53] <fagan> ralsina: thats fine then :)
[10:53] <fagan> Well on the bright side I think I know how all the puzzle pieces fit now
[10:54] <fagan> since the twisted stuff
[10:58] <fagan> oh no the u1 client isnt detecting my internet connection since the update on the network manager in 11.10 last night
[11:02] <fagan> brb
[11:06] <fagan> back and nope restarting doesnt help looks like someone will have to debug it with me
[11:08] <mandel> ralsina: which version of ubuntuone-dev-tools do you have?
[11:11] <fagan> mandel: im on 0.1.3+r32-10~natty1 which is the nightly if that helps
[11:12] <ralsina> mandel: give me 1'...
[11:12] <ralsina> mandel: 0.1.3+r32-10~natty1
[11:12] <fagan> same as me then
[11:12] <mandel> ralsina: can you do a u1trial -h for me and tell me if you have a reactor option
[11:13] <ralsina>   --reactor=REACTOR     Run the tests using the specified reactor.
[11:14] <mandel> ralsina: ok, thx
[11:15]  * fagan break
[11:34] <mandel> ralsina: do you know which branch from alecu was giving hi issues with the QNetwork thing
[11:34] <ralsina> mandel: I would have to look. In 2'?
[11:36] <mandel> ralsina: sure, I just wanna see if merging with my branch fixes it
[11:36] <ralsina> mandel: I don t think alecu ever told me the name
[11:36] <mandel> :(
[11:38] <ralsina> let's check his branches!
[11:39] <ralsina> mandel: I would bet https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client
[11:50] <mandel> ralsina: do you remember what was the issue? it was something related to threads, right?
[11:50] <ralsina> mandel: unresponsive UI, IIRC
[11:51] <mandel> ok
[11:53] <mandel> ralsina: I'll wait for alecu to be back, atm it seems to work but I might be missing something
[11:53] <ralsina> mandel: good
[11:53] <ralsina> mandel: so, is anything missing to hook backend to frontend now?
[11:55] <ralsina> assuming all these branches land, I mean
[11:55] <mandel> ralsina: I have to get the creds approve, and write the sd tool, right?
[11:56] <ralsina> mandel: yes
[11:58] <ralsina> we still have a couple of hours before the .ar people arrive. So maybe I can help you with something
[11:58] <mandel> ralsina: I'm going to take a look at sd tool first, lets see how far I get, then look at alecus problem and hope is fixed
[11:59] <ralsina> ok
[11:59] <mandel> today seems to be a happy day so far :)
[12:00] <ralsina> mandel: let's keep it that way then :-)
[12:00] <mandel> hehehe
[12:04] <ralsina> mandel: I am going to take a look at making py2exe work with the control panel. Any suggestions?
[12:05] <mandel> ralsina: do a normal setup.py and we can work from there… there are going to be issues with the plugins, that means that the icons should be png and not jpg
[12:05] <mandel> ralsina: but that should not be a problem
[12:05] <ralsina> mandel: ok, no problem there
[12:06] <ralsina> mandel: you were using distutils-extra?
[12:06] <mandel> ralsina: yes, that works ok
[12:07] <ralsina> mandel: but I need to do it on windows, does it exist there?
[12:07] <mandel> ralsina: yes, and I patched it to make sure that ctypes works :)
[12:07] <ralsina> mandel: ok
[12:08] <ralsina> mandel: use_correct_reactor tries to use dbus on windows?
[12:08] <ralsina> or should I just go with trunk?
[12:08] <mandel> ralsina: atm it does I need to change that in a diff branch, but first we need sdtool ready
[12:09] <ralsina> mandel: ok, so no exe packaging until after that branch. I will start it on linux
[12:17]  * mandel walks dog
[12:27] <Mahoru`Tsunemi> hello
[12:27] <Mahoru`Tsunemi> i need some help
[12:28] <Mahoru`Tsunemi> i'm new to u1 and i start the sync
[12:28] <Mahoru`Tsunemi> on a distant computer the sync is now over, and i need to connect the sync with the PC i have here
[12:28] <Mahoru`Tsunemi> but i cant because le folder is already "full" of data
[12:29] <Mahoru`Tsunemi> (there is disk space, i just don't have other word :) )
[12:29] <duanedesign> hello Mahoru`Tsunemi
[12:29] <Mahoru`Tsunemi> hello duanedesign :)
[12:31] <nessita> Hello everyone!
[12:31] <duanedesign> Mahoru`Tsunemi: is this data that you put in your Ubuntu One folder on the 'distant' computer? Or is this data you uploaded via one.ubuntu.com?
[12:49] <Mahoru`Tsunemi> duanedesign: sorry for the wait
[12:49] <Mahoru`Tsunemi> so
[12:49] <Mahoru`Tsunemi> it's in a folder that was marked as sync
[12:49] <Mahoru`Tsunemi> and the sync is finished
[12:56] <duanedesign> Mahoru`Tsunemi: ok so the files are showing up in the cloud (one.ubuntu.com) but not on your other computer?
[12:56] <Mahoru`Tsunemi> not that's not the problem
[12:56] <Mahoru`Tsunemi> i have the data on the distant computer and on this one
[12:57] <duanedesign> ok
[12:57] <Mahoru`Tsunemi> and i want to have this computer synced
[12:57] <Mahoru`Tsunemi> but i can't check the "sync this folder"
[12:57] <Mahoru`Tsunemi> (it's greyed)
[12:57] <Mahoru`Tsunemi> (because there is data in this dir :) )
[13:00] <fagan> me
[13:01] <duanedesign> Mahoru`Tsunemi: is this a  folder in your Home directory?
[13:01] <Mahoru`Tsunemi> yup
[13:01] <Mahoru`Tsunemi> ~/Documents
[13:01] <Mahoru`Tsunemi> :)
[13:02] <duanedesign> Mahoru`Tsunemi: can you run this command in a Terminal to see if the folder is listed:  u1sdtool --list-folders
[13:02] <Mahoru`Tsunemi> Folder list:
[13:02] <Mahoru`Tsunemi>   id=8ede6cbe-78c7-4a9d-bf09-de479162f254 subscribed=False path=/home/mahoru/Documents
[13:03] <duanedesign> ok that is the folder... but subscribed is False and we want true.
[13:03] <Mahoru`Tsunemi> yup
[13:04] <Mahoru`Tsunemi> --subscribe-folder ?
[13:04] <duanedesign> Mahoru`Tsunemi: yes that might provide a workaround
[13:04] <nessita> fagan: still one hour to go
[13:04] <fagan> ralsina: im going to be off for standup (I thought it was at 1 whoops) I have a eye test appointment  and some errands to do
[13:05] <ralsina> fagan: ok
[13:05] <fagan> nessita: yeah realised that forgot
[13:05] <fagan> :D
[13:05] <nessita> :-)
[13:05] <duanedesign> Mahoru`Tsunemi: u1sdtool --subscribed-folder=8ede6cbe-78c7-4a9d-bf09-de479162f254
[13:05] <Mahoru`Tsunemi> that's i done :)
[13:05] <duanedesign> err --subscribe-folder
[13:05] <duanedesign> :)
[13:05] <Mahoru`Tsunemi> erk
[13:06] <Mahoru`Tsunemi> lot lot lot of upload to do :/
[13:10] <Mahoru`Tsunemi> hum
[13:10] <Mahoru`Tsunemi> upload are fast
[13:10] <Mahoru`Tsunemi> maybe there is only a hash check :)
[13:12] <ralsina> Mahoru`Tsunemi: if someone else has uploaded the same file, it's not "really" uploaded again
[13:14] <Mahoru`Tsunemi> :)
[13:15] <Mahoru`Tsunemi> and, u1 has problem with accentued file name ?
[13:16] <Mahoru`Tsunemi> (LCA - Linux sécuriser un réseau.pdf)
[13:18] <ralsina> Mahoru`Tsunemi: shouldn't!
[13:18] <Mahoru`Tsunemi> because i think i have uploaded this file a couple times :)
[13:28] <nessita> ralsina: 2 more question re QT
[13:28] <ralsina> nessita: shoot
[13:29] <nessita> ralsina: waitM RING BELL
[13:29] <nessita> oops
[13:29] <ralsina> :-)
[13:42] <nessita> I'm back!
[13:42] <nessita> ralsina: so, I was saying. Do you know of a pre-defined method to "humanize" bytes?
[13:42] <nessita> ie 1024 bytes to be 1Mb
[13:42] <ralsina> nessita: let me check
[13:42] <nessita> etc
[13:43] <nessita> ralsina: Glib has now that even handles internationalization :-) (That's why I ask instead of home-implementing it)
[13:43] <ralsina> apparently not
[13:44] <ralsina> there are some tiny implementations but of course may be too naive
[13:46] <nessita> ralsina: second question. In a treewidget, how can I make a column to be wider by default? even better, to be as wide as possible in order to try to make the text in it to be all visible
[13:47] <ralsina> you can set one column to use all available width, let me find the API
[13:48] <ralsina> nessita: first, get the widget's header, using header()
[13:48] <ralsina> then set stretchlastsection to false
[13:49]  * nessita does
[13:49] <ralsina> then (let me find it ;-)
[13:50] <ralsina> then, for the column you want to be biggest, set it's resizeMode to QtGui.QHeaderView.Stretch
[13:50] <ralsina> that is using header().setResizeMode()
[13:50] <ralsina> the header is a QHeaderView, documented here: http://doc.qt.nokia.com/latest/qheaderview.html#setResizeMode
[13:51] <nessita> ralsina: perfect, I'll go from here. Thanks a lot!
[13:51] <ralsina> happy to help!
[13:56] <dobey> hmm
[13:57] <nessita> dobey: good morning to you too :-)
[13:57] <ralsina> dobey: hmm to you too!
[13:57] <dobey> buenas dias
[13:57] <nessita> buenos días!
[13:58] <nessita> (the days are masculine)
[13:58] <nessita> :-)
[13:58] <ralsina> however, mornings, evenings and nights are femenine. Wonder how that works.
[13:59] <alecu> hello!
[13:59] <nessita> hello alecu!
[14:00] <mandel> alecu: ping
[14:00] <alecu> mandel, pong
[14:00] <alecu> me
[14:00] <mandel> me
[14:00] <mandel> alecu: which was the branch you were having issues with the reactor?
[14:00] <dobey> me
[14:01] <mandel> alecu: I'd like to test my branch with your issues and see what happens
[14:01] <nessita> me
[14:01] <dobey> mandel: any that use qt reactor and dbus
[14:01] <nessita> ralsina, thisfred?
[14:01] <ralsina> me
[14:01] <thisfred> me
[14:01] <alecu> mandel, let me find it
[14:01] <ralsina> I have fagan's to
[14:01] <ralsina> too^
[14:02] <alecu> DONE: a few reviews, did some debugging to understand qtreactor+dbus issue, started working on "devices" tab, did pre-sprint laundry
[14:02] <alecu> TODO: finish "devices" branch
[14:02] <alecu> BLOCKED: no
[14:02] <alecu> NEXT: mandel
[14:02] <mandel> DONE: Reactor on Windows and Linux for control panel. Started with sd on windows.
[14:02] <mandel> TODO: finish sd on windows.
[14:03] <mandel> test reactor with alecus branch
[14:03] <mandel> BLOCKED: no
[14:03] <mandel> nessita: please
[14:03] <nessita> I think dobey is next
[14:03] <nessita> dobey: go!
[14:03] <mandel> dobey: no, I wanna try one that uses a threaded select reactor and dbus
[14:03] <dobey> λ DONE: holiday
[14:03] <dobey> λ TODO: bug #789299, bug #789300, bug #771488, more magic
[14:03] <dobey> λ BLCK: None.
[14:03] <ubot4`> Launchpad bug 789299 in ubuntuone-dev-tools "DBusTestCase sometimes connects to real session bus (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/789299
[14:03] <ubot4`> Launchpad bug 789300 in ubuntuone-dev-tools "DBusTestCase needs to work with Qt main loop as well (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/789300
[14:03] <ubot4`> Launchpad bug 771488 in ubuntuone-dev-tools "u1trial should unset GTK_MODULES (affects: 1) (heat: 4)" [Medium,In progress] https://launchpad.net/bugs/771488
[14:04] <dobey> nessita: you
[14:04] <nessita> DONE: swap day. Last Fri: tons of QT work on modelling the Cloud Folders tab. Mumble meeting with ralsina, mandel and alecu to re-estimate windows control panel remaining work.
[14:04] <nessita> TODO: finish Cloud folders tab, add tests to that, catch up with the rest of the team.
[14:04] <nessita> BLOCKED: nopes
[14:04] <nessita> NEXT: ralsina
[14:04] <ralsina> DONE: reviews, meetings, helped bits with Qt, lost internet half a day yesterday, so working longer today. TODO: try to figure out how we are going to make everything work, BLOCKED: no, I think .
[14:04] <ralsina> now fagan's: DONE
[14:04] <ralsina> * Tried to figure out why I couldnt login to u1 on 11.10 and figured out it was the keyring bug that dobey fixed in trunk.
[14:04] <ralsina> * installed trunk
[14:04] <ralsina> * found I think a bug where the client doesnt detect that I have an internet connection (I guess it might be the nm update that happened or something but I dont know)
[14:04] <ralsina> TODO
[14:04] <ralsina> * debug the bug or find out whats causing the issue (?)
[14:04] <ralsina> * payroll
[14:04] <ralsina> Blocked
[14:04] <ralsina> * nope
[14:04] <dobey> it's not fixed in trunk
[14:05] <ralsina> thisfred?
[14:05] <thisfred> DONE: memorial day TODO: file bugs for u1-unity integration improvements and fix them, some assorted other bugs to look at/triage/fix BLOCKED: no
[14:05] <ralsina> BTW: network manager in O broke our "are we connected" detection.
[14:05] <mandel> dobey: my irrc client crashed, did you get my last message?
[14:05] <dobey> yes i know NM broke us too
[14:06] <dobey> mandel: about select reactor + dbus?
[14:06] <nessita> ralsina: ack, we can fix after windows, right?
[14:06] <ralsina> nessita: indeed
[14:06] <alecu> ralsina, we should let fagan know that the keyring access is also broken, so he'll have no luck either on O.
[14:06] <mandel> dobey: yes, about trying to use a threaded select reactor instead with integration in the Qt main loop
[14:06] <alecu> or perhaps not ;-)
[14:06] <ralsina> alecu: yeah
[14:06] <nessita> also, NOTE: I'm going today to university instead of tomorrow (I'm leaving in 15 minutes, so speak now! :-))
[14:06] <dobey> mandel: well, there are a couple bugs in devtools
[14:06] <mandel> dobey: hmmm what kind of bug?
[14:07] <dobey> mandel: i expect in that case you'll still have similar issues :)
[14:07] <mandel> dobey: heheh common share them ;)
[14:07] <alecu> nessita, if resizing icons and getting html labels right is too much trouble on the tree widget, I suggest doing something similar to the "devices" tab.
[14:07] <dobey> mandel: 789299 and 789300
[14:07] <nessita> alecu: what did you do there?
[14:08] <alecu> nessita, I'm still working on it, but it's a "device" widget that gets included many times inside a scroll-widget.
[14:08] <alecu> nessita, (a scroll-something-whatever-its-name-widget)
[14:08] <Chipaca> FWIW, I'm in 11.10 and the only issue i have is with NM
[14:08] <Chipaca> and that's workaroundable with dbus-send
[14:09] <Chipaca> as in http://askubuntu.com/questions/45814/network-manager-0-8-999-and-ubuntu-one
[14:09] <alecu> nessita, that way you'll have the icon size you want plus the html labels plus disabling the way you want.
[14:09] <nessita> alecu: I already implemented all that using stuff from the qtreewidget, but I'll take a look to what you're doing :-)
[14:09] <mandel> dobey: ok, looking
[14:10] <mandel> nessita: can you re-review the branch wth the creds management tool?
[14:10] <ralsina> yes, for up to a few dozen rows, that solution is workable
[14:10] <dobey> Chipaca: lies :)
[14:11] <nessita> mandel: yes! but as soon as I get back from Uni, I'm leaving in 10. Or do you need it sooner?
[14:11] <Chipaca> dobey: i swear!
[14:11] <alecu> ralsina, is there any hard limit to it?
[14:11] <ralsina> alecu: no, just that when you start having hundreds of widgets, things get slow
[14:11] <alecu> ralsina, like X's 32768 pixel height limit on widgets?
[14:12] <alecu> ralsina, ok.
[14:12] <ralsina> alecu: I don't think scrollviews are limited like that for the content, so just apply common sense ;-)
[14:13] <alecu> ralsina: apply(commonsense, widgetlist) ?
[14:13] <ralsina> alecu: ha!
[14:13] <mandel> nessita: I can wait, I'll move to something else
[14:13] <dobey> huh
[14:14] <alecu> ralsina, mandel, all: can I have some reviews on this branch? https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client/+merge/62889
[14:15] <mandel> alecu: is that the one that gave you problems with the reactor?
[14:16] <ralsina> alecu: on it
[14:16] <alecu> mandel, the problems with the reactor I had were related to the bug 789300 that dobey is working on.
[14:16] <ubot4`> Launchpad bug 789300 in ubuntuone-dev-tools "DBusTestCase needs to work with Qt main loop as well (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/789300
[14:17] <alecu> mandel, what I found is that the QApplication has to be created before the qt reactor is installed
[14:18] <alecu> mandel, that way the threading warnings do not show up
[14:18] <nessita> ok, I'm leaving for teaching duties. See ya'll in about 3~ hours!
[14:18] <alecu> (and everything ends up fine, with no segfaults)
[14:22] <dobey> alecu: --gui does that
[14:23] <mandel> alecu: yes, that is in the documentation of qt
[14:24] <mandel> you always have to create the QApplication first otherwise the reactor will create a new QCoreQpplication that does not take care of the UI events
[14:24] <mandel> is in the few first ines of the README of the qtreactor
[14:24] <mandel> alecu: was that the only reason?
[14:24] <mandel> I mean the only problem you had?
[14:25] <ralsina> alecu: seems to work for me
[14:25] <dobey> what my problem is, is that i can't seem to get the tests to disconnect from the dbus-daemon fast enough :(
[14:25] <dobey> and i am not sure how to fix that
[14:26] <alecu> dobey, that's weird. That never happened on the glib dbus tests
[14:26] <alecu> dobey, are you returning a deferred from the tearDown function?
[14:27] <dobey> alecu: yes it is. it's just not so much visible with glib, since the DBusTestCase client connection is using the glib main loop
[14:29] <alecu> dobey, but the dbus "disconnect" calls are blocking... so it should not be a problem.
[14:29] <alecu> dobey, is this happening because the tests are not connecting to the test daemon, and connecting to the session daemon instead?
[14:30] <alecu> dobey, perhaps the "not disconnected" is not your process but another process on the real session bus.
[14:31] <mandel> dobey: but the qtreactor is using the Qt main loop, right? so if you use the Qt dbus implementation it should work, or am I missing something?
[14:31] <dobey> alecu: no, it doesn't matter which one they connect to
[14:31] <mandel> alecu: we actualy do not need to use the reactor on linux, right?
[14:32] <dobey> alecu: and it's definitely the tests not disconnecting fully, because the amount of connections goes up with each following test
[14:32] <mandel> alecu: since the IPC is dbus, we can tell the code to just use the twisted reactor on windows and not on linux
[14:32] <alecu> mandel, yeah, we can do that for now.
[14:32] <dobey> mandel: that's another problem. we need to split up the DBusTest case, so that we have a DBusGTestCase and DBusQtTestCase or something like that, both inheriting from a DBusTestCase
[14:34] <alecu> dobey, mandel is right: we don't need dbus-qt for the windows port, so if it keeps giving trouble we can safely get rid of it.
[14:34] <mandel> alecu: it would not just be for now, since we do not use twisted for any type of communication we will never need it on linux, just windows.
[14:34] <dobey> alecu: it doesn't matter because we're still doing qt stuff on linux also
[14:35] <alecu> dobey, right, but we won't be doing qt+twisted+dbus in the same process.
[14:35] <dobey> alecu: yes we will.
[14:35] <mandel> we should not use twisted at all on linux
[14:35] <alecu> dobey, and we can solve the dbus+qt issues later.
[14:35] <alecu> dobey, if it keeps giving trouble: no.
[14:35] <dobey> alecu: not in live install perhaps, but the tests are run with a reactor; they have to be.
[14:36] <dobey> alecu: unless we just stop running the tests and you write a different test runner that only uses unittest+qt+dbus or something, instead of the twisted test runner
[14:36] <alecu> dobey, we can have the qt tests running in a different way... exactly.
[14:36] <dobey> i don't even want to begin thinking about that mess though :(
[14:37] <mandel> yes, I would not do that...
[14:37] <dobey> alecu: and either way, we still need to fix several of these issues anyway
[14:37] <alecu> dobey, right, but we don't need it *now*.
[14:37] <dobey> well, we do, but whatever
[14:38] <gord> hi all, me again, ubuntu one has gone crazy :) it just dies after you try and start it, ie: using u1sdtool -s or -c or anything, it starts, then dies. grepped http://paste.ubuntu.com/615344/ from syncdaemon-error.log which seems to be the cause
[14:38] <dobey> gord: are you on O?
[14:38] <gord> dobey, still on natty
[14:38] <dobey> gord: and not using the gnome3 ppa?
[14:39] <alecu> dobey, we currently have to run the tests twice, because we can't have the qt and the glib reactors installed. So I say we do the dbus part of the tests using the glib reactor, and the qt part of the test on their own.
[14:39] <gord> dobey, nope
[14:40] <dobey> gord: ok, good; then hopefully someone can help you. might be due to today being a server rollout day though.
[14:40] <mandel> alecu: getting back to your issues with the reactor, what was the problem, just hte treads and the fact that you had to create the QAppliation first?
[14:41] <alecu> mandel, the issue had to do with the initialization order.
[14:42] <mandel> alecu: well, is a feature from the qtreactor, rather than a bug…
[14:42] <dobey> alecu: well, i don't understand what that has to do with fixing the obvious bugs in devtools.
[14:43] <alecu> mandel, no, wait, there's more: you could not even define any class that derives from dbus.service.Object
[14:43] <mandel> alecu: do you have some code that shows that error?
[14:44] <alecu> you have to make sure that the DBusQtMainLoop and the QtApplication are created before even doing any class xxx(dbus.service.Object).
[14:44] <alecu> mandel, I have a bit of code, yes.
[14:45] <mandel> alecu: may I see it to try to understand the error?
[14:45] <alecu> mandel, sure... I'll push in a minute.
[14:45] <mandel> cool
[14:47] <dobey> alecu: well, the main() should be creating a QApplication and setting up DBusQtMainLoop(), no?
[14:48]  * fagan back
[14:48] <dobey> alecu: gtk+/glib isn't really any different in that respect
[14:48] <fagan> i have to go again to pick up glasses in an hour though
[14:50] <alecu> fagan, reading glasses or drinking glasses?
[14:51] <fagan> alecu: well seeing far away glasses
[14:51] <fagan> not really reading glasses
[14:51] <mandel> dobey: indeed, that seems perfectly logical
[14:53] <alecu> dobey, right. Main() should be creating QApplication and DBusQtMainLoop. But you can't import any module that defines a class derived from dbus.service.Object till the QApplication has been created.
[14:54] <fagan> ok so who is going to help me figure out why u1cp doeesnt think im connected to the internet
[14:54] <alecu> mandel, dobey: https://code.launchpad.net/~alecu/%2Bjunk/qt-dbus-fails/
[14:54] <dobey> alecu: well importing  should be fine, no? It's instantiation that should fail
[14:54] <alecu> dobey, no.
[14:55] <alecu> dobey, import is fine for glib, but fails for qt.
[14:55] <alecu> dobey, if you run "fails.py" in the branch I pasted above it shows the error.
[14:56] <alecu> uh.,
[14:56] <alecu> I guess you are right :P
[14:56] <ralsina> fagan: it's a change in network manager
[14:57] <fagan> ralsina: ah ok then
[14:57] <fagan> ralsina: then that takes away 1 work item for me :D
[14:57] <alecu> dobey, anyway, instantiation does not fail, it just prints a warning.
[14:57] <fagan> Ill sort payroll then
[14:57] <mandel> alecu: looking
[14:58] <dobey> alecu: also, why did you use qtreactor for that test instead of regular qt loop? :)
[14:59] <dobey> well, anyway, i was right :)
[14:59] <alecu> :P
[14:59] <dobey> so fix your code. and weird that it doesn't raise something, yeah
[15:01] <alecu> It prints a warning, but it fails, because nothing gets exported on the bus... let's see.
[15:02] <dobey> well, trying to do something with those dbus interfaces later will fail, but it should give you some way to handle the problem right there, instead of being a latent error
[15:04]  * alecu needs to go to read the dbus decorators' source
[15:04] <alecu> I'll do it some other day.
[15:05] <dobey> it is complicated; but i don't think that warning is coming from the dbus decorators
[15:06] <dobey> or well, not directly. i think it's coming from the dbus.mainloop.qt code, also indrectly
[15:07] <mandel> alecu: why do you import gobject?
[15:08] <fagan> ok payroll done ralsina have anything for me to do
[15:08] <alecu> mandel, because that snippet was converted from a glib dbus sample.
[15:08] <fagan> i have a little less than an hour before I have to run again
[15:08] <ralsina> fagan: find out when network manager changed online detection for me, please ;-)
[15:08] <fagan> ralsina: cool
[15:08] <dobey> grmbl grmbl
[15:09] <dobey> oh bother, i have to buy postage stamps today
[15:15] <fagan> ralsina: ok so the change as now they have states and they are all listed here http://projects.gnome.org/NetworkManager/developers/migrating-to-09/spec.html#type-NM_DEVICE_STATE
[15:16] <ralsina> fagan: ooooook
[15:16] <ralsina> fagan: check if there is a bug, if not create it and add that link to it, please
[15:16] <ralsina> bug on us, not on NM
[15:16] <fagan> ill create it id say no one is on 11.10 yet
[15:18] <dobey> lots of people are on 11.10 yet
[15:18] <dobey> and i think it's also an issuse in the gnome3 ppa on 11.04
[15:18] <fagan> do they have network-manager updates in that ppa?
[15:19] <mandel> alecu: so if I understand correctly the issue is that if you don't create the QApplication at the very beggining  you get the warnings and  the dbus code does not work right?
[15:19] <dobey> fagan: i think so now
[15:19] <dobey> mandel: it's if you don't create the QApplication before instantiating the dbus objects
[15:20] <dobey> mandel: when using DBusQtMainLoop
[15:21] <mandel> dobey: yes, but that makes complete sense, the DBusQMainLoop requires QThreads and a QThreads needs to know the instance of the application to be able to work
[15:21] <dobey> mandel: right
[15:22] <mandel> dobey: then I see no problem, sorry, is just that the code is wrong
[15:22] <dobey> mandel: problem is that it's just a stupid warning on stdout or stderr it seems, when it should probably raise an exception
[15:22] <dobey> mandel: if only to tell the programmer "hey, you're doing it wrong numbskull!"
[15:23] <mandel> dobey: hahaha true, that is a shitty way to tel someone he is doing it wrong
[15:23] <fagan> Bug #790717
[15:23] <ubot4`> Launchpad bug 790717 in ubuntuone-client "Changes to the network manager break network detection (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/790717
[15:23]  * fagan grabs some food
[15:23] <dobey> mandel: que ella eso! :)
[15:26] <mandel> hahaha
[15:26] <mandel> alecu: then I'm goingto change the code that adds the correct reactor for you to use, and we will see what is going on
[15:27] <mandel> alecu: I though you had a more complicated issue and did a qt + twisted integration using a diff reactor because there was a bigger issue
[15:29] <alecu> mandel, I'm back.
[15:34] <mandel> alecu: I have a branch with the reactor installing according to the platform that I'll push and I'd like you to take a look, if that is ok I'll like to move to remove the Dbus main loop from main and move it in a platform specific part
[15:34] <ralsina> ok, I am about to take a break. Anyone need something from me right now?
[15:35] <mandel> alecu: I'd like to be able to show the UI on windows by this afternoon
[15:35] <mandel> with no backend work at all, just Ui
[15:35] <ralsina> alecu, mandel: yes, that would be good news
[15:35] <alecu> mandel, cool
[15:44]  * fagan goes to get glasses
[15:58] <mandel> I officialy hate that importing the reactor installs it, that i ugly ugly guly...
[16:02] <dobey> hrmm
[16:02] <dobey> all this defer.inlineCallbacks stuff is causing problems
[16:02] <dobey> mandel: the default select reactor, you mean?
[16:03] <alecu> dobey, how is inlineCallbacks causing problems?
[16:03] <mandel> dobey: yes, is a pain, they should allow you to import the reactor and then install what ever you wanted, I cannot see the reasoning behind the current implementation
[16:04] <dobey> alecu: in the DBusTestCase stuff
[16:05] <dobey> alecu: i am not sure how to explain what i am seeing though
[16:05] <dobey> alecu: because i don't know why the current code is designed the way it is
[16:07] <dobey> i think because of ubuntuone-client, but sso and cp aren't doing stuff the same way
[16:08]  * dobey tries u1client tests with his devtools branch
[16:09]  * fagan back
[16:14] <mandel> alecu: can you take a look at: https://code.launchpad.net/~mandel/ubuntuone-control-panel/use_correct_reactor/+merge/62961
[16:29] <dobey> bbiab, lunch time
[16:39] <mandel> alecu: ping
[16:39] <alecu> mandel, pong
[16:40] <mandel> alecu: did you take a look at the merge proposal I sent you?
[16:46] <alecu> mandel, not yet... gimme me a few minutes.
[16:47] <fagan> mandel: I could look at it...
[16:47] <mandel> alecu: ok, I need to go to walk the dog and some errands, will be back later to fix any commnets and try to get the control panel running on windows
[16:47]  * mandel walks dog + others
[16:47] <alecu> mandel, ok, cool.
[17:32] <fagan> EOD
[17:32] <dobey> back
[17:52]  * nessita is back from U
[17:59] <dobey> hrmm
[17:59] <dobey> i think windows updated bricked my windows 7 install
[18:01] <AJenbo> dobey, did you remember to do the happy dance while it was updating?
[18:01] <dobey> oh, now the .. is moving on the update/boot screen, but the hdd light isn't blinking so much
[18:02] <cwayne> ello
[18:02] <dobey> hi cwayne
[18:02] <cwayne> i just have a quick question, is the hash that the rest api gives you when you GET a file/folder md5 or sha1
[18:03] <AJenbo> dobey, yeah i does that fore some of the big onces, not really sure what it is wating for
[18:12] <nessita> mandel: ping
[18:17] <dobey> i feel like my laptop is crying
[18:27] <dobey> sigh
[18:47] <dobey> damn, this update better be "upgrading to windows 8" or something
[18:48] <dobey> it has been running for about an hour now, and is still on "Installing update 1 of 12 .. .. .."
[18:54] <nessita> mandel, ralsina: ping?
[18:55] <nessita> dobey: hey there. Were there any updates regarding the isssues we were having with devtools + qtreactor + dbus?
[18:55] <nessita> dobey: do you need some help?
[18:56] <dobey> nessita: i just proposed https://code.launchpad.net/~dobey/ubuntuone-dev-tools/dbus-priv/+merge/63022
[18:57] <nessita> dobey: reviewing
[18:57] <dobey> nessita: it's partial fix (only one of the issues), but helps a lot
[18:57] <nessita> dobey: right, this doesn't fix the cleanup on tearDown, no?
[18:57] <dobey> awesome; now my laptop's screen is just black :(
[18:58] <dobey> nessita: right, there are some very weird issues with the cleanup issue; and i'm not sure i understand everything well enough, and tcole hasn't replied to my earlier ping yet
[18:58] <dobey> and i haven't seen him on irc at all
[18:59] <nessita> dobey: testing the branch now... (code looks OK, I would add the actual value of DBUS_SESSION_BUS_ADDRESS to the execption string)
[18:59] <nessita> exception*
[19:00] <tcole> dobey: ?
[19:00] <dobey> tcole: so i think the inlineCallbacks in the DBusTestCase that you added is causing more issues
[19:01] <tcole> dobey: it might be *exposing* more issues, but believe me it is the correct thing
[19:02] <tcole> dobey: there's a problem with the way that super() chains in trunk, b/c of testtools & testresources bugs :(
[19:02] <dobey> tcole: hrmm, when I get rid of it, and some other code in that testcase though, everything seems to work as expected in sso-client, control-panel, and u1client
[19:02] <tcole> dobey: I have a branch that sorts that out too, but I needed all of these things in the various projects before I could pull them all together
[19:02] <tcole> dobey: argh, well, those tests may have been written wrong
[19:02] <tcole> adapted to the incorrect behavior or something
[19:03] <tcole> *believe me* that chaining deferreds to the parent class setUp is correct
[19:03] <dobey> tcole: is there a specific issue i can replicate which you were fixing, to see if my changes break it or not, so i can understand all this insanity a bit better?
[19:03] <tcole> dobey: no, it's just that you're supposed to wait for the parent class setUp to complete before setUp returns
[19:03] <tcole> dobey: and we weren't doing that there
[19:03] <tcole> dobey: it's part of the defined interface for twisted.trial.unittest.TestCase
[19:03] <dobey> tcole: but i think the yield does that, right? what does inlineCallbacks have to do with that?
[19:04] <tcole> dobey: inlineCallbacks and yield go together
[19:04] <tcole> dobey: the yield makes the function a generator, and inlineCallbacks massages that back into a function that returns a deferred
[19:06] <dobey> hmm
[19:06]  * dobey deletes a bunch of code, makes some changes, and hopes it works
[19:07] <tcole> it isn't strictly necessary to use yield+inlineCallbacks to do this, but it yielded a smaller diff
[19:07] <tcole> (no pun intended)
[19:10] <nessita> alecu: do you know about mandel or ralsina?
[19:10] <nessita> are they gone for the day? are they coming back?
[19:11] <alecu> nessita, I know they are both bearded.
[19:11] <nessita> alecu: well, mandel mentioned he shaved a while ago, so who knows!
[19:11] <dobey> heh
[19:11] <alecu> nessita, mandel said he was coming back after walking the dog and some errands.
[19:12] <alecu> oh, right.
[19:12] <alecu> nessita, and ralsina said he was taking a break.
[19:12] <nessita> ack, thanks
[19:12] <alecu> he didn't specify how long
[19:12] <nessita> I'll wait for them eagerly :-)
[19:12] <nessita> alecu: how are your cp stuff going?
[19:13] <alecu> nessita, weird. I'm getting a "Segmentation fault" after adding some lines of python code, so I'm not happy.
[19:14] <nessita> alecu: is there any dbus involved?
[19:14] <alecu> not at my layer, but surely in the backend.
[19:14] <nessita> that sucks
[19:14] <alecu> nessita, perhaps I need to fake that part, like you did, right?
[19:14] <nessita> right
[19:15] <nessita> alecu: any odea in which layer you have some dbus?
[19:15] <nessita> idea*
[19:15] <dobey> hrmm, no love
[19:15] <nessita> dobey: need help? I'm skilled with yields and inlineCallbacks
[19:16] <alecu> nessita, backend.devices_info is the one calling syncdaemon thru dbus.
[19:17] <alecu> that's the issue :-(
[19:17] <nessita> alecu: you can use my branches
[19:17] <dobey> nessita: i think i need a miracle
[19:17] <nessita> alecu: and that will abstract you from dbus. Please merge trunk in
[19:17] <nessita> dobey: no way :-). Wanna be more specific? I may help
[19:17] <nessita> (at least I can try)
[19:18] <alecu> nessita, will do, thanks!
[19:18] <nessita> alecu: merging the last branch of mine that landed this morning, there is no more DBus for syncdaemon (except for the StatusChanged signal). Then, if you look at:
[19:18] <nessita> gui/qt/gui.py
[19:18] <nessita> you will find that I fake the SyncDaemonTool patching the "system" one
[19:18] <nessita> and then you can add all the fixed info you need
[19:19] <nessita> to run IRL, that is
[19:20] <tcole> dobey: if it aids understanding, these two implementations of setUp are functionally equivalent: https://pastebin.canonical.com/48004/
[19:21] <tcole> dobey: oops
[19:21] <tcole> dobey: hang on
[19:21] <tcole> dobey: okay, try this: https://pastebin.canonical.com/48005/
[19:21] <tcole> I made a typo in the first paste
[19:25] <dobey> so if that is correct, what is causeing the shsutdown failures then
[19:29] <alecu> nessita, can I have your review on this? https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client/+merge/62889
[19:29] <nessita> alecu: sure, I'll do it in a couple of mins (finishing with dobey's)
[19:32] <nessita> dobey: approved
[19:36] <dobey> tcole: i don't understand what is keeping these dbus connectsions open then; because when i remove all the defer.inlineCallbacks magic, it seems to work :(
[19:37] <tcole> dobey: what happens when you use the non-inlineCallbacks version instead?
[19:38] <tcole> (from the pastebin)
[19:38] <dobey> tcole: http://pastebin.ubuntu.com/615467/ works, but if I add the decorator, it fails.
[19:38] <dobey> tcole: hrmm, let me try
[19:39] <tcole> dobey: if that makes things pass where the inlineCallbacks version doesn't, then I'm totally OK with replacing the inlineCallbacks version with the explicitly callbacked one, but we do need one or the other to be correct :/
[19:40] <dobey> exceptions.AttributeError: 'NoneType' object has no attribute 'addCallback'
[19:41] <dobey> tcole: ^^^ get that with yours
[19:41] <tcole> hnnnh
[19:41] <nessita> dobey: that means that you have a function decorated with inlineCallbacks that does not return a deferred
[19:42] <nessita> dobey: where are you getting that error?
[19:42] <dobey> nessita: in trying to use tcole's suggested other implementation of setUp without inlineCallbacks
[19:43] <nessita> dobey: can you please point me to a branchable branch (:-P) to be run by myself?
[19:43] <tcole> dobey: so, apparently (in the failing test cases) there's another class in the inheritance hierarchy which is getting put before TestCase.setUp in the method resolution order, and itself fails to chain callbacks correctly via setUp
[19:44] <tcole> nessita: I strongly suspect MI/mixin shennanigans wrt chaining setUp deferreds :/
[19:44] <nessita> tcole: maybe, but is hard to guess for me without imagining what code is failing
[19:45] <nessita> alecu: question, why the rename ubuntuone/controlpanel/web_client/linux.py => ubuntuone/controlpanel/web_client/libsoup.py?
[19:45] <tcole> nessita: it's apparently coming from the modified setUp in this case -- this means that super(DBusTestCase, self).setUp() is returning None and not a deferred
[19:45] <nessita> alecu:  and... OH, we're both editing some ui files at the same time (smells like BOOM spirit)
[19:46] <tcole> nessita: which shouldn't normally happen since the next class up in the hierarchy which defines setUp is twisted.trial.unittest.TestCase, which *does* return a deferred
[19:46] <alecu> nessita, because on linux we may use other webclient other than libsoup. Ie, twisted.web.client.
[19:46] <dobey> nessita: no, because i haven't pushed one, because i'm experimenting to try and understand this better so i can fix the problems
[19:46] <dobey> tcole: the only thing in the middle is BaseTestCase in the same file, which doesn't override setUp/tearDown at all
[19:46] <tcole> nessita: so, for the things that are failing, some other class is getting interposed in the inheritance linearization via multiple inheritance
[19:46] <nessita> dobey: wanna push so we can help debug?
[19:46] <alecu> nessita, we can manually merge, it's not so complicated.
[19:46] <tcole> dobey: right, but MI downstream can end up inserting other classes in the method resolution chain between them
[19:47] <dobey> hrmm
[19:47] <nessita> mandel: I need you to review a Needs Fixing, please!
[19:47] <tcole> dobey: DBusTestCase -> BaseTestCase -> t.t.u.TestCase
[19:48] <tcole> dobey: but let's say we have a class Foo(DBusTestCase, WheeTestCase), where WheeTestCase -> t.t.u.TestCase
[19:48] <dobey> tcole: so, i am getting that failure i pasted in the devtools tests, and there is no MI in there
[19:48] <tcole> huh
[19:48] <dobey> tcole: the missing addCallback, that is
[19:48] <dobey> hrmm
[19:49] <tcole> I don't know then, the tests passed for me before I proposed that branch
[19:49] <tcole> s/before/when/
[19:49] <tcole> and for that matter they got through tarmac if it landed
[19:51] <dobey> well tarmac didn't do the non-inlineCallbacks method
[19:51] <nessita> dobey: inlineCallbacks + yield is 100% equivalent to chaining callbacks
[19:52] <nessita> dobey: can you please push what you're modifying so we can help you by looking at the code itself?
[19:52] <tcole> nessita: not completely, IIRC inlineCallbacks uses maybeDeferred with yield
[19:53] <nessita> tcole: you sure?
[19:53] <tcole> I'm pretty sure yes
[19:53] <tcole> anyway, the parent class setUp really *shouldn't* be returning None in this case; since it is, that suggests something else is wrong
[19:54] <tcole> maybeDeferred shouldn't be needed in this case
[19:54] <dobey> tcole: ok; so i figured out that problem
[19:54] <thisfred> something in the class hierarchy fails to call super (correctly), is my hunch
[19:54] <dobey> super() is dumb.
[19:55] <tcole> nessita: seems I'm wrong, inlineCallbacks doesn't automatically use maybeDeferred
[19:55] <tcole> dobey: oh?
[19:55] <dobey> if the parent class doesn't override the method, then it apparently isn't calling that parent's method as well
[19:56] <dobey> so for some reason, it got None
[19:56] <mandel> nessita: pong
[19:56] <tcole> dobey: normally when that happens it's because of MI and a mixed-in class that defines setUp without calling super()
[19:56] <dobey> if i add a setUp() to BaseTestCase that just does super() though, the AttributeError thing went away
[19:56] <mandel> nessita: is kind of late her but tell me
[19:56] <nessita> mandel: hey there! I was just looking at your branch. 2 things:
[19:56] <tcole> mm
[19:56] <tcole> dobey: so, that shouldn't be necessary
[19:57] <tcole> dobey: can you show me the __mro__ for the test class where this is actually failing?
[19:57] <nessita> mandel: could you please approve https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/update-file-sync-status/+merge/62575? your Needs Fixing is preventing me from lkand
[19:57] <nessita> land*
[19:57] <mandel> nessita: done
[19:58] <tcole> dobey: like, if the failure(s) happen when running the tests in SomeTestCase, I'd like to see SomeTestCase.__mro__
[19:58] <nessita> mandel: the other thing, in your credentials branch, you are duplicating all the logger setup in both linux and windows code. In the review I asked you to move that to the non-platform specific code
[19:58] <nessita> mandel: maybe you forgot to push that?
[19:58] <nessita> mandel: thanks to the review!
[19:58] <mandel> nessita: oh, indeed
[19:58] <mandel> nessita: I'll do it right now
[19:58] <nessita> mandel: thanks! then I'll approve also globally, so it lands
[19:59] <dobey> hmm
[20:00] <dobey> tcole: ok, one minute
[20:00] <dobey> (or five)
[20:00] <nessita> alecu: can you please merge into your branch the one from https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/update-file-sync-status/+merge/62575? is about to land and I can tell it will cause conflicts with yours
[20:01] <alecu> nessita, ok
[20:05] <dobey> tcole: hrmm, how do i see that?
[20:05] <tcole> dobey: eh, do a sys.stderr.write("DEBUG: mro = %r\n" % (SomeClass.__mro__,)) or something
[20:05] <tcole> (note well the tuple comma)
[20:06] <tcole> or just import stuff in an interactive python session
[20:06] <tcole> at which point you can just evaluate SomeClass.__mro__ interactively
[20:08] <mandel> nessita: changes pushed
[20:08]  * mandel changing network...
[20:09] <dobey> tcole: (<class 'ubuntuone.devtools.services.tests.test_dbus.TestWithDBus'>, <class 'ubuntuone.devtools.testcase.DBusTestCase'>, <class 'ubuntuone.devtools.testcase.BaseTestCase'>, <class 'twisted.trial.unittest.TestCase'>, <class 'twisted.trial.unittest._Assertions'>, <class 'unittest.case.TestCase'>, <type 'object'>)
[20:09] <tcole> huh.
[20:10] <tcole> so, if BaseTestCase doesn't define its own setUp(), super(DBusTestCase, self).setUp() should totally go straight to twisted.trial.unittest.TestCase.setUp
[20:10] <dobey> i would think so too, but it doesn't seem to be
[20:12] <dobey> tcole: although, twisted.trial.unittest.TestCase doesn't define a setUp either :(
[20:12] <dobey> nor does _Assertions
[20:13] <tcole> hmm
[20:13] <nessita> mandel: ack
[20:15] <dobey> rather
[20:15] <dobey> twisted's TestCase seems to call setUp inside a maybeDeferred
[20:16] <dobey> same with tearDown (and all the tests actually)
[20:17] <dobey> looking at the code it seems like the general case should be to just write stuff like it's normal unittest bits without deferreds?
[20:17] <nessita> dobey: any hints about why https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/update-file-sync-status/+merge/62575 failed? I think the key error is:
[20:17] <nessita> sh: pyrcc4: not found
[20:18] <dobey> nessita: sounds like it's failing to build stuff?
[20:18] <nessita> dobey: tarmac needs pyqt4-dev-tools
[20:18] <mandel> alecu: ping
[20:18] <alecu> mandel, pong
[20:18] <nessita> dobey: can you please install it?
[20:18] <mandel> alecu: did you have the time to look at the branch?
[20:18] <tcole> dobey: unfortunately that won't work
[20:19] <tcole> (reliably)
[20:19] <alecu> mandel, yes, and it needs fixing
[20:19] <mandel> alecu: cool, I'll take a look
[20:19] <tcole> dobey: everyone has to consistently chain deferreds or it all goes wonky and race condition-y
[20:19] <dobey> tcole: unfortunately, in my experience "reliable" and "twisted" don't go together :(
[20:20] <dobey> nessita: when was that added as a dep?
[20:20] <mandel> alecu: he, stupid non compiled langs… Is funny that pylint did not catch that problem
[20:20] <nessita> dobey: with this branch. Shall I have added to any predefined list? (I forgot to tell you directly)
[20:20] <mandel> alecu: for testing we should move the dbus stuff out… I'll work on it
[20:21] <dobey> nessita: i don't see where it gets called in that branch?
[20:22] <nessita> dobey: is automatically being called by setup build, something in the qt build chain generates the proper resources files that we now need for icons
[20:22] <dobey> tcole: hrmm, i wonder what is deriving from us that is chaining deferreds on setUp?
[20:22] <tcole> dobey: everything should
[20:24] <dobey> tcole: ok, well i don't understand how to fix this then; the only apparent proper solution to me seems to be "twisted needs to gtfo" :-/
[20:25] <tcole> dobey: I think using maybeDeferred in DBusTestCase could be sufficient
[20:25] <tcole> yield maybeDeferred(super(DBusTestCase, self).setUp)
[20:26] <dobey> ugh
[20:26] <tcole> trying to work out in my head whether that covers the MI case
[20:26] <tcole> I think it does
[20:27] <dobey>   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 133, in maybeDeferred
[20:27] <dobey>     result = f(*args, **kw)
[20:27] <dobey> lol. fml.
[20:27] <dobey> exceptions.TypeError: 'NoneType' object is not callable
[20:27] <nessita> mandel: tons of lint issues! :-)
[20:29] <nessita> mandel: errors added to the merge proposal
[20:29] <nessita> dobey: would you please let me know when the new dep is installed so I can re-approve?
[20:29] <dobey> nessita: oh sorry; it is installed now
[20:29] <nessita> dobey: thanks!
[20:30] <dobey> distracted by twisted and qt being horrible things :-/
[20:31] <tcole> twisted gtfo is sounding pretty appealing just now
[20:31] <nessita> dobey: you still don't show me anything so I can help you with! :-)
[20:32] <tcole> nessita: we just hit a design problem in twisted -- DBusTestCase (and any class like it) needs to chain setUp with super() to be MI-safe
[20:32] <tcole> nessita: but Twisted's TestCase (nor any of its ancestors) doesn't define its own setUp
[20:32] <dobey> nessita: i don't think there's any way to fix wrapper(None) trying to call None(*args, **kwargs) from breaking
[20:32] <nessita> tcole: I will suggest asking jml directly, he built that as far as I know :-)
[20:33] <tcole> nessita: he seems to be away on an extended basis atm
[20:33] <nessita> oh
[20:34] <dobey> i would be too if it was 20:30 here
[20:34] <nessita> right
[20:34] <tcole> I meant more "idle for 4 days" extended
[20:34] <nessita> email him maybe?
[20:34] <mandel> nessita: really? but I did not change a think… man I hate lint, I'll fix them asap
[20:35] <dobey> mandel: see my e-mail to the list about switching to pyflakes, and tell me what you think :)
[20:35] <nessita> mandel: "I did not change a thing" <- lier! you moved stuff around like crazy :-)
[20:35] <nessita> dobey: right, I need to dive in too
[20:36] <mandel> nessita: well I moved the logger, but nothing else… it does not make sense to block due to that… anyway I'll fix them
[20:36] <nessita> dobey: at this stage I think you're right, you now. Though I may be running pylint myself as a personal measure
[20:36] <mandel> dobey: yes, I hate lint, I also hate that ython is not compiled...
[20:36] <nessita> mandel: well, you left ununsed imports
[20:37] <thisfred> I have not yet found anything I'd miss from pylint that pyflakes does not have
[20:37] <dobey> mandel: yes; we can just summarize all that as "i hate python" :)
[20:37] <nessita> mandel: I'll approve, once your lint changes kick in, approve the merge proposal yourself, yes?
[20:37] <dobey> thisfred: well there is the XXX/FIXME/etcc customization
[20:37] <thisfred> meh
[20:37] <dobey> thisfred: and it's nice to shove those in your face during the lint run
[20:37] <mandel> nessita: sure
[20:37] <dobey> thisfred: even if all it makes you do is remove them from the code
[20:38] <mandel> dobey: hehe yes, I'm starting to do it a little :)
[20:38] <thisfred> dobey: I suppose, yeah
[20:38] <tcole> dobey: I think I may have a short-term fix
[20:38] <nessita> alecu: my branch landed (FYI)
[20:38] <tcole> dobey: let me ponder some more
[20:38] <alecu> great
[20:38] <dobey> tcole: ok
[20:39] <dobey> hrmm
[20:43] <dobey> grr
[20:44] <nessita> alecu: let me know when I should re branch yours to review
[20:45] <tcole> dobey: so, I think basically what we have to do, until I get twisted straightened out, is this:
[20:45] <tcole>     superSetUp = super(DBusTestCase, self).setUp
[20:45] <tcole>     if superSetUp is not None:
[20:45] <tcole>         yield defer.maybeDeferred(superSetUp)
[20:46] <tcole> dobey: thankfully not everywhere, but in fact for every class which doesn't normally get a defined setUp from its ancestors
[20:47] <alecu> tcole, may I suggest not using super, and manually calling the parent class setUp?
[20:47] <alecu> tcole, as per http://fuhm.net/super-harmful/
[20:47] <tcole> alecu: NO
[20:47] <dobey> hrmm
[20:48] <tcole> I agree with that article, but our situation is one where we have no choice but to use super and use it consistently
[20:48] <tcole> in any case, the problem here is that the parent class may not have setUp
[20:49] <dobey> well one problem
[20:49] <alecu> but "Superclasses must use super if their subclasses do". And we can't modify all of trial and twisted, so manually calling the right setUp on the parent sounds reasonable.
[20:49] <dobey> afaict it works perfectly fine (actually, everything is working as i expect it would), without all the inlineCallbacks stuff
[20:50] <dobey> i don't understand how doing inlineCallbacks actually makes anything work, since for me, all it does is make stuff not work :(
[20:54] <tcole> dobey: it's mainly for the MI case
[20:55] <tcole> alecu, dobey: unfortunately we have a lot of MI happening with twisted test cases; our only choice is to use super consistently everywhere
[20:55] <dobey> can i just make the test case check for MI and fail with a GTFO message? :)
[20:55] <tcole> not easily
[20:56] <tcole> that wouldn't really help either
[20:56] <dobey> tcole: i don't mind calling super(); that is fine by me; my problem is that for some reason @inlineCallbacks makes what i'm doing just not work
[20:56] <dobey> if i remove @inlineCallbacks, it works perfectly
[20:56] <tcole> well, there is the problem of the None-setUp from above
[20:56] <tcole> that is part of the breakage there
[20:57] <tcole> dobey: with inlineCallbacks, I mean
[20:57] <dobey> that doesn't explain why my own tearDown doesn't seem to be getting called
[20:57] <dobey> or at least, not called consistently
[20:57] <tcole> your teardown is asynchronous, isn't it?
[20:58] <tcole> typically what is going on in those cases is that the teardown is being called, but the deferred is not chained/waited for
[20:58] <dobey> not now; it has 3 yield foo(), the last of which is calling super() with the check for parent tearDown being there
[20:58] <tcole> that's asynchronous yes
[20:58] <tcole> at least from an outside perspective
[20:59] <tcole> anyway, probably you're ending up with a race condition where someone is calling your tearDown (via super() or otherwise), but not waiting for it, so there's a race condition as far as whether it can complete before the test cleanup finishes
[20:59] <tcole> if not, unclean reactor etc.
[21:00] <tcole> but, let's try the superSetUp thing next
[21:00] <tcole> and see how far that gets us
[21:00] <dobey> then is there any good reason to not remove the inlineCallbacks wrappers until wisted is fixed?
[21:01] <dobey> the checking for parent setUp/tearDown works fine, but inlineCallbacks still breaks the world
[21:02] <tcole> well, is it really inlineCallbacks?
[21:03] <dobey> well, if i remove it, it works; if i add it, it breaks
[21:03] <tcole> that's a bit simplistic
[21:03] <tcole> here, let me do up the equivalent explicit callbacks version
[21:04] <dobey> well, i have no idea how else to debug why my teardown isn't working right
[21:04] <dobey> inlineCallbacks got added to setUp, and stuff started breaking; if i remove it, things work right again
[21:06] <dobey> hell, i'll tweak the twisted code and see if it fixes it then
[21:06] <tcole> dobey: try this: https://pastebin.canonical.com/48013/
[21:06] <tcole> it *should* fail in the same way as with inlineCallbacks
[21:06] <tcole> if it doesn't then that tells us some things though
[21:07] <tcole> hopefully at that point we can focus more specifically on what's going on in tearDown
[21:10] <dobey>         yield self.bus.flush()
[21:10] <dobey>         yield self.bus.close()
[21:10] <dobey> that's basically tearDown()
[21:10] <dobey> with a check/yield/maybeDeferred on the super() call after that
[21:12]  * tcole nods
[21:14] <dobey> tcole: hrmm, with that way of doing things, it seems that the setup_dbus never gets called
[21:17] <dobey> exceptions.AttributeError: 'TestWithDBus' object has no attribute 'bus'
[21:17] <dobey> that happens when tearDown() gets called
[21:20] <tcole> interesting
[21:21] <tcole> what happens if you short-circuit it with d = defer.succeed(None) ?
[21:21] <tcole> (putting that after the if/else)
[21:21] <thisfred> well, since superSetup apparently is None in some cases, it's unsurprising
[21:21] <thisfred> since in that case it's not called.
[21:21] <tcole> why would that be unsurprising?
[21:21] <tcole> thisfred: given this: https://pastebin.canonical.com/48013/
[21:22] <dobey> overriding the d instantiation doesn't help
[21:23] <thisfred> well the super method being None is the problem, but all this does is explicitly break the super chain, right? so the setting of the .bus property not happening is unsurprising
[21:27] <tcole> thisfred: have you read the code I pasted?
[21:27] <tcole> if superSetUp is None, then it falls through to the d = defer.succeed(None) case
[21:27] <thisfred> tcole, yep.
[21:27] <tcole> after which point d.addCallback(setup_dbus) is called
[21:27] <tcole> and that should call setup_dbus immediately
[21:27] <tcole> and setup_dbus sets self.bus
[21:27] <thisfred> ah right
[21:28] <thisfred> I only read the first part
[21:28] <thisfred> so then the issue is the callback does not fire at all?
[21:28] <dobey> tcole: isn't defer.succeed() supposed to take True/False as argument, not None?
[21:28] <dobey> though I guess None evals to False
[21:29] <tcole> dobey: no, it takes a result
[21:29] <dobey> thisfred: it doesn't appear to get called
[21:29] <tcole> dobey: which gets passed to callbacks
[21:29] <dobey> ah ok
[21:29] <tcole> http://twistedmatrix.com/documents/8.1.0/api/twisted.internet.defer.html#succeed
[21:30] <dobey> so definitely not getting called
[21:30] <dobey> i added a raise to the setup_dbus, and nothing happens.
[21:31] <tcole> is superSetUp not None, perhaps?
[21:32] <thisfred> it should only ever be None in the "superest" class right?
[21:33] <thisfred> no, the ultimate base class can't call super, that would just fail
[21:34] <thisfred> I don't see how it can ever be None, rather than an attribute error
[21:35] <dobey> so it's not
[21:35] <dobey> the problem is that it returns None
[21:35] <thisfred> right
[21:36] <dobey> since it ultimately is hitting the unittest.TestCase.setUp
[21:38] <tcole> I thought TestCase didn't have a default setUp
[21:39] <tcole> hm, so it does
[21:39] <dobey> unittest does
[21:39] <dobey> twisted doesn't
[21:40] <tcole> but twisted apparently inherits from TestCase
[21:40] <tcole> er, from unittest
[21:40] <dobey> yes
[21:40] <dobey> but 'pass' just gives you back a None :)
[21:40] <tcole> I feel like we've been here before
[21:40] <dobey> watch out for windows that don't exist any more
[21:42] <tcole> dobey: all right, so... as far as the original problem you were hitting
[21:42] <tcole> what's the briefest way to reproduce?
[21:43] <thisfred> what happens if you do this: https://pastebin.canonical.com/48018/
[21:44] <thisfred> or does that fail in case the setup *does* return a deferred?
[21:48] <dobey> did this instead: https://pastebin.canonical.com/48019/
[21:48] <dobey> but still fails
[21:48] <dobey> the _setup_dbus doesn't seem to get called
[21:48] <dobey> or twisted is just trapping the exception
[21:49] <thisfred> does pdb.set_trace() work?
[21:50] <thisfred> or just debug prints, to see what the values are
[21:51] <dobey> work where?
[21:51] <dobey> so i know that the defer.succeed() is being called there
[21:52] <thisfred> in this setUp, so you can see what d is? I suppose it is None
[21:52] <thisfred> right
[21:52] <thisfred> and the callbacks are added, they just never get called
[21:53] <dobey> right
[21:53] <dobey> i am guessing it is just twisted being broken
[21:54] <tcole> I don't even know at this point
[21:56] <thisfred> t.t.u.TestCase has deferSetup and deferTearDown. Helpfully without any doc strings
[21:57] <dobey> doc strings are for kids. twisted is hardcore.
[22:08] <thisfred> Looks like those are only used internally, to call the class' setUp and tearDown in an asynchronous fashion.
[22:09] <dobey> right
[22:09] <dobey> which totally breaks everything ever
[22:10] <nessita> alecu: how's the merge going? too much trouble? can I help?
[22:11] <tcole> dobey: I think before I waste too much more of your time with this, I should devise a test case that captures the case that the inlineCallbacks change is supposed to fix
[22:11] <thisfred> dobey: it suggests to me though, that subclasses shouldn't have to bother with deferred themselves in either setUp and tearDown
[22:13] <alecu> nessita, a bit messy. yes. no, thanks.
[22:13] <dobey> tcole: i would appreaciate that
[22:13] <nessita> alecu: :-)
[22:13] <dobey> thisfred: right, which is why i want to get rid of the inlineCallbacks usage
[22:13] <thisfred> right
[22:14] <dobey> well, and because getting rid of it makes everything work like how i'd expect it to
[22:16] <tcole> thisfred: no, they have to
[22:16] <tcole> thisfred: subclasses are responsible for chaining deferreds with parent classes
[22:16] <tcole> deferredSetUp only does the initial call to setUp
[22:18] <thisfred> tcole: but that would only matter if the superclasses do anything with deferreds in *their* setup, right? Which the dbus test case does, I guess
[22:18] <dobey> tcole: it seems like what you're trying to say is that parent classes are responsible for chaining deferreds with subclasses, instead; no?
[22:18] <tcole> thisfred: yeah, in practice, though it's not very good to *assume* that the superclass doesn't
[22:19] <tcole> dobey: well, they're responsible for returning a deferred that subclasses can chain to
[22:19] <thisfred> tcole: well, that seems to be twisted's expectation, foolish or no
[22:19] <tcole> dobey: and they're responsible for using super() correctly and chaining to that deferred so that MI works correctly
[22:20] <thisfred> hmm, maybe not. They just cater to the simplest use case
[22:20] <tcole> I don't think whoever wrote this thought this through very carefully
[22:21] <tcole> or maybe MI wasn't part of the intended use case
[22:21] <tcole> but I guess we need to fix that since we have a lot of MI in tests
[22:21] <dobey> i don't think MI matters here right now
[22:22] <tcole> some of DBusTestCase's subclasses in ubuntuone-servers use MI, IIRC
[22:22] <dobey> ugh a recall on my car
[22:24] <dobey> tcole: afaict, nothing in ubuntuone-servers is using DBusTestCase
[22:24] <tcole> lemme check
[22:24] <dobey> some of the ubuntuone-client tests do, and a couple might use MI. not sure
[22:26] <tcole> yeah, it's the client tests apparently
[22:26] <tcole> ./sourcecode/ubuntuone-client/tests/platform/linux/test_dbus.py:class DBusTwistedTestCase(DBusTestCase, BaseTwistedTestCase):
[22:26] <dobey> right
[22:26] <tcole> and it doesn't chain super() correctly
[22:26] <tcole> or the deferred
[22:26] <tcole> gee, I wonder why these tests are so flaky? :P
[22:28] <dobey> but that doesn't explain why adding the deferred junk makes the tests fail that don't use MI
[22:32] <dobey> omfg, someone else decided to name something 'neon'
[22:34] <alecu> dobey, as in "Evangelion" ?
[22:35] <dobey> well, so there is an http library called neon
[22:35] <dobey> and then at UDS, there was that arm graphics project thing mentioned, also called neon
[22:35] <dobey> and now there is a kde thing called project neon
[22:47] <dobey> anyway
[22:47] <dobey> my brain is twisted now
[22:47] <dobey> have a good evening all. hopefully we can fix this tomorrow
[22:48] <dobey> oh, can i get a second review on https://code.launchpad.net/~dobey/ubuntuone-dev-tools/dbus-priv/+merge/63022 please?
[22:48] <dobey> anyway, good evening :)
[22:54]  * nessita -> food hunting, brb
[23:01]  * thisfred off too, see y'all tomorrow
[23:01] <thisfred> let's see if the dog wants to go out in 96F