[04:37] <nirazio> I am using Ubuntu 10.10 with all upgrades. Ubuntu One will sync files very good but it is not syncing the contacts or bookmarks...
[04:38] <nirazio> Can anybody help  me pls.
[04:41] <nirazio> Anyone???
=== spm` is now known as spm
[05:33] <intrader> Anyone, I am concerned about whether my ubuntu one information is safe from access by others.
[05:35] <nirazio> I am using Ubuntu 10.10 with all upgrades. Ubuntu One will sync files very good but it will not sync the contacts or bookmarks.
[05:38] <intrader> nirazio, I have only used it for files and for tomboy notes. Good luck with contacts and bookmarks - you may export the contacts and bookmarks to your ubuntuone folder - do this periodically and you should be safe.
[05:45] <nirazio> intrader: But it's not syncing
[05:50] <intrader> nirazio, what files?
[05:51] <nirazio> intrader: How to sync contacts and bookmarks???
[05:56] <nirazio> intrader: You there???
[06:12] <intrader> nirazio, sorry, I dis not see the session blinking. In your browser and mail tools export your bookmarks and contacts to a file under the ubuntu-one folder
[06:22] <intrader> nirazio, I have just tried it with thunderbird and firefox. I see the files in the second machine. I must go now.
[06:22] <nirazio> oke let me try
[07:18] <tparcina> I'm experiencing problems manifested in slow synchronisation.
[07:18] <tparcina> Yesterday I have create Ubuntu One account, and yesterday it was slow as well.
[07:19] <tparcina> Now, in few minutes, it has synced only few megabytes.
[08:20] <tparcina> Are there any problems with Ubuntu One servers? I ask this because what I'm experience now is extremely slow.
[08:31] <tparcina> rye: On ubuntuforums.org they are mentioning that you can help in troubleshooting this thing.
=== soren_ is now known as soren
[12:14] <nessita> mandel: ping
[12:16] <zyga> hi
[12:16] <zyga> u1sync daemon is totally ignoring upload cap on maverick
[12:17] <zyga> I measured this with iftop, there is no other traffic and the connection to amazon s3 is taking all of my upstream connection despite the limit set to 10KB (and confirmed in the config file)
[12:17] <zyga> there were bugs about this over and over on lp
[12:17] <zyga> should I report another one
[12:18] <zyga> with this setup u1 us totally useless as latency for everything else grows to >10s
[12:21] <nessita> zyga: hi! could you please report that in a new bug, adding as much info as you can?
[12:21] <nessita> zyga: once reported, share the bug # with me and I'll assign properly
[12:24] <duanedesign> nessita: i was searching, trying to see if there was a 'master' report for this  issue...
[12:28] <nessita> duanedesign: there might be, but I'm not aware of any. Did you find anything?
[12:30] <zyga> nessita, sure, just a sec
[12:31] <duanedesign> nessita: I did not find one. I did find two reports that are similar FWIW. bug #600832 bug #460031
[12:32] <ubot4> Launchpad bug 600832 in ubuntuone-client "Bandwidth limit not taken into account (affects: 3) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/600832
[12:32] <ubot4> Launchpad bug 460031 in ubuntuone-client (Ubuntu) "sync slows down internet connection (affects: 4) (heat: 17)" [Medium,Triaged] https://launchpad.net/bugs/460031
[12:32] <nessita> duanedesign: thanks, I'll point those to the foundations team
[12:33] <zyga> nessita, new bug or attach extra info to one ot them
[12:34] <nessita> zyga: attach new info to the first one, please
[12:34] <nessita> to bug 600832
[12:34] <ubot4> Launchpad bug 600832 in ubuntuone-client "Bandwidth limit not taken into account (affects: 3) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/600832
[12:37] <zyga> funny, the cap is not respected so I cannot launch ubuntuone-preferenses without getting timeouts
[12:38] <zyga> I wanted to include a screen shot
[12:43] <nessita> zyga: no worries about the screenshot, just paste the contents of ~/.config/ubuntuone/syncdaemon.conf
[12:47] <zyga> nessita, done, please have a look and tell me if I should add anything else
[12:47] <nessita> ok
[12:48] <zyga> nessita, I also reported #690145
[12:49] <nessita> zyga: the limit BW comment is ok, did you subscribed to the bug?
[12:50] <nessita> zyga: thanks for the other report
[12:52] <zyga> nessita, thanks, I just subscribed
[13:30] <nessita> mandel: ping?
[13:37] <mandel> nessita: pong
[13:40] <mandel> nessita: I was having lunch and walking the dog, you were looking for me?
[13:41] <nessita> mandel: yes!
[13:41] <nessita> mandel: ralsina told me that you gave your +1 to leaving the pairing code for u1 in the dc source tree. I was wondering if you can confirm that the relevant code will be executed proprely, since yesterday thisfred couldn't tell for sure
[13:42] <mandel> nessita: what do you mean, if the code will work as expected? Or if we can write a module to do that?
[13:43] <mandel> nessita: If it is the first question, yes I see no issue with that code, we simply have to add it in desktopcouch.application.service and update the tests to ensure that occurs.
[13:44] <mandel> nessita: if it the second, create an extra package to add the extension and leave it in our source tree, yes I see no problem, I can do that for you, no need to test the current setup, we just need to add an extension point like setuptools does
[13:44] <nessita> mandel: the second thing you said
[13:44] <nessita> mandel: now is the first :-D
[13:45] <mandel> nessita: the code, as it is, has no issues, yet we need to create the setup.py for the extension, we can mumble about it if you want? :P
[13:45] <nessita> mandel: my worries is that the code us not currently executed by anything, right?
[13:46] <mandel> nessita: indeed, it is not, if is very urgent I can get a branch for you after the stand up
[13:46] <nessita> mandel: will thisfred know what to do? I know you're very busy
[13:46] <nessita> mandel: can you coordinate with eric? so you can guide him but not use your slot
[13:47] <mandel> nessita: he should know, but do not worry, is a small script :)
[13:47] <mandel> nessita: ok, I'll speak with thisfred then :)
[13:48] <mandel> nessita: I'll move this to the #desktopcouch channel, since you are there an is a more appropiate place for it :)
[13:48] <thisfred> nessita: mandel: I don't know that I'm the best person to do this: I'm also pretty busy or at least I'm trying to be but keep getting distracted :)
[13:48] <thisfred> kk
[13:48] <nessita> thisfred: oops, I didn't know you were pretty busy
[13:49] <thisfred> well everyone is, I'm guessing, as always ;)
[13:51] <ralsina> Everyone, standup in 7 minutes!
[13:58] <ralsina> alecu, dobey, thisfred, mandel, nessita standup in 1 minute
[14:00] <ralsina> standup, who's first?
[14:00] <nessita> ralsina: we define the order saying 'me'
[14:00] <nessita> ralsina: you can go first! :-)
[14:00] <ralsina> right
[14:00] <ralsina> me
[14:00] <nessita> me
[14:00] <mandel> me
[14:00] <alecu> me
[14:01] <ralsina> ping thisfred dobey
[14:01] <thisfred> me
[14:01] <ralsina> Ok, I'll start
[14:02] <ralsina> DONE: got my new notebook :-) organizing natty packaging, reading MORE code
[14:02] <ralsina> TODO: start setting up development environment today (will need help with that)
[14:02] <ralsina> BLOCKED: no
[14:02] <ralsina> nessita?
[14:02] <nessita> DONE: started work on bugs 689646, 674459, 683619. Made a couple of reviews. Answered thousands of pings. Talk about bug 689772. Bug triage.
[14:02] <nessita> TODO: bug 689646, bug 674459, bug 683619. Really good talk with the boss.
[14:02] <nessita> BLOCKED: nopes
[14:02] <nessita> NEXT: mandel
[14:02] <mandel> DONE: Integration tests, python COM code for IPC.
[14:02] <ubot4> Launchpad bug 689646 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "Allow subscribe/unsubscribe from UDF list (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/689646
[14:02] <ubot4> Launchpad bug 674459 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "After machine adding, show folders tab (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/674459
[14:02] <ubot4> Launchpad bug 683619 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "Unify booleans coming and going from dbus (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/683619
[14:02] <ubot4> Launchpad bug 689772 in desktopcouch "Desktopcouch and Ubuntu One pairing is missing (affects: 2) (dups: 1) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/689772
[14:02] <mandel> TODO: create a branch so that we have a beta2 branch that uses SD, currently everything is in my machine (bad mandel!) Add extension point to desktopcouch to create the pairing with U1 using SSO. Talk with CardinalFang, I need to learn how to create package correctly (about time!)
[14:02] <mandel> BLOCKED: no, but I request 30 hours days!!!!
[14:03]  * mandel does a drop kick and gets 3 points, next is alecu!
[14:03] <alecu> DONE: started playing with mozmill for bindwood. Platform sprint administrativia. Got zg branch approved, but it won't merge yet
[14:03] <alecu> TODO: bindwood
[14:03] <alecu> BLOCKED: according to Marianna, there's no room in the sprint hotel
[14:03] <alecu> next: thisfred
[14:03] <thisfred> DONE: discussion/review with JamesTait and teknico about contacts sync in u1 | discussion of where u1 desktopcouch pairing should live | more bindwood digging (finally getting a grip on it) TODO: help mandel package u1 pairing | finish contacts sync review | start coding in bindwood BLOCKED: no
[14:04] <nessita> alecu: why your branch will not merge?
[14:04] <alecu> nessita, otto says: "There are additional revisions which have not been approved in review. Please seek review and approval of these new revisions."
[14:05] <ralsina> alecu: are those big changes or just cosmetic?
[14:05] <alecu> nessita, then I set the branch to approved again, and it tried to, but it failed with an encoding problem
[14:05] <nessita> alecu: re approve the branch your self, and that should be it
[14:05] <nessita> ah
[14:05] <nessita> :-/
[14:05] <nessita> alecu: try asking in #chicharra
[14:05] <nessita> any other comments?
[14:05] <alecu> after that, I fixed it. It was only missing an .encode(...)
[14:05] <alecu> and then otto won't merge it again.
[14:06] <nessita> alecu: set it to approve again
[14:06] <alecu> nessita, yes, it's set to approve
[14:06] <alecu> look:
[14:06] <alecu> https://code.launchpad.net/~alecu/ubuntuone-client/ziggy-for-filesync/+merge/43495
[14:07] <ralsina> Any more comments about the standup?
[14:07] <nessita> not here
[14:07] <nessita> alecu: talk to dobey...
[14:08] <ralsina> dobey: right on time, you're next :-)
[14:08] <dobey> eh, i don't know that i would call "x crashing and server going to sleep" "right on time" :-/
[14:09] <dobey> λ DONE: 688184, 689800, 689851, backports research
[14:09] <dobey> λ TODO: 683351, backports
[14:09] <dobey> λ BLCK: None.
[14:09] <ralsina> ok, one comment from me: please pay attention to the incoming bugs queue and take the ones you own
[14:10] <ralsina> I can't do good triage yet, so I need to rely on you people.
[14:10] <ralsina> Unless you want me to start assigning them randomly just for giggles.
[14:10]  * nessita shouts no no!
[14:10] <dobey> i can write a bot to do that
[14:10] <dobey> then at least i'll get all the karma
[14:11]  * ralsina admires dobey's initiative
[14:11] <ralsina> So, take a few minutes each morning/evening and take a look.
[14:11] <ralsina> Any other comments?
[14:12] <ralsina> eom
[14:12] <nessita> ralsina: thanks!
[14:12] <dobey> i wish i knew how to get useful info from these crashes
[14:13] <ralsina> dobey: it seems the only branch we need to wait is alecu's, at least I asked everyone I could think of :-)
[14:13] <dobey> because afaict, it all just goes into a black hole
[14:13] <ralsina> dobey: faulty hardware?
[14:13] <dobey> i doubt it
[14:14] <dobey> but i suppose it's a possibility
[14:14] <alecu> dobey, I have a u1-client branch that just won't merge: https://code.launchpad.net/~alecu/ubuntuone-client/ziggy-for-filesync/+merge/43495
[14:15] <alecu> dobey, first otto complained about missing reviews, then I set the branch to approved, then one test failed, then I fixed and set it again to approved, but now it won't merge.
[14:15] <alecu> dobey, and otto is silent
[14:15] <alecu> dobey, should I get both reviewers to rubberstamp it again?
[14:16] <ralsina> add a dummy change
[14:16] <dobey> no
[14:16] <dobey> let me see what is actually wrong
[14:17] <dobey> sigh, something is still failing, but it's causing Python to break:
[14:17] <dobey> 2010-12-14 09:15:33 ERROR    An error occurred trying to merge lp:ubuntuone-client: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)
[14:18] <Chipaca> utf8 in the commit message?
[14:18] <ralsina> Ugh
[14:18] <dobey> Chipaca: no, probably something using smartquotes when it shouldn't be
[14:19] <Chipaca> why would that block the merge?
[14:20] <dobey> because the tests failed, and when tarmac tries to combine stdout/stderr into a string and post it as a comment, Python says no, and causes tarmac itself to exit
[14:20] <Chipaca> ah, ok
[14:22] <alecu> dobey, I find that pasting all the stdout/stderr logs make the bug page extremely large. Would it be possible to have them attached as a text file to the bug?
[14:22]  * alecu brbs
[14:22] <dobey> alecu: it's not the bug, it's the merge, and merges don't have attachments, no
[14:23] <dobey> i wish they did though
[14:25] <dobey> hmm
[14:26] <dobey> well stuff passed
[14:26] <dobey> so wtf broke
[14:26] <alecu> dobey, oh, right. Didn't realize that merges didn't have attach, sorry.
[14:28] <alecu> dobey, the tests run fine locally, both for me and reviewers
[14:28] <alecu> dobey, it seems that the default encoding is set differently on the server that's running tarmac
[14:28] <dobey> no, it's not
[14:29] <dobey> the machine running tarmac in this case is running narwhal
[14:29] <dobey> and in fact, python is still defaulting to 2.6.6
[14:29] <dobey> and tarmac is being run with LANG=C LC_ALL=C
[14:30] <dobey> wtf
[14:30] <alecu> dobey, that's the issue. I have LANG=en_US.utf8
[14:30] <dobey> no it's not the issue
[14:31] <dobey> setting the locale to C is required to keep gcc from printing smartquotes
[14:31] <dobey> but i did just find this: http://pastebin.ubuntu.com/543615/
[14:31] <dobey> that should clearly have failed there
[14:32] <alecu> but it's failing with "exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xf1' in position 163: ordinal not in range(128)"
[14:32] <dobey> yes
[14:32] <dobey> setting the system language to en_US.UTF-8 won't fix that
[14:33] <alecu> dobey, I guess it does.
[14:33] <dobey> no, it doesn't
[14:34] <alecu> dobey, yes, it does because of: sys.getfilesystemencoding()
[14:34] <dobey> you're assuming it does because the tests passed on your system.
[14:34] <dobey> alecu: that has nothing to do with encoding/decoding strings to/from unicode in python
[14:35] <dobey> filesystem != strings
[14:35] <alecu> dobey, it does when you are encoding unicode strings into the bytes that the filesystem uses as filenames
[14:35] <thisfred> nessita: libubuntuone1.0.cil fails to install on natty for me:
[14:35] <nessita> thisfred: yes, I've seen tons of reports
[14:35] <alecu> dobey, the one that failed is os.lstat(path)
[14:35] <dobey> alecu: no, you are simply making assumptions that you somehow know what the problem is, and you don't
[14:36] <nessita> thisfred: rodrigo is assigned, but he's on holiday
[14:36] <thisfred> ah ok, never mind me then
[14:36] <thisfred> as long as we know about it
[14:36] <dobey> thisfred: fails to install why?
[14:36] <alecu> dobey, os.lstat(path) is receiving a unicode string, and it's using sys.getfilesystemencoding to turn it into a filename in bytes.
[14:36] <nessita> thisfred: https://bugs.launchpad.net/ubuntu/+source/libubuntuone?field.searchtext=&orderby=-datecreated
[14:36] <dobey> alecu: where are you even getting that information from?
[14:37] <thisfred> dobey: subprocess installed post-installation script returned error exit status 9
[14:37] <alecu> dobey, https://pastebin.canonical.com/40942/
[14:38] <dobey> alecu: that is a different problem.
[14:40] <dobey> alecu: and you fixed that; there is a different problem now
[14:44] <dobey> and i'm trying to figure out what it is, but my system load is going nuts now
[15:09] <dobey> ok i see the problem
[15:09] <hallyn_> hm, my ubuntu one files (updated daily) haven't been updated since dec 2.
[15:10] <hallyn_> that's gonna make it tough to switch between laptops
[15:10] <dobey> alecu: it's because you were creating a file on disk in the test, that wasn't valid ascii, and the test didn't remove it after creating it, so the clean-up after running tests was failing because bzrlib couldn't encode the path
[15:11] <alecu> dobey, cool, thanks a lot for finding that.
=== zyga is now known as zyga-food
[15:12] <alecu> dobey, how should we fix this? should we fix the tests or bzrlib?
[15:12] <alecu> or both?
[15:12] <dobey> alecu: so i'm working around it by doing make clean after the make check
[15:12] <alecu> nice, thanks.
[15:12] <alecu> You are doing that in the tarmac config, right_
[15:12] <alecu> ?
[15:12] <dobey> well there isn't anything to fix in tarmac or bzrlib in that case. the tests should remove files they create on disk, though
[15:13] <dobey> yes
[15:34] <nessita> hallyn_: hi there. Can you please run in a terminal 'u1sdtool -s' and paste the output in ubuntu.pastebin.com?
[15:36] <hallyn_> nessita: sorry, i can't - i've deleted all the machine entries for now.  will manually rsync, then retry later
[15:37] <nessita> hallyn_: ok then
[15:37] <hallyn_> nessita: my one.ubuntu.com/account machines listing listed lots of entries for each laptop for some reason
[15:37] <hallyn_> now i'm pretty sure it had one for files and one for notes, not sure if it was suppsoed to
[15:38] <nessita> hallyn_: you should have only one token per machine, but due to bug #687523 the tokens are being duplicated. So at most 2 tokens per machine
[15:38] <ubot4> Launchpad bug 687523 in ubuntu-sso-client (and 1 other project) "SSO service creates two tokens for one request (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/687523
[15:39] <nessita> hallyn_: if you remove tokens from the website, please be sure to remove your tokens locally on seahorse, otherwise syncdaemon will not be able to authenticate against the server
[15:40] <hallyn_> nessita: thanks, will do.  and i guess is hould go look at https://launchpad.net/bugs/687523 to see if i was suppsoed to work around it :)
[15:40] <ubot4> Launchpad bug 687523 in ubuntu-sso-client (and 1 other project) "SSO service creates two tokens for one request (affects: 1) (heat: 6)" [High,Confirmed]
[15:40] <nessita> hallyn_: no current workaround for now :-/
[15:40] <hallyn_> nessita: and does it prevent syncing after that?
[15:41] <nessita> hallyn_: not at all, syncdaemon works just fine
[15:41] <nessita> hallyn_: your syncdaemon is probably not connected to the server
[15:41] <nessita> that's why is not synching. To debug, I'd need either your logs or the output of the command I mentioned
[15:43] <hallyn_> nessita: i'm pretty sure i had done a bunch of 'u1sdtool -c's over the past 2 weeks...  but no sense speculating without evidence
[15:43] <nessita> hallyn_: right. IN that case, we definitely need your logs, those are located at ~/.cache/ubuntuone/log
[15:44] <hallyn_> nessita: i'll try to get those tomorrow.  thanks.
[15:44] <nessita> you're welcome!
=== ralsina is now known as ralsina-lunch
=== ralsina-lunch is now known as ralsina
=== beuno is now known as beuno-lunch
[16:12]  * ralsina is installing ubuntu ;-)
[16:22] <dobey> ralsina: got the new hardware early?
[16:22] <nessita> dobey: ping
[16:23] <ralsina> got it 2 hours ago :-)
[16:23] <nessita> dobey: http://pastebin.ubuntu.com/543673/ <- ZG should not be a dependency for u1client, but a recommends
[16:24] <dobey> uhm
[16:24] <dobey> what version of python-ubuntuone-client?
[16:24] <nessita> nightlies
[16:25] <dobey> specific please
[16:25] <nessita> Version: 1.5.0+r773~maverick1
[16:25] <nessita> updated this morning
[16:27] <dobey> ok, next builds will be fixed
[16:27] <alecu> dobey, any news on the branch that won't merge? is there any way I can help?
[16:29] <dobey> alecu: i guess the make clean wasn't enough. i wonder why _trial_temp isn't getting removed
[16:30] <nessita> dobey: thanks!
[16:30] <dobey> alecu: anyway, will look at again in a second, as soon as i file this bug for libu1 and push/propose the branch to fix it :)
[16:30] <alecu> cool, thanks.
=== rajul_ is now known as rapha
=== rapha is now known as rajul
[16:42] <dobey> nessita: btw, just proposed https://code.edge.launchpad.net/~dobey/libubuntuone/srcdir-signing/+merge/43668
=== zyga-food is now known as zyga-waiting-for
[16:56] <dobey> alecu: ok, i'm going to go grab some lunch. trying something, and will see what happens with it as soon as i return.
[16:56] <nessita> dobey: does that fix all the reports thisfred mentioned?
[16:56] <thisfred> all the reports? I only said it didn't install for me :)
[16:56] <dobey> nessita: the postinstall issue has already been fixed in the packages with a much simpler band-aid
[16:57] <dobey> nessita: this fixes it in a more robust manner though, and adds a test to ensure it doesn't break again :)
[16:57] <nessita> thisfred: "all the reports I mentioned to thisfred when he detected the problem"
[16:57] <nessita> dobey: very good, how can I test it?
[17:00] <dobey> nessita: to see it fail in trunk, you can i suppose do "mkdir foo && cd foo && ../autogen.sh --enable-debug && make && sn -T bindings/mono/ubuntuone-sharp.dll"
[17:00] <dobey> nessita: that should print out info about the assembly when done, but should not have the "Public Key Token:" bit in it
[17:00] <dobey> nessita: doing the same in my branch, you should see the "Public Key Token:"
[17:01] <nessita> ack
[17:01] <dobey> ok, must get some food, bbiab
=== beuno-lunch is now known as beuno
[17:34] <nessita> dobey: I can't run that command since, inside foo, I'm getting:
[17:34] <nessita> /bin/bash: ubuntuone/clientdefs.py: No such file or directory
[17:46] <dobey> nessita: in libubuntuone?
[17:47] <nessita> dobey: nopes, you told me to: cd foo && ../autogen.sh --enable-debug && make
[17:47] <dobey> nessita: yes, you're doing that with lp:libubuntuone right?
[17:48] <nessita> nopes, in u1client. I see the problem now :-)
[17:48] <dobey> :)
[17:51] <nessita> dobey: I have room in my hard disk now, which was it the command to install all the deps for libu1?
[17:53] <dobey> nessita: apt-get build-dep libubuntuone
[17:54]  * nessita installs
[17:55] <nessita> dobey: look!
[17:55] <nessita>   File "/usr/lib/pymodules/python2.6/ubuntuone/devtools/services/dbus.py", line 78, in start_service
[17:55] <nessita>     self.dbus_pid = int("".join(sp.stderr.readlines()).strip())
[17:55] <nessita> ValueError: invalid literal for int() with base 10: 'Failed to start message bus: Abstract socket name too long'
[17:55] <nessita> dobey: attempting to run the test suite for control panel in a directory called /home/nessita/canonical/ubuntuone/control-panel/show-folders-after-computer-added
[17:57] <dobey> nessita: make your branch name shorter
[17:58] <nessita> -.-
[17:58] <dobey> nessita: classic unix sockets path length issue
[17:58]  * nessita renames
[17:59] <nessita> argh a sym link will not fix the issue!
[18:00] <dobey> no it won't
[18:12] <alecu> ralsina, the zeitgeist branch-o'-doom has landed on u1-client
[18:14] <ralsina> alecu: awesome
[18:14] <ralsina> next time try something new, like files with umlauts in the names or something ;-)
[18:22] <alecu> nessita, "Dbus booleans are now those strings whose bool() defines its value. So, '' for False and any other non empty string for True"
[18:22] <alecu> nessita, that looks *very* pythonic. And that's not good for a dbus api :-)
[18:23] <nessita> alecu: that's the same convention that syncdaemon has. I think is good that we follow that convention.
[18:23] <alecu> nessita, ok, sounds reasonable.
=== alecu is now known as alecu-lunch
[18:24] <nessita> alecu: I updated the google doc, and will add it to the soon to come official doc
=== kklimonda1 is now known as kklimonda
=== kklimonda is now known as Guest60816
[18:30] <nessita> dobey: still can't finish the make run: http://pastebin.ubuntu.com/543732/
=== Guest60816 is now known as kklimonda
[18:32] <dobey> nessita: hrmm. i guess there's a similar issue with the python bindings too
[18:32] <nessita> that's trunk, FYI
[18:33] <dobey> right
[18:33] <dobey> nessita: can you file a bug for that too?
[18:33] <nessita> dobey: sure
[18:34] <nessita> dobey: in the project or in the package tracker?
[18:34] <dobey> project
[18:37] <nessita> dobey: bug 690291
[18:37] <ubot4> Launchpad bug 690291 in libubuntuone "No such file or directory: 'ubuntuone.override' when building sourcecode (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/690291
[18:38] <nessita> dobey: can I tets your branch using some other procedure?
[18:40] <dobey> nessita: i suppose you could move the mono.snk file out of the way temporarily, and just run make check there
[18:46] <nessita> dobey: can you please be more specific?
[18:46] <nessita> I'm not familiar with this code
[18:48] <dobey> nessita: bindings/mono/mono.snk is the key used to sign the resulting .dll
[18:49] <dobey> nessita: if it's not there i think it should just not sign the dll, and then the check i added should fail since it's not signed
[18:49] <nessita> trying that
[18:49] <nessita> dobey: on trunk I'm getting:
[18:49] <nessita> error CS1548: Error during assembly signing. The specified file `mono.snk' does not exist
[18:50] <nessita> in red!
[18:50] <dobey> ok
[18:50] <nessita> so, I thought your branch added that check, but seems like is already there?
[18:51] <dobey> no, that's the compiler failing
[18:51] <dobey> but yes, i don't know why it would have failed in the package building
[18:51] <dobey> since if the file isn't there, it should fail in that manner
[18:53] <dobey> ah
[18:53] <dobey> because AssemblyInfo.cs was not compiled in
[18:54] <dobey> nessita: so if you add the configure.ac bit, and the check: rule i added from my branch, to trunk, make distcheck will fail because the file is not signed
[18:54] <dobey> and the rest of the changes in my branch fix that failure
[18:57] <nessita> I guess at this point I will trust you, I need to get back to my tasks. The diff makes sense, you I'm approving
[18:57] <dobey> ok, thanks
[18:59] <nessita> dobey: did you mark all the dupes as such?
[19:01] <dobey> for the packaging bugs? no
[19:01] <nessita> can you, please?
[19:02] <dobey> was planning to, when i'm not doing a million other things at the same time :)
[19:02] <nessita> sure, when you find a moment
[19:02] <nessita> I just want to drop that from my cache :-D
=== teknico is now known as teknico_away
=== alecu-lunch is now known as alecu
[19:27] <dobey> done i think
[19:27] <dobey> at lesat, unless anyone is in the process of reporting it again at the moment
=== zyga-waiting-for is now known as zyga
=== teknico is now known as teknico_away
[20:40] <ralsina> ok, that's it for me today. Have a nice evening everyone.
[20:50] <thisfred> bb in an hour or so, dentist's appt
[20:50] <nessita> thisfred: good luck
[20:50] <thisfred> thx
[20:51] <thisfred> btw I can't get to irc.canonical.com somehow, probably comcast dns screwing up again...
[22:01]  * nessita is leaving
[22:01] <nessita> bye all!
[22:27] <jderose> CardinalFang: thisfred: sil: is there anything sensitive in replication log? is it safe to attach log to bug?
[22:35] <thisfred> jderose: depends: the secrets are blacked out, but sometimes names or even contents of records shows up in case of failures, which may or may not be sensitive
[22:36] <jderose> thisfred: hmm, i guess i do have contacts in u1.... i'll find the bits related to the DB in question (which doesn't have anything sensitive)
[22:40] <jderose> thisfred: how about the paired_server record from management?  is the pairing_identifier sensitive?  if not, I'll paste that in too
[22:42] <thisfred> no not sensitive, it's just a uuid to prevent collisions
[22:46] <jderose> thisfred: CardinalFang: bug report - https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/690406
[22:46] <ubot4> Launchpad bug 690406 in desktopcouch (Ubuntu) ""dmedia" in exclude_names but old records synced back from UbuntuOne (affects: 1) (heat: 6)" [Undecided,New]
[22:46] <thisfred> jderose thx
[22:46]  * jderose gets logs to attach
[23:01] <jderose> thisfred: not exactly sure what i'm looking for in desktop-couch-replication.log, but as best I can tell, it's replicating "dmedia" despite being in excluded_names:
[23:01] <jderose> 2010-12-12 00:04:56,914 DEBUG    want to replipull 'dmedia' from static host '40f6173e-75ae-41d4-9bbe-05ecd24f9600' @ couchdb.one.ubuntu.com
[23:02] <thisfred> yeah, that's definitely a replication attempt
=== thisfred is now known as thisfred_