[00:02] <nessita> (I just subscribed to ubuntu-release, jic)
[00:02] <dobey> nessita: i don't think it's necessary.
[00:02] <dobey> i think joshuahoover attends it though
[00:03] <nessita> ack
[00:03] <nessita> well, then I'm off for now
[00:04] <nessita> dobey: will finish tarballing tomorrow
[00:04] <dobey> cheers
[00:04] <nessita> have a good evening everyone!
[09:39] <mandel> morning all!
[10:41] <gatox> mandel, ping
[10:41] <mandel> gatox, morning!
[10:42] <mandel> gatox, I already approve them, hehe
[10:42] <gatox> mandel, both branches?
[10:42] <gatox> mandel, puuuuuuuuuu..... i get up earlier just to do that!!!
[10:42] <mandel> gatox, yep, is called revenge :P
[10:42] <mandel> gatox, go back to bed ;)
[10:42] <gatox> mandel, jejejeje
[10:43] <gatox> mandel, i hate you....... :@
[10:43] <gatox> jeje
[10:43] <mandel> gatox, buahahahaha
[10:43] <mandel> :P
[12:21] <nessita> hello!
[12:21] <mandel> nessita, morning!
[12:24] <gatox> back!
[12:27] <facundobatista> mandel, hola, che! which one was your branch?
[12:27] <mandel> facundobatista, let me get you the mp
[12:28] <facundobatista> mandel, gracias
[12:28] <mandel> facundobatista, here you go: https://code.launchpad.net/~mandel/ubuntuone-client/add-virtual-watches/+merge/88726
[12:28] <mandel> facundobatista, I removed the any for the subdirs and after some serious coffee and thinking I added tests for the race condition and fixed it
[12:28] <mandel> facundobatista, grep for slow_listdir :P
[12:29] <facundobatista> mandel, awesome!!
[12:31] <ralsina> good morning!
[13:35] <mandel> ralsina, nessita so here are a number of results some WITH failures from jenkins:  https://jenkins.errormessaging.com/job/ubuntu-sso-client-windows-test/37/testReport/?  https://jenkins.errormessaging.com/job/ubuntuone-control-panel-windows-test/41/testReport/? https://jenkins.errormessaging.com/job/ubuntuone-windows-installer-windows-test/65/testReport/? (we need to identify why this is going on)
[13:35] <ralsina> mandel: looking...
[13:35] <mandel> ralsina, nessita jenkins got 'cloudy' due to an error in jenkins itself were it was not pulling correctly the source code
[13:36] <mandel> but that has been fixed
[13:36] <mandel> ralsina, nessita I expect that the next build for u1-client will be a failure with 3 tests (we already now that)
[13:36] <ralsina> mandel: it's looking great!
[13:37] <ralsina> it's actually easier than the console output :-)
[13:37] <mandel> ralsina, hehe
[13:38] <mandel> ralsina, so, with all this sorted out I'm going to ignore jenkins since now we have nice reports etc..
[13:38] <mandel> ralsina, the rest is fixing those broken tests and automating the build of the .exe, which is a complete diff story
[13:39] <ralsina> mandel: sounds good to me
[13:39] <mandel> nessita, gatox I hope that all this setup make you live a little easier when porting the Qt code to linux, at least you will know what was broken earlier etc..
[13:40] <mandel> ok, lunch time for manuel :)
[14:20] <ralsina> nessita: no1-1 while you are on sprint. Enjoy ;-)
[14:31] <nessita> ralsina: ack!
[14:46] <nessita> dobey: ping
[14:50] <dobey> in a call
[14:52] <nessita> dobey: ack, let me know when you have some minutes
[15:01] <mandel> dobey, ralsina standup?
[15:03] <mandel> hola??
[15:03] <ralsina> mandel: oops, no notes!
[15:03] <dobey> pass
[15:03] <ralsina> let's pass
[15:03] <mandel> puos!!! I have notes
[15:03] <mandel> I'm going to paste them :P
[15:03] <ralsina> NEXT mandel:
[15:03] <ralsina> ;-)
[15:03] <mandel> DONE: Fixed Bug 924384 Bug 924369 and ensured that jenkins does work with them. Looked at bug 904554 and bug 873012(ralsina we should talk about this)/
[15:03] <mandel> TODO: Finish fix for bug 904554 and bug 873012. Proxy. Chat with alecu (around my 10pm)
[15:03] <mandel> BLOCKED: no
[15:03] <ubot4> Launchpad bug 924384 in ubuntuone-control-panel "Allow to pass extra parameters to run-tests.bat that should be fowarded to u1trial (affects: 1) (heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/924384
[15:03] <mandel> cabrones!
[15:03] <ubot4> Launchpad bug 924369 in ubuntuone-windows-installer "Add the skip-lint flag to the run-tests.bat (affects: 1) (heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/924369
[15:03] <ubot4> Launchpad bug 904554 in ubuntuone-client "Windows: when creating empty files, those are not uploaded (affects: 1) (heat: 42)" [Medium,Triaged] https://launchpad.net/bugs/904554
[15:04] <ubot4> Launchpad bug 873012 in ubuntuone-windows-installer (and 1 other project) "Should not synchronize Desktop.ini files (affects: 1) (heat: 9)" [Undecided,Confirmed] https://launchpad.net/bugs/873012
[15:04] <mandel> ralsina, we need to talk about bug 873012, we need to consider splitting the configuration between windows and linux
[15:04] <ralsina> dobey: I need to talk with you 5' later today about a few things, is in 4 hours ok with you?
[15:04] <mandel> or something smarter
[15:04] <dobey> sure
[15:04] <ralsina> mandel: is that syncdaemon config?
[15:05] <ralsina> mandel: if so, we can just add another config file "windows.conf" and that's it
[15:05] <mandel> ralsina, yes, so, on windows we need to ignore extra files, yet is that the correct way?
[15:05] <dobey> we can add extra config files easily enough
[15:05] <ralsina> mandel: we'd have to check the configglue docs, but it eems you can have as many config files as you want, so we can just add one that's only there for windows
[15:06] <dobey> but why not just add the ignores to the current config?
[15:06] <dobey> why would you ignore them on one platform, but not the other?
[15:06] <ralsina> dobey: they are platform-specific files
[15:06] <mandel> exactly
[15:06] <ralsina> dobey: a Desktop.ini is "special" on windows, but it's not special on lnux
[15:07] <dobey> right, but why would i want to sync that on linux?
[15:07] <mandel> ralsina, but, multiple config files means that the last loaded one is the one used, and it would be nice to aggregate them rather than one step on the other one
[15:07] <ralsina> mandel: we should number them
[15:07] <mandel> dobey, users are 'special'
[15:08] <ralsina> dobey: because you are a linux-only user and having a file that magically doesn't sync is strange?
[15:08] <mandel> although we have similar issues with users that do Test and test in the same dir :P
[15:08] <dobey> like symlinks?
[15:08] <dobey> or yeah, case sensitivity issues
[15:09] <mandel> dobey, ralsina and thinking about it.. what happens if a sync a funny file called desktop.ini from linux to windows?
[15:09] <ralsina> mandel: mess
[15:09] <nessita> dobey: you available now? :-)
[15:09] <dobey> nessita: now, yes :)
[15:10] <nessita> dobey: yesterday, I mistakenly proposed the SSO update-stable-from-trunk branch against trunk instead of against stable-3-0. I thought I noticed that soon enough to prevent the landing (I reverted to 'needs review' and superseded the proposal ASAP), and I did not got a "merged" email, but apparently, the branch was merged the same. So, now, to fix that situation, I could either propose a branch that revert the (minor) changes, or remove
[15:10] <nessita> dobey: no branches have landed after that, nor are about to land
[15:11] <dobey> nessita: what minor changes?
[15:11] <nessita> dobey: setup.py version and a execution flag in a .py windows (not sure who added that, but is there)
[15:11] <nessita>  M  setup.py
[15:11] <nessita>   * ubuntu_sso/main/tests/test_windows.py
[15:11] <nessita> All changes applied successfully.
[15:12] <nessita> dobey: I will like not to have that revno in trunk at all....
[15:12] <nessita> so pushing the revno right before that makes sense to me
[15:12] <dobey> ok
[15:13] <dobey> well you need to uncommit the new revision i think
[15:13] <nessita> dobey: from trunk? I was about to do: bzr branch -r 841 lp:ubuntu-sso-client r841; cd r841; bzr push lp:ubuntu-sso-client
[15:14] <dobey> that might work
[15:15] <nessita> mandel, ralsina: please no one lands nothing to sso trunk (for a couple of minutes)!!!
[15:15] <ralsina> nessita: ack
[15:17] <mandel> nessita, np!
[15:23] <nessita> dobey: pushing to lp:ubuntu-sso-client with revno 841 is giving me "No new revisions or tags to push.". Seems like it won't override the current history... would that be a new "feature"?
[15:25] <dobey> nessita: no, you'd need to push --overwrite to do it
[15:25] <nessita> ah, you're right :-)
[15:31] <alecu> mandel, ping
[15:31] <nessita> dobey, ralsina, mandel: ussoc trunk is now ready
[15:31] <mandel> alecu, pong!
[15:31] <mandel> nessita, ack
[15:31] <alecu> mandel, we've got half an hour now till lunch: do you want to mumble now?
[15:33] <mandel> alecu, I perfer to do it later, if it is not a pita for you
[15:34] <alecu> mandel, no problem
[15:34] <mandel> cool
[15:35] <mandel> ralsina, nessita would it be adding a config for linux and one for windows something we could consider (follow the conversation on #chicharra if you can)
[15:36] <mandel> mainly, add the windows one in the lp:ubuntuone-windows-installer and change the installer for that
[15:37] <ralsina> mandel: answered in#chicharra
[15:55] <mandel> ralsina, sys.platform returns linux2, will it ever return a diff number?
[15:55] <mandel> as in linux3 if I used a 3.* kernel
[15:55] <ralsina> mandel: IIRC, it will return linux2 for the foreseeable future, also on linux 3
[15:55] <dobey> mandel: i think it was fixed to keep returning linux2 on 3.x, to avoid breaking the world
[15:56] <mandel> ack
[15:56] <dobey> mandel: thisfred did make a couple fixes in a few places back in the day to work with linux3 as well if it did change
[15:57] <dobey> checking for sys.platform being linux feels weird to me though
[15:58] <dobey> we should do what twisted does, i think
[15:58] <dobey>     if runtime.platform.getType() == 'posix':
[15:58] <dobey> it seems more correct to me, at least
[15:58] <thisfred> that implies we run on much more than linux though :)
[15:58] <thisfred> but yeah
[15:59] <thisfred> why not be ambitious :)
[15:59] <dobey> well, there's really no reason we shouldn't
[15:59] <thisfred> at least it shouldn't break on filenames
[15:59] <dobey> we should at least work on HURD
[15:59] <thisfred> and gentoo
[15:59]  * thisfred runs
[15:59] <mandel> and mac os x
[16:00] <dobey> pyinotify is probably the only thorn in the side, which is why i've been saying for a long time we should drop it and just use the gio watch api
[16:05] <thisfred> dobey: one thing I recently thought of: can we have u1trial call trial with --reporter=text by default?
[16:06] <dobey> thisfred: i don't think we should change the default from what trial itself does by default
[16:06] <thisfred> dobey: that way we only get errors/failures in the report, which will make the launchpad merge proposal pages more useful in case we mess up.
[16:06] <thisfred> dobey: why not?
[16:06] <dobey> we can probably fix it so we do that in tarmac
[16:06] <thisfred> dobey: when is it ever useful to see test_foo [OK]
[16:07] <thisfred> that's fine too, but it's more useful when running tests locally too, I find
[16:07] <thisfred> no need to scroll back for pages
[16:07] <dobey> perhaps it should be discussed with twisted and changed upstream then
[16:07] <dobey> i don't know the reason why the default is the default
[16:07] <thisfred> why? If a program has options, they can be used, surely?
[16:08] <thisfred> dobey: right now u1trial hides that option completely. If it's passed through, that would also work for me
[16:08] <thisfred> or does it pass on all options it doesn't define itself now?
[16:09] <dobey> because defaults were chosen for a reason surely, and if it's useful for us to change the defaults for us, it's likely useful for a million other people as well, no?
[16:09] <dobey> thisfred: u1trial passes everything through to trial which it doesn't handle itself, yes
[16:10] <mandel> dobey, after a apt-get build-deps ubuntuone-client I'm getting **Error***: You must have gtk-doc >= 1.0 installed on P, that should not happen, right?
[16:10] <dobey> thisfred: u1trial --help should show all the same options as trial, plus the pieces we add on top (or need to change, like reactor handling)
[16:10] <dobey> mandel: that shouldn't happen, no. but i guess you probably don't have the nightlies ppa added, either.
[16:10] <mandel> dobey, I do
[16:11] <dobey> mandel: gtk-doc isn't needed to build the tarball release, but is needed for the nightlies
[16:11] <dobey> mandel: you don't have the source repo added or enabled, then
[16:11] <ralsina> Have to go to thedoctor in lieu of lunch. See you all in about 90 minutes
[16:11] <mandel> dobey, indeed, sources is not enabled
[16:15] <dobey> thisfred: ok, i really don't like --reporter=text, at least for local runs. it seems to just block and then dump everything all at the end, no progress, and no ability to tell where it's hanging or such, if a test ends up hanging
[16:16] <thisfred> dobey: ok, I didn't realize that. I used it with non-twisted tests only I guess ;)
[16:17] <dobey> well, at least that's what seems to happen when i run u1trial --reporter=text ubuntuone in ubuntuone-dev-tools
[16:17] <thisfred> dobey: still I think it would be good for tarmac, where there is no sense of progress, and tests hanging is catastrophic either way
[16:17] <dobey> those are all non-twisted tests
[16:18] <thisfred> dobey: I only used it on a hobby project where all the tests pass in like a millisecond, so I didn't notice
[16:18] <dobey> yeah, i don't know why it was slow here
[16:19] <dobey> well now they were all faster
[16:19] <dobey> though for some reason, some are getting skipped
[16:19] <mandel> elopio, ping!
[16:19] <dobey> grmbl
[16:20] <mandel> dobey, on ubuntuone-dev-tools?
[16:20] <mandel> got squid or the apache tools installed?
[16:21] <mandel> I need to reboot due to updates..
[16:21] <mandel> stupid alpha!
[16:24] <dobey> yes
[16:25] <dobey> mandel: test_squid_testcase is getting skipped, but test_squid is all running fine
[16:26] <dobey> i need to get some lunch though.
[16:26] <dobey> bbiab
[16:26] <elopio> mandel: pong!
[16:37] <nessita> dobey: hey there, would you please re-review my gtk-gi branch when you have a chance? I kinda depend on that branch to move forward another branch I need for to the Qt port
[16:54] <mandel> elopio, still here?
[16:57] <elopio> mandel: yes sir.
[16:58] <mandel> I was looking into a bug you reported, bug 904554
[16:58] <ubot4> Launchpad bug 904554 in ubuntuone-client "Windows: when creating empty files, those are not uploaded (affects: 1) (heat: 42)" [Medium,Triaged] https://launchpad.net/bugs/904554
[16:58] <mandel> elopio, I tried to reproduce it and I got the test file in my cloud, yet I created the file by creating a new file via the shell menu
[16:59] <elopio> mandel: let me see... If I remember correctly, the problem appears when you don't change the name of the file.
[16:59] <elopio> mandel: what's the shell menu?
[17:00] <mandel> elopio, right click create new text file :)
[17:00] <mandel> elopio, but that calls it new blah
[17:00] <mandel> and I renamed if to test.txt and get uploaded
[17:00] <elopio> mandel: do not rename it.
[17:01] <mandel> elopio, ok, looking
[17:01] <elopio> when you rename it, u1 records a move. Or something like that explained nessita.
[17:02] <mandel> elopio, yes, is a move from 'blah' to 'new blah'
[17:02] <mandel> elopio, my question would be, does it even matter? I mean, if you wrote nothing you have notihg to loose :P
[17:02] <elopio> mandel: yes, I would make it really low priority :)
[17:03] <mandel> elopio, its simple to fix
[17:03] <mandel> elopio, I can fake a modify after the create
[17:04] <elopio> mandel: that sounds like a weird workaround, but you are the expert.
[17:04] <mandel> elopio, well, let me check why it does not get uploaded
[17:07] <mandel> elopio, can you do the same test on a linux machine?
[17:11] <elopio> mandel: sure. It works on precise without having to rename it.
[17:11] <elopio> Untitled Document gets uploaded. Do you want the syncdaemon log?
[17:12] <mandel> elopio, ok
[17:12] <mandel> elopio, can I get the logs of that?
[17:16] <elopio> mandel:  https://pastebin.canonical.com/59227/
[17:21] <mandel> elopio, if you do a search you will see that FS_FILE_CLOSE_NOWRITE is missing
[17:21] <mandel> elopio, on windows I mean, so we have to fake a write on windows :P
[17:23] <elopio> mandel: um, yes, I got it.
[17:23] <mandel> elopio, if i ever write a windows driver ofr u1 we will not have this problems ;)
[17:25] <elopio> mandel: ow, writing windows drivers sounds like the least funny job. There should be daily free hugs for whoever does it.
[17:26] <mandel> elopio, hehe
[17:27] <elopio> mandel: but, go for the bug fix! There's a beer waiting in Costa Rica for the fix of everyone of my bugs.
[17:27] <elopio> hum, let's better make it half a beer. Half for the reporter, half for the fixer.
[17:27] <mandel> elopio, I'm on it atm :)
[17:28] <dobey> nessita: sure. does it need the gireactor to run installed, or only for the test suite?
[17:32] <nessita> dobey: it does need the gireactor
[17:33] <nessita> dobey: wait, perhaps I'm not sure what you asked :-)
[17:33] <nessita> dobey: the service to run, do not need any reactor. The GTK UI tests to run, need the gireactor
[17:33] <dobey> nessita: so it's only for the test suite?
[17:34] <nessita> dobey: yes
[17:41] <dobey> ok
[17:56] <nessita> ralsina_doctor: may I have a review for https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/stable-3-0-update-2.99.3/+merge/90964 ?
[17:58] <dobey> i wonder what the scottish siri gag skit would be like, if it had someone with a really thick scottish accent.
[18:04] <dobey> nessita: is there a test server i could run locally (or a live staging server), that i can point ubuntu-sso at for testing? or does it have to use the production server always?
[18:10] <dobey> nessita: regarding the layout differences, it seemed to be that the label wasn't wrapping, for example, so the the dialog was quite wide
[18:10] <nessita> dobey: sorry for the delay, reading the first question now
[18:11] <nessita> dobey: you can use the sso staging server but those account will not work with U1 (but you will be able to create dummy, plain, sso accounts). To do so, run the sso service with this line:
[18:12] <nessita> (grepping files)
[18:12] <dobey> that's fine. i don't want to create any u1 accounts. though if we could also connect staging u1 and staging sso to test account creation on both, that would be nice indeed
[18:17] <nessita> dobey: hum, apparently is not working (no related to this branch). Formerly, you could do:
[18:17] <nessita> DEBUG=True PYTHONPATH=. USSOC_SERVICE_URL="https://login.staging.ubuntu.com/api/1.0" bin/ubuntu-sso-login
[18:18] <mandel> EOD for me, catch you all tom!
[18:18] <gatox> mandel, bye
[18:18] <nessita> dobey: but now the service is not fully starting, and I would rather not debug ATM this. I usually create dummy accounts on productions... so could you do that, for this branch?
[18:19] <dobey> nessita: any idea about the label not wrapping?
[18:20] <nessita> dobey: let me check if the label is set to wrap (it should). Before GTK3, we had a hack to make the label have the size-request that the parent had, but I removed that hack
[18:21] <nessita> confirmed that the header label, the secondary text label, and the warning label have "wrap mode" set to warp_word
[18:22] <nessita> dobey: all the GtkLabels in the ui.glade file have <property name="wrap">True</property>
[18:24] <dobey> hrmm
[18:25] <nessita> dobey: FYI, I found the proper way to use the staging server:
[18:25] <nessita> DEBUG=True PYTHONPATH=. USSOC_SERVICE_URL="https://login.staging.ubuntu.com/api/1.0/" bin/ubuntu-sso-login
[18:26] <nessita> dobey: the key is ensuring a trailing backslash to the url
[18:29] <dobey> hrmm, that broke recently then
[18:29] <nessita> dobey: what do you mean?
[18:30] <nessita> dobey: an assertion was added to the code, yes, because we never should pass service uris without a trailing spaces
[18:30] <dobey> because i tried it another version of sso and it worked :)
[18:30] <dobey> but ok
[18:31] <dobey> nessita: how do i create an account, if i can't see the captcha, btw? :)
[18:31] <nessita> dobey: the assertion was added a couple of revnos ago
[18:31] <nessita> dobey: right. I can provide a diff to apply to the libsoup that will make it work (but is not good enough to be in trunk)
[18:32] <dobey> i guess people just won't be able to create accounts in nightlies for a while?
[18:33] <nessita> dobey: yes, though is better that now, where they can't do anything at all that involves a UI
[18:33] <nessita> dobey: alecu will fix this before this week ends
[18:34] <dobey> nessita: hrmm, I can't seem to ^C the new ubuntu-sso-login :(
[18:35] <nessita> dobey: yes, neither can ^C any that have a gtk mainloop
[18:36] <nessita> dobey: I've tried with u1sdtool, for example
[18:36] <nessita> and magicicada, and any other app I run in a terminal that use a glib mainloop
[18:36] <dobey> huh
[18:38] <dobey> well that sucks
[18:38] <dobey> but indeed it seems it is probably a python-gi bug
[18:39] <dobey> ugh, and an ugly one at that :-/
[18:39] <nessita> dobey: yeah
[18:42] <nessita> dobey: let me share the soup diff with you
[18:42]  * nessita greps logs
[18:42] <dobey> that's ok
[18:44] <dobey> hrmm
[18:44] <dobey> looks like i got a 403 when it's trying to hit the u1 ping URL
[18:44] <dobey> oh doh
[18:45] <nessita> dobey: it will not work with the sso staging server
[18:46] <dobey> yeah, i just realized i was still running it with that set :)
[18:46] <nessita> dobey: ;-)
[18:46] <dobey> gah, i wish launchpad had attachments for merge proposals
[18:47] <dobey> because they are necessary when reviewing things with UI
[18:50] <dobey> nessita: https://launchpadlibrarian.net/91640946/sso-gtk3-nowrap.png
[18:57] <nessita> dobey: looking
[18:57] <nessita> dobey: you want me to fix that in this branch?
[18:58] <dobey> I don't know. If it's trivial, yes. If it's not, then well, I don't know. I suspect it is not trivial though
[18:59] <nessita> dobey: let me do a quick googling
[18:59] <ralsina> nessita: reviewing
[18:59] <nessita> ralsina: welcome back. You ok?
[18:59] <dobey> gtk3 has various changes that screw up layout in lots of apps
[18:59] <ralsina> nessita: yes, doctor was overbooked
[19:01] <nessita> dobey: can you please tell me what do you understand from " Note that setting line wrapping to TRUE does not make the label wrap at its parent container's width, because GTK+ widgets conceptually can't make their requisition depend on the parent container's size. For a label that wraps at a specific position, set the label's width using gtk_widget_set_size_request()."?
[19:01] <nessita> (from http://developer.gnome.org/gtk3/3.2/GtkLabel.html#gtk-label-set-line-wrap)
[19:01] <ralsina> nessita: you need to fix the width for the wrapping tobe useful?
[19:01] <nessita> ralsina: yeah, and we should not fix the width, no?
[19:02] <nessita> fixing width is very bad :-/
[19:02] <ralsina> nessita: I usually frown upon it, yes
[19:02] <dobey> nessita: it means setting wrapping to true on the label will never work right
[19:02] <ralsina> dobey: another way to put it
[19:02] <nessita> dobey: which is a bummer
[19:02] <dobey> nessita: which means having to do the size-allocate hack
[19:02] <ralsina> Or you have to do wacky stuff resetting the width on parent resizing events or somesuch
[19:02] <nessita> dobey: let me try to put that back in
[19:03] <nessita> dobey: though, I must say, it was the same (ie, bad) with the hack in
[19:03] <dobey> i thought gtk3 was supposed to fix this and do funky layout to make it work, though :(
[19:03] <nessita> dobey: that was my understanding as well
[19:03] <dobey> nessita: it didn't wrap with the hack?
[19:03] <nessita> dobey: yeap, but let me re-check it
[19:09] <nessita> dobey: I restored the hack and the labels work the same as without it. Want me to push this changes?
[19:09] <dobey> also, should we land my u1client branch now, that adds gireactor support, and switches to gi tests by default?
[19:09] <dobey> nessita: lets leave it out for now
[19:10] <nessita> dobey: if we have the stable-3-0 already updated from trunk, let's land that
[19:10] <dobey> nessita: is there already a bug for the missing captcha?
[19:10] <dobey> stable-3-0 isn't updated yet
[19:10] <nessita> yes, is in the merge proposal iirc
[19:10] <dobey> ah ok, yes it is
[19:11] <nessita> dobey: yeap, bug #921822
[19:11] <ubot4> Launchpad bug 921822 in ubuntu-sso-client "webclient with libsoup backend is not reading the whole body response (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/921822
[19:11] <nessita> dobey: alecu confirmed he will be fixing that next
[19:12] <dobey> yeah, that's fine. i just wanted to make sure there was a bug for it.
[19:12] <nessita> yes, thanks
[19:12] <nessita> and thanks for the thorough review :-)
[19:13] <dobey> i'm filing a bug for the label wrapping
[19:14] <nessita> dobey: great
[19:16] <dobey> https://bugs.launchpad.net/ubuntu-sso-client/+bug/925042
[19:16] <ubot4> Launchpad bug 925042 in ubuntu-sso-client "Labels not wrapping properly with Gtk3 version of SSO (affects: 1) (heat: 6)" [Medium,Confirmed]
[19:16] <dobey> nessita: approved
[19:16] <nessita> dobey: yey! thanks
[19:33] <dobey> https://code.launchpad.net/~dobey/rhythmbox-ubuntuone/update-from-trunk/+merge/91152
[19:33] <dobey> can i get a review or two for that?
[19:35] <nessita> dobey: let me propose a branch and will review
[19:36] <dobey>   sure, thanks
[19:49] <nessita> ralsina: if you happen to have some extra minutes: https://code.launchpad.net/~nataliabidart/ubuntuone-windows-installer/stable-3-0-update-2.99.3/+merge/90963
[19:51] <ralsina> nessita: got it
[19:56] <dobey> nessita: you pushed changes after changing the branch to approved! (i reset it back to approved though)
[20:11] <nessita> dobey: i pushed a trunk merge, and I set it to approve after that (but did not check if LP got that push though)
[20:12] <dobey> right. you didn't wait for the rescan :)
[20:15] <ralsina> nessita: +1
[20:15] <nessita> dobey: yeah... and now it fails with xvfb not being able to start... would that be installed in the precise tarmac?
[20:16] <dobey> should be, i'll check
[20:16] <nessita> dobey: also, question from your branch: is this import "from MusicStoreWidget import U1MusicStoreWidget" correct? can't we have a fully import, such as "from ubunutone.something.MusicStoreWidget..." ?
[20:17] <nessita> ralsina: thanks
[20:17] <dobey> nessita: it's correct. that isn't a python package
[20:18] <nessita> dobey: ack. What is it then? :-) (trying to understand a little deeper)
[20:18] <dobey> nessita: relative import from the directory in which the plug-in is installed
[20:18] <nessita> ah, I see
[20:18] <nessita> for python 3 we'll need to make that from .Music... :-)
[20:19] <dobey> it used to be from ., but python doesn't like that for things that don't have __init__ (which aren't python packages)
[20:20] <dobey> and i have no idea when rhythmbox will support python 3. probably not for a while :)
[20:20] <nessita> right
[20:20] <dobey> and i think i'd prefer to rewrite the plug-in in vala or c by that time anyway
[20:21] <nessita> dobey: would have bet you would say that ;-)
[20:21] <dobey> well, it will actually make it easier to support older versions of rhythmbox, as well as the new ones
[20:22] <dobey> supporting both now, from python, is basically impossible
[20:23] <dobey> nessita: xvfb appears to be installed
[20:23] <dobey> it is precise though, so very likely could be broken :(
[20:31] <dobey> nessita: and no x-related upgrades available
[20:32] <nessita> dobey: did we need to tweak tarmac <somehow> to have xfvb running? something related to having an x window?
[20:32] <dobey> no
[20:32] <nessita> an X display I meant
[20:32] <dobey> xvfb creates a virtual display; that's the whole point of xvfb :)
[20:32] <nessita> dobey: isn't tarmac running as a cron process, where <something> from X is not set?
[20:32] <nessita> yes... but I think I recall it needed <something> :-)
[20:33] <nessita> but I can't remember *what*
[20:33] <dobey> nessita: yes, but that's true in all tarmac instances. we've not done anything special for xvfb that i know of
[20:33] <nessita> dobey: in natty, you mean
[20:33] <nessita> ?
[20:34] <dobey> or lucid or maverick. tarmac is running from a cron job with basically empty environment, in all of them
[20:34] <nessita> let's ask sidnei, he may have done something when he setup that tarmac (you were on holidays... iirc)
[20:34] <dobey> i don't think so
[20:34] <nessita> you don't think you were on holidays? or that something extra is needed? :-)
[20:35]  * nessita is not sure of both
[20:35] <dobey> both.
[20:35] <nessita> heh
[20:35] <dobey> i wasn't on holiday yesterday, and pretty sure xvfb doesn't need anything special
[20:35] <nessita> dobey: so, xvfb will work in my precise install...
[20:35] <dobey> xvfb can be fidgity though
[20:37] <nessita> gatox: https://code.launchpad.net/~nataliabidart/ubuntu-sso-client/qt-in-linux/+merge/91164
[20:38] <gatox> nessita, do you want me to review it? merge that branch with mine and keep working? both?
[20:38] <nessita> gatox: both! :-D
[20:38] <gatox> nessita, roger that
[20:38] <nessita> good guess :-P
[20:49] <dobey> https://code.launchpad.net/~dobey/ubuntuone-client/update-from-trunk/+merge/91166
[20:53] <nessita> dobey: approved the former one
[20:53] <dobey> nessita: thanks!
[21:16] <dobey> hmm
[21:38] <dobey> nessita: i think it's a timing issue
[21:39] <nessita> dobey: hey there, my net connection starting acting up :-/
[21:39] <nessita> dobey: timing issue between who? :-)
[21:39] <dobey> i see that
[21:39] <dobey> heh
[21:39] <dobey> timing issue re: xvfb problem
[21:40] <dobey> i am running the tests myself on the tarmac vm instance, but they are going *very* slowly
[21:40] <nessita> dobey: yes... but timing between what and what?
[21:40] <dobey> i don't know yet
[21:40] <dobey> but i think it's a timing issue somewhere :)
[21:42] <dobey> wtf is java running for
[21:42] <dobey> oh jenkins
[21:42] <dobey> hrmm
[21:43] <dobey> u1trial and xvfb are what are using all the CPU
[21:44] <nessita> dobey: copy that. I had to go... I guess I'll help you debug tomorrow
[21:44] <nessita> dobey: anyways, my net conn will not let me do much more today, apparently :-/
[21:44] <nessita> ok, see ya tomorrow! Thanks!
[21:45] <dobey> nessita: ok. chao
[21:46] <dobey> eh i am an idiot, but i need to go as well, really.