[00:11] <cyberplop> As I can sync contacts ubuntu one with thunderbird in  ubuntu 12.04?
[11:04] <gatox> good morning
[11:08] <mandel> gatox, morning!
[11:09] <gatox> mandel, hi! how are you?
[11:09] <mandel> gatox, good, done with some of the reseach about the fs events.. do you know why we have never considered kqueue?
[11:11] <gatox> mandel, no idea... i saw that long time ago when i was researching fs events for ninja.... but only a quick peek
[11:12] <mandel> gatox, hm.. ok I'm sending a long email to ubunet-discuss, canonical-tech and us (as in people working on the mac) with all the things I have looked at
[11:12] <gatox> mandel, good
[11:13] <gatox> mandel, i talk with alecu yesterday.... as soon as i have something to show here, i'm going to send you (alecu, you and mmcc) the branch, with the explanation of why i did everything, so we can discuss how to improve it, what need to be changed, and so....
[11:14] <mandel> gatox, how is he doing?
[11:14] <mandel> gatox, I mean alecu :)
[11:14] <gatox> mandel, he seems fine.... he went to google circus yesterday :P
[11:15] <gatox> mandel,  and he was really excited with qml
[11:15] <mandel> gatox, hahaha lucky him!
[11:26] <mandel> gatox, boring email sent, can you take a look at it and let me know if I forgot anything?
[11:26] <gatox> mandel, ack..... reading.....
[11:28] <mandel> gatox, I have a feeling that kernel qs is a better idea that reading from the fsevents io.. but I'm not sure..
[12:34] <mandel> gatox, I'm off to have lunch
[12:35]  * mandel lunch
[12:37] <gatox> mandel, ack
[12:54] <ralsina> good morning
[12:54] <gatox> ralsina, hi
[12:54] <ralsina> hi gatox, how are you?
[12:54] <gatox> ralsina, fine.... trying to fix some api things in fs-notif.... to see if i can start with the tests (it's a lot of codeee... i need to test it)
[12:55] <ralsina> gatox: cool
[12:55] <gatox> ralsina, you?
[12:55] <ralsina> gatox: fine, finally slept 7 hours last night, so better than the last few days
[12:55] <ralsina> gatox: for one reason or another I have been sleeping 3-4 hours since saturday
[12:56] <gatox> ralsina, why weren't you able to sleep?
[12:56] <ralsina> gatox: well, on saturday I arrived hone at 3:30 from the pyday :-)
[12:56] <gatox> ralsina, the excitment of the pyday :P
[12:56] <ralsina> then a family thing on sunday, then my sleep patters were just gone to hell
[12:57] <gatox> ralsina, i hate when that happens...... because you TRY to sleep.... and it's even worse!
[12:57] <ralsina> yeah
[12:58] <ralsina> so I spent all yesterday trying not to sleep and crashed at 10PM, and woke up today at 5:30, so not that bad
[12:58] <ralsina> and tonight it should be ok
[13:00] <gatox> ralsina, the next time you can't sleep, you should go to the hoyts in DOT... it's like be sitting in heaven! jeejjeee so relaxing!
[13:01] <ralsina> it's an expensive nap, though ;-)
[13:01] <gatox> or buy a chair like that!
[13:01] <gatox> jeje
[13:18] <ralsina> I would need to buy another living room
[13:42] <mmcc> morning folks…
[13:42] <gatox> mmcc, hi
[13:42]  * mandel back
[13:42] <mmcc> hey, my schedule this morning is a little weird - I need to take lunch a little early so I'm popping in early
[13:43] <mmcc> hi mandel, I saw your note earlier about kqueue - it's good for small things, but you need an open file descriptor for each file you need to monitor, so for our purposes we'd run out of file descriptors
[13:43] <mandel> mmcc, ralsina, gatox, so, what do we use for fs events? (did you read the mail?
[13:43] <mmcc> potentially
[13:43] <mmcc> I haven't read the mail yet, sorry
[13:44] <mandel> mmcc, yes, that is a problem we currently have with inotify too
[13:44] <gatox> mandel, i vote to give it a try to kqueue.....
[13:44]  * mmcc fires up his VM to read the email
[13:44] <mmcc> …and the VM crashed
[13:45] <ralsina> mandel: did
[13:45] <ralsina> mmcc: no, we don't run out of file descriptors on inotify we run out of watches
[13:45] <ralsina> anyone: I am getting a test failure on ussoc trunk on test_after_timeout_cache_expires
[13:45] <mmcc> ralsina, what's the limit on watches?
[13:46] <ralsina> mmcc: like 2048 IIRC
[13:46] <ralsina> this seems familiar to anyone ? https://pastebin.canonical.com/65732/
[13:47] <mandel> ralsina, which is similar in the way that you need one per directory
[13:47] <mmcc> ralsina: interesting. that's really low…
[13:47] <ralsina> mmcc: ha, mine are set to 524288 I suspect I will not run out ;-)
[13:47] <ralsina> mmcc: if you have an ubuntu near, read /proc/sys/fs/inotify/max_user_watches
[13:47] <mmcc> I just checked 'ulimit -n' on my osx box and got 'unlimited'
[13:47] <mandel> ralsina, I have seen that problem before, why is it happening?
[13:48] <ralsina> mandel: not the slightlest idea, I am fixing a completely unrelated thing
[13:48] <ralsina> mandel: I intend to submit and not care unless tarmac tells me to
[13:48] <mandel> mmcc, in mine I get ulimit -n: 256
[13:48] <ralsina> mmcc: ulimit -n is 1024 on ubuntu by default, it seems
[13:49] <mandel> ralsina, which distro, and what bug? if you changed something in weblcient it might be the reasons
[13:49] <mmcc> my 12.04 ubuntu has  8192 for max watches
[13:49] <mandel> s/reasons/reason
[13:49] <ralsina> mandel: ubuntu, I am just tweaking QApplication parameters to add a -testability for elopio
[13:49] <mandel> ralsina, weird.. if you want I can try in mine
[13:49] <ralsina> mmcc: I suspect I may have ran into the limit and kicked it a bit higher
[13:49] <ralsina> mandel: please
[13:50] <ralsina> mandel: if it's just my box, I will ignore it
[13:50] <mandel> mmcc, ralsina, match number of watches in mine is 8192
[13:50] <mandel> ralsina, that is why I offered a diff machine :)
[13:50] <ralsina> mandel: my branch:  lp:~ralsina/ubuntu-sso-client/testability
[13:51] <mmcc> ralsina: interesting. so what do we do now when we run out of inotify watches?
[13:51] <mmcc> if the answer is read the email, ok
[13:51] <ralsina> mmcc: we get a support request ;-)
[13:51] <ralsina> mmcc: but in order to get that, you need to be syncing 2000 folders, which is unusual
[13:51] <mandel> mmcc, ralsina, we can ask facundobatista, what happens when we run out of watches?
[13:51] <ralsina> mandel: it logs an error
[13:52] <facundobatista> mandel, we stop watching
[13:52] <ralsina> hmmmm ubuntu doesn't have a useful "man ulimit" and I ever remember what option is what.
[13:52] <mmcc> oh, the watches are only for directories… ok. what about the files? I was under the impression that inotify gave us per-file events?
[13:52] <mmcc> http://ss64.com/bash/ulimit.html ralsina
[13:52] <ralsina> mmcc: yes, but you only set watches on folders
[13:52] <mmcc> I had the dame problem
[13:52] <mmcc> same
[13:53] <ralsina> I had dame problems but then I got married
[13:53] <mandel> ralsina, mmcc, I'm inclined towards kqs just to avoid the need to run a daemon with root that does that stuff
[13:53] <mandel> if not, we can do the idea of make the daemon listen to a unix domain per user to ensure that we do not let people be evil
[13:53] <ralsina> mandel: using a lot of FDs is evil
[13:53] <ralsina> mandel: we may make the session crash if we starve other processes that need them
[13:54] <mmcc> ralsina: is there really a global pool of fds? this kind of thing is different on different systems
[13:54]  * mandel is surprised that file systems are not better written.. they seemed easy at uni
[13:54] <mmcc> over on solaris I once wrote a program that opened many tens of thousands of files, that was ok
[13:54] <ralsina> mmcc: at least on ubuntu, IIRC there is a limit per-user
[13:54] <ralsina> mmcc: no idea on OSX
[13:54] <mmcc> ralsina: ok, I'll look into that
[13:54] <ralsina> ok, no it's per process
[13:55] <ralsina> and there is a per-system limit "in some operating systems". Thanks for nothing internet!
[13:56] <mmcc> one thought I had a while ago was using kqueue to watch the N files in the most recently changed folders, and fsevents for the rest
[13:57] <mmcc> a little complicated but might be the best of both worlds - speed for people with small folders or lots of unused data, and just runs slower if you abuse it with lots of files that change a lot
[13:58] <mmcc> it is appealing to avoid a root daemon. the amount of work to do that the officially recommended OS X way is kind of high. I have an email drafted about this that I'll send in a bit
[13:58] <ralsina> mmcc: kqueue doesn't require root?
[13:59] <mmcc> ralsina: uh, maybe it does
[13:59]  * mmcc goes to check
[13:59] <mandel> ralsina, mmcc, no, they don't I've tested that already
[13:59] <mandel> ralsina, mmcc, I downloaded and ran the example app (one of the links in the email) and worked straight away
[13:59] <mandel> that is the only thing I have towards them, not root needed
[14:00] <mmcc> mandel ralsina, I thought so - I wrote a hacky program to use kqueue to run tests when source changed once, years ago: http://michael-mccracken.net/2009/09/stakeout-info/ I didn't think it required root
[14:00] <ralsina> mmcc: cool then
[14:02] <mandel> mmcc, how hard is it to tell launchd (by the way ralsina, is a much better way to launch user daemons/activities over our current approach in sso) to use several unix domain sockets?
[14:02] <mmcc> mandel, not hard, you give it a list
[14:03] <mmcc> a launchd daemon is an executable and a .plist metadata file that tells the launchd daemon how & when to start (and optionally kill) it
[14:03] <ralsina> mandel: there are tons of things we do that could be done better if we had an infinite amount of time ;-)
[14:03] <mmcc> so I meant you give it a list in the metadata file
[14:04] <mandel> mmcc, so, my idea would be, using the root daemon, to use a domain socket per user and update that list per new user that wants to use u1
[14:04] <mandel> mmcc, that way when we get a whitelist we know where it is coming from and can do some security checks, what do you think?
[14:06] <mmcc> mandel, I'm not sure if we need one named socket per user. If doing that means we need to change the metadata for the launchd daemon, then it won't work with code signing
[14:06] <mmcc> the metadata gets signed with the executable, so if you change it afterwards, launchd will refuse to run it
[14:07] <mandel> mmcc, dammed.. cause I read and read about launchd and if is is a daemon and not an activity (that is a user daemon, right) there is no way lauchd can help us with that.. :(
[14:08] <mmcc> right, a "launchd activity" would be appropriate for eg. the SSO stuff, but the fsevents daemon needs to run in system context, as a "launchd daemon"
[14:09] <mmcc> there's a way to do this, I'm sure… a root daemon that needs to know which user it's talking to can't be an unexpected use case
[14:09] <mandel> mmcc, I cannot find any docs about it..
[14:10] <mmcc> mandel, at this level, there's a gap in the docs. sometimes you need to read through their code samples
[14:11] <mandel> mmcc, I'll be reading the entire daemon docs and hope I missed something
[14:11] <mmcc> and in some cases if it's well-documented stuff in BSD or POSIX, apple won't have bothered to write new docs about it, or even really point you to the right stuff
[14:12] <mmcc> so if the answer is "oh yeah, it's the same on all unixes, just read the man page for accept() or socket() or whatever," then you won't find that in Apple's docs.
[14:12] <mmcc> the man pages are all there, but their tech writers assume that if you need to look at them, you already have. or something
[14:16] <mmcc> mandel, we need to read over 'man 2 accept' and the SEE ALSOs in there :)
[14:17] <mandel> lets see..
[14:17]  * mandel looks
[14:18] <briancurtin> ralsina: windows 3.0.0 release is live
[14:18] <mandel> \o/
[14:18] <ralsina> \o/ |o| /o/ /o\
[14:18] <ralsina> That was the YMCA dance
[14:19]  * ralsina is happy
[14:19] <gatox> awesome!
[14:20] <mmcc> ok guys, I have to duck out for a bit, call it an early lunch.
[14:20] <mmcc> I think I will probably miss the standup, so :
[14:20] <mmcc> DONE: lots of research on launchd, code signing, IPC protocols, etc
[14:20] <mmcc> TODO: more of the same
[14:20] <mmcc> BLCK: no
[14:25] <mandel> mmcc, ralsina, from the apple docs: http://paste.ubuntu.com/977950/
[14:25] <mandel> gatox, ^
[14:26]  * gatox reading...
[14:26] <mandel> ralsina, running your branch: http://paste.ubuntu.com/977952/
[14:28] <mmcc> mandel, just read that. that's OK because we don't need to use the window server
[14:29] <mmcc> the 'dedicated user' thing is still a good idea, but since that makes it hard to do drag-to-install, apple made the SMJobBless API that interacts with code signing and launchd
[14:31] <mmcc> look at this readme from the relevant sample code: https://developer.apple.com/library/mac/#samplecode/SMJobBless/Listings/ReadMe_txt.html
[14:31] <mmcc> and now I am going again…
[14:31]  * gatox starts with filesystem_notifications tests.....
[14:58] <ralsina> team, standup in 2'
[14:59] <ralsina> mandel: oops, forgot to push
[14:59] <mandel> ralsina, np
[14:59] <ralsina> mandel: could you try now?
[15:00] <gatox> me
[15:00] <ralsina> me
[15:01] <briancurtin> me
[15:01] <ralsina> thisfred: standup
[15:02] <ralsina> mandel: stndup
[15:02] <thisfred> me
[15:02] <ralsina> ok, mandel is last
[15:02] <ralsina> gatox: go
[15:02] <mandel> me
[15:02] <gatox> DONE:
[15:02] <gatox> Finish with filesystem_notifications/darwin.py, some reviews, starting with tests for filesystem_notifications on MAC OS.
[15:02] <gatox> TODO:
[15:02] <gatox> Check filesystem notifications implementation in MAC OS (tests), Fix: Bug #995146, Bug #996025. Include run-mac-tests on u1-client
[15:02] <gatox> BLOCKED:
[15:02] <gatox> No
[15:02] <gatox> ralsina, go
[15:02] <ralsina> DONE: canonicaladmin sweep, couple of 1-1s, working on a bug for elopio TODO: finish that bug, start another one, doctor's appointment BLOCKED: no NEXT  briancurtin
[15:02] <briancurtin> DONE: installer automation, 1-1, pushed on the installer upload and it was completed this morning
[15:02] <briancurtin> TODO: switch to embed our own copy of the CRT rather than including and running vcredist.exe
[15:02] <briancurtin> BLOCKED: None
[15:02] <briancurtin> NEXT: thisfred
[15:02] <briancurtin> also TODO: dr. appt at 1300 my time
[15:03] <thisfred> DONE: get u1todo ready for workshop
[15:03] <thisfred> TODO: last minute fixes if any
[15:03] <thisfred> BLOCKED: no
[15:03] <thisfred> NEXT: mandel
[15:03] <mandel> DONE: research, think about fs events and the diff approaches.
[15:03] <mandel> TODO: Do a small demo of how we could deal with using a root daemon.
[15:03] <mandel> BLOCKED: no, but problem is hard.
[15:06] <alecu> hola!
[15:07] <gatox> alecu, buenas
[15:08] <alecu> gatox: did I just missed the standup?
[15:09]  * alecu should go downstairs to get a better internet connection.
[15:11] <gatox> alecu, yep
[15:11] <ralsina> alecu: yes you did, but you are exempt
[15:11] <ralsina> alecu: rule is, you are in UDS, be in UDS
[15:11]  * gatox lunch...
[15:12] <alecu> gatox, ralsina: I know I'm except, but I really wanted to listen to it.
[15:12] <alecu> ralsina, mandel's mail from this morning is awesome.
[15:12] <ralsina> alecu: I can pastebin if you want
[15:12] <alecu> (my morning at least)
[15:12] <ralsina> alecu: yeah, when he thinks before writing stuff, it usually is :-)
[15:12] <alecu> ralsina, don't worry: I'll get it from irclogs.ubuntu.com
[15:12] <alecu> ralsina, lols
[15:13]  * alecu should also get some breakfast before sessions begin.
[15:13] <alecu> ralsina, gatox: I'll try to be in tomorrow's mumble
[15:14] <mandel> ralsina, you mean when I have time to think ;)
[15:14] <alecu> mandel, oh, hi!
[15:14] <mandel> alecu, hola! how was the circus?
[15:15]  * mandel misses one uds in 2 years and they get a circus, wtf?!
[15:15] <alecu> mandel, my gripe with kqueue is that afaik we have to keep an open file descriptor per file and folder that we are watching.
[15:15] <alecu> mandel, it was circus + minigolf.
[15:16] <mandel> alecu, yes, that is an issue.. which is a problem if we reach the limit and if that limit is set for the user
[15:16] <alecu> mandel, you would have loved the circus. They had a really tall guy in a tight blue latex bunny suit.
[15:17] <mandel> alecu, lol
[15:17] <alecu> mandel, there were also a lot of nice ladies in oldish outfits, but you'd really liked the bunny man.
[15:17] <mandel> alecu, I would have loved it indeed, the bunny man I mean.. hehe
[15:18] <alecu> mandel, I'm pretty sure pictures will pop up of geeks playing minigolf while circus ladies distracted them.
[15:18] <mandel> alecu, the concern I have with the unix domain socket is the security, one thing we could do is to ask the connecting client to give us a token/cookie that we can only acquire
[15:18] <mandel> alecu, lol dmedia posted a number, well jason
[15:19] <alecu> cool :-)
[15:20] <alecu> mandel, so, a cookie sounds interesting, and we do that for tcp connections in the proxy tunnel, since there's no other way to do it.
[15:20] <alecu> mandel, but for unix domain sockets there are other ways...
[15:20] <mandel> alecu, tell me, tell me
[15:20] <alecu> mandel, like having the root daemon creating the socket in a directory owned by the user with 0600 permissions
[15:21] <alecu> mandel, perhaps in the user's .cache folder.
[15:21] <alecu> mandel, oh, and back to kqueue
[15:21] <mandel> alecu, and we create on for each user? that was my idea wondering if we can use launchd.plist to provide a list of users, but it is not the case
[15:22] <mandel> alecu, we would have to create them per user, which is a little ugly
[15:22] <alecu> mandel, I've no idea about launchd, but I love the fact that you now do :-)
[15:22] <alecu> mandel, per user is fine, I think.
[15:23] <mandel> alecu, he, give me a circus with a guy dressed as a bunny and I'd happily forget it
[15:23] <mandel> alecu, well, per user is not ubber terrible since we do not expect to have 20 users in a laptop or imac
[15:23] <alecu> mandel, right
[15:24] <mandel> alecu, ok, I'll try to write a small example that does that and see what happens
[15:24] <alecu> mandel, and in any case, users that are not logged in will not get any packets in those UDSs, since their files won't be touched. right?
[15:25] <alecu> mandel, also: I think the root daemon should send no packets at all until it's requested by one syncdaemon to start watching a given folder.
[15:25] <mandel> alecu, yes, unless we start supporting things out of $HOME, but that is someones problem atm
[15:25] <alecu> (or recursive folder, even better)
[15:25] <alecu> mandel, well.... right. But we probably want to support stuff out of HOME only when that stuff is owned by the user that started syncdaemon.
[15:26] <mandel> alecu, yes.. I'll do a quick mock and we can see how well it works with several users, might be ready by late tom for us to test
[15:26] <alecu> I'm getting ahead of my head. We should first of it all define what we want to do with out of HOME stuff, and then see how we fit it for all OSs
[15:27] <alecu> mandel, so, let's not worry about out of HOME for the mac port until we are worrying about that for every OS.
[15:27] <alecu> mandel, one last thing.
[15:27] <ralsina> alecu: we need to have a design meeting or that when yu are back from UDS
[15:27] <alecu> mandel, regarding kqueue:
[15:27] <alecu> mandel, I'm not saying we should rule out kqueue: we should run some experiments with it too
[15:28] <alecu> mandel, afaik, there's a kqueue reactor that runs ok on mac, so it might be an easier solution.
[15:28] <mandel> alecu, yes, I've seen that in the twisted docs, but we need to test it, it might happen the same as the IOCPReactor
[15:29] <alecu> mandel, I only gave it a quick look, but we surely should look at it in a more deeper way.
[15:29] <mandel> is there, doesn't work
[15:40] <mmcc> guyas, launchd creates the socket for you - our root daemon doesn't call socket(), it gets the file descriptor for an already open socket from launchd when it does a "checkin" through launchd's api
[15:40] <mmcc> s/guyas/guys
[15:41] <mmcc> so, we tell launchd ahead of time in an info.plist (that we have to code-sign with our certificate) which sockets to creatte
[15:41] <mmcc> so, I don't think one per user will work with launchd.
[15:41] <mmcc> but you *can* get a connection per user, on the single socket.
[15:42] <mmcc> might want to look at how mysql does it - it has a single socket at /tmp/mysql.sock, but I'm guessing it manages to do so securely
[15:43] <ralsina> mmcc: it uses its own auth system internally
[15:43] <ralsina> mmcc: you have to send/get credentials over that socket
[15:44] <mmcc_phone> Ah ok.
[15:44] <ralsina> mmcc: so, we may do something like a cookie system. The user has to create a cookie file in his $HOME and send the right data over the socket, then the daemon verifies that the user got it from that (secure) file
[15:54] <mandel> ralsina, mmcc, the other idea is to let our daemon to create several sockets, one per user under xdg cache.. I wonder if lancudh allows to do that..
[16:01] <mmcc_phone> Mandel I dont think it will. It wants to create all our sockets for us.
[16:01] <mandel> mmcc, greedy launchd...
[16:01] <mmcc_phone> So it can start us on demand and kill us at will
[16:03] <mandel> mmcc_phone, can he? uh..
[16:05] <ralsina> revert the socket. Make the client start one and just send a message 'connect to user blah's socket'
[16:06] <ralsina> a-la ftp active mode
[16:07] <mmcc_phone> we can inhibit killing. I only mentioned it because it it one reason launchd wants control pf your sockets
[16:08] <mmcc_phone> Ralsina hmmm interesting. But it seems like it shouldnt be this hard right? We ought to be able
[16:08] <ralsina> mmcc: yes
[16:08] <mmcc_phone> To find out what user we connected to when we accept()
[16:09] <mmcc_phone> Thats all we need
[16:09]  * mmcc_phone is sure its in the manpages somewhere but they are not on his phone
[16:09] <mandel> mmcc_phone, ralsina, yes the server can try to connect and request the whitelist of dirs intead of the otherway around
[16:20] <ralsina> dobey: ping whenever you have a moment, did you get a chance to think/ask about the aptdaemon problem in installer?
[16:22] <dobey> ralsina: sort of. mvo was going to look at the installer code. will ping him again today before he leaves
[16:23] <ralsina> dobey: ack
[17:20]  * briancurtin lunch+doctor
[17:25] <mandel> ok, EOD for me laters!
[17:30] <ralsina> gatox, thisfred: may I get a couple of easy reviews? https://code.launchpad.net/~ralsina/ubuntu-sso-client/testability/+merge/105232
[17:30] <thisfred> sure, after u1db workshop
[17:32] <ralsina> thisfred: thanks1
[17:33] <gatox> ralsina, on it
[17:35] <gatox> ralsina, the line 27 of the diff is it necessary?? i'm only looking at the diff, not the whole file
[17:35] <ralsina> gatox: looking...
[17:36] <ralsina> gatox: the "import os"? Yes
[17:36] <ralsina> gatox: or else I can't see os.environ
[17:36] <gatox> ralsina, i was asking because it's the only thing new in that file
[17:36] <ralsina> gatox: nope it's not. Line 47 of the diff is in the same file
[17:37] <ralsina> oh, wait
[17:37] <ralsina> no it's not.
[17:37] <ralsina> agreed, let me remove it
[17:37] <gatox> ralsina, ack
[17:39] <ralsina> gatox: fixed and pushed
[17:39]  * gatox looking....
[17:43] <duanedes1gn> gatox: ralsina i just got a response from windows user runing -- "echo %USERPROFILE%" and I got
[17:43] <duanedes1gn> the response "C:\Users\Adam""echo %USERPROFILE%" and I got
[17:44] <duanedes1gn> Ubuntu One is askinh fim Please choose a folder inside your "C:\SPB_Data" directory
[17:44] <gatox> duanedes1gn, mmmm that's weird.... why is returning another path then.....
[17:45] <ralsina> duanedes1gn: is that with 2.0.3?
[17:45] <ralsina> duanedes1gn: we had a case a long time ago about if the user had %HOME% set, then we got confused. It *may* be that, but that's fixed in 2.0.3 IIRC
[17:47] <gatox> ralsina, everything is ok with the branch, just a minor fix about a lint issue..... i paste it in the MP
[17:47] <ralsina> gatox: thanks, my pylint is kinda broken for some reason :-/
[17:47] <duanedesign> i can ask him for logs for more info. does not look like our conversation includes version number
[17:47] <ralsina> gatox: OTOH, I am on windows ;-)
[17:47] <gatox> ralsina, ahhhhhhh
[17:47] <ralsina> duanedesign: you can tell him to update to 3.0.0 which is out today :-)
[17:47] <ralsina> gatox: thanks!
[17:47] <duanedesign> ok :)
[17:48] <ralsina> gatox: pushed with lint fix
[17:49] <gatox> ralsina, great
[17:53] <gatox> ralsina, +1
[17:53] <ralsina> gatox: gracias!
[17:58] <thisfred> ralsina: I don't understand the branch: when the env variable is *not* there you add the argument?
[17:58] <ralsina> thisfred: no, when the variable *is* there
[17:58] <thisfred> + if os.environ.get('TESTABILITY', False) and \
[17:58] <thisfred> 48	+ 'testability' not in sys.argv:
[17:58] <thisfred> 49	+ sys.argv.append('-testability')
[17:59] <thisfred> ah
[17:59] <thisfred> nm
[17:59] <ralsina> thisfred: ok, when the variable is set and is not already in argv
[17:59] <ralsina> thisfred: just to not put it twice
[17:59] <thisfred> ralsina: brainfart. I sort of forgot how get worked
[17:59] <thisfred> ralsina: C is rotting my brain
[17:59] <ralsina> thisfred: also, that's wrong
[18:00] <mmcc> thisfred: C is good for you! C is a vitamin!
[18:00] <ralsina> missing - in the second line
[18:00] <thisfred> see, I knew there was something wrong!
[18:00] <ralsina> thisfred: I wrote it, it *must* have something wrong :-)
[18:00] <thisfred> mmcc: I actually liked doing C more than I expected. Or hated it less, if you will ;)
[18:01] <ralsina> thisfred: pushed the change
[18:01] <thisfred> ralsina: cool
[18:01] <mmcc> btw I'm back for good now, sorry about being around intermittently this morning… now making sure I really understand bsd sockets api
[18:02] <mmcc> thisfred, C really has its charms. a featureful standard library isn't one of them, but that's OK
[18:02] <thisfred> ralsina: also the win32 path does not do that check at all, if that matters
[18:02] <ralsina> thisfred: I did it because on the tests I ended with -testability thrice and that looked ugly. IRL it doesn't matter, rally
[18:03] <thisfred> kk
[18:03] <ralsina> thisfred: also could be argued that the tests for main suck but what's new ;-)
[18:03] <thisfred> ralsina:  +1
[18:03] <ralsina> thisfred: thanks!
[18:03] <thisfred> on the review. The tests sucking I am +0 no idea
[18:04] <thisfred> https://en.wikipedia.org/wiki/Rational_ignorance
[18:04] <thisfred> tldr: tldr
[18:04] <ralsina> he
[18:10]  * gatox finds out..... that in order to test filesystem_notifications in mac, he is going to need some other packages....
[18:10]  * gatox starts writing a branch for os_helper
[18:14] <ralsina> I have to go to a doctor's appointment, should be back in 90' or so
[18:14] <gatox> ralsina, ack
[18:15] <mmcc> gatox, I have a darwin version of os_helper that I hacked together a while ago, are you interested?
[18:16] <gatox> mmcc, ok!! i was just starting to write a branch for that
[18:17] <mmcc> it's a short diff, just a sec I'll paste it
[18:21] <dobey> why don't i get this bug?
[18:21] <ralsina> dobey: what bug?
[18:21] <dobey> the installer bug
[18:22] <mmcc> gatox, here is what I did, diffed against a recent os_helper/linux.py
[18:22] <mmcc> http://paste.ubuntu.com/978435/
[18:22] <Captain_Proton> Have a stupid problem. I install ubuntu one music app for android, but I can not figure out how to login to my account
[18:23] <mmcc> gatox, I didn't push it anywhere because tests weren't working so I haven't tested it, but hopefully it's a little useful for you :) let me know if anything doesn't make sense
[18:23] <gatox> mmcc, thanks, i'll grab that and make the tests..... thanks!
[18:25] <ralsina> dobey: you need to have out-of-date data in apt
[18:25] <ralsina> dobey: like, disable nightlies, remove u1, enable nightlies again
[18:25] <dobey> what sort of out of date data?
[18:26] <ralsina> dobey: the kind that needs an apt-get update
[18:26] <ralsina> and now I am really off
[18:32] <Captain_Proton> No one has any idea how to login to ubuntu one music app? Should I contact support?
[18:34] <dobey> i don't have android
[18:34] <dobey> duanedesign: can you help Captain_Proton ?
[18:35] <duanedesign> Captain_Proton: do you have Ubuntu One Files installed?
[18:35] <Captain_Proton> yes
[18:37] <Captain_Proton> i thought it would use that key, but all it show in the music app is the demo songs
[18:37] <duanedesign> Captain_Proton: it should use that key
[18:38] <duanedesign> Captain_Proton: can you select 'Demo' at the top of he screen and change the mode?
[18:40] <Captain_Proton> Opps, something went wrong... maybe it just my crappy phone :)
[18:50] <Captain_Proton> duanedesign, thanks atlest I know how I will play with it see if I can get it to work
[18:52] <Captain_Proton> uninstalled it  & reinstalled it and it work now :D
[19:07] <ralsina> blah, doctor cancelled
[19:14] <ralsina> mmcc: based on the nicks you used today I am guessing you have emacs on your phone.
[19:17] <mmcc> ralsina: heh, I wonder if that's possible. no, I was on the phone, now I'm using emacs
[19:17] <ralsina> mmcc: http://lists.gnu.org/archive/html/guile-user/2011-06/msg00024.html
[19:17] <mmcc> I had a scheme REPL on a Palm III once, so that's something...
[19:18] <ralsina> mmcc: http://www.emacswiki.org/emacs/EmacsOnAndroid
[19:18] <ralsina> mmcc: you first have to install a ROM... with Debian ;-)
[19:19] <mmcc> heh. Well, maybe if there's ever an Ubuntu phone, then I can get my emacs there too
[19:21] <gatox> mmcc, do you know how to set the application name in mac for a python application?
[19:21] <mmcc> gatox, that's a big question - that's why I punted on the function in os_helper
[19:22] <gatox> yep..... i'm trying to figure it how to do it, but i can't find it
[19:22] <mmcc> There isn't really API to do that programmatically
[19:22] <mmcc> it's a packaging thing. The app name is a value you set in the Info.plist that's inside your .app bundle
[19:22] <gatox> mmcc, yep..... that's what i'm seeing
[19:22] <mmcc> if you don't have a .app bundle, well then you're not an "Application" that should have a name, as far as os x is concerned
[19:23] <mmcc> that's one reason why our SSO client has a default python icon - there's a bug for that assigned to me now
[19:23] <mmcc> so I think the right thing to do with that os-helper function is to make it a noop
[19:24] <mmcc> and we'll take care of it if necessary during packaging
[19:27] <mmcc> gatox, does that sound OK to you? should make testing it easy :)
[19:27] <gatox> mmcc, yes..... it sounds right
[19:27] <mmcc> gatox: cool
[20:08] <mmcc> I knew there had to be an easier way - on BSD, you can call get
[20:08]  * mmcc getting used to emacs relay chat
[20:09] <mmcc> BSD has getpeereid, which tells you the effective user/group ID of the process on the other end of a connected UNIX domain socket
[20:10] <mmcc> there's a similar but not exactly compatible linux mechanism using an ancillary message of type "SCM_CREDENTIALS"
[20:10] <mmcc> the manpage tells me this is reliable, and a common use is for a server to verify the credentials of its client, so this is the way to go :)
[20:24] <gatox> eod here! bye people!
[20:24] <mmcc> bye gatox o/
[20:24] <gatox> mmcc, bye
[20:48] <joshuahoover> ralsina: support keeps getting reports from turkish users who can't connect, all of them that have tried nightlies report back the same so i filed bug #997326
[20:49] <ralsina> joshuahoover: ack, let's try to find a workaround tomorrow (I am EOD in 10 minutes)
[20:49] <ralsina> joshuahoover: let me find something to try
[20:49] <joshuahoover> ralsina: you can't figure out in 10 minutes?
[20:49] <joshuahoover> ;)
[20:49] <ralsina> joshuahoover: well, I do have something, but I would need windows to verify it ;-)
[20:50] <ralsina> joshuahoover: on windows control panel, look for certificates, and then would have to look for the valicert certificate and enable it for all purposes
[20:50] <ralsina> joshuahoover: that would make the symptom go away at least
[20:50] <ralsina> joshuahoover: there is a good chance this is caused by the government firewall of Turkey
[20:50]  * ralsina remembers internet in turkey: not fun
[20:51] <joshuahoover> ralsina: this is on ubuntu, precise (using nightlies to get the debug info)
[20:51] <ralsina> oh :-(
[20:52] <ralsina> joshuahoover: then we need to find how to install the valicert certificate in ubuntu
[20:52] <ralsina> joshuahoover: I can ask, but not in 8 minutes ;-)
[20:52] <joshuahoover> heh
[20:53] <ralsina> joshuahoover: cp /usr/share/ca-certificates/mozilla/ValiCert_Class_2_VA.crt /etc/ssl/certs
[20:54] <ralsina> joshuahoover: with all due caveats ;-)
[20:54] <ralsina> joshuahoover: and probably a reboot
[20:55] <joshuahoover> heh, k...i can have them try that
[20:55] <ralsina> joshuahoover: wait, on my system those two are the same file
[20:55] <joshuahoover> oops
[20:55] <ralsina> joshuahoover: maybe in theirs it's not
[20:55] <joshuahoover> ralsina: right, it's in mine too
[20:56] <joshuahoover> ralsina: i'll have them try and let us know one way or the other
[20:56] <ralsina> ack
[23:54]  * mmcc goes to play some hockey.