[01:10] <karni> CardinalFang: beuno: aquarius: I added Brainstorming section, and some content. Please review and leave any comments https://wiki.ubuntu.com/mkarnicki/u1f
[11:41] <czajkowski> muffinresearch: Thanks
[11:43] <muffinresearch> czajkowski: np. We will get someone to investigate as soon as we can.
[11:44] <czajkowski> muffinresearch: no bother as long as I've my music I'm fine, just confusing for folks.
[12:30] <gord> hi all, does anyone happen to remember the name of that awesome little tool that lets you monitor what ubuntu one is doing? (not u1sdtool)
[12:36] <nessita> gord: you mean the indicator? or the desktop app?
[12:37] <gord> nessita, it was a desktop app
[12:37] <nessita> gord: maybe magicicada?
[12:37] <gord> thats the one, thanks very much :)
[12:38] <nessita> https://launchpad.net/magicicada
[12:38] <nessita> gord: the PPA is a bit outdated, we're planning on making a release soon
[12:38] <gord> nessita, on natty, its in the repos ;)
[12:39] <nessita> gord: yeah, but that version is kinda old... we really need to do a new release (<- facundobatista), you can join #magicicada on freenode if that version doesn't work for you
[12:39] <nessita> gord: I can give you a new .deb if needed
[12:43] <gord> ah yes the version in natty doesn't work, but i grabbed the latest source and that works fine
[12:44] <nessita> gord: good. Last source has public files in it!
[12:55] <facundobatista> nessita, when people starts to using trunk, is a good indication that releases are needed, :p
[12:56] <nessita> facundobatista: yeah...
[13:13] <ralsina> good morning everyone
[13:13] <nessita> hi ralsina
[13:13] <CardinalFang> hi
[13:14] <ralsina> I'm feeling really sick today. Since my stomach hurts the same whether I am on IRC or not I will be around, but don't expect me to be very smart :-(
[13:19] <nessita> ralsina: ouch
[13:21] <alecu> hello all
[13:22] <ralsina> hola alecu!
[13:22] <nessita> hola alecu, how are you feeling today?
[13:22] <alecu> hi nessita, ralsina: much better
[13:23] <ralsina> alecu: great! As a welcome... remember bug #650671 ?
[13:23] <ubot4`> Launchpad bug 650671 in ubuntuone-client (Ubuntu) (and 3 other projects) "UbuntuOne "out of space" dialog is broken (affects: 11) (dups: 1) (heat: 40)" [High,Triaged] https://launchpad.net/bugs/650671
[13:23] <alecu> ralsina, I do
[13:23] <alecu> (heat: 40) !
[13:23] <ralsina> it hit beuno yesterday
[13:24]  * beuno shows alecu his scar
[13:24] <ralsina> there is a SRU for the patch that removes the notification. I was wondering if we could think maybe of a less drastic fix, if it is doable without much effort
[13:25] <ralsina> If it takes real effort, we just kill it and that's it
[13:26] <alecu> ralsina, I{
[13:26] <alecu> ralsina, I'll take another look.
[13:27] <ralsina> alecu: cool. I was thinking something like not showing that more than once every couple of minutes or something, but be creative :-)
[13:38] <beuno> ralsina, alecu, we need to be careful not to annoy users
[13:38] <beuno> so I'd avoid a notification every few minuters
[13:38] <beuno> *minutes
[13:38] <beuno> or allow a "don't tell me about this again" option
[13:39] <alecu> beuno, nice. But that would mean more strings to i18n and I believe that is out of the SRU scope
[13:39] <ralsina> beuno, alecu: yes, that can't go in, IIRC.
[13:41]  * beuno hms
[13:41] <ralsina> And just not telling the user he's out of quota EVER is probably annoying too
[13:42] <beuno> ralsina, yeah, what I want to avoid is us being percieved at hassling people into buying more storage
[13:43] <alecu> ralsina, also: this same dialog is also shown when a folder shared by another user runs out of space while you try to upload something to it.
[13:43] <ralsina> alecu: that's an official ouch
[13:43] <alecu> ralsina, and the logic for what message to show is in the syncdaemon
[13:44] <alecu> ralsina, as we have previously discussed with nessita, the logic to rate-limit should be in the syncdaemon as well
[13:45] <ralsina> alecu: yes, agreed in principle. I just want a fix we can actually implement. If rate-limiting is not it, then it's not it.
[13:46] <alecu> ralsina, I can surely implement rate limiting in the gsd plugin. But it will blindly rate limit all out of space notifications (for the user account and for shared folders(
[13:46] <nessita> alecu: when ralsina said "there is a SRU for the patch that removes the notification" he means that the bug was nominated for maverick by me and that we need a branch from you doing the removal
[13:46] <ralsina> alecu: you don't have information about what path is out of space, right?
[13:47] <ralsina> nessita: I thought the branch was done. Sorry.
[13:47] <nessita> alecu: the branch of the removal should be targeted to stable-1-4
[13:47] <nessita> ralsina: :-)
[13:47] <nessita> ralsina: the out of space is not per path, but per account...
[13:47] <ralsina> In any case it should be a small branch at least ;-)
[13:47] <nessita> I think so, yes
[13:47] <ralsina> nessita: but when it's on a shared folder from another user, you know it?
[13:48] <nessita> ralsina: yes, the notification from syncdaemon sends the 'share_id'
[13:48] <nessita> ralsina: the gsd plugin definitely knows, since a different legend is shown in each case
[13:48] <ralsina> nessita: ok, then we COULD separate the logic and still display it for shared folders
[13:49] <nessita> I think so, yes. But, from my POV, there is no gain on putting effort for natty on this
[13:49] <ralsina> nessita: I meant in the SRU branch
[13:49] <nessita> since we're supposed to show that quota exceeded error using the ZG events
[13:49] <alecu> nessita, why not?
[13:49] <nessita> alecu: since we're supposed to show that quota exceeded error using the ZG events
[13:49] <ralsina> agreed that for natty this is dead code anyway
[13:49] <alecu> ralsina, I see that we have that path, yes.
[13:49] <alecu> nessita, we won
[13:50] <alecu> hmmm
[13:50] <nessita> alecu: and the new notifications in unity doesn't use gsd, AFAIK
[13:50] <alecu> nessita, that makes sense.
[13:50] <alecu> nessita, but zeitgeist is not the best place to put oospace notifications
[13:51] <nessita> alecu: from my POV, ZG will store that notif and the aggregator will aggregate them... right?
[13:51] <alecu> nessita, we would still need something like the gsd plugin if we want for those events to be shown up.
[13:51] <alecu> nessita, right. But aggregation is a scheduled event that happens every x minutes, so you won't find out immediately about the out of space problem.
[13:53] <nessita> alecu: I disagree, I thought that the aggregator was not an scheduled event but a notification process that will aggregate info properly, but will show up a notification when relevant
[13:53] <nessita> alecu: anyways, if it was an scheduled event, a delay of minutes is totally acceptable
[13:53] <nessita> as long as minutes < 3? 5?
[13:54] <alecu> nessita, well, if it's something that needs to be running all the time, then it's just like the gsd plugin.
[13:55] <alecu> nessita, I thought we don't want yet another "resident" python process
[13:56] <nessita> alecu: even if is not another resident process, the quota notif will be shown eventually, in the next 5 minutes, let's say
[13:56] <nessita> that's good, 5 minutes will not change the user preception, I think
[13:56] <nessita> perception*
[13:58] <ralsina> yes, 5 minutes for out of quota in the cloud is not a problem, I think
[13:59] <ralsina> The user will just assume it was syncing and run out of space at the moment he saw the notification.
[13:59] <nessita> yeah
[14:00] <thisfred> me
[14:00] <nessita> me
[14:00] <ralsina> me
[14:01] <alecu> ok, we should discuss this further, because I'm not happy with the way aggregation is supposed to work. (or I'm not getting the full picture)
[14:01] <alecu> me
[14:01] <vds> me
[14:01] <mandel> me
[14:01] <dobey> me
[14:02] <nessita> thisfred: go!
[14:02] <thisfred> DONE: helped teknico and JamesTait with a missing feature in desktopcouch, landed a fix for bug #696972 TODO: desktopcouch bug triage | update server code to work with new desktopcouch | prepare for platform rally BLOCKED: no
[14:02] <ubot4`> Launchpad bug 696972 in desktopcouch "Wrong import path in bin/desktopcouch-get-port (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/696972
[14:02] <thisfred> nessita: you go!
[14:02] <nessita> DONE: worked on bug #693879, bug #693798, and bug #696782. Tried to coordinate with dobey how to make the transition preferences -> control panel, need to ping him about this. Submitted merge for bug #697211, still need a re-review before landing it. Made a review for mandel.
[14:02] <ralsina> nessita: please handle the standup, I'm on mumble :-(
[14:02] <nessita> TODO: finish aforementioned bugs, talk with dobey re preferences migration
[14:02] <nessita> BLOCKED: nopes
[14:02] <nessita> NEXT: ralsina
[14:02] <ralsina> DONE: started looking for windows contractor, team leads meeting, 3rd party API meeting, discussed bindwood's future, reviewed no-more-gobject , reviewed really-errback-on-error, reviewed/helped a bit on load_test_according_to_platform, chased people around as usual.
[14:02] <ralsina> TODO: more reviews, management stuff, have HR fix things for me, someday actual coding ;-)
[14:02] <ralsina> BLOCKED: no
[14:02] <ubot4`> Launchpad bug 693879 in ubuntuone-control-panel (Ubuntu) "The package lacks a .desktop file (affects: 1) (heat: 302)" [High,Triaged] https://launchpad.net/bugs/693879
[14:02] <ubot4`> Launchpad bug 693798 in ubuntuone-control-panel (Ubuntu) "u1cp should recommend u1cp-gui, and u1cp-gtk should provide it (affects: 1) (heat: 276)" [High,Triaged] https://launchpad.net/bugs/693798
[14:02] <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:02] <ubot4`> Launchpad bug 697211 in ubuntuone-client (Ubuntu) (and 1 other project) "Provide a specific login D-Bus service (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/697211
[14:03] <ralsina> alecu!
[14:04] <alecu> DONE: sick day
[14:04] <alecu> TODO: look again at bug 650671, change desktopcouch to start up a test db, setup a vm for bindwood tests
[14:04] <alecu> BLOCKED: not at all
[14:04] <ubot4`> Launchpad bug 650671 in ubuntuone-client (Ubuntu) (and 3 other projects) "UbuntuOne "out of space" dialog is broken (affects: 11) (dups: 1) (heat: 40)" [High,Triaged] https://launchpad.net/bugs/650671
[14:04] <alecu> coming up: vds
[14:04] <vds> DONE: discussed APIs work, selected a list of list of tasks, discussed with aquarius, beuno, chad and pedronis
[14:04] <vds> TODO: come up with better specs for the APIs work
[14:04] <vds> BLOCKED: nope
[14:04] <vds> mandel: please
[14:04] <mandel> DONE: Reviewed facundobatista branch. Found bug 697636 and bug 697661. Fixed both. Added tests for dc that mock db access for the deprecated API.
[14:04] <mandel> TODO: Finish rest of mocked tests of dc. Add skip decorators for dc.
[14:04] <ubot4`> Launchpad bug 697636 in desktopcouch "Trash record id is not correctly generated (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/697636
[14:04] <ubot4`> Launchpad bug 697661 in desktopcouch "The trash db object is recreated everytime there is a record to dele (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/697661
[14:04] <mandel> BLOCKED: no
[14:05]  * mandel looks at dobey
[14:07] <dobey> λ DONE: more work on bug 696968
[14:07] <dobey> λ TODO: bug pitti about backports, finish 696968 tests
[14:07] <dobey> λ BLCK: None.
[14:07] <ubot4`> Launchpad bug 696968 in desktopcouch "Pairing fails (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/696968
[14:07] <nessita> any closing comments?
[14:07] <alecu> ralsina, what about "discussed bindwood's future" ?
[14:08] <ralsina> alecu: I talked with thisfred, and it came up in the team leads call
[14:08] <ralsina> alecu: that it seems bindwood is in trouble and needs help
[14:08] <thisfred> alecu: we're running out of time quickly, and have not made much progress unfortunately
[14:09] <alecu> exactly
[14:09] <ralsina> It's understandable, it's like it's coding in a parallel universe
[14:09] <alecu> but I understand that there's a whole more month allocated to it at the end of the cycle
[14:09] <ralsina> I had a few very bad hours reading code last night
[14:09] <ralsina> alecu: yes, but Chipaca estimates there's more than that needed to finish it
[14:10] <ralsina> So, we are trying to get help. If we overestimate the effort, I am sure we will find things for you guys to do with the free days ;-)
[14:10] <alecu> I won't argue with that :-)
[14:11] <thisfred> :)
[14:11] <ralsina> On the 3rd party APIs work, I just talked with stuart and we'll go with dbus apis in principle.
[14:11] <ralsina> Depending on how long that takes we may try to create something else, but dbus is language agnostic
[14:11] <thisfred> alecu: I would like to take a little time this week somewhere to discuss what I need to know for next week, if anything
[14:11] <nessita> dobey: any idea why https://code.launchpad.net/~nataliabidart/ubuntu-sso-client/really-errback-on-error/+merge/45016 is not landing? it has commit message, proper approves
[14:12] <ralsina> Of course, that leaves windows outside of it, but I am sure mandel and I can find a solution that doesn't suck on that platform :-)
[14:12] <nessita> ralsina, alecu, thisfred: I think having the unity notifications in place is much more important for this cycle, so if there is any spare time we should dedicate it to that
[14:12] <alecu> thisfred, sure. Regarding the zg/aggregation stuff, right?
[14:12] <thisfred> right
[14:13] <dobey> nessita: it says merged
[14:13] <nessita> hum, right
[14:13] <nessita> dobey: your computer was turned off, right?
[14:13] <nessita> dobey: it merged when you boot your computer :-)
[14:14] <nessita> any other stand up comments?
[14:14] <ralsina> nessita: yes, notifications have time allotted, though.
[14:14] <alecu> nessita, by "unity notifications" you mean the stuff that appears on the "mail" icon on the indicator applet?
[14:14] <dobey> nessita: no, but my server apparently fell asleep this morning, so i guess it was merged after i woke it up so i could use the internets again
[14:15] <nessita> ralsina: yeah, thought I foresee some potential delays on that, so we should be prepared
[14:15] <ralsina> nessita: indeed.
[14:16] <ralsina> eom?
[14:16] <dobey> i really wish i knew why my server was going to sleep though
[14:16] <nessita> alecu: not really, I call "unity notifications" the thing we have to implement on unity for showing status and activity of Ubuntu One for natty. That covers making the Ubuntu One icon sping when necessary, and show messages on the messaging system
[14:16] <nessita> spin*
[14:16] <nessita> alecu: the Ubuntu One icon in the launcher, that is
[14:17] <nessita> ralsina: eom for me
[14:17] <alecu> we'll make it spin? puaj!
[14:17] <nessita> alecu: we talked about this on UDS...
[14:17] <nessita> "we all" agree :-)
[14:17] <dobey> ...
[14:18] <vds> CardinalFang dobey ralsina back to the APIs work, no work needed for 14 - 17 -21 so I have 11 - 13 - 15 - 16 left, anyone else decided what to pick?
[14:18] <alecu> nessita, I think I missed *that* session.
[14:18] <nessita> dobey: next request, could you please re-review https://code.launchpad.net/~nataliabidart/ubuntuone-client/auth/+merge/45116 ? it shouldn't take long and I can't land it even if someone else approves
[14:18] <ralsina> one last comment... desktopcouch is not released yet!
[14:18] <nessita> ralsina: really? where? what version?
[14:19] <ralsina> for natty
[14:19] <CardinalFang> vds, I added a column to the doc.
[14:19] <dobey> alecu: are you sure? it's the one where i consistently told everyone they were wrong
[14:19] <dobey> you know, i wish people would review *my* branches
[14:19] <ralsina> dobey: bug me, I will
[14:19] <nessita> dobey: shoot
[14:19] <nessita> alecu: you were there, also attended Chipaca, John Lea, a few more unity-experts
[14:19]  * ralsina will review anyone's branches, just ASK
[14:20] <vds> CardinalFang: thanks
[14:20] <dobey> https://code.edge.launchpad.net/~dobey/ubuntuone-client/fix-674876/+merge/43093
[14:20] <dobey> https://code.edge.launchpad.net/~dobey/libubuntuone/srcdir-signing/+merge/43668
[14:20] <dobey> https://code.edge.launchpad.net/~dobey/libubuntuone/python-srcdir/+merge/43830
[14:20] <dobey> https://code.edge.launchpad.net/~dobey/ubuntuone-client/fix-657850/+merge/43976
[14:20] <dobey> https://code.edge.launchpad.net/~dobey/ubuntuone-client/fix-657850-stable/+merge/43977
[14:20] <alecu> nessita, I missed one session, and I think it was that one.
[14:20] <dobey> https://code.edge.launchpad.net/~dobey/ubuntuone-client/fix-692566/+merge/44243
[14:20] <dobey> https://code.edge.launchpad.net/~dobey/rhythmbox-ubuntuone-music-store/fix-translations/+merge/44511
[14:20] <nessita> alecu: ouch
[14:21] <ralsina> dobey: maybe you should ask for reviews more often. I will try to get them all today ;-)
[14:21] <vds> CardinalFang: 22 will need some discussion probably, as we are storing subsonic style playlist and I have no idea what format other apps will use
[14:21] <nessita> dobey: https://code.edge.launchpad.net/~dobey/ubuntuone-client/fix-674876/+merge/43093 is not approved
[14:22] <nessita> dobey: is *now*
[14:23] <nessita> also is https://code.edge.launchpad.net/~dobey/ubuntuone-client/fix-657850/+merge/43976
[14:23] <ralsina> who was doing the natty upload of desktopcouch before the break?
[14:23] <dobey> ralsina: i thought CardinalFang was
[14:24] <ralsina> dobey: thanks.
[14:24] <dobey> but we are going to need another release/upload anyway :(
[14:24] <ralsina> CardinalFang: are you? That really needs to be done very soon
[14:24] <CardinalFang> ralsina, dobey, yes, I have a branch ready.  It depends on python-couchdb update, which has conflicts.
[14:24] <alecu> dobey, how should I test https://code.edge.launchpad.net/~dobey/rhythmbox-ubuntuone-music-store/fix-translations/+merge/44511 ?
[14:24] <CardinalFang> ralsina, I'm trying to get it done today.
[14:24] <ralsina> dobey: oh, right, the pairing bug?
[14:25] <ralsina> CardinalFang: cool
[14:25] <alecu> dobey, should I just open rhythmbox with a different locale?
[14:25] <ralsina> CardinalFang: keep me posted, please
[14:25] <dobey> alecu: install the plug-in and open it with spanish i guess
[14:25] <nessita> I need to run a quick errand, bbiab
[14:25] <dobey> ralsina: the "desktopcouch doesn't work at all" bug
[14:26] <dobey> i guess i need to file a bug about it, now that i understand more though
[14:26] <ralsina> dobey: how did you test to see if your fix worked?
[14:26] <ralsina> dobey: indeed that deserves a bug ;-)
[14:26] <dobey> ralsina: my fix works, but can't really test it because of the other problems
[14:27] <ralsina> dobey: ok
[14:27] <dobey> and i got tired of trying to fix all the other problems in my branch and not getting any further really, so i'm about to push up my fixes for the plug-in issues and propose that
[14:28] <dobey> just need to figure out how to override __import__ so i can make the unit test for load_plugins work
[14:28] <dobey> nessita: i'm pretty sure "constants" don't exist in python.
[14:29] <rye> dobey, hi, happy new year btw, but do you know why natty's ubuntuone-client is at 1.5.0-r777 while other releases have  1.5.1+r785 ?
[14:31] <dobey> rye: yes, because of the gir api versioning change to the package names that debian made. and i haven't figured out the best way to fix it yet
[14:31] <rye> dobey, is there a bug report about that so that i could mark my one as duplicate?
[14:32] <dobey> rye: i didn't file one. but i haven't kept up on the deluge of u1client bugs, and nobody has assigned one to me
[14:33] <rye> dobey, ok, i will assign that one then
[14:33] <dobey> ok
[14:34] <dobey> ralsina: do you know how to override __import__ for testing?
[14:34] <ralsina> dobey: no. But I can figure it out ;-)
[14:34] <ralsina> http://docs.python.org/library/imp.html#examples-imp
[14:35] <dobey> that would be great, because google was horribly unhelpful last night, and i havn't been able to make __import__ = fake_import work
[14:36] <dobey> i saw that, but i don't think that's an example for overriding __import__, but rather simply an example of how __import__ itself is implemented internally
[14:36] <dobey> ie: this is how you might use imp.find_module/load_module
[14:37] <ralsina> ok, let me try a couple of things. be back in 5'
[14:37] <dobey> i suppose i could change the code to just use the imp module instead and do all the harder work myself instead of doing __import__
[14:38] <dobey> i even tried doing FOO_IMPORT = __import__, and changing FOO_IMPORT in the test, to no avail :(
[14:38] <ralsina> weird, __import__ = whateverfunc works for me
[14:39] <ralsina> can you pastebin me a small example of it not working?
[14:40] <dobey> http://pastebin.ubuntu.com/550658/
[14:40] <dobey> with that, the _fake_import never gets called
[14:40] <dobey> nor does doing plugins.__import__ = _fake_import
[14:41] <Chipaca> dobey: __builtins__.__import__ = whateverfunc
[14:41] <kklimonda> dobey: try __builtins__.__import__
[14:41] <kklimonda> right
[14:41] <ralsina> That's because you are replacing __import__ in the local scope, not in the plugins module
[14:41] <dobey> ah
[14:41] <ralsina> Try plugins.__import__ = _fake_import
[14:42] <dobey> exceptions.AttributeError: 'dict' object has no attribute '__import__'
[14:42] <Chipaca> dobey: or if you want to be nice to the world, you could do module.__import__ and override it by injecting it into the right namespace :)
[14:42] <dobey> Chipaca, kklimonda: ^^ builtins gives that
[14:42] <Chipaca> dobey: but the latter needs more chumminess with the code you're testing, which might not be what you want
[14:42] <Chipaca> dobey: imp is a pain
[14:42] <dobey> and plugins.__import__ doesn't work either, same results as trying to just use __import__
[14:43] <ralsina> dobey: well, you *could* replace __import__ in __builtins__
[14:44] <ralsina> Just don't expect anything to work afterwards ;-)
[14:44] <dobey> *how*?
[14:44] <ralsina> __builtins__.__import__=_fake_import
[14:45] <ralsina> That's where the module is getting it from
[14:46] <dobey> i get the AttributeError with that
[14:46] <ralsina> oh, wait a second
[14:46] <kklimonda> dobey: it has to work - I did use it at some point ;)
[14:46] <ralsina> You got exceptions.AttributeError when doing plugins.__import__?
[14:47] <ralsina> Try desktopcouch.application.__import__ = _fake_import
[14:47] <dobey> no, when doing __builtins__.__import__
[14:47] <ralsina> dobey, what do you get with print __builtins__ ?
[14:47] <dobey> a big unreadable mess of a dict
[14:48] <ralsina> ok, I get a module :-)
[14:48] <ralsina> You can try __builtins__['__import__']=_fake_import
[14:48] <ralsina> But then I suppose it depends on the python version
[14:50] <dobey> yes, using the string works
[14:50] <kklimonda> dobey: what python version?
[14:50] <dobey> 2.7
[14:51] <kklimonda> weird, does this fail: http://pastebin.com/FBcrEpRm ?
[14:51] <nessita> dobey: what do you mean with "nessita: i'm pretty sure "constants" don't exist in python"?
[14:51] <kklimonda> a.py is just import sys
[14:51] <ralsina> dobey: that's really weird
[14:52] <ralsina> in any case, you can import __builtin__ and do __builtin__.__import__ = _fake_import
[14:53] <ralsina> Here's a full example of reimplementing __import__: http://www.etsimo.uniovi.es/python/dev/src/py/html/knee_8py-source.html
[14:53] <kklimonda> yeah, that's an even nicer (or rather less CPython-specific) way of abusing Python ;}
[14:53]  * nessita is back
[14:53] <ralsina> kklimonda: oh, I can abuse any version of python ;-)
[14:55] <kklimonda> heh ;)
[14:57] <dobey> nessita: i mean the language is dynamic, and there are no such things as actual constants
[14:57] <ralsina> karni: the APIs are not secret, I just got sidetracked :-)
[14:57] <karni> ralsina: ^ ^
[14:57] <nessita> dobey: so how would you do the APP_NAME deprecation thing?
[15:00] <dobey> nessita: one second, i'll pastebin
[15:00] <nessita> dobey: thanks
[15:08] <designduane> hello all
[15:08] <kklimonda> o/ designduane
[15:08] <designduane> Hey! it is kklimonda
[15:08] <designduane> :)
[15:08] <karni> hi duanedesign !
[15:08] <nessita> llohe designduane!
[15:09] <designduane> hey. I am not interupting a stand up or anything.
[15:09] <nessita> nopes
[15:09] <designduane> :) ok
[15:09] <designduane> I am on my *cough* Windows machine
[15:09] <kklimonda> it happens ;)
[15:10] <designduane> I tried to use Purtty
[15:10] <designduane> PuTTY
[15:11] <designduane> to log into my server running irssi. But forgot I had a ssh key set up.
[15:11] <alecu> dobey,  I'm reviewing lp:~dobey/libubuntuone/python-srcdir, and I'm getting this while trying to build trunk: http://pastebin.ubuntu.com/550670/
[15:12] <alecu> dobey, it complains that "No package 'libsyncdaemon-1.0' found", but I have 'libsyncdaemon-1.0-1' installed
[15:13] <kklimonda> alecu: do you have libsyncdaemon-dev ?
[15:13] <alecu> ahhh
[15:13] <kklimonda> or even libsyncdaemon-1.0-dev
[15:13] <alecu> thanks kklimonda
[15:13] <alecu> that was it.
[15:16] <dobey> nessita: http://pastebin.ubuntu.com/550676/
[15:17]  * nessita looks
[15:17] <ralsina> dobey do you have the URL for the API spreadsheet at hand? Can you mail it to me?
[15:17] <dobey> alecu: yeah you need the -dev. 'apt-get build-dep $project' with nightlies added
[15:20] <nessita> dobey: code looks good, though I don't see the gain of having that instead a global warning, since the deprecation warnings are printed the same
[15:21] <nessita> dobey: don't you think is better to have the global warning and import ubuntuone.credentials to fill the APP_NAME and related values?
[15:22] <dobey> nessita: because otherwise if i import something else, like say GETTEXT_PACKAGE, then i still get the warning, with your code. this way, the warning is only emitted when using those variables that are actually deprecated
[15:22] <nessita> dobey: according to my test, no...
[15:22] <nessita> dobey: if you import other constant, the deprecation warning is shown the same
[15:23] <nessita> dobey: to your code, I added a TEST = 'bla'  and run:
[15:23] <nessita> from <my faked sacript> import TEST
[15:23] <nessita> and all the deprecation warning appeared, which makes sense since python will read and interpret the whole clientdefs file
[15:24] <nessita> the deprecated is executed at import time, for each constant
[15:25] <kklimonda> you should make that into a decorator
[15:25] <nessita> kklimonda: wanna share a snippet? I gave it a try yesterday and failed :-)
[15:26] <kklimonda> nessita: hmm.. give me a sec :)
[15:26] <dobey> nessita: hrmm
[15:26] <nessita> and I still think this is too much trouble for the value gained in showing the deprecation code, since I'll be migrating all the APP_NAME clients anyways
[15:26] <dobey> nessita: oh, it seems python2.7 doesn't print deprecation warnings at all :(
[15:26] <nessita> deprecation warning*
[15:27] <nessita> dobey: that's in ubuntu, I think, there were hidden becasue... something
[15:27] <nessita> because*
[15:27] <dobey> bah
[15:27] <nessita> there was an email about it, I wish I knew where that is
[15:27] <dobey> well i'm not developing software on fedora
[15:28] <nessita> dobey: so, shall I remove the deprecation warning and leave a nice warning comment?
[15:28] <nessita> dobey: I'll be migrating the client anyways...
[15:29] <nessita> yes, known clients, but I don't think we have unknown clients
[15:29] <nessita> and if we had, API  will not be broken, so I think we can settle?
[15:31] <dobey> well, why not just break the API then?
[15:31] <nessita> dobey: because you hate breaking APIs, and I do too.
[15:31] <nessita> I don't think breaking APIs is a good idea.. see what happend with aptdaemon.defer
[15:32] <karni> CardinalFang: What's your opinion on direct sqlite db use in Android applications instead of using the ContentProvider itself? I know the ContentProvider is used to specifically expose data, but it also enables to make those inserts/queries in a more elegant way. However, it turns out it's relatively slow.
[15:32] <dobey> well, aptdaemon.defer was a bad idea, yes
[15:32] <karni> CardinalFang: Yesterday (didn't commit that yet) I optimized the initial sync by ~8x, using transactions and raw SQL
[15:32] <dobey> nessita: why not just 'break' it by removing the current variables and just importing them from credentials then
[15:33] <dobey> nessita: just add from ubuntuone.credentials import (...)
[15:33] <nessita> dobey: right, that was my proposal at (12:21:24 PM)
[15:33] <nessita> let's do that /me fixes
[15:34] <dobey> nessita: well i don't want the global warning
[15:34] <nessita> right\
[15:34] <nessita> I'll add a commnet
[15:34] <dobey> and i disagree with testing the script being impossibly hard
[15:35] <dobey> we were already doing it anyway
[15:35] <dobey> and i hate it when people put code only meant to be run by one script, into public python libraries
[15:36] <karni> nessita: aquarius: Is the files publishing API used by the desktop-client documented anywhere? (If it exists, I'd prefer that over source-as-docs)
[15:36] <nessita> dobey: that code can be used from some other places if needed. I can make a single module instead of a package, if that helps
[15:36] <dobey> nessita: the dbus service really should not be used directly from other places
[15:37] <nessita> dobey: the constants might, and we may add more func to that package
[15:37] <dobey> karni: i think the source is the only docs, but the source is pretty obvious if you know what to look at
[15:37] <karni> dobey: ack
[15:37] <dobey> nessita: i'm not saying ALL the code should be in the script
[15:37] <aquarius> karni, no, it isn't, yet. It will be.
[15:37] <dobey> nessita: the 'constants' should obviously be in a publicly importable library
[15:38]  * karni nods
[15:38] <nessita> karni: I think not, but you can take a look to the Dbus API which is very clear, IMHO
[15:38] <karni> ok, thanks all :)
[15:38] <dobey> nessita: but i think all the "only should be used by *our* script code" should be in the script itself (or alternatively in a private library, but that is a pain in python)
[15:38] <karni> *thanks everybody (that's more grammatically proper I think)
[15:39] <ralsina> dobey: if there's anything specific that you think should not be "public" that can be mangled, or we can use __all__ and hide it
[15:39] <dobey> karni: everyone would be more appropriate than everybody there
[15:39] <karni> dobey: thank you :)
[15:39] <karni> ok, gotta commute back home. later everyone
[15:40] <nessita> dobey: all that logic will not go into a script, because it makes the testing and reading of the code harder.
[15:40] <ralsina> In fact, I would like a policy of ALWAYS having __all__ defined so everything starts as hidden and only is shown when it's deemed useful
[15:40] <dobey> ralsina: i don't see how that helps us here
[15:40] <kklimonda> nessita: ah, you are trying to deprecate values, it won't work with decorators (and even if it did you would get the same result as with dobey's code - i.e. the warning would show up at the import time for all values that are "wrapped" in deprecate function)
[15:40] <nessita> kklimonda: right :-)
[15:41] <ralsina> dobey: I was talking about your generic "hate it when people put things in public libraries" (paraphrasing)
[15:41] <dobey> ralsina: right, but if we hide something, and it's not in __all__ how does that help us use the hidden things in our own scripts?
[15:41] <ralsina> dobey: then that has to be public
[15:42] <ralsina> the idea is that only "useful" stuff gets exposed, instead of relying on everyone not using everything that's in the module
[15:42] <dobey> ralsina: right, so __all__ is pretty much useless :)
[15:42] <ralsina> dobey: nope
[15:43] <ralsina> dobey: __all__ makes you expose things intentionally and not by accident. I am not saying it has anything to do with the specific current argument.
[15:43] <dobey> ralsina: so if DBusServer is hidden by not being in __all__, how do we use DBusServer in our script?
[15:43] <ralsina> dobey: read the above
[15:43] <dobey> right i know what __all__ does. i just think it's generally useless for us
[15:43] <dobey> since we're always using all our new code
[15:44] <kklimonda> nessita: it is still possible to do, but not that straightforward
[15:44] <dobey> there might be a few places where it's useful to hide a few globals
[15:44] <dobey> it would be better if it were __hidden__
[15:45] <dobey> so you only list the things you want hidden, which is probably a shorter list than the things you want public
[15:45] <nessita> dobey: we can't move the ubuntuone.credentials import to clientdefs since it will generate a circular import dependency, since ubuntuone.credentials import clientdefs to use the GETTEXT_PACKAGE value. I'll revert to the initial version of my branch, and propose a few more branches were clients of those values are migrated to new credentials module
[15:45] <ralsina> dobey: whatever, I am not being useful for the current problem.
[15:45] <dobey> nessita: ugh. right. :(
[15:46] <dobey> i guess that means my code would break too
[15:46] <dobey> bah
[15:46] <nessita> dobey: why?
[15:46] <dobey> nessita: because it imports the new values to return the proper value
[15:47] <kklimonda> nessita: you would have to create a proxy for the module - funny stuff, but if your approach work then there is no need to dig into that :)
[15:47] <dobey> meh, instead of fixing python 2.7, someone changed bzr to just hardcode python2.6 in the hashbang it seems :-/
[15:49] <CardinalFang> karni, One of my goals is to give Ubuntu One Publish as an option on file entries from other apps.
[15:50] <CardinalFang> karni, Hooking to the "Share with..." facility, and an Intent should do it, I think.  Do you foresee me hitting any problems?
[15:51] <nessita> dobey: change revert to client defs pushed to revno 784
[15:54] <dobey> ralsina: https://code.edge.launchpad.net/~dobey/desktopcouch/fix-696968/+merge/45252
[15:55] <ralsina> dobey: will test it in 15'
[15:58] <dobey> cool
[15:59] <dobey> i am going to need to put on warmer clothing if i'm going to go outside :-/
[16:03] <dobey> nessita: approved the auth branch, reluctantly; i still don't like the lack of separation of concerns there
[16:03] <nessita> dobey: would you prefer a single module instead of a python package?
[16:05] <dobey> i would prefer things that clients should be using, to not be in $PYTHONPATH
[16:05] <dobey> err, should not be
[16:05] <nessita> :-)
[16:06] <nessita> dobey: well, thanks for the approval
[16:06] <nessita> despite where that code lives is a very  good thing to have
[16:09] <nessita> dobey: so, there is one more thing I need your input in, and that is how to handle the "migration" preferences -> control panel. I have a packaging branch where the .desktop file is installed, and that desktop file is the same as the preferences. I want to avoid conflicts, and I'm not sure how to do that. Shall we release a new version of u1client without installing the .desktop file for preferences and make u1cp conflict with any previous version of u
[16:09] <dobey> is the .desktop file not in the source?
[16:10] <dobey> the desktop file should be a different filename
[16:10] <nessita> dobey: for the u1cp, the .desktop file is indeed in the source. It is a different filenam
[16:10] <nessita> but the both define the app for GNOME;GTK;Setting for Ubuntu One
[16:11] <dobey> right
[16:11] <nessita> dobey: wouldn't be a conflict when a .desktop file define the same as other .desktop file?
[16:11] <dobey> i guess the real question is how we handle the dependencies
[16:11] <nessita> not sure what you mean with that, but please say more
[16:12] <dobey> well, right now, the "sign up for ubuntuone" bit is a process somewhat contained in ubuntuone-client
[16:12] <dobey> but with ubuntuone-control-panel being a separate package, that's not true
[16:13] <nessita> I don't (yet?) see a problem
[16:14] <dobey> how do i change file sync preferences, without having the control panel installed?
[16:14] <nessita> dobey: well, the control panel will be installed
[16:14] <nessita> unless you explictely uninstall it
[16:15] <dobey> that does not answer the question
[16:15] <nessita> is the same question as 'how do i change file sync preferences, without having u1-client-gnome installed?'
[16:15] <ralsina> lunch break
[16:15] <dobey> it is uninstallable, so people *will* uninstall it
[16:15] <nessita> dobey: right, same for current approach. I still don't see a problem.
[16:16] <dobey> u1-client-gnome is not an entirely separate project
[16:16] <nessita> and?
[16:16] <dobey> i give up
[16:16] <nessita> we're talking packages here
[16:16] <dobey> no we're not
[16:16] <nessita> oh, sorry, I was
[16:17] <nessita> so, from a package point of view, what I'm concerned about is how the collision in providing the same Settings -> Ubuntu One feature by 2 different .desktop files can be handled
[16:17] <nessita> I think I can propose a branch in u1client packaging branch removing the install of the preferences .desktop file
[16:18] <nessita> and then propose the u1cp packaging branch?
[16:18] <nessita> and make that u1cp branch depend on the u1client's (new) version
[16:24] <dobey> my point was that packages are always going to be broken until the separation of concerns at the project level is fully understood
[16:25] <dobey> if you intend to remove stuff from u1client, i guess you should propose a branch to remove those things
[16:25] <dobey> and then go from there
[16:27] <nessita> ok then
[16:27] <nessita> dobey: do you have a planned u1client natty release?
[16:28] <dobey> no
[16:28] <dobey> 'when it is appropriate to do so'
[16:28] <dobey> but right now, i must get some lunch
[16:28] <dobey> bbiab
[16:30] <karni> CardinalFang: Not forseeing any problems. If volumeId+nodeId is the only data we need to use the publishing API, then the 'Share wit..' is a 20-30 minute work :) It's good that you're saying it now, we'd be duplicating some work (I had it planned, too). However -- first I need to implement the publishing part of the service (which I planned for 3-4 weeks from now, unless I shuffle the order of things)
[16:31] <karni> CardinalFang: How about the photo-sync you've been on some time ago?
[16:31] <karni> CardinalFang: I'm curious were you ended up when I blocked you with my work
[16:32] <CardinalFang> karni, I'll touch it again soon.  I think it's pretty much done, as it's small.
[16:32] <karni> CardinalFang: I'm curious how you tapped in. Was it the ACTION_MEDIA_SCANNER_FINISHED? What did you use?
[16:33] <CardinalFang> karni, no, just listened on a Cursor with a media Observer.
[16:35] <karni> CardinalFang: doesn't that assume an open db and open cursor? where you'd put it? (if you're busy now, it's ok. excuse my questions)
[16:35] <karni> I thought it was more of an async nature, or broadcast based or the like.
[16:36] <CardinalFang> karni, it's in a Service.  It's idle until the system starts the Observer when something changes.
[16:37] <CardinalFang> karni, a Cursor is in a Service.  The Service is idle until the system starts the Observer when something changes.
[16:37] <karni> CardinalFang: It it a Broadcast intercept? I'm sure you're aware that the Service doesn't actually run all the time (not even being idle).
[16:37] <karni> CardinalFang: Ok, excuse my curiosity. I'll let it be, we'll be in touch :)
[16:39] <CardinalFang> karni, it doesn't have to run all the time to get things in synch eventually.  Any change after a Cursor is Observer-ed will scan the media index.
[16:39] <karni> CardinalFang: Sounds great!
[16:42] <karni> CardinalFang: What's your opinion on direct sqlite db use in Android applications instead of using the ContentProvider itself? ContentProvider is used to specifically expose data to other apps, but it also enables to make those inserts/queries in a more elegant way. However, it turns out it's relatively slow, and not suitable for heavy db traffic (as opposed to direct access and raw SQL).
[16:43] <karni> CardinalFang: I'm asking to know beforehand if you'll have nothing against raw SQL in future commits :)
[16:43] <CardinalFang> karni, I have no opinion.  If you're accessing your own, then it's fine.  If you're accessing system DBs, then I say use ContentProvider.
[16:44] <karni> CardinalFang: Definitely our own. Ok, thanks.
[17:05]  * nessita -> lunch
[18:48] <karni> beuno-lunch: Bon apetit! | It's sometimes hard to come up with user-understandable error messages ("Failed to sync content meta" already sounds complicated, not to mention "Failed to sync volume meta" - volume? meta?) -- I'll just keep on coding, and we'll leave the strings for later brainstorming, is that ok? Maybe the design team will also have some comments on that.
[18:48] <beuno> wow
[18:48] <beuno> I haven't been eating for hours!
[18:49] <beuno> karni, yeah
[18:49] <beuno> I would just say "Something went wrong, please report this error"
[18:49] <beuno> or not report it
[18:49] <beuno> but more generic as a user-facing error
[18:49] <karni> beuno: right. is soo easy to forget about eating while coding/working
[18:49] <karni> hmm
[18:53] <karni> beuno: how about: Show a non-persistent notification 'Something went wrong.. subtitle: Please report this error', which after being tapped would take the user to an activity that would explain what happened, turn on Debug logging, and ask the user to send the logs next time?
[18:54] <karni> beuno: there might be some unexpected errors that happen really rarely - we could handle them the way I suggest here ↑
[18:55] <karni> for example, I don't expect to go something wrong with the sync - but if the servers or the protocol fails, the app should handle these problems gracefully, too.
[19:50] <beuno> karni, yeah, agred
[19:50] <karni> beuno: ack
[20:03] <kklimonda> karni: there shouldn't be "Please report this error" if you can't report it immediatelly, and only after you enable debug and recreate the error.
[20:04] <karni> kklimonda: yes, that makes sense. I'm thinking about it. We don't want everyone to have verbose debugging on.
[20:04] <karni> kklimonda: Got it. I think I know how to report the problem immediately :>
[20:05] <kklimonda> karni: I don't know - it could enable verbose debugging for the remainder of the session (or 10 minutes, or something like that) and display only "Something went wrong.." for the first time, and then if user generates another error it could display "Something went wrong.. would you like to report it?"
[20:05] <kklimonda> oh, cool
[20:06] <karni> kklimonda: Nevertheless, good idea!
[20:06] <karni> kklimonda: I recalled a neat idea I once saw
[20:08] <karni> kklimonda: Since I've got the Throwable that was thrown near the problem source, I could make a http GET/POST and contain the error/stack trace in the url params / the POST contents. We'd have to set up a server for that (it's a php few-liner), and we can collect even single throwables (if the user wishes to 'Report the problem.')
[20:09] <karni> This 'trick' is really neat. No need to enable anything or mail anything.
[20:10] <beuno> karni, we can do that on our servers
[20:10] <beuno> we already have the infrastructure for it
[20:10] <beuno> so we'll talk about it soon  :)
[20:10] <karni> beuno: great :) I'll definitely think about that :)
[20:10] <karni> beuno: ok! cool
[20:10] <beuno> this is what we call "oopses"
[20:11] <karni> beuno: aha =) !
[20:11] <karni> beuno: and the trick is to minimize the number of oops'es I imagine hahaha
[20:11] <beuno> exactly  :)
[21:32] <karni> I have to work on making smaller changes per commit..
[21:33] <dobey> everyone needs to do that :)
[21:37] <karni> dobey: I'm way over resonable limit of changes without a commit today. It's not a problem only because I'm working heavily on it on my own (yet!), but that'll probably change quite soon.
[21:38] <dobey> karni: i was in a similar situation yesterday. realized the additional problem was getting to be too big to fix in one branch, so cleaned up and got the original intent of the branch proposed, and filed a bug for the additional problems to fix in another branch or 3
[21:39] <karni> dobey: uhm, that's resonable approach
[21:39] <dobey> exactly :)
[21:40] <karni> :)
[21:42] <karni> dobey: oops.. bzr diff|wc -l returned 1798. I will definitely watch out for those lines-per-commit next time.
[21:43] <karni> it'd be impossible to review that if I was to propose a merge (I'll just push happily push to trunk, this time).
[21:44] <dobey> fewer lines == less likely to have error in review. i wouldn't say 1800 lines is impossible, but it is tedious, and software engineers get bored easily :)
[21:44] <karni> dobey: right =)!
[21:59] <karni> beuno: if you're still here - U1 has slowed down really, again. it's even similar hour. - what was the reason of the previous slowdown?
[22:00] <karni> hour = I meant time of the day
[22:01] <beuno> __lucio__, ping
[22:01] <beuno> ^
[22:01] <beuno> are things slow?
[22:02] <karni> instead of auth ~4-5s and ~7s sync from scratch, it's running over 2-3 minutes (I re-run it few times)
[22:04] <karni> oh, the download's slow, too. 27KB over wifi is quite often <2s, it's been 15+s maybe
[22:04] <karni> beuno: I'm not complaining, just wondering what slows down the whole thing from time to time.
[22:04] <karni> :)
[22:05] <beuno> yeah, we need to keep an eye out
[22:09] <kklimonda> bzr doesn't have something like git add -i?
[22:10] <kklimonda> it's the best thing since the sliced bread
[22:10] <kklimonda> (it makes it possible to select chunks of diff to be commited so you can split huge changes into small commits)
[22:12] <karni> kklimonda: aha. don't know really, i'm few months new to bzr, but I'll know it sooner or later, with my tendency to overdo the number of lines changed ;)
[22:13] <kklimonda> karni: that's why I'm asking - I haven't seen it so I assume that there is either some obscure option or plugin I can use :)
[22:13] <karni> :)
[22:13] <beuno> it does not
[22:13] <beuno> it has shelve
[22:13] <beuno> that allows you to hide changes
[22:14] <beuno> which you bring back after committing
[22:14] <beuno> also
[22:14] <beuno> I just commit all the crazy code
[22:14] <kklimonda> beuno: ah, it's like stash - not what I'm talking about :)
[22:14] <karni> right, that I saw in the manual ^ ^
[22:14] <beuno> I prefer keep an accurate history of what I did rather than lying!
[22:14] <karni> beuno: true :D hahahaha
[22:14]  * karni laughs laudly
[22:15] <kklimonda> beuno: I just hate commiting hundreds of changes with messages like "heh, big pile of changes - fixed bugs, added new features, closes bugs 1, 2, 3, [7-10] ;)
[22:15] <karni> kklimonda: :D that's what I'll have to do this time (my bad)
[22:15] <kklimonda> too much coding, not nearly enough self control ;)
[22:17] <karni> beuno: we're back on speed.
[22:17] <beuno> karni, I'll look at our graphs tomorrow, figure out if there's a cron job running at this time or not
[22:17] <karni> beuno: uhm :)
[22:17] <beuno> things seem stable in general, but maybe there's one db server being annoying
[22:18] <alecu> dobey, ping
[22:19] <karni> beuno: Please never tell me when you finish work at work days. I'll have an excuse to bother you any time of the day ;)
[22:19] <beuno> karni, I'm around 24/7
[22:19] <karni> 158KB in <2 seconds, now that's what I like!
[22:19] <beuno> \o\
[22:19] <karni> beuno: cool, I won't hesitate to write from time to time :)
[22:19] <beuno> (speed)
[22:19] <dobey> alecu: hi
[22:19] <karni> hahhahaha :D
[22:19] <karni> beuno: (cool !) \o\
[22:20] <alecu> dobey, hi! one question: where should I store settings for the u1-gnome-settings-plugin? gconf? some .ini?
[22:20] <alecu> dobey, I've been adding some code so the out of space dialog is not shown repeatedly, but I'd also like to add some way to turn it off.
[22:21] <alecu> dobey, I believe the nautilus plugin uses gconf, right?
[22:21] <dobey> settings?
[22:22] <dobey> i don't know if the nautilus extension has settings or not
[22:22] <dobey> there shouldn't be any reason for the gsd plug-in to have settings
[22:25] <alecu> dobey, I see that the nautilus has two settings, and that they are stored in gconf
[22:27] <alecu> dobey, for the gsd plugin, I want a way to turn off the "out of space" dialog completely.
[22:27] <alecu> dobey, because there's a bug in the way that "out of space" are being sent from the syncdaemon, and it'
[22:27] <alecu> it's being shown repeatedly.
[22:28] <dobey> the way to fix a bug is not to add a setting that is "[] hide the bug"
[22:29] <alecu> dobey, well, I agree it's not the way to go forward, but it's the quickest way to fix what's currently run by the users.
[22:29] <nessita> dobey: any idea what's wrong when making distcheck that I'm getting cp: cannot stat `./ubuntuone-icons.rendercache': No such file or directory?
[22:30] <dobey> alecu: it's probably not the quickest way to fix it. it's adding a feature, and we can't add new features to maverick :)
[22:31] <dobey> nessita: do you not have inkscape installed?
[22:31] <nessita> dobey: maybe... let's see
[22:31] <alecu> dobey, well, for that broad definition, every line of code is a feature :-)
[22:32] <nessita> dobey: is installed, Version: 0.48.0-1ubuntu2
[22:32] <dobey> alecu: adding new configuration is a new feature. i presume you're also adding new UI to be able to use the feature
[22:32] <alecu> dobey, I'm not adding any UI for this
[22:33] <dobey> nessita: hrmm, then not enough info.
[22:33] <alecu> dobey, this is only affecting a small number of users, so we can point them at gconf-editor when it nags them.
[22:33] <nessita> dobey: ok, thanks
[22:34] <dobey> alecu: if i's affecting a small number of users, and unimportant enough to have a solution that is "tell the users to upgrade, and then tweak some random setting in gconf-editor, which is not installed by default"; then i think it is appropriate to say it is not a high or critical bug, and we can take the little extra time to fix it properly
[22:35] <dobey> alecu: if the answer is to add code and tell people to just disable the extension, then i think a safe workaround is "sudo rm /usr/lib/gnome-settings-daemon-2.0/ubuntuone.gnome-settings-plugin"
[22:37] <alecu> dobey, but that would break if we release any update to the u1 client package, right?
[22:37] <alecu> dobey, I agree it's a nice workaround, tho.
[22:37] <alecu> ralsina, ping
[22:40] <dobey> alecu: hopefully an update to the package would include the proper fix
[22:42] <nessita> ok, I'm off
[22:42] <nessita> bye all!
[22:43] <dobey> me too


[16:54]  * wrst is amazed netritious is still with us :)
[18:32]  * cyberanger is suprised.
[18:32] <cyberanger> minasota: my home theatre runs on 12V so I think you'd prefer another one