[02:29] <achiang> hello, i went into the web U1 interface and selected a folder to "stop syncing". while i do understand the message that it does *not* delete my local folder, do i understand correctly that it deleted the server copy?
[08:32] <mandel> morning!
[08:38] <rye> achiang: yes, you are right, the server-side copy will be removed and UDF will no longer be subscribed on the client
[08:49] <JamesTait> Good morning, all! *8O)
[11:13] <gatox> good morning
[11:40] <mandel> gatox, morning!
[11:40] <gatox> mandel, hi
[11:43] <mandel> gatox, I finally managed to fix the tests for domain sockets!
[11:43] <mandel> gatox, I need to ensure that I did not brake any on your windows vm ;)
[11:44] <gatox> mandel, great...... i have the run-tests script working on mac, with a script to setup the env... only need to fix u1lint and i'll ready to propose the branches
[11:44] <mandel> gatox, superb! we start moving, great news \o/
[11:45] <gatox> mandel, give your branches i'll test them
[11:45] <mandel> gatox, we have to be very very careful windows tests are kept like the are, linux is not a problem we have tarmac, but we are the windows tarmac ;)
[12:23] <alecu> EHLO one.ubuntu.com
[12:25] <gatox> alecu, buenas
[12:25] <mandel> alecu, hello!
[12:25] <mandel> alecu, logging ssl branch updating with the message you proposed
[12:25] <mandel> alecu, and I'm off to have lunch :)
[12:48] <ralsina> good morning!
[12:49] <gatox> ralsina, good morning
[13:02] <rye> mandel: hi, about the SSL-moar-info-please thing, poking you :)
[13:06] <dobey> hmm
[13:09] <alecu> hola ralsina. Hola dobey.
[13:09] <joshuahoover> ralsina: is the installer briancurtin emailed to us yesterday the one that we should have some users try that are impacted by the 3.0 auth issues?
[13:10] <alecu> rye, mandel is off for lunch. Got any more info on the issue?
[13:10] <ralsina> joshuahoover: exactly
[13:10] <alecu> joshuahoover, yes
[13:10] <ralsina> joshuahoover: should give us the actual SSL error
[13:10] <ralsina> rye: brian uploaded an installer yesterday with mandel's branch in it, I can give you the link
[13:10] <joshuahoover> ralsina: very good, i'll see who we can get to test that out for us
[13:11] <ralsina> rye: http://u1.to/~brian.curtin/g/3.0.0-windows-installer
[13:12] <dobey> hola alecu
[13:31] <rye> ralsina: oh, that's what is it, ok
[13:40]  * mandel back!
[13:44] <mandel> alecu, so in https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-ssl/+merge/103147 I would add the logger, I know is not used, but ensures that the weclient api is consistent over all implementations
[13:44] <mandel> alecu, if we remove the skip we will have failures such because of the lack of logger
[14:06] <thisfred> ralsina: lucio and I have been discussing whether or not to ask for a bit of design help on the u1todo example app, to make it more compelling. We decided to ask for your opinion in the matter... :)
[14:06] <ralsina> thisfred: please do, I have seen how that looks and it needs it ;-)
[14:07] <ralsina> thisfred: although it's an example app so the theming code may be distracting
[14:07] <ralsina> thisfred: but just a qss can do wonders for it
[14:07] <ralsina> thisfred: and layout
[14:08] <thisfred> ralsina: yeah I want to keep the layout code to a minimum, but since the ui is already separate, we should be able to spruce it up a little
[14:08] <thisfred> ralsina: ok, so do I ask lisettte directly? (hi! ;) or do I need to go through channels, and if so what are they?
[14:09] <ralsina> let's just ask lisette, but it all depends on how much work she has on her plate
[14:10] <ralsina> thisfred: we could also just STEAL
[14:10] <thisfred> It's not super urgent. I'm trying to keep the code and ui as independent as possible, so adding it later should still be easy enough
[14:10] <ralsina> thisfred: yes, the major functions are already in place
[14:10] <lisettte> hi ralsina, thisfred, what's up?
[14:10] <thisfred> ralsina: from what? u1cp?
[14:10] <ralsina> thisfred: and minimalistic is nice
[14:10] <ralsina> thisfred: from the world. Find a todo app people like :-)
[14:10] <thisfred> lisettte: hi, I'm developing a little example app on top of u1db
[14:11] <thisfred> lisettte: mostly to show developers how to do stuff
[14:11] <lisettte> thisfred: sounds cool
[14:12] <dobey> ugh. not feeling the greatest today
[14:12] <thisfred> lisettte: we'd like it to look a little less ugly than I made it so far, but it doesn't have to be on brand or anything, since it's just example code.
[14:13] <lisettte> thisfred: aha
[14:17] <rye> ok, ubuntuone-scripts are unmanageable now. Starting to manage
[14:18] <ralsina> dobey: you *are* the greatest. There, better?
[14:19] <dobey> no :)
[14:20] <ralsina> hey, I tried!
[14:20] <dobey> but i did just troll Neil deGrasse Tyson again, so it's a start.
[14:20] <gatox> dobey, ping... question: in mac we are using the buildout to configure the development environment, the thing is, im trying to keep the things as independent as possible, but u1lint is starting pylint as a process and this process is tryinng to use the python from the system, not the one from the buildout... it is reasonable to modify u1lint to start the python from the buildout instead of the one from the system for MAC?? (just wanted to kn
[14:20] <gatox> ow if i can do that... to avoid adding a lot of folders from the buildout to the pythonpath of the system)
[14:20] <ralsina> you mentioned that on "Iron Sky" the moon nazis are not astronomically correct?
[14:21] <ralsina> gatox: why not just manipulate PATH?
[14:21] <dobey> ralsina: no. much much better than that: https://twitter.com/#!/dohbee/status/194792155791892480
[14:22] <ralsina> he
[14:22] <gatox> ralsina, path? i'm addinng a python_u1... to avoid crashing and don't affect the system just to run tests, etc
[14:22] <dobey> gatox: i have no idea how the buildout works. why does pylint not "just work" ?
[14:22] <ralsina> gatox: let's talk about this on mumble in 10'. You are probably making it too hard for yourself :-)
[14:23] <dobey> gatox: and how do we solve this for other places where we do subprocess.Popen()?
[14:23] <ralsina> gatox: for example: u1lint probably has system python on its shebang, and shouldn't
[14:23] <gatox> dobey, inn other places we have all the dependencies installed in the system...... that is not what the buiildout do
[14:23] <ralsina> gatox: or pylint does
[14:23] <gatox> ralsina, yes, i know
[14:24] <dobey> ralsina: conversly, i recently saw a report about us using "env python" on shebang, and saying we shouldn't
[14:24] <gatox> ralsina, ok...... let me know when you can have a quick mumble, and i'll tell you what is going on
[14:24] <ralsina> gatox: in both cases, that's because they were installed using the system python, since setup.py is supposed to put the "right" python there
[14:24] <ralsina> dobey: yes env python is bad for things that are installed system wide
[14:24] <briancurtin> gatox: subprocesses don't really start correctly in the buildout - i have the same problem in Windows that i've temporarily fixed by finding the "bin\python-script.py" and inserting it as the first argument to sys.executable
[14:25] <dobey> hmm
[14:25] <gatox> briancurtin, i add the bin folder from the buildout to the PATH...... but i rename the python in there to python_u1, and use that to run tests, etc
[14:25] <briancurtin> so if you want to run Popen([sys.executable, "yourscript.py", "your arg"]) it really has to be [sys.executable, "path\to\bin\python-script.py", "yourscript.py"...]
[14:26] <ralsina> so, let's call the custom python "python" and add that to the PATH
[14:26] <ralsina> why would that not work?
[14:26] <ralsina> except of course for things that have the python hardcoded
[14:27] <dobey> briancurtin: hrmm, nobody should ever be passing sys.executable to Popen()
[14:27] <briancurtin> dobey: any reason?
[14:27] <thisfred> lisettte: to give you an idea of how much we need your help, this is what it looks like now: http://ubuntuone.com/1aHSGoXtfWsHs91TmR6CKt Note that this is not super urgent, so it needs to be planned in at some point, and again, the aim is not to make it look as good as possible, but more like someone has actually given any thought to it.
[14:27] <gatox> ralsina, well... in this case doing that i'll have the same problem, because pylint has that.....
[14:28] <ralsina> gatox: unless we install pylint using that python
[14:28] <thisfred> also: one feature that isn't shown yet is "ta
[14:28] <ralsina> or we also do a virtualenv
[14:28] <dobey> briancurtin: well, it's python, so any random piece of code you import could change it out form under you. and there should never be any need to use it. if you find yourself using it, you're grasping straws to work around a larger problem, it would seem
[14:28] <thisfred> "tags", which have to be attachable to any item, and searchable/filterable
[14:29] <gatox> ralsina, actually now the ONLY problem remaining is for pylint... if it is possible to modify u1lint to add 1 line...... problem solved
[14:29] <briancurtin> dobey: so how would you start a script using the same python interpreter you used? i get that someone could change it, but we're running tests with it (the common usage of Popen([sys.executable...])), so...don't change it
[14:30] <lisettte> thisfred: cool
[14:31] <dobey> briancurtin: why should you start a script with the same interpreter?
[14:31] <ralsina> dobey: because we don't want to use the broken system python
[14:32] <briancurtin> why wouldn't you? i dont get it. problem: i want to run another script - solution: run another script
[14:32] <dobey> yes, why do you *care* what interpreter it runs with, or that it's python?
[14:33] <ralsina> dobey: because pylint *loads* the module it's parsing. If the module uses things that are not installed on the python pylint is using, it breaks horribly.
[14:35] <dobey> how is that a problem with Popen() though?
[14:38] <ralsina> dobey: it's a problem with pylint using the wrong interpreter. If when calling popen you call "therightpython pylint" it works
[14:38] <dobey> why is pylint using the wrong interpreter? PATH is wrong?
[14:39] <gatox> dobey, pylint is using the interpreter from the system, and the buildout generates his own python with all the libs
[14:40] <gatox> we want to use the one from the buildout
[14:40] <dobey> but *WHY* is it using the system one?
[14:40] <gatox> but without breaking the one from the system
[14:40] <ralsina> dobey: because pylint's first line says "#!/usr/bin/python"
[14:40] <dobey> so do all of our scripts
[14:41] <ralsina> dobey: not i they are installed via setup.py with the python you want to use. The shebang is corrected on install.
[14:41] <ralsina> Which is why I believe that pylint is not installed correctly
[14:42] <gatox> ralsina, ( briancurtin correct if i'm wrong ) we don't have pylint installed, we have the eggs inside the eggs folder from the buildout and we are taking them from there
[14:43] <briancurtin> gatox: correct
[14:44] <gatox> ralsina, so that's why we need to call it in this case like: python_u1 pylint *args
[14:44] <urbanape> Dr_Who: thanks for all the input on the Files app. I'll be incorporating a lot of that over the next few days.
[14:44] <ralsina> gatox: if pylint is not installed, where did that pylint came from/
[14:44] <ralsina> ?
[14:45] <gatox> ralsina, fromm the buildout, the buildout download a bunch of stuff...... but don't install those libs, instead creeate a custom python that use them, so your system remains clean from the development environment
[14:45] <mandel> gatox, FYI in order to ensure that we do not brake lots of things with the tcpactivation I first have to make some changes in devtool
[14:45] <ralsina> gatox: and it installs a pylint script with the wrong shebang?
[14:45] <gatox> mandel, ack
[14:46] <Dr_Who> you're very welcome urbanape :-)
[14:46] <gatox> briancurtin, can you explain that? ^^
[14:46] <Dr_Who> urbanape, will certainly do some more
[14:46] <dobey> ralsina: maybe it got built with system python?
[14:47] <ralsina> dobey: that's my guess
[14:47] <dobey> a full log of the buildout build would be helpful i guess :)
[14:47]  * ralsina suggests editig the freaking pylint script
[14:47] <briancurtin> gatox: i have no idea. on windows theres no shebang. we have an env.bat script which sets up paths and copies pylint (and a few others) out of their deep egg structures and puts them in the bin\ folder to be run
[14:47] <ralsina> briancurtin: and those bats use the system python instead of the custom one?
[14:47] <gatox> i'm doing something similar in mac
[14:48] <briancurtin> ralsina: everything is started from bin\python.exe which is actually the system python but called with bin\python-script.py to setup "the buildout" (modifies sys.path to point to all of the eggs and whatnot")
[14:49] <ralsina> briancurtin: ok, I am lost now. But that's normal.
[14:49]  * ralsina suggests using a virtualenv
[14:49] <ralsina> but probably just more hassle
[14:49] <gatox> ralsina, we are going to have some problems with PyQt with virtualenv i think
[14:50] <ralsina> gatox: I just copy it
[14:50] <ralsina> gatox: since it doesn't install in virtualenv
[14:50] <ralsina> gatox: or buildout for that matter
[14:50] <briancurtin> bin\python.exe actually executes """C:\Python27\python.exe bin\python-script.py""" to give your bin\python.exe the right environment
[14:50] <ralsina> briancurtin: ahhhhh
[14:50] <ralsina> ok, so if it's just pylint, and we use pylint for nothing else, let's change pylint.bat (and the pylint shebang on mac) so it does the right thing/
[14:51] <ralsina> or let's not run pylint on windows where it never wors anyway
[14:53] <dobey> https://code.launchpad.net/~dobey/ubuntuone-client/queue-limit-3-0/+merge/103174
[14:54] <dobey> https://code.launchpad.net/~dobey/ubuntuone-client/fix-981255-3-0/+merge/103179
[14:54] <dobey> thisfred, urbanape: ^^ if you could please review those. they're simple backports from trunk to stable-3-0
[14:54] <thisfred> kk
[14:55] <dobey> ralsina: btw, what about switch to pyflakes/pep8 or flake8 and just killing pylint?
[14:55] <Dr_Who> urbanape, say did you have any thoughts / feedback on the little design tweek I had sent you ?
[14:55] <ralsina> dobey: pyflakes/pep8 doesn't notice missing docstrings
[14:56] <ralsina> dobey: and that was just the first time we tried to use it on something
[14:56] <urbanape> Dr_Who: we actually had some mockups like that, and have some UI work on the roadmap that will enter that territory.
[14:57] <Dr_Who> o cool ?  is that up on a wiki somewhere or akin ?
[14:57] <gatox> mmmmm it's really easy to check for missing strings with ast....
[14:57]  * gatox is going to send a patch to pyflakes
[14:57] <gatox> missing docstrings
[14:58] <ralsina> in any case, even a first quick test did not fill me with confidence :-(
[14:58] <dobey> boo
[15:00] <gatox> me
[15:00] <dobey> does PEP 8 require docstrings? or is that all PEP 257?
[15:01] <briancurtin> 257, 8 just references it
[15:02] <gatox> ralsina, dobey thisfred mandel alecu briancurtin mmcc standup?
[15:02] <thisfred> me
[15:02] <dobey> meh
[15:02] <alecu> dobey, pep8 does requires some docstrings; pep257 expands on it. http://www.python.org/dev/peps/pep-0008/#documentation-strings
[15:02] <ralsina> me
[15:03] <alecu> but... "Docstrings are not necessary for non-public methods"
[15:03] <alecu> me
[15:03]  * mmcc doesn't know what to say here. me?
[15:03] <briancurtin> me
[15:03] <ralsina> mmcc: yes :-)
[15:03] <mandel> me
[15:03] <mandel> ups
[15:03] <gatox> DONE:
[15:03] <gatox> Improve MAC OS scripts to configure the development environment. Almost done, just need to fix some issues running pylint.
[15:03] <gatox> TODO:
[15:03] <gatox> Finish with the mac os scripts and propose the branches for all U1.
[15:03] <gatox> BLOCKED:
[15:03] <gatox> No
[15:03] <gatox> thisfred, go
[15:04] <thisfred> DONE: found and fixed indexing bug in u1db, added real persistence to u1todo TODO: bug #987414 BLOCKED: no NEXT: dobey
[15:04] <dobey> λ DONE: backports, expense, review
[15:04] <dobey> λ TODO: backports, SRUs, u1db packaging/buildsys
[15:04] <dobey> λ BLCK: none.
[15:04] <dobey> ralsina
[15:04] <ralsina> DONE: tech leads call, mgmt call, helped around, some reviews, management stuff, etc. TODO: help around, reviews, etc. BLOCKED: no
[15:04] <ralsina> alecu?
[15:04] <alecu> DONE: some research on SSL handshake error, team leads meeting, back to security issues
[15:04] <alecu> TODO: roadmap call, code some more
[15:04] <alecu> BLOCKED: no
[15:04] <alecu> NEXT: briancurtin
[15:04] <briancurtin> DONE: fought with Qt/PyQt version matching, got environment re-setup after that to do a one-off release and test it
[15:04] <briancurtin> TODO: i think i have Qt/PyQt figured out, have to rebuild it. fix up installer issues
[15:04] <briancurtin> BLOCKED: None
[15:04] <briancurtin> NEXT: mmcc
[15:04] <mmcc> DONE: email, wiki setup; code and dependencies downloaded
[15:04] <mmcc> BLOCKED: None
[15:04] <mmcc> TODO: run tests, ask lots of questions
[15:05] <mandel> ok, I go
[15:05] <mandel> DONE: Update ssl logging branch according to reviews. Some reviews. Work on tcpactivation got to the point of having tests running via tcp and domain sockets. Work on getting squid tests running on windows (will propose in a little)
[15:05] <mandel> TODO: add a bug so that tcp test cases from ubuntuone devtools can use endpoints (allow domain sockets to be used) Propose squid tests on windows.
[15:05] <mandel> BLOCKED: no
[15:05] <urbanape> dobey: you're good to go
[15:05]  * urbanape needs to remove himself from review days
[15:06] <dobey> oh right, guess we should put mmcc there instead :)
[15:06] <ralsina> urbanape: yes, and you can probably stop showing up on standups, although you are welcome :-)
[15:06] <ralsina> dobey, mmcc: yes, mmcc you are going to have a code review day. Take friday so you are not alone :-)
[15:07] <ralsina> mmcc: at least for the 1st month
[15:07] <ralsina> mmcc: the review day schedule should be in your google calendar
[15:07] <mmcc> ralsina, ok, I'll check
[15:08] <dobey> make sure you log in with the right account to google docs :)
[15:08] <mmcc> ralsina: I have nothing on there right now.
[15:08] <ralsina> mmcc: hmmm
[15:08] <mmcc> dobey: yep :) I use a separate browser for my personal account, for years now
[15:08] <ralsina> mmcc: do you have any calendars other than your own?
[15:08] <mmcc> ralsina: no - just mine and "Tasks"
[15:09] <ralsina> mmcc: ok, sending you a few
[15:09] <ralsina> mmcc: your account name?
[15:09] <mmcc> mike.mccracken@canonical.com
[15:09] <mandel> ralsina, any idea why would I have a TCP miss in squid when trying to get a resource form localhost?
[15:10] <ralsina> mandel: TCP_MISS is normal, it means "getting from server"
[15:11] <ralsina> mmcc: there, you should now have 3 more calendars
[15:11] <mandel> ralsina, I get the following: paste.ubuntu.com/944210
[15:11] <mandel> ralsina, the deny is expected, the miss are not happening on linux
[15:12] <mmcc> ralsina: yes. what is the the core hours schedule about? it's busy…
[15:12] <ralsina> mmcc: I usually have that one disabled, but is to show you when each person in online services is supposed to be working
[15:12] <ralsina> mmcc: just in case you want to see if you can meet with someone
[15:12] <mmcc> ralsina: ah, ok. I get it
[15:12] <ralsina> mandel: as I said, TCP_MISS is perfectly normal
[15:13] <ralsina> mandel: TCP_MISS or TCP_HIT are "good" results
[15:15] <mandel> ralsina, hm.. so when that happens, what is the client mean to do?
[15:15] <ralsina> mandel: makes no diference at all to the client
[15:15] <ralsina> mandel: the client still gets a page
[15:15] <ralsina> mandel: TCP_MISS => gets it from the server TCP_HIT => gets it from cache
[15:16] <mandel> ralsina, I'm getting a 504 Gateway timeout
[15:16] <ralsina> mandel: hmmm
[15:16] <ralsina> mandel: that's something else
[15:16] <ralsina> mandel: it could be it's not able to connect to the server
[15:17] <mandel> ralsina, to localhost with no firewall, weird..
[15:17] <dobey> damn sinuses
[15:17] <ralsina> mandel: squid should never "create" a 504
[15:18]  * dobey has now deleted all the currently existing maverick packages from nightlies
[15:18] <dobey> EOL FTW
[15:19] <dobey> mandel: btw, it seems squid is just slow to start on the lucid ppa build. :( https://launchpadlibrarian.net/102707979/buildlog_ubuntu-lucid-i386.ubuntuone-dev-tools_3.1%2Br66-19~lucid1_BUILDING.txt.gz
[15:20] <mandel> dobey, looking
[15:21] <mandel> dobey, shall we wait longer? for the rest of the platforms there is no problem
[15:21] <dobey> mandel: how long are we waiting now exactly?
[15:22] <urbanape> mmcc: if you want, you can just swap review days with me (Tuesdays)
[15:23] <mmcc> urbanape: I don't know enough to have a preference :) whatever's easiest, I guess…
[15:23] <urbanape> well, I just switched it to eric/?? for today.
[15:24] <mmcc> urbanape: but today might be a bad day to start ;) (or a good day?)
[15:24] <urbanape> Like the Klingons say, "Today is a good day to review merge proposals."
[15:24] <thisfred> I just switched it to ralsina/ralsina
[15:24] <mmcc> urbanape: those are some nerdy Klingons
[15:24] <urbanape> (it's a lot like dying)
[15:24] <ralsina> thisfred: hmmm
[15:25] <ralsina> thisfred: what's that, "anything can happen tuesdays"?
[15:25] <thisfred> oh wait, did you complete my evaluation yet? :D
[15:25] <ralsina> urbanape: reviews are not at all like dying. Dying you only do once. Reviews, we do twice.
[15:25] <urbanape> hahahahaha
[15:26] <ralsina> thisfred: yes, it says, "ask jdo when he's back from the dentist"
[15:26] <mandel> dobey, look at like 222 in ubuntuone/devtools/services/squid.py
[15:26] <mandel> dobey, we look and try several times to know the state of the proxy, we can either increase the numbers or just add 10, 15 to it, longer might be too much
[15:27] <thisfred> ralsina: truly anything can happen in that case :D
[15:28] <thisfred> "I'll get me coat then..."
[15:29] <ralsina> thisfred: he
[15:30] <dobey> Perhaps today *is* a good day to dye.
[15:34] <thisfred> punning clans are here again
[15:35] <mandel> thisfred, what mouse walks using just two legs?
[15:35]  * thisfred puts fingers in ears and hums loudly
[15:36] <mandel> thisfred, Mickey Mouse!
[15:36] <mandel> thisfred, and the duck?
[15:37]  * thisfred hums louder
[15:39] <mandel> thisfred, then I wont tell you :P
[15:41] <mandel> windows es un hijo de puta que merece una muerte lenta
[15:42] <mandel> ralsina, if you use locahols on windows + squid it does not know how to resolve it to 127.0.0.1
[15:42] <ralsina> mandel: yuck
[15:43] <ralsina> ping localhols fails on linux too ;-)
[15:43] <mandel> ralsina, double yuck, good news, ubuntuone-dev-tools squid tests now run on windows, which means I'll propose the branch and we can start running proxy tests on jenkins
[15:43] <ralsina> mandel: nice!
[15:48] <mandel> briancurtin, ralsina, question, I'm using Popen to launch squid, if I use pipes on widows it always crashes, any idea?
[15:48] <briancurtin> mandel: do you have any example code?
[15:48] <dobey> hmm
[15:49] <mandel> briancurtin, sure, give me a sec and I'll push the branch
[15:49] <ralsina> mandel: it should just work, code please
[15:50] <thisfred> lolcaholics unanimous
[15:53]  * gatox lunch
[15:53] <mandel> briancurtin, ralsina, if I do not pass -X to squid (which means be very verbose in stdout) it does not crash
[15:54] <mandel> briancurtin, ralsina, you can find the code in lp:~mandel/ubuntuone-dev-tools/fix-squid-tests
[15:54] <ralsina> mandel: are you capturing stdout/stderr? If you are not, things may crash on windows
[15:54] <thisfred> cautionary tale: I used the string "lolcathost" once in a functional test to see what happened with illegal urls. Then I forgot all about that, and later when something changed and it failed, neither I now someone else who was looking at it actually saw it wasn't localhost, so we lost about an hour wondering why the test was asserting that it *shouldn't* work against localhost.
[15:54] <mandel> ralsina, I do and when I don't it works
[15:55] <thisfred> There's a lesson in there somewhere
[15:55] <ralsina> thisfred: next time use something that doesn't look like a typo :-)
[15:55] <mandel> thisfred, on windows we have been seeing dns lookups for localhost.. is weird
[15:55] <ralsina> mandel: then don't :-)
[15:55] <thisfred> ralsina: that could well be it :)
[15:55] <mandel> ralsina, I want to do things right :)
[15:55] <ralsina> mandel: localhost may or may not be in your hosts
[15:55] <ralsina> mandel: that ship has sailed
[15:55] <mandel> ralsina, I could remove the -X will get less info but will work
[15:56] <ralsina> mandel: ok, no idea, really
[15:57] <mandel> ralsina, then I'll remove the -X and screw windows since we have access to the jenkins machine to see wtf is happening
[16:03] <ralsina> mandel: sounds like a plan
[16:03] <ralsina> mandel: let's pick our battles
[16:51] <alecu> mandel, since this will run inside trial, have you considered reactor.spawnProcess for squid?
[16:53] <dobey> mandel: capturing stdout/stderr on windows, crashes?
[16:54] <mandel> alecu, nop, but this is an update to present code, it sounds like a good idea for improvement
[16:54] <mandel> dobey, capturing A LOT of stdout makes squid on windows crash, not python
[16:54] <dobey> oh
[16:54] <dobey> well
[16:55] <dobey> something inappropriate about squid's mother, then
[16:56] <mandel> dobey, I did mention that too :)
[16:56] <dobey> heh
[16:56] <dobey> i would expect no less of you, mandel
[16:56] <mandel> thisfred, please review: https://code.launchpad.net/~mandel/ubuntuone-dev-tools/fix-squid-tests/+merge/103325
[16:57] <mandel> dobey, hehe I know
[16:57] <mandel> dobey, feel free to review ^
[16:57] <briancurtin> ralsina: 1-1 in a few minutes?
[16:57] <mandel> ralsina, briancurtin, I'd appreciate if you can test https://code.launchpad.net/~mandel/ubuntuone-dev-tools/fix-squid-tests/+merge/103325 on your windows boxes
[16:57] <ralsina> briancurtin: let's do it
[16:58] <mandel> dobey, also, squid fails to parse C:\path\in\windows you have to add it to the config as C:\\squid\\has\\mummy\\issues
[16:59] <dobey> of course
[16:59] <mandel> typo intended :)
[16:59] <mandel> dobey, and fails to pick up localhost..
[17:00]  * thisfred reviews
[17:00] <mandel> alecu, ralsina, FYI I'll be working a little tom morning on ubuntuone-dev-tools to add support for domain sockets in the tcp tests cases I added last time, that way I wont leave dirty reactor on linux and we will be able to run the tcpactivation and ipc tests both on domain sockets and tcp sockets
[17:01] <dobey> uh
[17:02] <alecu> mandel, great.
[17:03] <mandel> ok, with that EOD from here, laters o/
[17:07] <dobey> and i need to get lunch
[17:14] <mandel> alecu, I'm off to walk the dog and rugby, check https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-ssl/+merge/103147 if you want I can remove logger, no problema what so ever, I'll me back at my 1:00 am or something like that
[17:14] <alecu> mandel, great, thanks.
[17:19] <briancurtin> be back shortly, running to the bank and to grab a sandwich
[17:25] <ralsina> that nice feeling when the windows implementation works on linux
[17:43]  * briancurtin back
[17:43] <gatox> ok, now i have EVERYTHING working on mac
[17:44] <mmcc> gatox: I'm listening, what wasn't working before? I'm still digging around getting familiar with the code I've grabbed…
[17:45] <mmcc> (so that'd be helpful info - knowing what shouldn't work :) )
[17:46] <gatox> mmcc, i was just creating a couple of scripts so when you finish with the buildout, you can run another script to set some env-vars..... and then you will be able to run tests and lint checks, etc..... without a lot fo paths configuration and stuff
[17:46] <mmcc> gatox: aha, so that's very relevant to my interests, as you might imagine
[17:46] <gatox> mmcc, i'll update the document as soon as the branches start landing
[17:46] <gatox> mmcc, yes :P
[17:49] <mmcc> gatox: ok, good - for now I will just keep reading code/readmes/pyqt docs…
[17:53] <gatox> urbanape, ping
[17:58] <gatox> urbanape, hi, i'm going to create a branch from your mac-branch-port to fix the remaining things, so we can speed up that to make it land and we don't have to bother you with all the changes now that you went back to your team, if there is any problem with this please let me know :D
[17:59] <gatox> and i'll propose the new branch
[18:00] <achiang> facundobatista: so, last night i decided that u1sd simply couldn't handle a directory of 100GB+ so i did a workaround and just sync subdirs directly
[18:00] <facundobatista> achiang, probably, I don't think anybody tried with throwing 100GB at once...
[18:02] <mmcc> gatox: still figuring things out - so urbanape is on a different team and was just helping get the OSX port started? how long has the effort been going on and how far is it along?
[18:02] <urbanape> mmcc: not long
[18:02] <urbanape> and yeah, I'm on the Web & Mobile team
[18:03] <urbanape> gatox: pong
[18:03] <gatox> urbanape, hi... did you read my message?
[18:03] <gatox> urbanape, it's ok with you?
[18:03] <urbanape> nope, no problem
[18:05] <mmcc> urbanape: is there any overlap between the OSX code and your iOS code?
[18:05] <ralsina_lunch> gatox, dobey: reviews please https://code.launchpad.net/~ralsina/ubuntuone-control-panel/unique_in_ubuntu/+merge/103336
[18:05] <gatox> ralsina_lunch, on it
[18:05] <ralsina_lunch> dobey: that one should go in the P SRU so be harsh with it please ;-)
[18:05] <urbanape> mmcc: not really. We could ostensibly re-use the SSO code, but right now, we're hewing more closely to the linux and mac ports.
[18:06] <mmcc> urbanape: s/mac/win ?
[18:06] <urbanape> er, yeah
[18:07] <mmcc> yeah so I was just looking at the SSO stuff. I'm curious how it's done on iOS. I've used the OSX keychain, but I don't know what the done thing on iOS is…
[18:15] <gatox> ralsina, +1
[18:16] <ralsina> gatox: thanks!
[18:21] <mmcc> gatox: does one of your pending doc changes involve installing dbus? either I have a path wrong or I need to install…
[18:22] <gatox> mmcc, no, you are probably trying to run the tests in the wrong branch or not ignoring the proper files
[18:22] <gatox> mmcc, you don't need dbus
[18:22] <gatox> mmcc, are you using this branch? https://code.launchpad.net/~urbanape/ubuntu-sso-client/initial-darwin-port/+merge/101112
[18:24] <mmcc> gatox: sorry, bzr newbie. what's the fastest way to answer that question? :)
[18:25] <mmcc> bzr info didn't seem helpful there
[18:25] <gatox> mmcc, are you trying to run the tests for sso?
[18:25] <mmcc> yes.
[18:27] <mmcc> for completeness' sake, here's what I'm doing:
[18:27] <gatox> mmcc, show me the result of "bzr info" inside the sso foldeer
[18:27] <mmcc> Users/mmccrack/Documents/Canonical/Source/buildout-env/scripts/devsetup/parts/ubuntu-sso-client
[18:27] <mmcc> % bzr info
[18:27] <mmcc> Standalone tree (format: 2a)
[18:27] <mmcc> Location:
[18:27] <mmcc>   branch root: .
[18:27] <mmcc> Related branches:
[18:27] <mmcc>   parent branch: bzr+ssh://bazaar.launchpad.net/+branch/ubuntu-sso-client/
[18:28] <mmcc> oof, that was ugly. sorry for the multiline spam there
[18:28] <gatox> mmcc, right...... so, there do: bzr merge lp:~urbanape/ubuntu-sso-client/initial-darwin-port
[18:28] <gatox> mmcc, and you will merge your local copy of sso with the content of that branch
[18:29] <gatox> mmcc, you can also branch locally if you want to leave that one clean, like this:
[18:29] <gatox> bzr branch ubuntu-sso-client new-sso-branch......
[18:29] <gatox> and merge in the new branch..... so you will keep a clean copy of sso just in case
[18:30] <mmcc> gatox: ok, well for now I just merged in place. I can always grab a clean copy later I guess
[18:30] <mmcc> thanks
[18:30] <gatox> mmcc, yes.....
[18:31] <gatox> mmcc, now, try to run the tests in that branch as the docs says, and let me know if that works
[18:33] <mmcc> ok, so the doc has a PYTHONPATH override that I need to translate to my filesystem again. just a minute
[18:35] <gatox> mmcc, yes, the script that i made is going to avoid doing that..... but is not in trunk yet
[18:37] <mmcc> gatox: that's good news :)
[18:38] <gatox> mmcc, yep! :D
[18:39] <dobey> bah, where are the free downloads on google music now
[18:41] <mmcc> gatox: so now it's dying when it tries to import resources_rc from ubuntu_sso.qt.ui - I note the import line has been wrapped with pylint comments…
[18:41] <gatox> mmcc, yes...... sorry about that...... as you are running the test manually, you need to compile everything by your own.....
[18:41] <gatox> mmcc, execute: python setup.py build
[18:42] <mmcc> aha, ok
[18:42] <gatox> mmcc, later when the ./run-mac-tests will be available, you wont need to do that (among other things)
[18:45] <mmcc> gatox: are there other parts I need to build?
[18:45] <mmcc> from ubuntuone.devtools.testing.txwebserver import HTTPWebServer
[18:45] <mmcc> ImportError: No module named txwebserver
[18:45] <dobey> yay buildout using the old devtools
[18:46] <gatox> mmcc, ahhhh that's because the devtools that the buildout is downloading is not the last version
[18:46] <gatox> mmcc, you can do this:
[18:46] <briancurtin> yeah, that should be changed to be by source instead of a tarball/egg/whatever
[18:46] <briancurtin> or some other fix to get the latest version
[18:47] <gatox> mmcc, (in another folder) bzr branch ubuntuone-dev-tools........ then replace the content of: buildout-path/eggs/ubuntuone-dev-tools*/ubuntuone/devtools....... when the content of the devtools that you download it
[18:49] <gatox> mmcc, is it clear? i can explain it better if you want
[18:50] <mmcc> gatox: yeah, I'm a little confused
[18:50] <gatox> mmcc, ok..... typing......
[18:50] <gatox> mmcc, do you have mumble already configured?
[18:50] <mmcc> gatox: I'm going to say no, because I don't know what that is
[18:51] <ralsina> mmcc: mumble is our corporate voip "solution"
[18:51] <ralsina> mmcc: let me find the wiki page for you, but it should be on the new employee one
[18:51] <dobey> it's also what some people do when on mumble
[18:51] <mmcc> ralsina, ok - then definitely no, but I do have it on the todo list, I have the link
[18:52] <ralsina> mmcc: ack
[18:52] <gatox> mmcc, here you have: https://wiki.canonical.com/StayingInTouch/Voice/Mumble?action=show&redirect=Mumble
[18:52] <gatox> sorry..... https://wiki.canonical.com/StayingInTouch/Voice/Mumble
[18:52] <gatox> mmcc, well...... i'll explain you here......
[18:52] <mmcc> gatox, is this path & devtools stuff fixed in your new branch?
[18:53] <gatox> mmcc, in my branch is fixed everything, except the devtools thing....
[18:54] <mmcc> I ask because it's lunchtime + 2hrs for me and if I could come back and just use a new branch, that might be more efficient
[18:54] <mmcc> ah, ok. saw your reply while typing
[18:55] <gatox> mmcc, do you need to have lunch?? no problem... we can do this: go, let me propose the branches.... and i'll guide you later using my branches, altough there won't be in trunk yet...
[18:55] <gatox> mmcc, but you will help to test if they work
[18:56] <mmcc> ok gatox , that sounds like a good plan. I'll be back shortly…
[18:56] <gatox> mmcc, no problem...... let me know when you are around
[19:13]  * alecu goes to the kinder
[19:30] <gatox> brb....... need to get some food
[19:37] <gatox> back
[20:01] <mmcc> gatox, back.
[20:02] <gatox> mmcc, ack
[20:02] <gatox> mmcc, so..... can you tell me in which step of the doc are you?
[20:03] <mmcc> gatox, well, I've done everything in the doc.
[20:03] <mmcc> gatox  so I guess it's the last step that is failing
[20:04] <gatox> mmcc, ok...... go to the ubuntuone-windows-installer folder and do this: bzr merge lp:~diegosarmentero/ubuntuone-windows-installer/mac-env
[20:05] <gatox> mmcc, once the merge is complete a env-mac file should appear in: ubuntuone-windows-installer/scripts/devsetup
[20:06] <gatox> sorry: env-mac
[20:06] <mmcc> gatox, yes it did
[20:06] <gatox> mmcc, you can execute that file doing: ./env-mac
[20:07] <gatox> that should prepare the system so you can run the tests, etc easier
[20:08] <gatox> mmcc, just to let you know..... the content of this branches might change before they land...... so maybe you will need to update your env after the branches land
[20:08] <mmcc> gatox, ok
[20:09] <gatox_mac> mmcc, if everything was ok running env-mac, you will see:
[20:09] <gatox_mac> Rename python to python_u1 to avoid crash when adding folder to SYSTEM PATH
[20:09] <gatox_mac> Adding bin to PATH
[20:09] <gatox_mac> Adding u1trial to env-vars
[20:09] <gatox_mac> Adding u1lint to env-vars
[20:09] <gatox_mac> Adding pylint to env-vars
[20:09] <mmcc> gatox I see it's appending to ~/.profile, which I don't currently use. I might use what it puts there but keep it in a separate file to use manually. I'm a little paranoid about automatically setting dev env vars…
[20:11] <gatox> mmcc, ok, feel free to put that wherever you want, the importat thing is those paths are accesible
[20:12] <gatox> mmcc, so....... if you use .profile, or something else...... when that is done..... you will be able to open a new terminal and type: echo $pylint...... and you should see the path to pylint..... let me knnow if that is working
[20:20] <gatox> mmcc, is it working'
[20:20] <gatox> ?
[20:20] <mmcc> gatox: sorry for the delay, no - but I think maybe I'm complicating it by using zsh… :\
[20:21] <mmcc> still it's not working for me in bash either. I get a complaint that the full path to u1trial is not a valid identifier
[20:22] <gatox> mmcc, can you show me the output?
[20:22] <mmcc> gatox just a sec
[20:22] <gatox> mmcc, you can use this to share output or code: http://paste.ubuntu.com/
[20:23] <gatox> mmcc, if you can show me the output that you get when running env-mac....... and the content of .profile or the file where you are putting this
[20:23] <mmcc> gatox, see http://paste.ubuntu.com/944682/
[20:25] <gatox> mmcc, ahhh i see...... i need to fix something in my branch
[20:25] <mmcc> that one is missing the PATH edit because I had already executed it once
[20:25] <mmcc> yes, there's a quoting thing going on here, right?
[20:27] <gatox> mmcc, ahhhhhh you follow the doc where it says to copy u1lint and u1trial into bin manually..... remove them from there....... using my branch that is not necessary
[20:27] <mmcc> gatox, ok
[20:28] <gatox> mmcc, inside the ubuntuone-windows-installer folder, do: bzr revert && bzr merge lp:~diegosarmentero/ubuntuone-windows-installer/mac-env
[20:28] <gatox> so you will get the env-mac file with the changes i just upload
[20:29] <mmcc> gatox, ok, underway
[20:30] <gatox> now...... remove the content of .profile that the script added.... and run ./env-mac again
[20:31] <gatox> and show me again the content of .profile
[20:33] <mmcc> gatox: http://paste.ubuntu.com/944689/
[20:33] <gatox> mmcc, nice.....
[20:34] <gatox> mmcc, you can move the content of .profile later.... just check that this work, and then you can move that
[20:34] <mmcc> gatox, so then the idea is I will run e.g. bin/python_u1 $pylint
[20:34] <mmcc> (that works)
[20:34] <gatox> mmcc, not yet.....
[20:35] <gatox> mmcc, you will need to do a couple of things more (sorry...... if this were already in trunk it would be easy)
[20:35] <mmcc> gatox, no worries. I've seen much (much) worse
[20:36] <gatox> mmcc, so, now in another folder (in your home or whatever) do: bzr branch lp:~diegosarmentero/ubuntuone-dev-tools/u1lint-mac-support
[20:36] <gatox> mmcc, this willl give you the new devtools
[20:37] <mmcc> gatox, ok done
[20:38] <gatox> mmcc, go to the u1lint-mac-support folder.... and copy the "ubuntuone" folder.... and with that folder, replace the one in: buildout-folder/scripts/devsetup/eggs/ubuntuone_dev_tools-3.0.0-py2.7.egg
[20:40] <mmcc> gatox, ok done
[20:40] <gatox> and then copy u1lint from u1lint-mac-support/bin/u1lint (again.... sorry for the manual steps... this will be automatically once the branches land).... and copy that file into (replacing the existing one): buildout-folder/scripts/devsetup/eggs/ubuntuone_dev_tools-3.0.0-py2.7.egg/EGG-INFO/scripts/u1lint
[20:41] <mmcc> gatox, ok done…
[20:41] <mmcc> gatox: same with u1trial?
[20:41] <gatox> mmcc, no, no need
[20:42] <mmcc> gatox: ok
[20:42] <gatox> mmcc, now you should be able to do (in anotherrrr folder): bzr branch lp:~diegosarmentero/ubuntu-sso-client/mac-port ubuntu-sso-client   (this is the branch from urrbanape + some other stuff)
[20:42] <dobey> gatox: why are you using 3.0.0?
[20:42] <gatox> dobey, it's the buildout
[20:42] <gatox> dobey, we should be using trunk
[20:43] <dobey> indeed you should be :)
[20:43] <gatox> dobey, i'm using trunk..... the buildout is downloading 3.0.0..... but i'm replacing it
[20:44] <dobey> gatox: buildout shouldn't download 3.0.0; it should just build the one from trunk, like it does with sso and protocol and the other stuff of ours
[20:44] <gatox> mmcc, once you download that branch...... open a new terminal (just inn case, so we are sure that the env-vars are loaded, etc)...... go inside the last ubuntu-sso-client branch that we download....... and you should be able to do: ./run-mac-tests
[20:45] <gatox> dobey, i know..... but i wasn't working in that part... i was focus in having the tests running in mac... i'll modify that later, or talk with brian if he prefers to do it
[20:45] <gatox> mmcc, let me know if that works
[20:47] <mmcc> gatox: not quite, setup.py complains:
[20:47] <mmcc> To build this program you need https://launchpad.net/python-distutils-extra
[20:47] <gatox> mmcc, ahhhhh i thought you have that.... just a sec
[20:48] <gatox> mmcc, ok, great! i was missing that
[20:48] <gatox> mmcc, open the run-mac-tests script with some editor
[20:49] <mmcc> gatox ok
[20:49] <gatox> and replace the line: ./setup.py build....... with: python_u1 setup.py build
[20:49] <mmcc> gatox. I thought that's what you'd say. that works.
[20:50] <gatox> mmcc, are the tests running?
[20:50] <mmcc> gatox:  yes.
[20:50] <gatox> mmcc, AWESOME!! \o/
[20:51] <mmcc> gatox, PASSED (skips=50, successes=583)
[20:51] <gatox> mmcc, that is correct!
[20:51] <alecu> gatox: congrats!
[20:51] <mmcc> gatox: yes, thanks for the patient help :)
[20:52] <gatox> mmcc, no problem!
[20:52] <gatox> mmcc, now you can run the tests just using the run-mac-tests script.... but only for sso (the tests in the other branches are not working though)
[20:53] <gatox> ok....... now i'm EOD :P
[20:53] <mmcc> ok gatox, thanks again. good night
[20:54] <gatox> mmcc, bye...... i'll connected anyway.... ping me if you have any problem
[20:54] <gatox> see you tomorrow people!! bye
[21:00] <dobey> thisfred: care to review https://code.launchpad.net/~dobey/ubuntuone-client/sdtool-q-3-0/+merge/103376 ? :)
[21:00] <ralsina> End of day for me. Have fun people, see you all tomorrow!
[21:08] <thisfred> dobey: on it
[21:13] <thisfred> dobey: I don't understand the operators.setitem?
[21:14] <thisfred> dobey: ah, assignment is not a function?
[21:14] <thisfred> is the reason?
[21:14] <thisfred> nm. stupid lambdas :P
[21:14] <dobey> thisfred: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/syncdaemon-q/+merge/100984 for reference. i don't know exactly
[21:14] <thisfred> I think I do
[21:14]  * dobey just backporting merges from trunk :)
[21:16] <thisfred> can't do lambda x: whatever = x, because whatever = x is a statement, and you can't do statements in lambda
[21:16] <dobey> right
[21:17] <thisfred> dobey: approved
[21:17] <dobey> cool
[21:37] <dobey> alright, later all!