[04:32] <wilee-nilee> Hello channel, so when I fire up ubuntuone in ubuntu it asks for my password, is there any way to have it login into ubuntuone automatically with out using my password on the OS there also?
[11:22] <gatox> good morning
[12:35] <JoseExposito> Hi! Someone can say me where the source code of u1sdtool please?
[12:39] <gatox> JoseExposito, it's part of the ubuntuone-client project
[12:39] <JoseExposito> gatox, can you say me what class(es) please?
[12:39] <gatox> JoseExposito, but i'm having problems with launchpad at this moment, you can do: bzr branch lp:ubuntuone-client
[12:40] <gatox> JoseExposito, u1sdtool is a script inside the bin folder
[12:40] <JoseExposito> I'm looking for a simple example to add a python utility tool to get the state of the files to the finder plugin
[12:41] <JoseExposito> gatox, ok, thank you very much!!
[13:36] <dobey> u1sdtool as a script doesn't really do anything though
[13:36] <dobey> you need to look at the SyncDaemonTool API that it uses
[14:12] <dobey> gah stupid hurricane. it is too cold here for an anime convention
[14:13] <gatox> nuuuuuuuu
[14:22] <dobey> heh
[14:28] <JoseExposito> dobey: I'm sorry, I was eating. Where can I check the available calls to the SyncdaemonTool? Is there any documentation?
[14:38] <gatox> dobey, could you review this trivial branch? https://code.launchpad.net/~diegosarmentero/ubuntuone-client/case-insensitive-search/+merge/132703
[14:41] <dobey> JoseExposito: u1sdtool does make those calls; and they should be documented in the module so you can read the docs with pydoc, but i don't recall the exact module import path right now
[14:43] <mmcc> JoseExposito, the SyncDaemonTool class is defined in ubuntuone-client/ubuntuone/platform/tools/__init__.py — there are two implementations of the SyncDaemonToolProxy IPC proxy that it uses , and the one we use on os x is in perspective_broker.py
[14:44] <mmcc> you don't really need to look at the perspective_broker proxy, I only mention it to explain the other files in that directory
[14:45] <JoseExposito> mmcc, ok thank you very much, I'll check this module and I'll try to do something
[14:46] <gatox> mmcc, hi, when you have sometime please: https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/socket-communication/+merge/132409 i think you have been already reviewing this
[14:49] <dobey> hrmm
[14:50] <dobey> even for dummy data, i don't really like seeing '/path/to/foo' in it; because in the tests there is no 100% obvious "this is completely useless dummy data" separation from "this actually touches the disk somewhere"
[14:50] <mmcc> JoseExposito you're welcome - I think you will want the 'get_metadata' call. to save you hours of figuring out the IPC, if you want to know what that actually returns, the function that ends up getting called is get_metadata in the SyncdaemonFileSystem class in ubuntuone/syncdaemon/interaction_interfaces.py
[14:51] <mmcc> JoseExposito and you can play around with u1sdtool --info to see what that call returns
[14:51] <gatox> dobey, we actually have that in a lot of places
[14:52] <mmcc> JoseExposito, unfortunately it's not super user friendly, but you can always ask here if something's not obvious. good luck!
[14:52] <dobey> gatox: dummy data with '/foo/' you mean?
[14:52] <gatox> yes
[14:52] <JoseExposito> mmcc, thanks! I think that get_metadata and change_public_access is all that I need
[14:53] <dobey> gatox: yes, mostly due to historical reasons.
[14:53] <mmcc> gatox, yes I'm reviewing that now.
[14:53] <JoseExposito> mmcc, but I don't see any field with the status of the file (uploading or uploaded)
[14:54] <mmcc> JoseExposito yep, that's what I meant by not user friendly :) it might require some understanding of the syncdaemon internals
[14:55] <dobey> JoseExposito: you should probably connect to syncdaemon via IPC and actually connect to the necessary signals, rather than trying to poll for status of individual files
[14:56] <mmcc> JoseExposito actually there's other SDTool API that might be more useful. look at get_current_uploads and get_current_downloads, for example
[14:57] <mmcc> and dobey is right, you will want to register for updates as well, so you don't have to poll… let me see if there's a good example of that
[14:57] <JoseExposito> dobey, the problem is that the Finder plugin must be wrote in objective-c, and it doesn't has a twisted API (as I know)
[14:57] <dobey> it's too bad libsyncdaemon is a) not great, and b) not cross-platform
[14:58] <dobey> JoseExposito: you can't use pyobjc?
[14:58] <JoseExposito> mmcc, yes, it looks more easy
[14:58] <JoseExposito> dobey, I don't try it, but I think that no
[14:58] <mmcc> you could, but it wouldn't be easy
[14:59] <JoseExposito> dobey, think that Finder doesn't allow plugins, is all reversing & code injection
[14:59] <dobey> JoseExposito: if it's not a plug-in, then i see no reason it would need to be in ObjC :)
[15:00] <rockstar> me
[15:00] <gatox> me
[15:00] <JoseExposito> dobey, could be possible, but I think that inject python code in a objc process is not possible
[15:00] <briancurtin> ,e
[15:00] <briancurtin> me
[15:00] <mmcc> dobey it is much easier to inject objc code into the finder than arbitrary C code…
[15:00] <mmcc> me
[15:01] <dobey> me
[15:01] <mmcc> JoseExposito , we're just doing a quick meeting, will get noisy for a sec
[15:01] <JoseExposito> ok
[15:01] <dobey> mmcc: i understand objc is obviously easier. we're doing python on mac, so basically nothing is 'easy' :)
[15:02] <rockstar> DONE: Track down support App store problem (bug in App store). Catch up with outstanding tasks from urbanape.
[15:02] <rockstar> TODO: Split up this branch work into reviewable pieces (it's a mega-branch currently, and still isn't quite finished)
[15:02] <rockstar> BLOCKED: Nope
[15:02] <rockstar> NEXT: gatox
[15:02] <gatox> DONE:
[15:02] <gatox> Fixed some branches, fix case insensitive search, trying to get u1-cp running on windows to check a bug (not possible yet), working in a u1-cp related bug. Complete the canonical survey.
[15:02] <gatox> TODO:
[15:02] <gatox> Finish and propose the branch, keep fixing u1-cp, u1-client bugs.
[15:02] <gatox> BLOCKED:
[15:02] <gatox> No
[15:02] <gatox> briancurtin, go
[15:02] <briancurtin> DONE: tiny branch to fix ubuntu_sso.constants, installer rebuilding. tested new installer with cert branch on XP, Vista, 7, and 8, and it works
[15:02] <briancurtin> TODO: send build to QA, keep on testing, reviewing what needs to be done in order to do final release. need to look where we version log files, i believe that needs to be done by hand as of right now on windows
[15:02] <briancurtin> NEXT: mmcc
[15:02] <mmcc> DONE: pyobjc menu integration
[15:02] <mmcc> TODO: same
[15:02] <mmcc> BLOK: no
[15:02] <mmcc> NEXT: dobey
[15:03] <dobey> ONE: reviews of diego's branches, discussion about terminology, team call
[15:03] <dobey> TODO: reviews, tarmac updates
[15:03] <dobey> BLCK: None.
[15:03] <mmcc> next dobey
[15:03] <mmcc> um
[15:03] <dobey> s/ONE/DONE/
[15:03] <mmcc> sorry
[15:03] <dobey> and done.
[15:03] <rockstar> next dobey
[15:03] <rockstar> :)
[15:03]  * mmcc dislikes my irc client
[15:03] <mmcc> it stopped scrolling the text…
[15:03] <chaselivingston> mmcc: what are you using?
[15:04] <mmcc> chaselivingston - Linkinus for the last couple weeks. I was using Colloquy but it was annoying for other reasons
[15:04] <rockstar> Use textual. Don't look back.
[15:04] <chaselivingston> mmcc: yeah, I've found textual is probably the best
[15:05] <mmcc> ok, I'll take another look. that's the only one I haven't tried yet…
[15:06] <dobey> just run irssi on a server somewhere under screen/tmux
[15:06] <mmcc> "a server somewhere" :(
[15:06] <briancurtin> the cloud
[15:06] <mmcc> the moon!
[15:07] <chaselivingston> i'm setup on the team's bip server, so i can just connect my client when i want to read what's been going on
[15:07] <dobey> nah, the king of the moon can be moody
[15:08] <dobey> so he might cut off your connection/head
[15:08] <mmcc> I knew moon computing was hype
[15:11] <mmcc> to call back into the patched finder and make your changes. It's all possible, but a bit messy, and every interaction with the finder code is unsupported and fragile…
[15:13] <dobey> bah; that clip isn't on youtube :-/
[15:13] <briancurtin> dobey: stable 4.2 is what i should be releasing out of, correct?
[15:14] <dobey> briancurtin: not yet; afaik you should release what's in stable-4-0 for a windows release
[15:40] <dobey> ok, need to get lunch. bbiab
[15:47]  * gatox lunch
[15:57] <JoseExposito> mmcc, I'm looking how to connect objc with twisted, that I think that is the better option: http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
[15:58] <JoseExposito> where can I found the protocol definition? (and the sync daemon port)
[16:06] <mmcc> JoseExposito, the protocol that it uses is the twisted "perspective broker" RPC protocol. if you want to write an objc-only client for the IPC, you would have to re-implement that protocol in objc. Just a sec and I'll send you links to their docs.
[16:10] <mmcc> JoseExposito here: http://twistedmatrix.com/documents/current/api/twisted.spread.pb.html
[16:11] <briancurtin> i'm heading to lunch with some old coworkers. be back in a while, will stick around later.
[16:11] <mmcc> I'm not sure if there's any docs on how to implement that in other languages, probably not. The best bet is looking at the source, and you're looking at a significant amount of work…
[16:13] <JoseExposito> mmcc, mmmm it looks so difficult, not like the chat example xD I'll check it, but it looks more easy add a plain text based protocol to the sync daemon that implement this in objc :S
[16:13] <mmcc> JoseExposito it might be less work to implement a separate python wrapper that uses the twisted perspective broker API to talk to syncdaemon and then a simpler custom RPC protocol to talk to your plugin.
[16:13] <JoseExposito> mmcc, yes, I think that is a better idea
[16:15] <mmcc> JoseExposito yes. I wouldn't want to reimplement the perspective broker stuff in C/objc. You'd need to fully understand the python implementation first, and twisted is large…
[16:17] <JoseExposito> mmcc, Probably a python auxiliar script that receives some command line arguments and prints the output state in a JSON could be the easier way
[16:20] <JoseExposito> mmcc, thank you so much for the support, I have to go, see you!
[16:21] <mmcc> JoseExposito you're welcome, feel free to ask any more questions over email too. bye!
[16:41] <chaselivingston> mmcc: will the mac app run on 10.5?
[16:41] <mmcc> chaselivingston nope.
[16:41] <chaselivingston> mmcc: ok cool, thanks
[16:42] <mmcc> chaselivingston no problem, that was an easy one :)
[16:42] <chaselivingston> mmcc: yep, you're welcome :)
[16:58] <rye> ralsina_: do you recall andy DeadReferenceError bug report?
[17:05] <dobey> rye: ralsina_ is on holiday
[17:05] <rye> dobey: ah, thanks
[17:06] <dobey> rye: but i don't recall seeing DeadReferenceError in any reports
[17:18] <gatox> mmcc, dobey when you have a moment: https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/x-button/+merge/132729
[17:20] <dobey> why is that bug private+security?
[17:20] <gatox> dobey, i don't know
[17:21] <mmcc> and why do I sometimes get a new CP instance and sometimes not… :(
[17:21] <gatox> mmcc, that is for me?
[17:23] <mmcc> gatox not really. It's about your branch but I don't know how to reproduce it yet so I don't want to bother you. sorry about the moaning
[17:24] <gatox> mmcc, the only reason i can think of why sometimes it's open a new cp....... it's because for some reason the socket process fail..... and because of that the exit is not being executed.... but it should..... that's why the part that send the message via socket is inside a try-except
[17:25] <mmcc> gatox, right. well, there was some strangeness about the args that I noticed yesterday. I thought it was fixed with the try, though. I guess not
[17:25] <gatox> mmcc, about the args?
[17:26] <mmcc> specifically, on darwin there are two extra args appended for the graphicssystem, or there should be, but I don't see them show up if I print the args in the socket message code…
[17:26] <mmcc> so I'm not sure the assumptions about argv are necessarily going to work on darwin… I'm looking into it now
[17:27] <dobey> mmcc: i don't guess the socket message sending code, sends those as messages; but only sends the --switch-to for now
[17:28] <gatox> yes
[17:29] <dobey> mmcc: so if you're printing in the process method, that's all you'll see. if you print argv in _send_messages (before the try) i'd guess you'd see them all
[17:30] <mmcc> yeah, I'm printing in send_messages. I should see everything, but something's wacky
[17:30] <dobey> mmcc: perhaps we're adding them after we're calling send_messages then?
[17:31] <mmcc> dobey they're added on the line before the UniqueApplication instance is created in main/__init__.py
[17:34] <dobey> mmcc: ah; i bet QUniqueApp or whatever it is, pops those args out
[17:35] <gatox> mmcc, yes..... but send_messages is only taking care of what is defined in SOCKET_MESSAGES ..... should that be sent to the already running application?? are they really necessary if the app is already running?
[17:35] <dobey> mmcc: if you print right before _send_messages is called, i suspect they aren't there either
[17:35] <dobey> mmcc: no, it shouldn't be sent to the running app.
[17:36] <gatox> right
[17:38] <mmcc> ok, QApplication does pop the -graphicssystem raster off.
[17:38] <mmcc> so that's explained
[17:39] <mmcc> yeah, it works from source but not from the wrapped .app . trying again with some debug prints, have to wait for build…
[17:47] <mmcc> of course now it works fine
[18:01] <mmcc> yep, can't reproduce. hooray computers
[18:01] <gatox> mmcc, software is a collection of not deterministic code most of the time :P
[18:02] <mmcc> bleh
[18:02] <mmcc> bleh to software that is, you're right of course
[18:07] <dobey> maybe you should consult a doctor about that problem
[18:08] <dobey> irc isn't really the place to discuss your personal issues ;)
[18:09] <mmcc> "I can't reproduce with this computer"
[18:10] <dobey> ugh; we need to move the certs i guess
[18:14] <dobey> now my brain is stuck
[18:20] <mmcc> nope, broke it again…
[18:22] <gatox> briancurtin, u1-cp is working for you from sources in windows?
[18:34] <mmcc_other> gatox: it does for me - what problems are you seeing?
[18:36] <gatox> mmcc, just getting stuck on the overlay when i open it
[18:37] <mmcc> gatox: sounds familiar, check the syncdaemon logs to see if it has an exception. also make sure you've got the most recent trunk, since briancurtin fixed a few things
[18:37] <gatox> mmcc, yap....... i'll do that
[18:38] <dobey> someone filed another bug about that today
[18:38] <dobey> 3.0.2b getting stuck on the getting info for folders tab
[18:49] <mmcc> ok, I'm seeing a situation where the QLocalSocket is getting a connection refused error when connecting to the socket, even though there is a running instance already
[18:52] <dobey> and you get a second instance in that case?
[18:53] <mmcc> yeah, since the connection doesn't happen, it falls through to create its own new server and then runs along happily
[18:53] <mmcc> I can create as many instances as I want once this happens
[18:53] <gatox> mmcc, ahh but is it failing before the send_messages part then?
[18:54] <mmcc> gatox: yes, it's apparently an old bug…
[18:55]  * briancurtin back
[19:11] <mmcc> oh hey that's useful, QLocalServer is now listening on fullServerName=''
[19:12] <mmcc> silly me was expecting a socket filename or something
[19:14] <dobey> does QLocalServer generally work on osx?
[19:14] <mmcc> dobey: maybe not? this is the only time I've really tested it
[19:16] <briancurtin> gatox: yeah, it works for me
[19:16] <briancurtin> (sorry for late response)
[19:16] <mmcc> now it's broken every time. Still not clear what breaks it. maybe it's leaving something timestamped in the filesystem somewhere. ugh.
[19:17] <gatox> briancurtin, yes, it's working now
[19:17] <briancurtin> magic!
[19:18] <gatox> briancurtin, http://youtu.be/x0yQg8kHVcI
[19:18] <briancurtin> hahahhaha
[19:34] <mmcc> so if I actually check the return value for qlocalserver.listen(), I see that it is failing because 'address in use'. So that explains things - one server died without cleaning up, and now the socket is broken for future servers. which means clients will try connecting to it and fail, and go on thinking they're the unique instance, attempt to start a server themselves, ignore that failure, and continue
[19:34] <mmcc> whee
[19:34] <gatox> makes sense.......
[19:40] <gatox> mmmm something is really wrong with the regex and windows paths
[19:41] <dobey> mmcc: eep, that's not good
[19:41] <mmcc> yeah, especially since I'm not sure how to get qt to tell me what socket it's trying to open :) qlocalserver only tells you its name if it's successfully listening
[19:55] <mmcc> well if I start a random server from the console with the name 'wtf', I get a file /var/folders/garbagestring/T/wtf — but there's no similar open file in lsof -U. and no file in /var/folders that 'find' can find named '*ubuntu*'
[19:56] <mmcc> so why does a new QLocalServer still fail?
[20:02] <dobey> magic?
[20:02] <briancurtin> magic!
[20:03] <briancurtin> dobey: i commented on that cert MP...i'm not totally happy with the whole thing myself, could use some guidance on the few questions there
[20:04] <dobey> briancurtin: i'm thinking about how to deal with that; we can't move the cert files in stable-4-0; the stable branches/ubuntu arrangement makes this a bit harder to do 'the right way' everywhere
[20:04] <mmcc> hmm, that's interesting, we're doing something that the Qt docs say we should "be careful to avoid" — calling removeServer without having closed the server
[20:05] <mmcc> of course they don't say *why*
[20:05] <dobey> mmcc: because! that's why!
[20:06] <mmcc> that function deletes the socket file. I think in our case it's harmless, because we only do it on our way out the door and we're not trying to use the running server afterward
[20:06] <briancurtin> dobey: i'm not opposed to doing something in a one-off way for windows. most releases i've done have required something a bit quirky
[20:14] <gatox> ok....... eod here!! see you people!
[20:39] <mmcc> OK, I think my problem with the socket stuff was related to it crashing and leaving the socket file around. I'm going to suggest that we add one line to that branch that should make it more robust. And maybe some error checking and logging
[21:02] <briancurtin> dobey: i think the cert MP is a bit more clean for the time being. using the function from storageprotocol, removed some lint
[21:04] <dobey> briancurtin: cool; like i said on the MP, i think it's fine to ship it as a patch in the windows build to get it done and working with the 4.0.x code, but we need to do a bit more thinking on how best to manage it in runk
[21:05] <briancurtin> dobey: cool, agreed. i'll move forward with the patched installer
[21:06] <dobey> great
[21:06] <briancurtin> dobey: is there supposed to be a stable-4-0 for windows-installer, or should i take that out of trunk?
[21:08] <dobey> briancurtin: no, there isn't one for that, as we were planning to rename it; but we never got around to the rename. i wonder if we should make the stable branches for it
[21:08] <dobey> they will get renamed anyway, so i probably should make them for it as well
[21:09] <dobey> man i love advertisements
[21:10] <dobey> "SAVE 80%" in REALLY BIG font, and then in really really tiny font between the two, it says 'up to'
[21:10] <briancurtin> i'm guessing it's close to your EOD so i'll wait on creating the installer if there's going to be a stable branch for the project
[21:11] <dobey> nah, go ahead and do the release
[21:11] <dobey> or the build at elast
[21:11] <dobey> least
[21:11] <dobey> i can make the stable branches whenever
[21:11] <briancurtin> with the installer out of trunk but the sso/client/etc branches from stable-4-0?
[21:11] <dobey> yeah
[21:12] <briancurtin> ok, cool
[21:20] <dobey> and with that, i'll be off.
[21:20] <dobey> have a good weekend all!
[21:20] <briancurtin> you too
[22:22] <mmcc> wow. I think this thing finally works.
[22:22] <briancurtin> mmcc:  which thing?
[22:24] <mmcc> the whole burrito — the pyobjc menu launched from within the main app, quitting and relaunching CP, remotely switching CP tabs, progress bars
[22:24] <briancurtin> nice
[22:24] <mmcc> no, I forgot a couple todo's
[22:24] <mmcc> but still, progress!
[23:10] <mmcc> ok, will be back later tonight to wrap up