[00:33] <nhaines> karni: ooh, is this an official U1 Android client?  :)
[00:35] <karni> nhaines: that's correct :)
[01:44] <nhaines> karni: yay!  Did I mention I have  T-Mobile G2 and love testing?  ;)
[01:46] <karni> nhaines: I don't recall but I'm happy to know. I'm digging it right now so I'll ping you once it's done, how about that?
[01:54] <nhaines> karni: that's because I didn't mention it.  But sure, I'd love to try it out.
[01:54] <karni> nhaines: I was kidding ;) I'm happy you have an Android phone!
[01:55] <nhaines> karni: I'd still be using my Nexus One if I didn't need a keyboard for ConnectBot and screen/irssi.  ;)
[01:56] <karni> nhaines: hah, I have HTC Hero and I'm using Irssi ConnectBot as well ;) touchscreen doesn't scare me. I do make quite a few typos, though.
[01:57] <nhaines> I used my Nexus One for a weekend after Gingerbread came out.  It was beautiful until I had to type something; then I wanted to punch a kitten.
[01:57] <karni> :D
[01:57]  * CardinalFang hugs Nexus One and Swype.
[01:58] <nhaines> CardinalFang: annoyingly, I didn't think to install it until that next Tuesday.  :)
[04:45] <karni> Why is there list_shares_retries and list_volumes_retries if volumes are the same thing as shares??
[04:56] <karni> I get it. root and udfs are volumes. shares are shares.
[05:04] <karni> I ran out of mineral water. Not good.
[05:17] <karni> verterok: Root and Udf classes are listed under ListVolumes, while VolumeManager retrieves the root volume from self.shares - I'm lost.
[08:31] <karni> noo not now.. maintanace :< ?
[08:32] <karni> phew.
[08:34] <karni> Ok, time to get 1h sleep.
[09:47] <JamesTait> Buenos días a todos!
[10:55] <verterok> karni: the root is in self.shares just for storical reasons...now all the volumes are retrieved from the server using listVolumes
[10:57] <verterok> karni: VolumeManager keeps the local volumes metadata, which is done in: self.shares and self.udfs
[10:57] <verterok> karni: but Root, Udf and Share volumes metdata is retrieved using ListVolumes
[12:39] <ralsina> good morning everyone!
[12:39] <duanedesign> morning all
[13:07] <alecu> hello all!
[13:07] <duanedesign> rye: have you made anything in python using the libsyncdaemon api?
[13:07] <duanedesign> hello alecu
[13:07] <rye> duanedesign, well, it is a bit hard to do
[13:08] <rye> duanedesign, bug #620735
[13:08] <ubot4`> Launchpad bug 620735 in ubuntuone-client "connect method of SyncdaemonDaemon object conflicts with connect from GObject (affects: 2) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/620735
[13:08] <rye> ah, connect_after()
[13:08] <rye> hmm
[13:58] <ralsina> standup in 3'
[14:01] <alecu> me
[14:01] <ralsina> me
[14:02] <thisfred> me
[14:03] <dobey> me
[14:03] <ralsina> alecu, please
[14:04] <mandel> me
[14:04] <alecu> DONE: a sample application that uses DroidCouch to get the tomboy notes from Ubuntu One servers (bug #725293), Docstrings for all exposed methods in DroidCouch, both Ubuntu One related and CouchDB related (bug #729096)
[14:04] <alecu> TODO: sort u1-unity, u1cp and zeitgeist bugs, work on them
[14:04] <alecu> BLOCKED: no thanks
[14:04] <ubot4`> Launchpad bug 725293 in droidcouch "Sample application that uses DroidCouch (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/725293
[14:04] <alecu> NEXT: ralsina
[14:04] <ubot4`> Launchpad bug 729096 in droidcouch "Documentation on how to use DroidCouch (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/729096
[14:05] <ralsina> DONE: holiday x 2
[14:05] <ralsina> TODO: organize a quality push, triage bugs
[14:05] <ralsina> BLOCKED: not yet
[14:06] <ralsina> thisfred?
[14:06] <thisfred> * DONE commented on bug #720155
[14:06] <thisfred> * DONE reviewed https://code.launchpad.net/~sil/ubuntuone-couch/add-headers/+merge/52676
[14:06] <thisfred> * NEEDSREVIEW bug #729055 https://code.launchpad.net/~thisfred/ubuntuone-client/filenames-in-notifications/+merge/52483
[14:06] <thisfred> * INPROGRESS bug #702172 https://code.launchpad.net/~thisfred/ubuntuone-client/quota-notifications
[14:06] <thisfred> * INPROGRESS bug #728722 https://code.launchpad.net/~thisfred/ubuntuone-control-panel/dbusify
[14:06] <ubot4`> thisfred: Bug 720155 on http://launchpad.net/bugs/720155 is private
[14:06] <thisfred> * TODO bug #702007
[14:06] <thisfred> * TODO bug #730661
[14:06] <ubot4`> Launchpad bug 729055 in ubuntuone-client (Ubuntu Natty) (and 2 other projects) "File names should be shown on notifications (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/729055
[14:06] <thisfred> * TODO bug #731023
[14:06] <ubot4`> Launchpad bug 702172 in ubuntuone-client (Ubuntu Natty) (and 2 other projects) "Syncdaemon needs to send a notification when a folder shared to the user exceeds the owning user's quota (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/702172
[14:06] <ralsina> my internet is cominf and going, sorry about delays
[14:06] <thisfred> * TODO bug #730929
[14:06] <thisfred> NEXT: dobey
[14:07] <dobey> λ DONE: branched libu1, start on updating libu1 for new webkit
[14:07] <dobey> λ TODO: releases, new webkit api in libu1, bug #727558, mp3 install in banshee
[14:07] <ubot4`> Launchpad bug 728722 in ubuntuone-control-panel (Ubuntu Natty) (and 5 other projects) "control panel should have a .service file so it can be opened through dbus (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/728722
[14:07] <ubot4`> Launchpad bug 702007 in desktopcouch (Ubuntu Natty) (and 2 other projects) "get_all_records does not return records with their attachments (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/702007
[14:07] <ubot4`> Launchpad bug 730661 in ubuntuone-client "progress bar does not show up in Unity or something (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/730661
[14:07] <dobey> λ BLCK: None.
[14:07] <ubot4`> Launchpad bug 731023 in libunity (Ubuntu) "ubuntuone-syncdaemon crashed with ImportError in get_interfaces_for_object(): No module named Dee (affects: 121) (dups: 45) (heat: 544)" [Critical,Fix released] https://launchpad.net/bugs/731023
[14:07] <ubot4`> Launchpad bug 730929 in dee (Ubuntu) (and 1 other project) "ubuntuone-syncdaemon crashed with SIGSEGV in g_typelib_get_dir_entry_by_gtype() (affects: 1) (heat: 6)" [Critical,Fix released] https://launchpad.net/bugs/730929
[14:07] <ubot4`> Launchpad bug 727558 in libubuntuone (Ubuntu Natty) (and 3 other projects) "Need to notify user when Purchased Music folder is not subscribed (affects: 2) (dups: 1) (heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/727558
[14:07] <mandel> DONE: bug triagging for windows. Code review for thisfred. Worked on qt UI for ubuntu_sso.
[14:07] <mandel> TODO: Work on UI for ubuntu_sso. Automated tests for UI. Write py2exe/pyinstaller for ubuntu_sso on windows. installer POC.
[14:07] <mandel> BLOCKED: no, but reviews on windows/linux for the sso stuff are welcome. (alecu/ralsina)
[14:07] <mandel> HATE: lint + twisted
[14:07] <ralsina> ok, comments
[14:08] <mandel> ralsina: I would not mind chatting with you an how we will approach the UI on ubuntu_sso
[14:08] <dobey> λ DONE: branched libu1, start on updating libu1 for new webkit
[14:08] <dobey> λ TODO: releases, new webkit api in libu1, bug #727558, mp3 install in banshee
[14:08] <ralsina> mandel: let's mumble in 5'?
[14:08] <ubot4`> Launchpad bug 727558 in libubuntuone (Ubuntu Natty) (and 3 other projects) "Need to notify user when Purchased Music folder is not subscribed (affects: 2) (dups: 1) (heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/727558
[14:08] <dobey> λ BLCK: None.
[14:08] <dobey> oh
[14:08] <dobey> doh
[14:08] <mandel> dobey: did you do it twice :)
[14:08] <dobey> yes
[14:09] <mandel> hehe
[14:09] <ralsina> I want a new release as soon as that unity thing works again, is that ok? Any branches that SHOULD merge ?
[14:09] <mandel> ralsina: ping me whenever you can
[14:09] <ralsina> Then I want to invite all of canonical to try it. Of course I want to try it myself first to see how broken we are ;-)
[14:10] <thisfred> ralsina: I 'd like my ^^ branch to be merged, need 1 more review
[14:10] <thisfred> it's not a must have
[14:10]  * alecu is updating 320mb worth of packages.
[14:10] <ralsina> And from here forward, we are mostly in bug fixing mode, except for dobey on the banshee stuff which is a separate thing.
[14:10] <thisfred> but a very nice to have
[14:10] <ralsina> thisfred: the names in notifications? I'll review it.
[14:11] <thisfred> yep
[14:11] <alecu> thisfred, on it too
[14:12] <thisfred> alecu: no need I have a +1 already
[14:12] <thisfred> although, I'd like your feedback
[14:12] <thisfred> so go ahead :)
[14:13] <ralsina> ok, alecu, you do it ;-)
[14:13] <ralsina> eom?
[14:14] <alecu> thisfred, we should build up the list of u1-unity strings for christian to review.
[14:14] <thisfred> alecu: yes, I think they're all there now
[14:14] <dobey> ralsina: there are a couple things that must merge before a release, yes
[14:15] <ralsina> O sea, creas un QPixmap (o un QImage? no me acuerdo), un QPainter que dibuje en el QImage, y haces widget.render(painter). Despues QPixmap.toImage().save()
[14:15] <dobey> one i guess i have to make
[14:15] <ralsina> ouch, wrong channel
[14:15] <ralsina> dobey: cool, there's no rush, today or tomorrow is the same to me.
[14:15] <alecu> thisfred, it should include not only the strings shown on notifications, but also the string shown when trying to log out when SD is running... and perhaps the strings on the messaging menu, if any.
[14:16] <alecu> thisfred, right, we should do it after this  branch lands.
[14:16] <thisfred> alecu: yep, basically, if we've done it right, we can search for everything that's i18n-ed :)
[14:17]  * alecu hates losing his wm decorations.
[14:17] <dobey> ralsina: and the unity issue should be 'fixed' now i think. though you will have to test with the nightlies for the moment
[14:18] <ralsina> dobey: 'fixed' as in 'no unity integration' ?
[14:18] <alecu> dobey, ralsina: what's the status of the problem with the Dee dependency?
[14:18] <ralsina> alecu: that's what we are discussing :-)
[14:18] <dobey> ralsina: fixed as in kenvandine fixed 2 issues with the libdee/libunity packages yesterday
[14:19] <ralsina> dobey: oh, much better
[14:19] <alecu> nice.
[14:19] <ralsina> so I need to update unity to unbreak u1?
[14:19] <dobey> ralsina: current 11.04 packages are "no unity integration" though since i pushed an update to prevent it
[14:19] <dobey> ralsina: but if one is running nightlies it *should* work again
[14:19]  * ralsina goes to update then
[14:19] <dobey> yes you need to install the latest updates and it should unbreak
[14:21] <ralsina> One administrivia thing that affects all of you: I will be taking the performance review training on friday because, yes, performance reviews are coming. Just so you know.
[14:23] <dpm> hey all, I'm getting ubuntuone-syncdaemon taking 100% cpu on natty. Any tips on debugging this or on how I can just stop it? Thanks
[14:24] <dobey> dpm: apt-get update && apt-get upgrade
[14:24] <dpm> dobey, I did it like half an hour ago. Was that a known bug and has that just been fixed?
[14:24] <dobey> really? what version of ubuntuone-client do you have installed?
[14:25] <dpm> dobey, 1.5.5-0ubuntu2
[14:25] <dpm> ah, it comes up as an update now
[14:26] <dobey> :)
[14:26] <dpm> let me upgrade then, thanks dobey, that was an easy one :-)
[14:26] <dpm> I'll pick a harder issue nex time
[14:27] <ralsina> mandel: ping
[14:27] <mandel> ralsina: pong
[14:28] <mandel> ralsina: mumble?
[14:28] <alecu> dpm, you are organizing the ubuntu developer week, right?
[14:28] <ralsina> mandel: mumble!
[14:28]  * mandel starts mumble
[14:28] <ralsina> mandel: desktop+ mano a manouh
[14:29] <dpm> alecu, yeah (AppDeveloperWeek), you up for a session? :-)
[14:30] <alecu> dpm, yes, I was thinking on making an improved version of the DBus talk of last AppDevWeek.
[14:30] <alecu> dpm, I guess I should just write it down on the wiki...
[14:31] <dpm> alecu, awesome - sure, pick up a slot at https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable
[14:39] <alecu> dpm, I've added my session... thanks for organizing this :-)
[14:40] <dpm> alecu, cool, thank you!
[14:41] <dpm> Anyone else from the Ubuntu One team is up for a session? Or any ideas on topics related to U1 interesting for app developers?
[14:43] <beuno> *cough*aquarius *cough*
[14:44] <dobey> i have an appt to go to. be back soon
[14:51] <aquarius> dpm, yeah, yeah, I just haven't got around to replying to your email yet. Pencil me in :)
[14:52] <dpm> aquarius, \o/, thanks. Any preferences for time/day? What cool thing would you like to talk about?
[14:54] <aquarius> dpm, Monday 18.00: make your applications work in the cloud with Ubuntu One
[14:58] <dpm> aquarius, cool, added, thanks! -> https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable
[15:03] <alecu> thisfred, ping
[15:03] <thisfred> alecu: pong
[15:03] <alecu> thisfred, I'm reviewing your branch: I like it a lot, but I have a small observation
[15:04] <thisfred> give it to me straight, doc
[15:04] <alecu> thisfred, I don't like the self.uploading_filename being set side effect.
[15:05] <thisfred> alecu: yeah, me either, but I couldn't immediately figure out a better way
[15:05] <alecu> thisfred, that is: it is set in the first function, and used in the second and third.
[15:05] <thisfred> since the queue may not have the filename anymore by the time we complete,
[15:05] <thisfred> unless I read that wrong
[15:05] <alecu> thisfred, perhaps that should go in a different function, and we would call it from the first, second and third.
[15:05] <alecu> oh, right.
[15:05] <alecu> I see.
[15:06] <alecu> thisfred, that makes sense.
[15:06] <thisfred> so we need to keep it around somehow, but there may be a less ugly way
[15:06] <thisfred> I have not thought of it yet
[15:07] <alecu> thisfred, I was worrying about the case of files being uploaded at the start while building the discovery_message
[15:07] <alecu> thisfred, then new files show for download, but the discovery_message is not shown.,
[15:08] <alecu> thisfred, then they would not appear on the progress nor final messages. Or something like that.
[15:08] <thisfred> I'm not sure I understand, but yeah the order things happen in is not always 100% clear. I'll have a look at whether I can make it more robust. If I can't do it quickly, I'll file a bug.
[15:09] <alecu> thisfred, great.
[15:11] <thisfred> alecu: my assumption was, that discovery will always happen for new uploads/downloads, but that is not the case?
[15:12] <thisfred> alecu: so the problem is, discovery shows, then new files come in, but because of throttling, we don't show the message?
[15:13] <thisfred> but the final message will have an updated count in that case though, right? And the progress bar would be updated in that the total would go up too?
[15:13] <alecu> thisfred, after the initial discovery, there are 10 seconds where the bubble is updated if new files are found, but after this there are 5 full minutes of not popping up the bubble again, even if new files show up.
[15:14] <thisfred> right, but that's the choice we made, I don't think that's a problem
[15:14] <thisfred> as long as the message at the end is accurate
[15:14] <thisfred> which it will be if the numbers are correct.
[15:15] <alecu> thisfred, right. But if only uploads happened during the first 10 seconds, then a download happens during the 5 minutes wait, that means that the string is still ""
[15:15] <thisfred> whether it says 'foo' and 11 other files were uploaded, or 'bar' and 11 other files...
[15:15] <alecu> thisfred, so the progress and final will say 'foo' and 11 other files were uploaded, and '' was downloaded
[15:16] <thisfred> alecu: ah, so the get_discovery_message is not called at all, rather than called but not displayed?
[15:16] <alecu> thisfred, I think it's not called.
[15:16] <thisfred> so I need a lower level event to do this
[15:16] <alecu> thisfred, that's what I don't like about the side effect
[15:16] <thisfred> right
[15:16] <alecu> thisfred, hold a sec.
[15:17] <alecu> thisfred, I believe the queue is emptied *after* the final message is shown
[15:17] <thisfred> oh, so I can just look at the queue after all?
[15:17] <thisfred> that would be great
[15:18] <alecu> thisfred, yes, queue_done shows the bubble and after that it resets the list of uploaded/downloaded files.
[15:18] <thisfred> awesome, that should be an easy fix
[15:19] <alecu> thisfred, so I guess you should be able to move those bits to a new method, and call them from the three string building methods.
[15:21] <thisfred> alecu: yeah. Looks like the tests don't have stuff in the queue though, but that may be because they're not faking well enough
[15:24] <thisfred> yeah, we just fake the numbers, and not the queue, looks like
[15:24] <alecu> thisfred, yes, very likely :-)
[15:31] <thisfred> alecu: hmm, it looks like the tests are talking to the real aggregator... :(
[15:32] <thisfred> alecu: I've noticed this happening before when anything goes wrong. Looks like the HundredFeetTestCase pollutes other tests, or at least that's what it looks like to me
[15:34] <thisfred> hmm, wait these tests are for the real aggregator, nm
[15:36] <karni> I'm back. God I hate shopping.
[15:36]  * alecu breathes back
[15:36] <thisfred> alecu: I don't think that the files are left in the queue until the end
[15:36] <karni> verterok: thanks for explanation. so Root is treated as a share, isn't it?
[15:37] <thisfred>     def handle_SYS_QUEUE_REMOVED(self, command):
[15:37] <thisfred>         """A command has been removed from the queue."""
[15:37] <thisfred>         if isinstance(command, action_queue.Download):
[15:37] <thisfred>             self.status_frontend.download_finished(command)
[15:37] <thisfred>         elif isinstance(command, action_queue.Upload):
[15:37] <thisfred>             self.status_frontend.upload_finished(command)
[15:37] <thisfred>         else:
[15:37] <thisfred>             self.status_frontend.queue_removed(command)
[15:37] <verterok> karni: only for the place to store the metadata
[15:37] <verterok> karni: the Root for syncdaemon is a "special" volume
[15:37] <alecu> thisfred, you are right: "self.files_uploading.remove" in upload_finished.
[15:37] <karni> verterok: I see
[15:37] <alecu> thisfred, sorry for the mixup :-(
[15:38] <verterok> karni: in the old days, there was no such concept (volumes), we only had shares + root
[15:38] <thisfred> alecu: np, I should look at where the totals are being updated, and keep state there as well, I think, that's the safest
[15:38] <verterok> karni: so, the root was stored in the same "place" (metadata  storage) as the shares
[15:38] <karni> verterok: I kinda get lost, because once we talked and I thought in the end shares are treated as volumes currently
[15:38] <karni> verterok: aha
[15:39] <verterok> karni: right, now we have volumes, and everything is a volume (root, shares and udfs)
[15:39] <karni> verterok: ack
[15:40] <verterok> karni: but the storage of the metadata is legacy stuff :p
[15:41] <karni> verterok: it's quite challenging to read sources that once were totally new to me, and yet be able to differ what is 'fresh' and what is 'legacy' ;) that's why I can't wait to meet you all in person and listen-on all the interesting discussions you may have
[15:41] <verterok> karni: :)
[15:42] <verterok> karni: think of this as an implementation detail of VolumeManager ;)
[15:42] <karni> verterok: ok :)
[15:42] <alecu> karni, it took me six months after joining canonical to meet all the non-argentinian people in the u1 team :-)
[15:42] <verterok> karni: VM, expose a get_volume(<id>) method
[15:42] <thisfred> alecu: r914 pushed
[15:42] <alecu> karni, hopefully it will be much faster for you :-)
[15:42] <alecu> thisfred, cool, re-re
[15:42] <karni> alecu: :O :)
[15:43] <verterok> karni: what is doing to actually get the volume metadata depends on the implementation :)
[15:43] <dobey> hmm
[15:43] <karni> verterok: right. for instance, I have the sqlite3 database.
[15:43] <verterok> karni: in the case of syncdaemon, it check if the ID in the "self.shares" or "self.udfs" storage
[15:44] <verterok> karni: right, you can put the root, shares and UDF in a single table :)
[15:44] <karni> verterok: mdid is metadata id -- it is just unique meta identifier, isn't it?
[15:44] <karni> verterok: I'm doing just that
[15:44] <verterok> karni: yes, for filesystem manager metadata nodes
[15:45] <karni> verterok: in the end, I think it'll take me still quite some time to have a nice, complete implementation of what u1 SD already contains on the desktop
[15:46] <karni> verterok: so the biggest challenge was to "try to be smart" and implement it the easiest way possible :)
[15:46] <karni> I've gotta use one more thread, as it seems I'm running part of sync commands on the UI thread, which is not good at all.
[15:47] <alecu> thisfred, StatusAggregator.__init__ already calls self.reset(), so I don't understand why it should do the same things as reset does.
[15:50] <alecu> thisfred, btw: I think that moving the initialization to download_started looks much better.
[15:51] <thisfred> alecu: ah, yeah, should have removed the reset, maybe
[15:51] <alecu> thisfred, why removing the reset? It's already done there, and it should be done as the first thing in the constructor.
[15:52] <thisfred> alecu: defining properties outside the __init__ is a bad idea in general, but yeah, since the reset is called, it's fine
[15:52] <thisfred> changing back
[15:53] <alecu> thisfred, yeah "defining properties outside the __init__ is a bad idea" sounds right.
[15:54] <alecu> thisfred, I agree with that, so do it as you prefer.
[15:56] <thisfred> alecu: well, in this case it's done inside the init, but by calling a method that is later reused, so I think we shouldn't make the code worse to satisfy pylint/pep8 because they're too dumb to see that
[15:56] <thisfred> alecu: r915 pushed
[15:56] <dobey> ralsina: so the unity stuff is working for you in nightlies then?
[15:56] <ralsina> dobey: havent finished updating yet
[15:56] <dobey> oh
[15:56] <ralsina> dobey: 5 days of updates are a lot of updates :-(
[15:57] <ralsina> and my internet is having a bad hair day
[16:00] <ralsina> dobey, I'm 120 of 350MB done. So it's going to take 1 or 2 more hours at this rate. I'll go eat.
[16:03] <dobey> ow
[16:03] <ralsina> I usually get about 300KBps, but it's now at 40 :-(
[16:04] <alecu> I updated after the standup. Now I see that there's a new gir1.2-dee-0.5 and gir1.2-unity-3.0
[16:04] <alecu> strange: I'm getting ~30kb as well :-(
[16:05] <dobey> ralsina: nromally i get 3000KB/s, but last night I was getting about 200, when updating my laptop :(
[16:05] <dobey> alecu: and you are running nightlies right?
[16:06] <alecu> dobey, right
[16:06] <alecu> we should all move to south korea.
[16:06] <ralsina> dobey: this internet thing is dying, probably. We'll all be back to faxes and UUCP in no time.
[16:07] <dobey> ralsina: i can convert the .debs to text documents full of 1s and 0s if you want, and you can scan it in page by page after i send you<PHONE_NUMBER>64 pigeons with notes attached
[16:08] <ralsina> dobey: well, if you can mail it via fedex overnight it's the same speed I am getting, as long as you use a 8GB usb thingie.
[16:08] <alecu> dobey, make sure to send one checksum bit pigeon.
[16:09] <dobey> alecu: the checksum bit is a sparrow
[16:10] <ralsina> sparrow for 1s, seagulls for 0s
[16:10] <alecu> dobey, ah, un gorrión!
[16:11] <dobey> "What is the air speed velocity of an unladen swallow?" "What do you mean, African or European swallow?"
[16:11] <ralsina> good thing mandel is at lunch, or he would have a picnic with that one
[16:13] <mandel> african would be faster on feet while the european is a faster swimmer
[16:14] <ralsina> mandel: I was expecting more of a pornographic/racist joke, so good thing you went in that direction :-)
[16:14] <mandel> ralsina: is racist, but you din't get it ;)
[16:14] <ralsina> ohhhhhhh ok ;-)
[16:15] <mandel> ralsina: I'm sure dobey gets  it :P
[16:15] <ralsina> olympic sports joke?
[16:15] <mandel> yes
[16:16] <dobey> haha
[16:16] <ralsina> ok then, I'll just go eat.
[16:16] <dobey> well not entirely racist
[16:16] <dobey> but i got it :)
[16:24] <mandel> dobey: is enough for a public channel :)
[16:34] <dobey> alright i need to get some lunch. bbiab
[16:37] <mandel> alecu: ping
[16:44] <alecu> mandel, pong
[16:45] <mandel> alecu: just a funny failure in one of the tests of ubuntu_sso: /dev/null is nu on windows
[16:45] <mandel> god I hate windows….
[16:45] <karni> mandel: haha
[16:46] <mandel> is nul, not nu but same thing :P
[16:50] <alecu> mandel, don't know who included /dev/null in a test, but we should put his/her head in a wrench next time :-)
[16:55] <alecu> mandel, also: addinfourl asused in that bit of code is not documented nor public.
[16:57] <mandel> alecu: I dot think it was a big deal, but when I saw the test fail I was WTF? is my vm network broken
[16:57] <mandel> then I saw the code an easily fixed it :)
[16:57] <thisfred> alecu: did you get a change to rererereview?
[17:01] <CardinalFang> mandel,  os.path.devnull ?
[17:01] <mandel> CardinalFang: ah, nice I had no idea that existed :)
[17:10] <rye> ok, i have an undelete script now
[17:10] <rye> YAY!
[17:10] <rye> well, for couchdb
[17:26] <karni> rye: sounds cool, what can you undelete?
[17:28] <rye> karni, earlier desktopcouch library used a deleted: True flag in the document itself to mark it as removed, undeleting the document should have been trivial if couchdb library in maverick was working seamlessly with oauth and notes supported temporary views - there's now a bug for the latter).
[17:28] <rye> karni, if you remove your note online then you can undelete it
[17:29] <karni> rye: oh, nice :)
[17:35] <karni> verterok: oh! by the way, so what's it all about with the String name and String path arguments to CreateUDF request?
[17:35] <karni> verterok: When I run the request, it created a ~/name/path UDF - why not just ~/path ?
[17:36] <karni> *ran
[17:45] <verterok> karni: Gimme 15' finishing lunch :)
[17:45] <karni> verterok: of course! :)
[17:46] <karni> I see I'm not the only one lurking on the channel while eating lunch.
[17:49] <karni> JamesTait: I like that Dashboard/Files/Notes bar more than the tabs we had before, congrats to you and the design team
[17:50] <JamesTait> karni: I can take no credit whatsoever for that, but thanks - I'll pass on the comments. :)
[17:50] <karni> JamesTait: :)
[17:51] <thisfred> alecu: I'm struggling a bit with DBus/u1-control panel. I assume you're lunching now, but I would like to ask some n00b questions when you're back, seen as how you teach DBus ;)
[17:52] <alecu> thisfred, :-)
[17:52] <alecu> thisfred, tell me
[17:52] <JamesTait> karni: ivanka and her team are responsible for that. :)
[17:52] <alecu> thisfred, will re-review in the meantime
[17:53] <thisfred> alecu: right, it's about bug #728722
[17:53] <ubot4`> Launchpad bug 728722 in ubuntuone-control-panel (Ubuntu Natty) (and 5 other projects) "control panel should have a .service file so it can be opened through dbus (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/728722
[17:53] <karni> ivanka: Nice job on the redesigned webpage!
[17:54] <thisfred> alecu: the parts that make it a little bit tricky, are 1) the backend has a dbus interface already, so do I reuse that for the gui, or make a new service (new service I'm pretty sure)
[17:55] <alecu> thisfred, looking
[17:55] <thisfred> 2) The new service is used to start the gui, and not much else (well, maybe bounce the launcher separately) for that, which parts of dbus do I/don't I need
[17:55] <karni> verterok: when you're back, 1st question was about UDF name/path, 2nd question: what is listShares for and how it relates to listVolumes?
[17:55] <ivanka> karni: thank you - I will pass on your congratulations to the team!
[17:55] <karni> ivanka: please do! :)
[17:56] <thisfred> 3) if I add a new foo.service.in, I assume I will need to look at the packaging branch to make sure that that is built, or is there autodiscovery?
[17:58] <verterok> karni: 1) the path is just "the path *to* the UDF" and the name is the name of the UDF, so the "path of the udf is: path + name
[17:58] <alecu> thisfred, 1) it's tricky, because the current dbus service runs on the control-panel-backend, but you really want to open the gui instead
[17:59] <verterok> karni: syncdaemon creates all the udfs using a kind of "special" path, "~" + <extra path elements>
[17:59] <karni> verterok: could you provide a dead simple example so I won't mix up names/paths/names ?
[17:59] <karni> verterok: uhum
[17:59] <karni> oh oh I see.
[18:00] <verterok> karni: so, syncdaemon will use those "special" paths as the "home" of the user
[18:00] <verterok> karni: so, if you create a UDF in $HOME/Documents/Foo (using syncdaemon/nautilus/u1sdtool)
[18:00] <verterok> karni: you will end up with a protocol message like this: CreateUDF(path="~/Documents", name="Foo")
[18:01] <karni> verterok: I see. how about a UDF in $HOME/Baz ? what is the path? null or empty string?
[18:01] <alecu> thisfred, 2) probably a dbus method call from sd into the ui. If the ui is not running, dbus activation should start it automatically. But let's double check because a dbus signal from the sd perhaps is more convenient.
[18:02] <karni> verterok: errr.. is it "~/" in such case?
[18:02] <verterok> karni: nope, message would be: CreateUDF(path="~/", name="Baz") (or just "~")
[18:02] <karni> perfec
[18:02] <karni> *t ;)
[18:02] <verterok> I don't remember exactly
[18:02] <thisfred> alecu: I think a dbus signal from sd makes it easier for instance to not start the control panel twice, which is currently the case
[18:02] <verterok> karni: are we good with 1)?
[18:02] <karni> verterok: ok, but I understand the point :) yes, thanks!
[18:03] <alecu> thisfred, regarding 3) I've no idea about the way our .services are built, nor about packaging branches. I'm sure dobey knows a lot about that.
[18:03] <dobey> que?
[18:04] <verterok> karni: regarding 2), listShares return a list of the shares you created/shared to someone and the shares offered to you (but not accepted yet), you should ignore the later as it's only for shares created using the protocol which no one uses
[18:04] <alecu> thisfred, the problem with dbus signals is that they don't do activation (I think), so the gui or backend should be running to listen for that signals beforehand.
[18:04] <thisfred> dobey: ohai: If I add a new .service.in to u1-control-panel
[18:04] <verterok> karni: the shares offered via the webui, are not listed there, because they aren't "shares", they are "share offers"
[18:04] <thisfred> dobey: will that be autodiscovered by the packaging branch, or do I need to modify that too?
[18:04] <dobey> thisfred: do it the same way ubuntu-sso-client does it
[18:05] <karni> verterok: and they're fetched via REST I imagine
[18:05] <dobey> and no, the packaging won't get it automatically, we'll have to update it
[18:05] <verterok> karni: what?
[18:05] <thisfred> dobey: ok thx
[18:05]  * thisfred looks at sso-client
[18:05] <verterok> karni: no, a share offer is just a link, syncdaemon knows nothing about share offers created via the web
[18:05] <karni> verterok: how to retrieve the list share offers? http oaht-signed reques...
[18:05] <karni> oh
[18:06] <karni> verterok: so I can't list them in my app and give possibility to accept them, can I?
[18:06] <alecu> thisfred, yes, dobey advice is sound. SD already uses the sso-client thru dbus to get at the credentials.
[18:06] <verterok> karni: you can create a share via the protocol, but you need to know the username
[18:06] <verterok> karni: no, you can't...at least not right now
[18:06] <verterok> karni: so, that's why these "shares via the protocol" are kind-of deprecated
[18:06] <karni> verterok: ok. well.. that kinda makes my life easier ;d but I think we'll want that in the future :)
[18:06] <karni> verterok: ack
[18:07] <karni> verterok: then were' good with 2) as well. thank you!
[18:07] <verterok> karni: np
[18:09] <thisfred> alecu: but if we can't *start* a service through dbus, the bug is probably invalid?
[18:09] <alecu> thisfred, wait
[18:10] <alecu> thisfred, we can't start a service to listen on a dbus signal, but we can surely start a service to reply to a dbus method.
[18:10] <alecu> thisfred, that's what dbus activation does.
[18:10] <karni> aquarius: beuno: one question (not relating to today, but nvm that) -- AFAIR we talked about implementing the new login/registration API. will we drop the browser-dance? is it because the app will be now official and ppl don't have to worry about providing their credentials to the app itself? (as AndroidU1 was 3rd party)
[18:10] <thisfred> alecu: I don't know the terminology well enough to parse that sentence
[18:11] <alecu> thisfred, right, sorry :-)
[18:11] <beuno> karni, well, implementing the SSO API means we can auth from within the app, yes
[18:11] <beuno> is is not a priority, though
[18:11] <karni> beuno: right. so we're fine with that, now that it'll be official app. okey.
[18:12] <alecu> thisfred, since you're going to be working with that dbus code, you better start here: http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html
[18:12] <karni> beuno: sure, sync is the most imporant core the users will expect to work. btw I moved almost all of it to the ActionQueue since yesterday, one command left. looks promising.
[18:13] <alecu> thisfred, also, make sure you install d-feet and play with it for a while.
[18:14] <beuno> karni, \o/
[18:14] <thisfred> alecu: thx!
[18:14] <karni> beuno: this is kind of an experiment, as the whole sync logic is 3k+ lines and not that obvious to port (involves VolumeManager, FileSystemManager, etc), but this will certainly be 1) much cleaner 2) more robust 3) more uniform (like the rest of commands)
[18:14] <karni> oh, and obviously 4) smaller and faster to implement.
[18:15] <alecu> thisfred, things to keep in mind while reading the tutorial: DBus is not used only by python, so data types are usually very strict
[18:15] <thisfred> right
[18:15] <beuno> karni, right, I understand it's not straightforward at all
[18:18] <alecu> thisfred, also: sync calls in dbus usually end up in some evil bugs because of incompatibilities with other libs, that's why we always end up adding the reply_handler and error_handler to make all dbus method calls async.
[18:19] <thisfred> right
[18:22] <dobey> well your dbus api should generally support both
[18:24] <thisfred> dobey: alecu: so we need to start a dbus service which we can then call to start the gui or return it if it's already open?
[18:24] <thisfred> and then what starts the service?
[18:25] <dobey> no
[18:25] <alecu> thisfred, I believe we should make the control panel gui a dbus service too
[18:25] <dobey> i am not even clear on what you're doing exactly, beyond adding a service
[18:25] <alecu> thisfred, so we call a method in that dbus service when we need to open the control panel to a given tab
[18:26] <thisfred> dobey: bug #728722
[18:26] <alecu> thisfred, and if it's not running, dbus activation will do it.
[18:26] <ubot4`> Launchpad bug 728722 in ubuntuone-control-panel (Ubuntu Natty) (and 5 other projects) "control panel should have a .service file so it can be opened through dbus (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/728722
[18:26] <alecu> I mean...
[18:26] <alecu> thisfred, and if it's not running, dbus activation will start it.
[18:26] <dobey> ok
[18:26] <thisfred> alecu: ah ok, so nothing needs to be running
[18:26] <alecu> thisfred, just syncdaemon.
[18:26] <dobey> so not entirely clear still but eh :)
[18:27] <alecu> thisfred, anyway: this all looks like a lot of work just so we don't use os.system...
[18:27] <alecu> thisfred, why don't we keep using os.system, or whatever we are using right now?
[18:27] <thisfred> alecu: true, but it will solve the problem that multiple control panels are opened as well
[18:28] <alecu> ok.
[18:29] <thisfred> and it allows us to bounce the launcher and switch tabs more elegantly
[18:29] <thisfred> I hope :)
[18:29] <alecu> thisfred, right :-)
[18:29] <dobey> actually
[18:30] <dobey> thisfred: doesn't the control-panel-backend thing provide a dbus service already?
[18:30] <thisfred> dobey, it does
[18:30] <thisfred> dobey: so one of my questions was, can I (ab)use that
[18:30] <dobey> thisfred: then you probably just need to add API to that, and hook it up to the UI instead
[18:30] <dobey> so that every different toolkit UI doesn't have to reimplement the same dbus service to switch tabs and whatnot
[18:31] <dobey> which reduces the change set to only having the one "hard" problem of deciding which front-end to open, and how to open it
[18:31] <dobey> which may require a simpler dbus activation thing in the front-ends, but not the entire API
[18:32] <thisfred> dobey: so you're saying, add all of the API to the current service, including an API call to open the gui?
[18:32] <thisfred> or everything except that
[18:33] <alecu> thisfred, I think we should: 1) add a new dbus service to the control-panel UI. (the UI is only a dbus client right now). 2) add a new dbus interface. 3) add a "open_tab(tabname, bring_to_front, bounce_icon)" method to that interface. 4) set the .service file to map the dbus name to our executable. 5) call the method from sd. 6) profit.
[18:33] <alecu> I don't believe this should be part of the control panel dbus backend.
[18:34] <alecu> hmm
[18:35] <dobey> thisfred: i think including that
[18:35] <thisfred> dobey: won't this cause an unfotunate dependency graph?
[18:36] <thisfred> right now I assume the GUI depends on the backend, but the other way around
[18:36] <thisfred> but not
[18:36] <alecu> let's scratch the "open_tab" method. Instead we should have methods with the names of the conditions that need to open the tab, and have the control panel decide whether to open a tab or show an error or bounce the icon or whatever.
[18:36] <dobey> thisfred: we already have an unfortunate dependency graph, because someone was brilliant and decided to make u1cp an external thing
[18:36] <alecu> thisfred, right now the gui depends on the backend.
[18:37] <dobey> thisfred: you've already introduced a dependency on u1cp in syncdaemon, which in turn has a dependency on syncdaemon
[18:37] <dobey> thisfred: say hello to the oroborus.
[18:38] <alecu> I've seen Ron Jeremy doing that.
[18:44] <thisfred> alecu: ok, so what's a compelling argument to *not* include this in the current service? (which is named com.ubuntuone.controlpanel.service, incidentally)
[18:44] <thisfred> alecu, is that not a case where we could have a /gui path?
[18:46] <alecu> thisfred, the compelling reason: we have two separate executables for the gtk ui and the backend.
[18:46] <alecu> thisfred, the only one that's started by dbus activation (that is: from a .service file) is the backend.
[18:46] <thisfred> right, and we need the service pointing to the ui executable for activation to work?
[18:47] <thisfred> ok, I get it
[18:47] <alecu> thisfred, exactly.
[18:47] <dobey> there are two issues
[18:47] <thisfred> at least :)
[18:47] <dobey> please don't conflate them into one solution :)
[18:47] <alecu> dobey, what are the two issues?
[18:48] <dobey> alecu: the actual API vs. the activation of the gui
[18:48] <dobey> alecu: and i don't think we should force all the frontends to reimplmeent the same API over and over just because they want to use a different toolkit
[18:49] <dobey> but *shrug*
[18:49] <thisfred> dobey: sure, but if the activation of the gui requires a new service, then doesn't putting the UI API there make sense?
[18:49] <dobey> not necessarily, no
[18:49] <thisfred> dobey: and won't they have to reimplement those things (switching tabs, asking for attention) in their own ways anyway?
[18:50] <thisfred> well, not switching tabs, but showing relevant information
[18:50] <dobey> thisfred: the backend could just have a signal for "switch_tab" or something
[18:50] <thisfred> tabs are a detail
[18:50] <dobey> and the front-end could just listen to the signal and respond accordingly
[18:50] <alecu> well, that makes sense.
[18:50] <dobey> rather than having to deal with all the dbus machinery to provide a service
[18:51] <thisfred> I don't understand the difference between listening to a signal and providing a service I guess
[18:51]  * karni reboots
[18:51] <dobey> thisfred: i guess you haven't written enough dbus services to hate writing dbus services yet
[18:52] <thisfred> exactly zero, but I'm not looking forward to it
[18:52] <thisfred> so if I don't have to that's great
[18:52] <dobey> eh, i don't think we should do any of it
[18:53] <dobey> but you already know that
[18:53] <dobey> circular dependencies are evil
[18:53] <thisfred> I agree, but
[18:53] <karni> I'm back.
[18:53] <thisfred> we do need to show the control panel when a user runs out of quota
[18:54] <thisfred> I would much prefer a U1 indicator, but it is not to be
[18:55] <dobey> i don't understand why we have to show the control panel
[18:55] <dobey> instead of doing what we're already doing, or slightly improving it
[18:56] <dobey> i mean, what does the control panel do special here? it just shows a warning with a button that opens the web page, right?
[18:57] <thisfred> dobey: well, I'm just executing what was decided at UDS where I was not present, so I don't know the rationale behind everything
[18:58] <thisfred> but what we currently do, does not integrate with unity at all
[18:58] <dobey> i don't recall deciding opening the control panel for low quota, being a decision at uds
[18:58] <thisfred> which we should
[18:58] <dobey> or at the rally
[18:59] <thisfred> we definitely talked about it at the rally, since that is where I opened the bugs
[18:59] <dobey> in fact, rather, at the rally, i am pretty sure we decided "the gnome-settings-daemon will be running, so we don't have to bother with it"
[19:00] <dobey> the only thing i recall from rally where we would have needed to open control panel was for the "accept shares" stuff
[19:00] <dobey> but eh
[19:00] <dobey> i blame nessita for keeping this code separate
[19:02] <thisfred> well, I'm at a loss as to what to do then. If you say everything is fine as it is, that definitely sounds attractive to me.
[19:03] <dobey> maybe i'm missing something, but i don't see the point of increasing complexity here
[19:03] <thisfred> except I don't see how we can integrate with the launcher from the current situation
[19:03] <alecu> dobey, didn't we disable the pop up quota message when the folder was a share from another user?
[19:03] <dobey> well we don't need to because we currently just open a dialog
[19:04] <thisfred> but that may be because I don't know the current situation very well
[19:04] <dobey> alecu: no, i had to add that back iirc
[19:04] <dobey> alecu: but i don't like it
[19:05] <alecu> oh, right.
[19:08] <dobey> anyway, i don't see how having circular deps is at all good here
[19:09] <alecu> dobey, thisfred: anyway: I recall discussing this with nessita and agreeing that we would be opening the control panel, and showing something. The "showing something" nessita has mostly taken care of, the opening is what we need to do.
[19:10] <dobey> alecu: i'm not questioning that agreement. just the sanity of it :)
[19:11] <dobey> alecu: i am fully aware we agreed opening to the folders tab for accepting shares made sense for the UX
[19:11] <thisfred> alecu: sure, but if it's contentious, and nobody is wildly enthousiastic about it,
[19:11] <dobey> but the practicality situation concerns me
[19:11] <thisfred> maybe we shouldn't spend all this time and do it with popen for now after all
[19:12] <alecu> thisfred, I think I agree with that
[19:12] <dobey> thisfred: but what happens when the unity integration is enabled, but control-panel-gtk isn't installed?
[19:13] <thisfred> dobey: I can put a try except around the popen ;)
[19:13] <alecu> thisfred, also, we should find some way to do only one instance from the control panel itself.
[19:14] <dobey> thisfred: and what would happen in the except clause?
[19:15] <alecu> thisfred, also: we will need to add more cmdline flags to signal the "bouncing" or the "show window below other open windows."
[19:15] <thisfred> alecu: that's done, or at least the first one is
[19:16] <alecu> cool
[19:16] <thisfred> alecu: popping under does not seem to be possible, currently
[19:16] <alecu> dobey, would inverting the order of dependencies fix that?
[19:16] <alecu> dobey, making sd depend on a control-panel, and control-panel-gtk providing that.
[19:17] <thisfred> alecu: opening only a single window should be possible without dbus, and is a separate issue, but I have time to look at that if we scrap the new service for now
[19:18] <dobey> alecu: fix my concerns? no
[19:18] <ralsina> thisfred: the current canonical solution is using dbus
[19:18] <dobey> alecu: a circular dependency is a circular dependency no matter how many times you try to walk around it :)
[19:19] <ralsina> canonical as in "established and correct" not as in "the company' :-)
[19:19] <dobey> ralsina: in gtk+ it's libunique usually, but dbus feels saner in most cases
[19:20] <thisfred> ralsina: sure, but it seems at this point there is barely a consensus on what the problem is and if we need to solve it
[19:20] <dobey> ralsina: and i think the way libunique works, it uses X atoms
[19:20] <dobey> thisfred: well the having multiple open control-panel-gtk windows is a separate problem, which i don't think there is any contention on
[19:20] <ralsina> dobey: a X atom in the root window? How quaint :-)
[19:21] <thisfred> ah ok, sry
[19:21] <dobey> ralsina: yeah. it's very 1987
[19:21] <thisfred> I thought ralsina was commenting on the whole discussion
[19:22] <dobey> uhm
[19:22] <dobey> ralsina: is nessita gone the entire week?
[19:22] <thisfred> so, we can add a service just for activation
[19:22] <ralsina> dobey: 2 weeks
[19:22] <dobey> doh
[19:22] <thisfred> dobey: yup holidays
[19:22] <dobey> well i hope here branch isn't important
[19:22] <ralsina> dobey: which one?
[19:23] <dobey>  Thanks, I can see it.
[19:23] <dobey> > >
[19:23] <dobey> > Great.
[19:23] <dobey> sigh
[19:23] <dobey> grr, X
[19:23] <dobey> https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/services-redesign/+merge/52258
[19:23] <dobey> that one
[19:23] <ralsina> actually that one is very important
[19:24] <dobey> it would have to be
[19:25] <ralsina> Is there a big problem with it?
[19:26] <dobey> well it failed to merge, because for some reason pylint is being used directly instead of u1lint there
[19:26] <dobey> and she added some #XXX comments
[19:26] <dobey> and pylint doesn't like them
[19:26] <ralsina> dobey: oh, great
[19:27] <ralsina> But yes, it is a very important branch because the UX for the services tab was bad
[19:27] <thisfred> dobey: I can make a branch to switch run-tests to u1lint...
[19:27] <dobey> and i don't know why she is using straight pylint there
[19:27] <ralsina> dobey: well, she's not around to ask :-)
[19:27] <dobey> thisfred: well i'd like to know why it's not doing so already
[19:27] <ralsina> thisfred: if you can make that branch merge, that would be awesome
[19:28] <thisfred> probably just historic reasons
[19:28] <thisfred> I'll see if u1lint works
[19:28] <dobey> and why is color output being used
[19:29] <dobey> thisfred: u1lint probably breaks with the pylintrc in there, because of the output
[19:29] <dobey> and i don't know what all is in the pylintrc there that's different from the one in devtools
[19:29] <dobey> and *sigh*
[19:30] <mandel> ralsina: ping
[19:30] <ralsina> mandel: pong
[19:30] <thisfred> dobey: I have no compunctions about deleting that either :)
[19:31] <dobey> thisfred: well if it has any ignores, those would be important
[19:31] <mandel> ralsina: I've fixed all the sso test that failed on windows so right now we are missing the UI and the installer bits for it (py2exe)
[19:31] <thisfred> dobey: u1lint shows only 2 easily fixed warnings
[19:31] <ralsina> mandel: yay!
[19:31] <mandel> ralsina: have you see the installer doc? what is that help button in the title bar?
[19:32] <ralsina> mandel: ignore that, windows doesn't have it
[19:32] <ralsina> mandel AFAIK
[19:32] <dobey> thisfred: ok, no ignores? (if so i think they can be added as cmdline arguments now)
[19:32] <mandel> ok, I'll start without it
[19:35] <thisfred> dobey: removed the pylintrc, and it had no effect. Fixed the two issues, and rerunning the tests, then I'll propose
[19:36] <dobey> ok
[19:36] <alecu> thisfred, the branch looks great. One tiny detail hoping you won't throw your monitor at me:
[19:37] <alecu> thisfred, the "if not self.uploading_filename" should be tested in test_file_download_started
[19:37] <alecu> thisfred, and perhaps add a new test for when self.uploading_filename is set
[19:37] <thisfred> right you are
[19:38] <alecu> (same for download)
[19:39] <alecu> mandel, ralsina: I think windows used to have a help icon on the title bar...
[19:40] <mandel> really? I probably never looked for it
[19:40] <alecu> http://stackoverflow.com/questions/1112472/adding-help-icon-to-winforms-form-titlebar
[19:40] <mandel> alecu: by the way, I'd really welcome if you can do some reviews for the branches I proposed in sso since you worked on it
[19:41] <alecu> mandel, sure
[19:41] <mandel> thx
[19:41] <ralsina> that help gives you access to the "whatis" (or similar) property on Qt widgets, BTW
[19:42] <ralsina> I had never seen it on  windows, KDE has it though :)
[19:42] <mandel> alecu: this would be the first https://code.launchpad.net/~mandel/ubuntu-sso-client/implement_windows_keyring/+merge/52089
[19:45] <mandel> ralsina: I think we are missing a big amount of steps in the design of the UI for sso, I'll do something similar to what we have on linux and then we can decide from there
[19:45] <ralsina> mandel: cool
[19:45] <mandel> alecu: is there a doc of the different screens used in sso?
[19:46] <alecu> mandel, don't think so...
[19:46] <alecu> mandel, do you need screenshots?
[19:46] <mandel> alecu: if you already have them it would be great, otherwhise I can see in a vm
[19:48] <alecu> mandel, no, I don't have them, I would need to log out and take them while registering anew.
[19:49] <mandel> alecu: no worries I can do that
[19:50] <dobey> hmm
[19:51] <alecu> mandel, why did you end up using deferToThread ?
[19:52] <dobey> ralsina: review my branch?
[19:53] <mandel> alecu: I want to make sure that the call was not blocking and since the windows client will have a twisted main loop I went down that path
[19:53] <alecu> mandel, cool.
[19:56] <thisfred> wtf. There is one lint error that will just not be disabled. dobey: have you ever seen that before (it's happening with W0201 specifically)
[19:56] <thisfred> whether I disable it globally or locally or with the inline comment, it keeps being reported by u1lint
[19:57] <dobey> is that the foo not in __init__ warning?
[19:57] <thisfred> yep
[19:57] <thisfred> perhaps that was the reason u1lint is not used
[19:58] <dobey> no, that is an issue with pylint
[19:58] <dobey> but maybe the pylintrc disabled it
[19:58] <dobey> you are doing disable= right, and not disable-msg?
[19:58] <thisfred> yep
[19:58] <alecu> mandel, tests ran fine, by pylint cries like this: https://pastebin.canonical.com/44495/
[19:58] <alecu> s/by/but/g
[19:59] <dobey> thisfred: but yes, i have seen that before a long time ago, before we even had ubuntuone-dev-tools
[19:59] <dobey> thisfred: is it complaining about it in a test?
[19:59] <thisfred> dobey: maybe because it's setting a property on a property of a property
[19:59] <thisfred> yep
[19:59] <mandel> alecu: take a look at the comment on top of the use of the delete
[20:00] <alecu> mandel, I don't worry about how you use it, it's pylint that's whining
[20:00] <dobey> thisfred: does changing it to setattr(object, value) instead of object.attr = value work?
[20:00] <mandel> alecu: hmm I'll add the diasble comment, since it will tkae long until the patch is applied and packaged for ubuntu
[20:00] <thisfred> let's see
[20:01] <alecu> mandel, I ran "make check" and that's what the merging bot will run.
[20:01] <dobey> err, setattr(object, "attr", value) i guess
[20:01] <dobey> can't remember that api exactly right now
[20:02] <mandel> alecu: yes, I know, I forgot to do that
[20:03] <thisfred> dobey, no dice, pylint is too smart in its stupidity
[20:04] <dobey> :(
[20:04] <thisfred> dobey: since it's a style warning, I'd be happy to pass it as a global ignore to u1lint, but what's the switch for that? man u1lint is subhelpful
[20:04] <dobey> there isn't a switch for it
[20:04] <thisfred> ah
[20:05] <thisfred> let me see if i can just fix the issue
[20:05] <dobey> thisfred: if you "bzr diff pylintrc|grep W0201", does it show up?
[20:09] <thisfred> nope
[20:09] <thisfred> dobey: so u1lint and pylint behave differently in this respect?
[20:10] <thisfred> dobey: looks like it's not able to deal with self.patch very well, and it looks at the original class rather than the fake/mock one or something
[20:10] <dobey> thisfred: no
[20:10] <dobey> thisfred: all u1lint does is run pylint and parse the output
[20:11] <dobey> thisfred: but u1lint handles the W0511 warnings specially to avoid failing for XXX/FIXME comments
[20:12] <dobey> thisfred: so if this warning wasn't showing already, there is likely something in the pylintrc that was there, which ignores it at that level, rather than in the code
[20:12] <dobey> because pylint is buggy
[20:13] <thisfred> dobey: well running pylint passes, running u1lint does not
[20:13] <thisfred> perhaps because of the invocation
[20:13] <dobey> that makese absolutely no sense at all
[20:13] <thisfred> I know
[20:14] <ralsina> dobey: I'll review it right away
[20:14]  * ralsina has  a3yo kid onhis lap becuse the nanny is sick
[20:16] <dobey> shen me niao pylint
[20:16] <mandel> alecu: you did make check or ./run_tests in ubuntu sso?
[20:17] <dobey> thisfred: "pylint --output-format=parseable --include-ids=yes --rcfile=/usr/share/ubuntuone-dev-tools/pylintrc" passes or fails?
[20:18] <thisfred> dobey: it gives me yet another warning
[20:19] <dobey> of course it would do something completely different
[20:19] <alecu> mandel, sorry: ./run-tests
[20:19] <dobey> thisfred: that is how u1lint is calling pylint
[20:19] <alecu> mandel, (make check is for u1-client)
[20:20] <thisfred>  pylint --output-format=parseable --include-ids=yes --rcfile=pylintrc ubuntuone/ works though, so the local pylintrc must escape that warning somehow
[20:20] <mandel> alecu: ok, then if you pull the new version it should be fixed
[20:20] <dobey> thisfred: that makes no sense
[20:20] <dobey> thisfred: you were running u1lint with the pylintrc still in the tree?
[20:21] <thisfred> both with and without
[20:21] <dobey> thisfred: and it failed in both cases?
[20:21] <alecu> mandel, you have more branches to review, right?
[20:22] <thisfred> dobey: yep
[20:22] <mandel> alecu: yes, but give me a min, I've discovered that the pipeline plugin does funny things,
[20:22] <thisfred> dobey: anyhow, I think I'll add W0511 to pylintrc and leave this for another day
[20:22] <mandel> I'm fixing them
[20:22] <dobey> sigh
[20:23] <dobey> that makes absolutely no sense whatsofnever
[20:23] <thisfred> yeah I can't figure it out at all either
[20:23] <dobey> maybe we should just stop using pylint and pyflakes both
[20:23] <dobey> or just use pyflakes everywhere
[20:25] <ralsina> dobey +1 on new-icon
[20:26] <mandel> alecu: can you take a look at https://code.launchpad.net/~mandel/ubuntu-sso-client/implement_windows_networkstatus/+merge/52091
[20:26] <thisfred> dobey: ralsina https://code.launchpad.net/~thisfred/ubuntuone-control-panel/escape-W0511/+merge/52759 should unblock nessita's branch
[20:26] <mandel> alecu: also if you can tell me where is the merge conflcit cause I dont understand it
[20:32] <dobey> ralsina: btw, did you ever get the updates installed to test unity crashiness with?
[20:34] <mandel> I'm done, see u all alter!
[20:37] <thisfred> alecu: r916 adds assertions for the filenames
[20:38] <ralsina> dobey: good question! Let's check
[20:39] <ralsina> Hey, got the ubuntu one shutdown inhibition :-)
[20:41] <karni> ralsina: what's that?
[20:42] <karni> ralsina: does it not let you shutdown the PC when syncing or something of that sort?
[20:43] <ralsina> dobey: no crashiness, but it seems a bit stuck in "processing the commands pool'
[20:43] <dobey> sigh, and gtk+ image loaders aer broken it seems
[20:43] <ralsina> karni: exactly
[20:43] <dobey> ralsina: well that's got nothing to do with me. talk to facundo, or delete all your files :)
[20:43] <ralsina> karni: of course you can tell it to shutdown anyway, but at least you know it's not syncing and it's your fault :-)
[20:43] <ralsina> dobey: hahaha
[20:44] <karni> ralsina: oh. don't tell me it's gonna be like Windows updates.. aha, good!
[20:44] <dobey> ralsina: and you *do* have gir1.2-unity-3.0 installed right?
[20:44] <ralsina> dobey: I even got the unity integration working correctly it seems
[20:44] <dobey> ok good
[20:44] <ralsina> yup, 3.6.2-0ubuntu3
[20:45] <ralsina> So that's looking good.
[20:50] <dobey> ok well hopefully i can actually make a release today
[20:50] <ralsina> I would prefer nessita's branch to be in the release
[20:50] <alecu> mandel, approved the first branch.
[20:50] <thisfred> ralsina: then review mine ;)
[20:50] <ralsina> thisfred: oh, tricky :-)
[20:50] <ralsina> URL?
[20:50] <dobey> ralsina: wrong project
[20:50] <thisfred> ralsina: well it unblocks nessita's:
[20:50] <thisfred> https://code.launchpad.net/~thisfred/ubuntuone-control-panel/escape-W0511/+merge/52759
[20:50] <thisfred> ah
[20:51] <thisfred> so right he is
[20:51] <dobey> but yes we need to release that too
[20:51] <ralsina> dobey: hahaha I am thinking product, not project ;-)
[20:52] <ralsina> thisfred: approved.So now nessita's branch has to be marked as approved again after this one merges, right?
[20:52] <thisfred> ralsina: correct
[20:52] <thisfred> ralsina: I will do that
[20:52] <ralsina> launchpad sometimes makes me feel I am programming for the DMV
[20:53] <ralsina> That's why on weekends I program like a hippie
[20:53] <thisfred> ralsina: you'd prefer to be able to land branches with failing tests? :)
[20:53] <ralsina> thisfred: no, and I believe the DMV has a place in all proper civilizations, too :-)
[20:54] <thisfred> ralsina: launchpad will happily let you do that btw, tarmac luckily will not ;)
[20:55] <dobey> tarmac will happily land branches with failing tests if i tell it to
[20:55] <thisfred> which you luckily don't
[20:56] <thisfred> unless we offer enough beer
[20:58] <ralsina> dobey: I talked to chipaca today about getting some "hardware" in ubuntu's private cloud for tarmac.
[20:59] <ralsina> dobey: I am scared your server will go to heaven while you are in Argentina :-)
[21:01] <dobey> i will fix it not to
[21:02] <ralsina> dobey: don't worry, you will still manage it.
[21:03] <ralsina> dobey: unless you don; t want to
[21:04] <dobey> i'm not worried
[21:05] <thisfred> nessita's branch approved again, let's see
[21:05] <ralsina> in fact, I don't even care to use the new hardware, as long as it's available if we ever need it
[21:06] <dobey> the reason it's not all in the DC already is because we need to retain control over it
[21:06] <dobey> because we need to have certain versions of certain things installed on certain versions of ubuntu, to do all the tests
[21:08] <dobey> we did set up a few things in the DC, but i am not even sure that tarmac is actively running any more. i have no control over it at all
[21:09] <dobey> anyway
[21:09] <dobey> guess i can roll some releases now
[21:10] <ralsina> dobey: the idea is that we would have the same control as now
[21:10] <karni> verterok: facundobatista: what's the difference between FS_FILE_DELETE and SV_FILE_DELETED? the latter means a file has been created on the system? and the first.. ?
[21:10] <ralsina> I don't want one where ww depend on faceless admins.
[21:11] <alecu> mandel, both your branches show this in launchpad: "Conflict adding file run-tests.bat.  Moved existing file to run-tests.bat.moved."
[21:11] <facundobatista> the first indicates that a file was deleted in the FS (file system), the second indicates that a file was deleted in the SV (server)
[21:11] <facundobatista> karni, ^
[21:11] <alecu> mandel, it also happened around here when merging.
[21:11] <dobey> ralsina: of course.
[21:12] <dobey> ralsina: but i also need my server to not be going to sleep while i'm away, for other reasons :)
[21:12] <karni> facundobatista: ah, SV is the server. thanks, you _rule_, rule! ;)
[21:12] <facundobatista> :p
[21:12] <ralsina> dobey: I image so :-) However I would prefer if our sprint was flaming-pigeon-proof :-)
[21:12] <ralsina> s/image/imagine/
[21:14] <dobey> ralsina: murphy won't allow it
[21:14] <ralsina> murphy always wins eventually, but he wins easier when we let him.
[21:14] <thisfred> dobey: I just set my branch to approved, will that make it in?
[21:15] <dobey> i tried to shoot murphy once, and ended up with a hole in my foot
[21:15] <thisfred> I would like it to, but it's not a blocker
[21:15] <dobey> thisfred: i know not of this 'branch' you speak
[21:15] <thisfred> dobey: https://code.launchpad.net/~thisfred/ubuntuone-client/filenames-in-notifications
[21:15] <ralsina> dobey: I once tried to shoot murphy but he came back as a robot policeman and I ended melting because I was immersed on toxic waste.
[21:16] <thisfred> that statik is a busy guy
[21:16] <dobey> thisfred: is he on a boat?
[21:17] <thisfred> his own island by now, surely
[21:17] <thisfred> all evil genii have one
[21:18] <thisfred> ralsina: nessita's branch is merged
[21:18] <ralsina> yay
[21:19] <karni> beuno: be advised I'm still working on it. minor adjustments that put the puzzle together. from what I've seen up to now I'm very happy with it.
[21:19] <beuno> karni, sounds pretty encouraging!
[21:20] <dobey> thisfred: wouldn't a true evil genius have a moveable island?
[21:20] <thisfred> His is a giant sea turtle
[21:21] <ralsina> giant sea turtles have so many disadvantages as mobile evil bases
[21:21] <ralsina> ok, will EOD. Will come back in 2 hours, so please mail me any review requests, please?
[21:21] <dobey> ralsina: well they are much better if you hollow them out first
[21:21] <thisfred> yeah, feeding them is expensive
[21:25] <dobey> thisfred: if you get them to shed their dependence on foreign oil, they are much cheaper
[21:25] <thisfred> how many cars do you have again? :P
[21:26] <dobey> 4, but only 3 are running right now
[21:27] <thisfred> you leave them running while you work? That's awesome! :D
[21:28] <dobey> yeah, for the background noise
[21:40] <thisfred> my branch was merged, so if you wanna cut a release now, I don't have any objections ;)
[21:42] <dobey> i think i'll revert your branch, just for spite :)
[21:58] <dobey> bah i need to take a break for a bit, my brain is obviously not all there at the moment. but i will do the releases today
[22:24] <karni> verterok: Is public link part of meta data? I receive new volume generation when I pulish a file, which is not exactly what I'd like.. Especially if a file is marked as syncable and starts to redownload. How does SD solve it?
[22:31] <verterok> karni: public url isn't part of the metadata, at least not yet
[22:31] <verterok> karni: syncdaemon check the hash of the file
[22:31] <verterok> *checks
[22:31] <karni> aha!
[22:32] <karni> verterok: and redownloads only if differet, correct?
[22:32] <verterok> yup
[22:32] <karni> verterok: thanks for dropping by so late and answering
[22:32] <verterok> np
[22:33]  * verterok bbiab, need to make some mate
[22:48] <thisfred> need to open some beer. See y'all tomorrow!
[23:24] <karni> can I use multiple --fixes switches when commiting branch ?
[23:45] <thisfred> karni: not sure, what I usually do is multiple commits with --unchanged --fixes
[23:45] <karni> thisfred: oh, thanks!
[23:45] <soren> karni: I'm quite sure you can just pass multiple --fixes.
[23:45] <karni> will try in a moment, thanks.
[23:46] <soren> Worked for me.
[23:46] <karni> oh cool