[01:41] <karni> If I'll keep working like that, I'll get RSI soon ;P
[01:43] <beuno> karni, please don't  :)
[01:43] <karni> beuno: ambition is killing me, seriously :D everytime I start coding, I can't stop! hahaha
[01:44] <beuno> karni, have a beer
[01:44] <karni> but things are looking better and better. it's what makes me tick!
[01:44] <beuno> they truly are
[01:44] <karni> beuno: I'm snowboarding for few hours tomorrow ^ ^ (actually learning!)
[01:45] <karni> I can't wait to stand on my new snowboard (been skateboarding for 7 years some time ago)
[01:47] <beuno> oh, that is very cool
[01:47] <beuno> I've never tried that
[01:47] <beuno> skied quite a bit
[01:47] <beuno> but snowboard looks hard
[01:48] <karni> beuno: skiing is hard! I did it few times, I did't like one of my skis driving cross the other haha. In snowboarding, you at least have your legs steady ;D
[01:48]  * karni tests new sync
[01:49] <beuno> well, good luck with that
[01:49] <karni> beuno: today I rewrote the regular sync to boost it the same way as the initial sync. and things are looking good
[01:49] <beuno> I remember doing some skiing in poland, but can't remember where
[01:49] <karni> beuno: whoaa, that's a surprize ^ ^
[01:49] <karni> thanks!
[01:49] <beuno> I lived there for 5 years, didn;t I tell you?
[01:49] <karni> what :D? no way
[01:50] <beuno> yeah, Warsaw
[01:50] <karni> fun ^^
[01:50] <beuno> 87-92
[01:50] <beuno> fun times
[01:50] <karni> nice :)!
[01:50] <beuno> remember little to no Polish, though
[01:51] <beuno> Ace of Base was a bit hit at the time
[01:51] <beuno> aaaaanyway
[01:51] <karni> ok, enough for today. I'll continue tomorrow, have to get some sleep.
[01:51] <beuno> off to walk the dog
[01:51] <karni> beuno: :D I remember that!
[01:51] <karni> beuno: ok, bye bye for now :)
[01:52] <beuno> karni, please do get some sleep  :)
[01:52] <beuno> have a great night
[01:52] <karni> beuno: thank you! talk to you later
[04:59] <phrozon> hallo thar
[12:03] <ploum> Hello
[12:03] <ploum> Can I remove the Ubuntu One folder once it's empty ?
[12:03] <ploum> I'm now synchronizing a bunch of folders
[12:03] <ploum> and I don't need that one anymore
[12:07] <ploum> I also have a problem : the folders that I moved from Ubuntu_One/ to another synced folder ( Documents/ ) are still displayed at the root in the U1 web ui
[12:08] <ploum> how can I get rid of them ?
[13:01] <nessita> ralsina: ping
[13:01] <ralsina> nessita: pong
[13:01] <nessita> ralsina: alecu is mentioning me that the bindwood task is no longer assigned to him nor to thisfred
[13:01] <nessita> which is kinda of good news :-)
[13:02] <ralsina> nessita: yes, I know :-)
[13:02] <alecu> well, it is still assigned to me for the remainder of this week, and 'till we do the handover and stuff
[13:02] <nessita> ralsina: I wanted to suggest that it would be a very good thing if they start/restart the work on zeitgeist and event aggregtion for unity
[13:02] <ralsina> let me check the assignments for the cycle...
[13:03] <nessita> is obvious I'm extremely concern about that task since unity is all new and unknown for us. And we rely on this feature (U1 in the launcher and showing messages) as discovery point for U1
[13:04]  * ralsina has not even been able to run unity on any of his computers yet
[13:04] <ralsina> But yes, thisfred is assigned to notifications + messaging starting this week
[13:04] <ralsina> alecu is on shares UX with you
[13:05] <ralsina> But I understand that's kinda blocked on ivanka, right?
[13:05] <nessita> yeah
[13:05] <nessita> unless until next week on the rally
[13:05] <alecu> ralsina, alpha 1 failed running on my laptop too... I'm about to install it into a vm
[13:06] <ralsina> alecu: at least on virtualbox it doesn't like it :-(
[13:06] <nessita> where alecu and thisfred will also have the EXTREMELY IMPORTANT chance to ask about unity stuff
[13:06] <ralsina> alecu: not even with 3d accel enabled
[13:06] <ralsina> alecu nessita: so, I think unity stuff + notifications is a good use of time until the sprint at least
[13:07] <ralsina> and during the sprint, probably, too
[13:07] <alecu> ralsina, did you managed to get your passport and visa?
[13:07] <ralsina> basically, squeeze as much as you can out of designers so you have clear ideas / goals
[13:07] <ralsina> alecu: nope
[13:08] <alecu> guessed so :-(
[13:10] <nessita> right
[13:11]  * alecu brbs
[13:12] <ralsina> and then explain everything to me over dinner when you are in BA :-)
[13:13] <mthaddon> can anyone take a look at https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/696265 - been almost a week now and I'm still missing some music I purchased
[13:13] <ubot4`> Launchpad bug 696265 in ubuntuone-client (Ubuntu) "Purchased album not downloaded (affects: 1) (heat: 6)" [Undecided,New]
[13:14] <mthaddon> s/anyone/someone/
[13:15] <beuno> sounds like a muffinresearch or alecu bug
[13:19] <muffinresearch> mthaddon: rye is probably the best person to talk to about that.
[13:19] <mthaddon> muffinresearch: ok, thx
[13:19] <mthaddon> muffinresearch: he's on holiday, or just TZ conflicted?
[13:20] <nessita> mthaddon: there he is (rye)
[13:20] <mthaddon> aha
[13:21] <mthaddon> rye: I've been told you may be able to help with https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/696265
[13:21] <ubot4`> Launchpad bug 696265 in ubuntuone-client (Ubuntu) "Purchased album not downloaded (affects: 1) (heat: 6)" [Undecided,New]
[13:22] <rye> mthaddon, ok, what's the output of u1sdtool --status ?
[13:23] <mthaddon> rye: http://pastebin.ubuntu.com/551063/
[13:24] <rye> mthaddon, how much time has it roughly taken to print an exception - more than a minute or less than that?
[13:24] <mthaddon> rye: I'd say right about a minute
[13:25] <rye>  mthaddon ok, could you please see whether there are more than 2 lines in ~/.cache/ubuntuone/log/syncdaemon.log ?
[13:25] <mthaddon> there are 66 lines in that file
[13:26] <mthaddon> 2011-01-06 13:25:38,997 - ubuntuone.SyncDaemon.Main - NOTE - ---- MARK (state: <State: 'READY'  (queues WORKING_ON_BOTH  connection 'Not User With Network')>; queues: metadata: 9; content: 8; hash: 0, fsm-cache: hit=4496 miss=4742) ----
[13:26] <mthaddon> that
[13:26] <mthaddon> that's the latest ^
[13:28] <rye> mthaddon, wow that's interesting... ok, trying to continue in a dumb mode - u1sdtool --connect
[13:28] <mthaddon> ok, that returned immediately without error
[13:28] <rye> mthaddon, if that returns exception too, then ... hmmm
[13:29] <rye> mthaddon, ok, basically it was not connected, could you please run u1sdtool --status now to see whether it pretends to work?
[13:30] <mthaddon> rye: http://paste.ubuntu.com/551064/
[13:32] <ploum> Can I safely remove the Ubuntu One folder if it's empty ?
[13:32] <rye> mthaddon, well, it is working now despite the first failure... and if you update to maverick nightlies you will get tritcask metadata storage which makes syncdaemon start up in under than 5 seconds...
[13:33] <mthaddon> rye: I don't really want to install from a PPA if I can help it
[13:33] <rye> mthaddon, well, it works now and your files should start appearing
[13:33] <mthaddon> rye: yep, they're appearing now - but why did it fail for so long?
[13:35] <rye> mthaddon, it was not connecting automatically (which nessita fixed already in trunk, nightlies etc.). however i am not sure why first --status failed
[13:36] <rye> or no, i know
[13:36] <nessita> rye: how did the first -s failed?
[13:37] <rye> mthaddon, how many files do you have in ubuntuone ?
[13:37] <mthaddon> rye: probably a few hundred but I'm not sure - is there some easy way to check?
[13:37] <nessita> mthaddon, rye: seeing http://pastebin.ubuntu.com/551063/, means that SD was just starting up (it takes a while). Seems like it wasn't running before
[13:38] <rye> ploum, yes, in case no files are there then removing the folder will not cause anything. Unless you continue using ubuntuone in which case it will be recreated (since that's a default storage)
[13:38] <ploum> rye, I'm syncing other folders
[13:38] <ploum> and I just don't want the Ubuntu One anymore
[13:39] <rye> nessita, i suspect that's my autostart-kills-sd-after-2-minutes of .SyncDaemon interface being missing bug
[13:40]  * rye realized he should propose a branch for removing that UniqueInstance thing since SD is so awesome it starts before anyone notices ^_^
[13:40] <nessita> probably
[13:40] <nessita> rye: YES PLEASE :-)
[13:40] <alecu> ralsina, http://www.webupd8.org/2010/12/how-to-test-ubuntu-1104-with-unity-in.html
[13:41] <alecu> (in virtual box 4)
[13:41] <ralsina> alecu: my upgrade to VBox 4 resulted on kernel panics on all my ubuntus :-(
[13:41] <ploum> rha, it looks like moving a file doesn't remove it from the remote U1 folder
[13:41] <ralsina> alecu: I couldn't even boot the natty live CD on VBox 4
[13:41] <ploum> that's really anoying
[13:42] <mthaddon> rye, nessita: so I'm happy to have my files but want to make sure the issue is well understood so others don't have the same problem - would you say this is a solved problem at this point?
[13:42] <alecu> hmm... I'll be following these steps: http://www.webupd8.org/2010/12/install-virtualbox-40-stable-in-ubuntu.html
[13:42] <nessita> mthaddon: on u1 nigthlies yes, it is
[13:43] <ralsina> alecu: VBox 4.0 is working, the problem is that if the VM has the guest extensions form 3.x it breaks
[13:43] <mthaddon> nessita: ok, thx
[13:43] <nessita> mthaddon: thank you
[13:43] <ralsina> alecu: so I could try to uninstall them and see what happens. But since I am using them all day long to work... not until saturday at least
[13:44] <alecu> oh, ok.
[13:51] <ralsina> alecu nessita thisfred CardinalFang dobey standup in 10'
[13:51] <thisfred> thx
[13:51] <ralsina> vds too :-)
[13:51] <vds> sure
[14:00] <nessita> me
[14:00] <ralsina> me
[14:01] <nessita> alecu, thisfred, mandel, vds, dobey, CardinalFang?
[14:01] <alecu> me
[14:01] <thisfred> me
[14:01] <vds> me
[14:02] <dobey> me
[14:02] <ralsina> mandel is on holiday
[14:02] <nessita> ah
[14:02] <rye> nessita, i think you will like this - https://code.launchpad.net/~rye/ubuntuone-client/uniqueinterfaceless/+merge/45376 :)
[14:03] <nessita> ralsina: shall we?
[14:03] <ralsina> yes, nessita, start!
[14:03] <nessita> DONE: several code reviews, coding is ready for bug #696782, still pending IRL testing. More questions for packging u1cp.
[14:03] <nessita> TODO: IRL testing for bug #696782. Try to move on on packing u1cp, need to remove u1-preferences entry points from natty first. Need review for https://code.launchpad.net/~nataliabidart/ubuntuone-client/remove-preferences-desktop/+merge/45375
[14:03] <nessita> BLOCKED: nopes
[14:03] <nessita> NEXT: ralsina
[14:03] <ubot4`> Launchpad bug 696782 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "Start DC service in backend to make that op asynch (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/696782
[14:03] <ralsina> DONE: A few reviews, searching for windows contractor, discussed bindwood's future some more, chased people around as usual.
[14:03] <ralsina> TODO: more reviews, management stuff, have HR fix things for me, someday actual coding ;-)
[14:03] <ralsina> BLOCKED: no
[14:04] <thisfred> DONE: * Fixed bug #697728 * Removed a monkey patch * started on migrating server code to new desktopcouch
[14:04] <thisfred> TODO: finish migrating server code to new desktopcouch
[14:04] <thisfred> BLOCKED: No
[14:04] <ubot4`> Launchpad bug 697728 in desktopcouch "database.delete_record fails on deleted records without a record_type (affects: 1) (heat: 6)" [Low,Fix committed] https://launchpad.net/bugs/697728
[14:04] <thisfred> oops sry alecu
[14:04] <alecu> DONE: a branch for bug #650671 that needs review love
[14:04] <alecu> TODO: a vm with natty for the rally, bindwood handoff
[14:04] <alecu> BLOCKED: not today
[14:04]  * alecu wears his magii costume and gives presents to vds
[14:04] <ubot4`> Launchpad bug 650671 in ubuntuone-client (Ubuntu Natty) (and 5 other projects) "UbuntuOne "out of space" dialog is broken (affects: 11) (dups: 1) (heat: 40)" [High,Triaged] https://launchpad.net/bugs/650671
[14:04] <vds> DONE: went trough the docs of the file storage rest APIs, made some experiment with django and urls, started a branch to implement the first APIs
[14:04] <vds> reviewed:
[14:04] <vds> https://code.launchpad.net/~thisfred/desktopcouch/remove-monkey-patch-AGAIN/+merge/45237
[14:04] <vds> https://code.launchpad.net/~mandel/desktopcouch/mock_db_for_records/+merge/45262
[14:04] <vds> https://code.launchpad.net/~thisfred/desktopcouch/fix-deletion-migration-view/+merge/45270
[14:04] <vds> TODO: work on the branch
[14:04] <vds> BLOCKED: nope
[14:04] <vds> dobey: go
[14:04] <dobey> λ DONE: finished bug 696968, bug 697321, bug 697648, filed bug 697732, fixed libubuntuone nightlies to deal with gir api version change
[14:04] <dobey> λ TODO: bug pitti about backports
[14:04] <dobey> λ BLCK: None.
[14:04] <ubot4`> Launchpad bug 696968 in desktopcouch "Pairing fails (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/696968
[14:04] <ubot4`> Launchpad bug 697321 in desktopcouch (Ubuntu Natty) (and 1 other project) "Installing desktopcouch-ubuntuone does not install desktopcouch (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/697321
[14:04] <ubot4`> Launchpad bug 697648 in ubuntuone-client "ubuntuone-client nightlies are not built for natty (affects: 1) (heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/697648
[14:04] <ubot4`> Launchpad bug 697732 in desktopcouch "desktopcouch-service has weird main loop/dbus issues (affects: 2) (heat: 10)" [Critical,Triaged] https://launchpad.net/bugs/697732
[14:05] <dobey> CardinalFang: ^^ 697732 is especially troublesome and we need to fix it and make a new desktopcouch release/upload
[14:06] <nessita> rye: reviewing it
[14:08] <ralsina> dobey, call the next guy :-)
[14:08] <nessita> there is no next, I think :-)
[14:09] <dobey> there wasn't one :)
[14:09] <ralsina> ok, then ;-)
[14:09] <ralsina> There were nighltlies that failed to build  -- https://launchpad.net/~ubuntuone/+archive/nightlies/+build/2125860/+files/buildlog_ubuntu-maverick-i386.desktopcouch_1.0.3%2Br246%7Emaverick1_FAILEDTOBUILD.txt.gz
[14:10] <dobey> ralsina: yes, and that is already fixed
[14:10] <nessita> dobey: can you please review https://code.launchpad.net/~nataliabidart/ubuntuone-client/remove-preferences-desktop/+merge/45375 ?
[14:10] <ralsina> dobey: that's the one you mentioned? ok then.
[14:10] <nessita> ralsina: you too, but probably after dobey reviews it
[14:11] <dobey> libubuntuone on narwhal is failing right now, due to the default python change, so i still need to fix that, but everything else is building fine
[14:11] <ralsina> nessita: ack
[14:11] <ralsina> dobey: ack
[14:12] <ralsina> any comments, questions, etc?
[14:12] <ralsina> Remember we have the weekly call on mumble today
[14:12] <nessita> I'll leaving to a dentist appointment so I will not attend the weekly call, ralsina has my summary
[14:12] <nessita> I'll be*
[14:14] <ralsina> ok, then, eom?
[14:17] <nessita> eom!
[14:36] <nessita> rye:  approved
[14:38] <dobey> that was a quick dental exam
[14:39] <nessita> dobey: I'm leaving in 30 minutes :-)
[14:43] <nessita> ralsina: can you review the https://code.launchpad.net/~nataliabidart/ubuntuone-client/remove-preferences-desktop/+merge/45375 proposal?
[14:44] <ralsina> nessita: sure.
[14:45] <ralsina> nessita: done
[14:56] <nessita> can I have a second review for https://code.launchpad.net/~nataliabidart/ubuntuone-client/remove-preferences-desktop/+merge/45375 ? alecu, would you be available? (I'm about to review yours)
[14:58] <nessita> alecu: hum I guess I will not, since it has a dissaprove :-/
[14:59] <beuno> nessita, it has an abstain, which is not the same
[14:59] <beuno> nessita, approved
[15:00] <nessita> beuno: the dissaprove is in one alecu's branch. Thanks!
[15:00] <beuno> ah
[15:01] <nessita> alecu: when you have a moment, I would like to ask about your branch. You're proposing for trunk, which is natty and will not be backported to maverick. But we said that since natty will be all unity, there wasn't much point on doing that work, since it will probably be not used anyways...
[15:01] <nessita> alecu: the branch we need with more 'urgency' is to disable the plugin for stable-1-4, that would go to maverick
[15:03] <dobey> it also needs to fix the problem, instead of simply making the problem be a little slower
[15:04] <alecu> dobey, I've discussed this again with ralsina, after your comments, and this was the solution we agreed to
[15:04] <ralsina> I thought this was proposed for maverick, my error
[15:05] <alecu> nessita, I believe gnome-settings-daemon will still be running for unity, and until we have anything that replaces this plugin, I believe it's ok to merge it to trunk.
[15:06] <dobey> either way, i still disapprove if the solution is "pop the dialog every 5 minutes" instead of "pop the dialog constantly" as it's not a solution
[15:06] <nessita> alecu: ok, I'm talking about this in #ubuntu-desktop
[15:06] <ralsina> dobey: noted.
[15:06] <dobey> anything being fixed in stable should be fixed in trunk first, unless the code no longer exists in trunk
[15:07] <nessita> dobey: well, in this case we might just remove the thing in stable
[15:07] <ralsina> dobey: this is the solution we can provide with the time constraints we have. It's not ideal? Sure. But it's what we can do right now.
[15:09] <alecu> dobey, in your review, what do you mean by "it certainly wouldn't require more incorrect usage of gconf" ?
[15:10] <dobey> ralsina: i disagree. the solution i mentioned on alecu's proposal would be simpler, and even only implementing half of it (assuming the second half isn't currently doable), it's still a much better stop-gap than simply slowing the bombardment of dialogs slightly
[15:11] <dobey> alecu: i mean the way gconf is supposed to be used, is not to inject random settings from code. there are schemas and translations that are supposed to be used.
[15:13] <alecu> dobey, oh, ok. I thought the way it was already being used in that same .c file was the right one.
[15:13] <nessita> dobey: showing the message one per session is too little, I think. The user will easily missed the message. Is not like 'little space in the hard drive', where the lack of space in the hard drive consequences are obvious. Lack of space on ubuntu one is not obvious at all
[15:13] <ralsina> dobey: so you argue against the setting? Currently it would show the warning every hour, so it's not every "few minutes", either.
[15:14] <dobey> alecu: yes, which is also wrong, hence your change increases the number of wrongness :)
[15:14] <ralsina> besides, people have sessions that go on for weeks, so once-per-session is not ideal either
[15:14] <dobey> ralsina: 300 seconds is 5 minutes
[15:14]  * ralsina checks the code again
[15:14] <rye> let's have a notification bar somewhere in unity? :)
[15:14] <nessita> #define DEFAULT_OUT_OF_SPACE_INTERVAL 3600
[15:14] <nessita> that's an hour
[15:14] <ralsina> define DEFAULT_OUT_OF_SPACE_INTERVAL 3600
[15:15] <ralsina> nessita, go to the dentist, everyone else, mumble ;-)
[15:15] <dobey> nessita: it's a dialog, that requires the user to actively tell it to go away. i think if it pops up when they log in, they are going to see it
[15:15] <nessita> yeah!
[15:15] <alecu> dobey, hmmm.. the other gconf code is used for the "CHECKED_BOOKMARK" option that was done by rodrigo, so I guessed it was done the right way.
[15:15] <nessita> dobey: what if the user rans out of spcae after logging in?
[15:15] <ralsina> alecu CardinalFang dobey thisfred vds full team weekly etc, etc in mumble in a minute
[15:15] <nessita> ok, I'm off
[15:15] <nessita> see ya later!
[15:15] <dobey> bah
[15:16] <vds> already there :)
[15:28] <dobey> nessitaway: my suggestion was to only show it once per log-in, not only attempt to show it at time of log-in.
[15:39] <alecu> thisfred, https://wiki.ubuntu.com/UbuntuOne/Specs/ZeitgeistIntegration/EventsSpec
[15:41] <alecu> thisfred, https://blueprints.edge.launchpad.net/ubuntu/+spec/other-ubuntuone-n-zeitgeist-integration
[15:41] <ralsina> I'm going to take my lunch break, be back in a while.
[15:47] <thisfred> alecu: https://wiki.ubuntu.com/UbuntuOne/Specs/ZeitgeistIntegration#UI Changes
[16:04]  * dobey also goes to get lunch
[16:21] <CardinalFang> What is the DBus inspection and injection GUI tool?  I've only used it once to test something of nessita's.
[16:22] <CardinalFang> "apt-cache search" fails me
[16:26] <CardinalFang> ah. d-feet.  That's an obvious name.
[16:26] <nigelb> aquarius: pinh, around?
[16:26] <nigelb> err, ping
[16:26] <aquarius> nigelb, pong
[16:27] <nigelb> aquarius: hey, we're having the ubuntu user days shortly, will you be able to talk about ub ubuntuone and all the goodies a new user to ubuntu could use?
[16:27] <aquarius> nigelb, potentially, yes. What's "shortly"?
[16:28] <nigelb> Jan 29th weekend
[16:28] <aquarius> actually over the weekend?
[16:28] <nigelb> yeah
[16:28] <nigelb> would you be able to spare an hour?
[16:28] <aquarius> can't do it :( I'm away that weekend -- my birthday, and my daughter's on stage
[16:28] <nigelb> ahhh, that's cool then :)
[16:28] <aquarius> but I'll try and make sure that you have someone to talk about things
[16:28] <aquarius> ralsina_lunch, ping
[16:29] <aquarius> nigelb, ralsina_lunch runs the desktop team; beuno-lunch runs the web and mobile team, so let's see if one of them or their teams are available
[16:29] <nigelb> aquarius: Great, thanks :)
[16:30] <nigelb> aquarius: Also, Happy Birthday in advance :D
[16:34] <aquarius> ralsina, beuno-lunch, ^
[16:35] <ralsina> nigelb: I will be happy to help
[16:35] <nigelb> ralsina: yay! What time over 29th/30th is good for you?
[16:36] <ralsina> I can adjust to any slot you may have if you tell me a week early :-)
[16:36] <nigelb> ralsina: oh, great.  What TZ are you in? (we don't want you taking a session at 2 am ;) )
[16:37] <ralsina> nigelb: UTC-3
[16:37] <nigelb> ralsina: ok, I'll talk to you soon :)
[16:38] <ralsina> nigelb: cool :-)
[16:38] <nigelb> ralsina: also, err, link to lp profile
[16:38] <nigelb> oh wait, I got it :)
[16:38] <ralsina> nigelb: http://launchpad.net/~ralsina
[16:38] <ralsina> nigelb: I am not creative with usernames/nicks ;-)
[16:40] <nigelb> ralsina: I'd have to say, I'm exactly the same :)
[16:40] <nigelb> https://wiki.ubuntu.com/UserDaysTeam/CourseSuggestions --> updated
[17:16] <beuno> yes
[17:16] <beuno> hi
[18:04]  * nessitaway is back!
[18:04] <nessitaway> starving, but back
[18:08] <dobey> you didn't get a lollipop?
[18:09] <nessita> dobey: nopes, only ugly and expensive medicine to buy
[18:10] <jblount> nessita: I thought medicine in .ar was cheap?
[18:10] <beuno> well, cheap for .us  :)
[18:11] <nessita> right, and non-'mandatory' medicine is not covered by the ensurance
[18:12] <jblount> :(
[18:12]  * beuno envisions nessita buying it from a dealer in a dark park
[18:12] <nessita> :-P
[18:13] <nessita> jblount: is not that bad, don't worry. It costs almost like a pair of jeans, which is... not sure
[18:14] <nessita> dobey: speaking of lollipops, would you be able to do a new release of u1client for natty?
[18:14] <nessita> so I can do, after that, the release of the u1cp
[18:16] <dobey> i need to anyway, yes
[18:17] <dobey> i'm also wondering how my cpu being 98% idle, can suddenly have a load of 3.something
[18:17] <dobey> especially when my cpu is 4 cpus with virtualthreadmagic
[18:20] <ralsina> dobey: i/o bound processes?
[18:21] <dobey> ralsina: not really. at least, nothing obvious. which makes the weird kernel process things be highly suspect
[18:23] <karni> beuno: aquarius: guys, have you seen this before http://www.couchone.com/ ? in particular, this http://www.couchone.com/page/android looks like some real goodies
[18:25] <beuno> karni, yeah
[18:25] <karni> I haven't gotten in depth with it, but that sounds like native contacts sync (no funambol)
[18:25] <beuno> well
[18:25] <beuno> it's not yet production-ready
[18:25] <karni> right
[18:25] <karni> they mention that, indeed
[18:25] <karni> was just wondering if you were aware of that (how could I have doubted! ;) )
[18:25] <beuno> we are keeping our eye on it, though  :)
[18:26] <ralsina> dobey: either that or a bad driver
[18:26] <karni> ok! :)
[18:26] <ralsina> dobey: you can discard IO using iotop
[18:27] <dobey> ralsina: more like https://twitter.com/#!/dohbee/status/23082249771556865
[18:28] <ralsina> dobey: you are talking to a guy whose main computers a month ago were a 5 year old P4 and a eee 701 ;-)
[18:30] <CardinalFang> gnome-terminal crashed.  Every window gone.   That hurt.  :(
[18:31] <CardinalFang> And crash-reporter has no stack trace.  Excellent.
[18:31] <dobey> ralsina: yes, but while the hardware was slow 15 years ago on my 75 MHz P1 with like 64M of RAM (if it was even that much), i never had i/o speed, or out of memory problems. and now i consistently have my 4 core system with 2GB RAM, and a SATA disk, having arbitrary I/O problems when i am not even doing anything.
[18:32] <ralsina> dobey: that's expected. One component will always be the slowest one, and you will have to wait on it :-)
[18:32] <dobey> in fact, i'm probably actually trying to do the same amount of work i was doing back then, but through the wonders of advanced technology, am required to consume 100x as many resources to do it :P
[18:32] <ralsina> dobey: BTW: you should add another 2GB there ;-)
[18:33] <dobey> ralsina: well, it would have 4GB, but the other 2GB stick is bad, so I have to figureo out how to RMA it :(
[18:33] <ralsina> dobey: that's mostly recall BIAS. I used to be happy with my eee... and now I have actually used an i3  I can't even look at it
[18:34] <ralsina> why did I type that in uppercase? No idea.
[18:34] <dobey> i'm pretty sure that Netscape 3.04 Gold couldn't even use 675MB of memory, even if it wanted to
[18:35] <dobey> and with firefox, i'm lucky if i can keep it under that now :(
[18:35] <ralsina> dobey: and it couldn't do CSS, or much of anything you do on any page nowadays :)
[18:35] <ralsina> twitter is almost like running a IRC client on javascript.
[18:35] <ralsina> just as an example
[18:35] <dobey> you assume i *want* css/javascript insanity
[18:36] <dobey> and java embedding worked just fine, and there were irc clients written in java back then
[18:36] <ralsina> dobey: I assumed you wanted to use websites, because of the mentin of firefox ;-)
[18:36] <dobey> :)
[18:36] <dobey> no, i'd rather not use web sites
[18:36] <ralsina> then don't use firefox, and it uses 0MB
[18:36] <dobey> i am just forced to thanks to the wonderful 'advances' in technology
[18:36] <dobey> haha
[18:36] <dobey> well, yes
[18:37] <dobey> i'll remember that when you try to fire me :)
[18:37] <dobey> "but my manager said it was ok if i didn't use the web!"
[18:37] <ralsina> dobey: as long as the work gets done, I don't actually *care* ;-)
[18:38] <dobey> yes, well, i haven't written a gtk+ client for launchpad yet. so sadly, i have to use the web
[18:39] <ralsina> dobey: launchpad should work with elinks
[18:42] <dobey> ralsina: this one time, i wrote a browser...
[18:42] <dobey> anyway
[18:42] <dobey> "the web" is certainly more apropos now
[18:43] <dobey> just waiting for the spider queen to show up and paralyze and coccoon me for a later feeding
[19:04] <CardinalFang> thisfred, of you're eq/ne d-c branch, if you add a [deeper [structure in] the test], I'd be happy with it.
[19:05] <nessita> dobey, ralsina: is there any way to debug bug reports such as bug #692653 ?
[19:05] <ubot4`> nessita: Bug 692653 on http://launchpad.net/bugs/692653 is private
[19:05] <nessita> ufa
[19:05]  * ralsina looks
[19:05] <ralsina> nessita: no, unless you have a debug build of it
[19:07] <thisfred> CardinalFang: so a list in a list? I already have dictionaries in a list
[19:08] <thisfred> or a nested mergeable list?
[19:08] <thisfred> and now you're gonna say both of course :)
[19:09] <dobey> nessita: uhm. i'm pretty sure ubuntu-sso-client doesn't have a panel applet
[19:11] <nessita> dobey: right. And does this traceback look familiar to you? bug #694002
[19:11] <ubot4`> Launchpad bug 694002 in ubuntu-sso-client (Ubuntu) "ubuntu-sso-login crashed with ImportError in <module>() (affects: 1) (heat: 507)" [Undecided,New] https://launchpad.net/bugs/694002
[19:12] <dobey> nessita: no, but the problem is obvious. is ubuntu-sso-client using gobject introspection for Gtk?
[19:13] <nessita> dobey: not directly, but maybe a lower layer?
[19:15] <ralsina> why is gtk importing something that is not installed? (or if it's installed, why is it failing?)
[19:15] <nessita> exactly
[19:15] <ralsina> dependency error?
[19:15] <dobey> it's not installed
[19:16] <nessita> dobey: but from the trace doesn't look like ussoc is importing that, but some other lower layer
[19:16] <dobey> at least gir1.2-glib-2.0 isn't i guess
[19:17] <CardinalFang> thisfred, ah, I missed test_eq2 being different.  Nevermind.  I like.
[19:17] <nessita> ussoc has no gir listed as dep, and as far as I know ussoc doesn't depend on any gir
[19:18] <CardinalFang> thisfred, I suppose a list of MergableLists will work too.
[19:18] <ralsina> precisely. who owns gi/__init__.py ?
[19:18] <ralsina> my dpkg-fu is weak
[19:18] <dobey> python-gobject
[19:19] <ralsina> so, I'd say python-gobject should require gir
[19:19] <ralsina> Since it imports it unconditionally in this case
[19:20] <dobey> well it doesn't import it unconditionally exactly
[19:20] <dobey> something would have to import gi
[19:21] <ralsina> It should be traceable if it were reproduceable
[19:22] <ralsina> A quick check makes me believe gio is guilty
[19:23] <ralsina> See https://pastebin.canonical.com/41589/
[19:24] <nessita> ralsina: mterry is telling me that python-gobject does have gir-glib on its Depends
[19:24] <nessita> so something is off
[19:24] <ralsina> maybe a broken update of that system?
[19:24] <ralsina> I had to do a bunch of apt-get -f installs a few days ago
[19:25] <nessita> right
[19:25] <nessita> sounds like it
[19:25] <nessita> thanks guys!
[19:28] <dobey> back to releasing things
[19:32] <nessita> dobey: would you please let me know when u1client is released?
[19:59] <CardinalFang> thisfred,  https://code.launchpad.net/~jderose/desktopcouch/version-in-package/+merge/44849
[20:01] <thisfred> CardinalFang: yes, I'm not sure what to do with that. We do need the version in the setup.py I think, so we may have to have the build do some magic copying of the version string to the __version__ variable. I'm not sure I completely agree that it's common or best practice, but it couldn't hurt to have it
[20:02] <thisfred> Usually I would expect to have different versions of anything built on top of a library for different versions of that library
[20:12] <CardinalFang> thisfred, I can't think of a place where it's totally necessary to have a version in the code, except perhaps in logging.
[20:14] <thisfred> CardinalFang: I think he wants to do things differently based on the version of desktopcouch, i.e. support multiple versions of dc from the same version of his software. I think that way madness lies, but he should be welcome to try ;)
[20:14] <thisfred> It's just that we don't want to give up the version in setup.py
[20:17] <dobey> CardinalFang: User-Agent
[20:17] <dobey> but alas i don't think just moving the definition of what the version is, outside of the setup.py, is the right way to achieve that
[20:17] <dobey> anyway, i need to take a break
[20:38] <nessita> ralsina: 2 branches for review, please: https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/replication-to-the-backend/+merge/45439 and https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/start-dc-on-backend/+merge/45441
[20:38] <nessita> the latter depends on the former
[20:39] <nessita> thisfred: would you be able to review the first one?
[20:40] <thisfred> nessita: sure thing, I'm on it
[20:40] <nessita> thisfred: I'm doing a last minute push with 2 forgotten files :-D
[20:40]  * nessita always forget to bzr add
[20:41] <nessita> thisfred: last revno should be 45
[20:41] <thisfred> kk
[20:45] <ralsina> nessita: looking at it
[20:47] <ralsina> nessita: trade you for alecu's https://code.launchpad.net/~alecu/ubuntuone-client/restrain-out-of-space-dialog/+merge/45317
[20:47] <nessita> yes, on it already
[20:54] <alecu> nessita, ralsina: same bug, targeted to stable-1-4, https://code.launchpad.net/~alecu/ubuntuone-client/restrain-out-of-space-dialog-1-4/+merge/45446
[20:54] <nessita> ack
[20:55] <ralsina> alecu: ack
[20:57] <nessita> ralsina: I will superseed the proposal https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/start-dc-on-backend/+merge/45441 since despite having the correct prerequisite branch, the replication_client.py is marked as new and that's not correct, it was added on its prerequisite branch
[20:57] <ralsina> nessita: ok
[21:02] <alecu> nessita, is that bzr or lp fault?
[21:05] <nessita> mine, I think
[21:05] <ralsina> let me guess, that was the file you forgot to add?
[21:05] <nessita> alecu: I had this huge branch that I split in two, and when doing the split seems like something got messy with the new files
[21:06] <nessita> ralsina: now is fixed, new merge proposal located at https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/start-dc-on-backend/+merge/45448
[21:07] <ralsina> nessita: ack
[21:07] <nessita> alecu: when executing ./test-flood.py I got no dialog at all
[21:07] <nessita> shall I install u1-client-gnome?
[21:08] <alecu> nessita, perhaps
[21:08] <alecu> nessita, I'm sure gsd-plugin must be in there
[21:09]  * nessita installs
[21:10] <nessita> alecu: u1clientgnome installed and no flooding notification for me, not even one
[21:10] <ralsina> nessita: I like the last suggested triaging method... a lot, really.
[21:10] <alecu> nessita, did you turn off syncdaemon?
[21:11] <nessita> alecu: yes
[21:11] <alecu> nessita, is gnome-settings-daemon running?
[21:11] <alecu> (the system one)
[21:11] <nessita> 146:nessita   1870  0.0  0.1 402812 15068 ?        Ssl  08:39   0:11 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
[21:11] <nessita> yes
[21:12] <alecu> nessita, try restarting it. It might not have found out about the gsd-plugin that u1-client-gnome installs.
[21:12] <nessita> ralsina: the one where each team member does triage one each day?
[21:12] <ralsina> nessita: yes
[21:12] <alecu> nessita, killall gnome-settings-daemon; sleep 3; gnome-settings-daemon
[21:12] <nessita> alecu: shall  just kill it?
[21:12] <alecu> yup
[21:12] <alecu> nessita,  you can log out and back in if you want :-)
[21:13] <nessita> alecu: nopes, that makes me hit a bug in nautilus where it eats my system up
[21:13] <alecu> nessita, what????
[21:13] <alecu> nessita, logging out?
[21:13] <nessita> alecu: nopes, logging in having u1-client-gnome installed
[21:13] <ralsina> nessita: is it normal that d-feet tells me replications_info returns nothing?
[21:14]  * ralsina probably has no replications, but anyway wants to be sure
[21:14] <nessita> the u1 plugin for nautlus crashes and restarts so quickly and unmeasurably that it kills the system
[21:14] <nessita> alecu: I got notifications now!
[21:15]  * nessita continues the test
[21:19] <nessita> alecu: (gnome-settings-daemon:11763): Gtk-WARNING **: The GTK_DIALOG_NO_SEPARATOR flag cannot be used for GtkMessageDialog
[21:19] <karni> beuno: What if the app is durnig some files content sync, and user hits Menu->'Stop sync' -- should it kill the sync? perhaps I should rename it to "Quit" and just let the SyncDaemon finish what it's up to, and know that it should shutdown immediately after that.
[21:19] <karni> aquarius: ↑
[21:19] <beuno> well
[21:20] <karni> beuno: aquarius: There are many design decisions that I don't feel comfortable to decide on myself.
[21:20] <beuno> sure
[21:20] <beuno> so
[21:20] <beuno> I would change it to quit, yes
[21:20] <beuno> and making the default behavior to finish the sync
[21:20] <aquarius> what happens if you abort a sync midway through?
[21:20] <karni> finish - interrupt or continue until it's done?
[21:21] <aquarius> does the amount of syncing you've already done take effect, or was all that work wasted?
[21:21] <karni> aquarius: right, the thing is that when we sync files from a volume
[21:21] <karni> aquarius: the generation number is saved
[21:21] <beuno> aquarius, resumable uploads are targeted for end of this cycle
[21:21] <beuno> you can resume downloads already
[21:21] <beuno> so I guess for downloads, maybe quit immediately
[21:21] <karni> aquarius: so that next time the rest of the files not being synced this time
[21:21] <nessita> alecu: I have another question, when you return
[21:21] <karni> will be missed during any of the next sync's
[21:21] <beuno> for uploads, continue uploading, but leave a notification in the top bar?
[21:21] <alecu> nessita, tell me
[21:22] <karni> beuno: sounds good. what about downloads? i.e. 50 files haven't finished downloading, and user hits Quit
[21:22] <alecu> nessita, what about the Gtk-WARNING ? do you think our code spits that out?
[21:22] <alecu> nessita, it might be any of the many plugins that gsd loads
[21:22] <karni> aha, quit immediately
[21:22] <alecu> nessita, but I'll check it out.
[21:22] <nessita> alecu: thanks
[21:22] <nessita> alecu: so, the first message got lost and then the second live was shown once and never again. By first message I mean:
[21:22] <nessita> ** (gnome-settings-daemon:11763): DEBUG: notification: Out of space - Your Ubuntu One storage is full. Follow the link below to upgrade your subscription.
[21:22] <beuno> karni, I think that's where we would have an option to run in the background
[21:23] <beuno> maybe not by default for now
[21:23] <karni> beuno: I see
[21:23] <karni> aquarius: correction: currently I clear unfinished downloads. instead, I can resume :)
[21:23] <aquarius> karni, beuno, that's what I'm thinking: complete the current upload (and only the current upload) because uploads aren't resumable, but immediately terminate downloads.
[21:23] <karni> next time the user opens the app
[21:23] <nessita> alecu: and the second is: ** (gnome-settings-daemon:11763): DEBUG: notification: Out of space - There is no available space on the folder: "~/A shared folder" shared by Some Body
[21:24] <beuno> we're going to need to be able to do background for keeping pictures in sync, for example
[21:24] <aquarius> if I tell an app to quit and it doesn't quit then i will (a) force-interrupt it, (b) uninstall it. :)
[21:24] <beuno> aquarius, agreed
[21:24] <karni> aquarius++
[21:24] <beuno> we will need an always-on option once we allow people to keep folders in sync
[21:25] <nessita> alecu: is it too hard to not to show the next message until the first one is closed?
[21:25] <karni> beuno: I can't agree. Let me collect my words.
[21:25] <karni> beuno: aquarius: first of all, we shouldn't run in the background all the time. it's a mobile environment, and TBH U1 might not be so important for everyone (i.e. periodic sync is sufficient)
[21:25] <beuno> agreed
[21:26] <karni> beuno: aquarius: also, that' what I was wondering about the pictures sync
[21:26] <alecu> nessita, for this branch? yes, it's hard.
[21:26] <karni> beuno: we don't need to run continously *anything* to do that
[21:26] <alecu> nessita, the fact is that there can be any number of messages...
[21:26] <alecu> nessita, (different shares from different people)
[21:26] <karni> beuno: I'm not sure what was Chads solution, but we could use, for instance, the MEDIA_SCANNER_FINISHED broadcast
[21:26] <alecu> nessita, so we would need a list of pending messages...
[21:26] <karni> beuno: aquarius ↑: that way, we can still track the pictures being taken, and not run at all! :)
[21:27] <alecu> nessita, or we should change the design of the dialog
[21:27] <nessita> alecu: ok then, I don't think a user runs out of quota at the same moment a shares runs out of quota
[21:27] <beuno> karni, so we would hook to that event, and trigger an uplaod after each picture is taken?
[21:27] <nessita> alecu: is ok how it is :-)
[21:27] <nessita> alecu: with ZG events, this will be very different
[21:27] <alecu> nessita, yes, it's possible, but hopefully it's unlikely to happen at the same time.
[21:27] <karni> beuno: aquarius: the policy is that the service should shutdown itself as soon as it's done with the work (unless it's a music player or something close to that)
[21:27] <karni> beuno: exactly
[21:27] <alecu> nessita, I keep repeating that ZG is not a silver bullet
[21:28] <beuno> karni, I like
[21:28] <karni> beuno: however, we could keep the connection for a period of time, say, 3 minutes, since a user might take few pictures
[21:28] <aquarius> I agree with that, and don't agree that we should run in the background all the time :)
[21:28] <karni> beuno: but we wouldn't want to recoonect
[21:28] <beuno> cool
[21:28] <beuno> all on the same page
[21:28] <alecu> nessita, zg will be fine for some kind of events, but probably not for this.
[21:28] <karni> CardinalFang: ↑ please review few previous sentences of mine, aquarius and beuno (I'd soo love to see your piece of code!)
[21:28] <nessita> alecu: but... ZG will store 'user ran out of quota' as one event, and 'share X ran out of quota', right?
[21:29] <beuno> karni, aquarius, we may want a background process at some point, because if people mark folders to be synced, then we need to be able to talk to the server, etc
[21:29] <karni> CardinalFang: PS I'll commit today. I've got a huge bzr diff, wouldn't want to waste your time on integrating with previous revision
[21:29] <karni> beuno: aquarius: so I guess periodic sync is not enough? well, we can give that choice to the user.
[21:29] <nessita> alecu: and then if there are 1000 events of kind A (user ran out of quota) a single message will be shown?
[21:30] <beuno> karni, maybe it is, we'll see
[21:30] <karni> beuno: aquarius: either periodic sync, or persistent connection. beware -- we'll have to ping the server to keep the connection alive!
[21:30] <beuno> for now, we're all on the same page
[21:30]  * karni nods
[21:31]  * karni hopes he didn't ruin CardinalFang's recent work on the Picture sync :/
[21:31] <beuno> of course not
[21:31] <beuno> CardinalFang is unruinable
[21:31] <alecu> nessita, riiiiiight. But we want those notifications to be shown asap, not when the zg query finishes running. Also the 1000 events will show up on the gnome-activity-journal...
[21:32] <karni> beuno: :)
[21:32] <alecu> nessita, those kind of events should be aggregated on syncdaemon itself, so only one "run out of quota" event is sent.
[21:32] <nessita> alecu: I'm not convinced of that... but you may be right. Please let's talk about this next week.
[21:33] <alecu> nessita, absolutely. We should discuss this with eric, and a lot more :-)
[21:33] <thisfred> +1
[21:34] <CardinalFang> "we'll have to ping the server to keep the connection alive"  -- we can never expect to keep it alive.  Losing connection every 5 minutes should be completely normal.
[21:35] <nessita> alecu: yeah. I'm +1 your branches
[21:35] <karni> CardinalFang: right, but if we loose connection (which will happen on every Mobile<->WIFI change), in the 'persistent' variant, we'll have to reconnect, and sync
[21:35] <karni> CardinalFang: but you're definitely right.
[21:36] <karni> authenticate, for example, is really heavy on GC (which can be seen in the logcat)
[21:36] <karni> I'm not sure how much data is actually sent during auth. Probably just a signed request.
[21:38] <alecu> nessita, thanks.
[21:38] <CardinalFang> karni, new network connection shouldn't be the sole trigger for connect and sync.  Add time, and maybe whether we know there's something in our outbound queue.
[21:39] <nessita> alecu: regarding the warning: gsd-ubuntuone.c:108:							      GTK_DIALOG_NO_SEPARATOR,
[21:39] <CardinalFang> I'm only saying obvious things, I think.
[21:39] <nessita> alecu: the GTK-WARNING is ours, apparently
[21:40] <nessita> alecu: can you plesae fix that before approving?
[21:40] <CardinalFang> karni, in any case, in my tests, I haven't seen that broadcast go across, MEDIA_SCANNER_FINISHED.
[21:40] <karni> CardinalFang: Say, a user want's to run U1 persistenly. He expects stuff to be in sync, all the time. Would you suggest scheduled sync anyway? What if files have changed when we lost connection (i.e. we were in the underground)?
[21:40] <alecu> nessita, you are right, but I don't like fixing that if it's just a gtk warning.
[21:40] <nessita> alecu: why not?
[21:40] <alecu> nessita, gtk is safely ignoring it
[21:41] <alecu> nessita, I can fix it on trunk, but I don't like fixing it on stable
[21:41] <nessita> alecu: agreed
[21:42] <CardinalFang> karni, I suspect it's not a big problem.  If they're in a place where the network is in flux or beneath the earth, they probably aren't also needing data synch'd very soon.  In my office, yes.  On a train and 45 minutes from accessing it from a computer, no.
[21:42] <karni> CardinalFang: I'm not fully sure, but it's possible the MediaScanner doesn't kick in immediately after picture was taken. Anyhow, you know the docs ( http://goo.gl/SiJKa ). I would expect to get that broadcast sooner or later, but you are definitely more experienced. I may be wrong.
[21:43] <karni> CardinalFang: true :)
[21:43] <alecu> nessita, "This option has been deprecated in GTK+ 2.22. It will be removed in GTK+ 3" http://library.gnome.org/devel/gtk/2.21/GtkDialog.html
[21:44] <nessita> alecu: right... so we should fix it in trunk, since that goes to natty
[21:45] <karni> CardinalFang: Ok. So I think we could track time when was the last sync, and in case we have already few dropped connections, and give time elapsed, we invoke sync. That's a bit better?
[21:45] <karni> CardinalFang: And yes, I'll have to implement those queues. Not there yet.
[21:46] <CardinalFang> karni, yes, that sounds good to me.  Maybe wait another moment.  If we're activating because the network is on, then it's because the user requested something to happen with the network, and we shouldn't try to eat all their bandwidth when they're trying to (e.g.) view maps.
[21:48] <karni> CardinalFang: Incredible how much more factors we'll have to consider in mobile environment, isn't it.
[21:48] <CardinalFang> Though, the program isn't activating because of network newly connected, are we?  The desktop does.
[21:49] <karni> CardinalFang: If the connection comes up, we would receive a broadcast. However if it changes WIFI->Mobile (or the oter way), we'll receive the same broadcast.
[21:49] <karni> CardinalFang: No, we're not there yet. That's strongly connected to 'Connection settings' which I'm supposed to aim, too.
[21:50] <karni> CardinalFang: It either says 'Working off-line' or just uses the current connection (That's where we're at ATM)
[21:50] <CardinalFang> karni, ah, then, yes, probably it would be polite to the user not to jump in and steal all the bandwidth they're trying to use.
[21:51] <CardinalFang> karni, ah, then, yes, probably it would be polite to the user if the program were to avoid stealing all the bandwidth they're trying to use.
[21:51] <karni> CardinalFang: I'm not sure if we can track what's the current bandwith taken without another PERMISSION, but once the queues are implemented, we can have a designated time interval before we start doing stuff.
[21:52] <karni> CardinalFang: sure
[21:52] <karni> CardinalFang: plus, there's also planned upload/download limit, but that'll be a bit tricky I think ^ ^ (we'll see! I'll do my best)
[21:52] <karni> CardinalFang: speed limit, that is
[21:54] <CardinalFang> karni, in any case, the media catcher is simple, and can run as a sub-service of the sync service, when it's connected and killed when it's disconnected.  It's mostly stateless.
[21:55] <CardinalFang> karni, that is probably upside-down from what you were thinking.
[21:55] <karni> CardinalFang: I see. Tell me - if we had a periodic sync (the service doesn't run continuously all the time), would your solution still work? i.e. can it invoke the service if it's it's sub-component?
[21:58] <CardinalFang> karni, well, if there's a broadcast intent that could wake up either the sync service or this media catcher service, that would be nice to use to try to upload immediately.  I see reference to one, but i haven't seen it in action yet.
[22:00] <CardinalFang> karni, if the periodic sync schedule is good enough for the user, in expecting things to arrive, then it will work.
[22:00] <karni> CardinalFang: I shall investigate once i'm done with what i'm on right now :)
[22:00] <karni> uhm
[22:07]  * nessita eods
[22:21] <ralsina> I'm leaving for today. Have a pleasant evening everyone!
[22:22] <karni> CardinalFang: beuno: aquarius: About picture auto-sync: Not to mention the easiest way would be to add a 'New..' option to the Menu, with choice of: Picture/Video/Audio -- 1. user still would have the picture in the gallery 2. we know we should sync the picture 3. this makes everything simple, and the only difference is that the picture is stored under /u1 folder instead of /DCIM/100Media (or similar)
[22:23] <karni> CardinalFang: beuno: aquarius: if the user doesn't want to sync, he just makes the picture with Camera app. if he want's to sync-it-up, he uses U1F->New->Picture-> same Camera app
[22:24] <beuno> karni, sounds like a lot of work for the user
[22:25] <karni> beuno: You think.. ? I know Dropbox is nothing to compare perhaps, but they have it the same way (the Menu->New.. item)
[22:25] <karni> beuno: It narrows the application Settings, too.
[22:25] <beuno> I mean, you have to remember to take pictures with our app
[22:25] <karni> beuno: however.. you might be right
[22:25] <beuno> you ahve to open it, etc
[22:26] <karni> beuno: yeah..
[22:26] <CardinalFang> Lete's not mimic Dropbox.
[22:26] <CardinalFang> Let's not mimic Dropbox.
[22:26] <karni> CardinalFang: That's not my intention :) However I do think the New.. item is a good idea. New note, new [other type of media]
[22:27] <karni> Maybe it's not Tomboy, but .txt is still fancy! ;)
[22:27] <beuno> karni, it requires that the user open our application
[22:27] <beuno> which makes it feel less magical
[22:27] <karni> beuno: ^ ^
[22:27] <CardinalFang> It's Iphoney.
[22:28] <beuno> I would try to be smart about it, make sure we don't sync down the files we uploaded from the gallery
[22:28] <karni> CardinalFang: What's Iphoney? The 'New..' item?
[22:28] <CardinalFang> yes.  Opening this app because of the destination of the data.
[22:28] <karni> beuno: that's doable. however, if somebody removes red-eyes on the desktop, it gets tricier, as we have to sync-down the file (and then we have two, but different, copies)
[22:29] <karni> CardinalFang: ah
[22:29] <beuno> karni, well, we keep track of file ids, not file names
[22:29] <karni> beuno: I have just a little feeling I was too conservative with time estimation haha. We'll definitely try to be smart.
[22:30] <karni> beuno: I know, I'm not saying anything about the names. It's just that if a user removes red-eye on the desktop
[22:30] <beuno> more brainz is good!
[22:30] <karni> (and we, at the same time, open the file not from U1, but from MediaProvider)
[22:30] <CardinalFang> I think Shotwell would store another file, FWIW.  It doesn't change the originals, I'm sure.
[22:30] <CardinalFang> It may store delta operations instead.  Not sure.
[22:30] <karni> beuno: then we should download the file if the user clicks it, instead of opening it - you get the point
[22:30] <beuno> right
[22:31] <karni> CardinalFang: that's not the point. if we use gimp, what then?
[22:31] <karni> CardinalFang: we *change* the file, and then copy A from MediaProvder != copy B on U1
[22:31] <karni> thus, instead of opening from MEdiaProvider, we download the file (if it's meta has been synced, and hash was different)
[22:32] <karni> CardinalFang: As a side note, this is much more then Dropbox :)
[22:32] <karni> Db app, I mean.
[22:33] <CardinalFang> Dang, I have to finish some packaging or my manager will be annoyed.  Let's talk tomorrow, karni.
[22:33] <karni> CardinalFang: Oh sorry. Sure, l8r!
[23:18] <karni> CardinalFang: Right. Probably the assumption that the default Camera app invokes MediaScanner instead of writing directly to MediaProvider was an epic fail. MediaScanner is invoked, among other, when the SD card is mounted.
[23:18] <karni> CardinalFang: beuno: aquarius: I'm therefore quite sure (I have tested that) the Camera app doesn't broadcast previously mentioned intent about the new picture (at least on Android version < 2.2). Thus, if we want to be that smart and auto-sync users media content, it eventually looks like we will *have* to run a persistent service, just like on the desktop (but not necessarily persistent connection - that can be decided by the user)
[23:20] <beuno> karni, we'll figure that part out, don't worry
[23:23] <karni> CardinalFang: beuno: aquarius: actually there's last idea, which may catch on. If use use Alarms (you all are probably aware what's that, sth like cron) for scheduled sync operation, we can select all media from content provider, that has not been there before during previous sync :) (using DATE_MODIFIED / DATE_ADDED media columns)
[23:23] <karni> beuno: how about that! :)
[23:24] <karni> this actually makes real sense. we could schedule more frequent alarms purely for the 'user media' sync. say, 5 minutes. if there's something new, sync-up!
[23:26] <karni> say I'm a camera-addict. I set U1 sync for every 3 hours, and media sync for every 15 minutes :) [the latter is really lightweight if there's no new media!]
[23:27] <karni> CardinalFang: When you have time, please read the last few lines (it can be tomorrow!)