[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???
[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.
[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.
[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!
[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.
[16:42] <dobey> nessita: btw, just proposed https://code.edge.launchpad.net/~dobey/libubuntuone/srcdir-signing/+merge/43668
[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
[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.
[18:24] <nessita> alecu: I updated the google doc, and will add it to the soon to come official doc
[18:30] <nessita> dobey: still can't finish the make run: http://pastebin.ubuntu.com/543732/
[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
[19:27] <dobey> done i think
[19:27] <dobey> at lesat, unless anyone is in the process of reporting it again at the moment
[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


[00:03] <RAOF> czajkowski: Could you please run “apport-collect 605041”?    Subject consistency is for the weak.
[00:52] <RAOF> Woot!  Only one segfault to go.
[01:14]  * Milos_SD-aWay is Away, Reason: ( Spavam ... ) | Since: ( Monday August 16 2010. 22:13:47 ) Xlack v2.1
[01:16]  * Milos_SD-aWay is back ( Away 1 min 52 secs )
[02:18] <era> bryceh, what is gevdev in relation to evdev?
[02:18] <RAOF> era: It's evdev + a gesture-creation patch.
[02:19] <era> oooh
[02:19] <era> utouch?
[02:19] <RAOF> It's basically a temporary, fairly small fork of evdev.
[02:19] <RAOF> Yeah.  utouch.
[02:19] <era> on a somewhat related matter, how do i install synaptic gestures?
[02:22] <RAOF> I'm not sure what you mean - do you mean the two-finger scroll, three finger middle-click type things?
[02:23] <RAOF> That should Just Work™, although there seems to have been some problems with devices getting mis-identified.
[03:57] <Sarvatt> darn, got my hopes up synaptics actually released the linux gesture suite to the public but nope!
[03:58] <Sarvatt> maybe if i dig through the dell support site i can find it
[04:05] <Sarvatt> darn, HP is the only OEM I can find shipping synaptics drivers with SGS enabled, no chance at getting a linux driver out of them :D
[06:18] <tjaalton> RAOF: I already asked to run 'ubuntu-bug' (the same thing, right?) but it didn't collect anything, which is weird
[06:18] <tjaalton> he's also using some custom kernel
[06:21] <RAOF> tjaalton: Aah.  It might be due to the lack of a source package hook for xorg-server, referenced in xorg (1:7.5+6ubuntu3)'s changelog.
[07:17] <knittl> hi. is nvidia-current currently abi-incompatible with xserver? :(
[07:18] <knittl> Xorg.0.log tells me something about -ignoreabi to override, how can i do that? as of now, boot hangs after splash and my pc does nothing
[07:20] <gord> knittl, add a section in your xorg.conf called "ServerFlags" then put Option "IgnoreABI" "true" inside that section
[07:21] <knittl> gord: ok, i'll try. thanks
[07:25] <knittl> gord: thanks a lot, it's booting again
[07:26] <gord> knittl, np
[07:27] <knittl> uh oh. i shouldn't use 3d applications though
[07:27] <knittl> totally crashes xserver
[07:28] <era> raof, why is two-finger scrolling blanked out? i have to use gconf to enable that setting.
[07:28] <knittl> if i use nouveau, shouldn't that use software rendering?
[07:29] <RAOF> It will, unless you've installed the experimental dri modules.
[07:29] <knittl> i don't think so
[07:30] <knittl> blender crashes xserver with nvidia driver
[07:30] <knittl> i'll try recompiling blender
[07:30] <RAOF> But that's not nouveau; that's the binary nvidia driver.
[07:31] <knittl> RAOF: yes, i asked about nouveau, because i need a working blender :D
[07:31] <knittl> and with nouveau it always told me that it cannot create glx-something
[07:34] <RAOF> Well, you could either try nouveau software rendering again, or you could try nouveau with the dri modules, or you could pastebin a backtrace of your X crash.
[07:35] <RAOF> era: That's a good question.
[07:35] <knittl> where would that backtrace be? i started blender in a screen session, but there was no output
[07:36] <RAOF> The backtrace would be in /var/log/Xorg.0.log.old, since it's the X server that's crashing, not blender.
[07:36] <era> i ask because it works perfectly and was disabled either during the karmic cycle i thing
[07:36] <era> *think
[07:36] <tjaalton> RAOF: duh, would've thought that was already there..
[07:36] <tjaalton> maybe even SRU'able to add it to lucid
[07:37] <knittl> RAOF: http://paste2.org/p/953368 does that help?
[07:37] <knittl> it's quite a short backtrace
[07:38] <RAOF> era: I'd guess it's a bug in gnome-control-centre, which provides that capplet.  It looks to me like the X side is doing its thing.
[07:38] <era> i'll give pics in a sec
[07:38] <RAOF> No need; I can reproduce locally.
[07:39] <era> ah
[07:39] <era> gconftool-2 --set /desktop/gnome/peripherals/touchpad/scroll_method --type int "2"
[07:39] <era> enables
[07:39] <RAOF> And since that works, and it looks like the correct driver is being loaded, I'm calling it Not An X Bug™.
[07:40] <era> doesn't work anymore
[07:40] <era> D:
[07:40] <RAOF> Ah.
[07:40] <era> worked a few weeks ago
[07:41] <era> now the touchpad option is disabled, yet filled
[07:41] <era> but now 2-finger scrolling
[07:41] <era> *but no
[07:42]  * RAOF wonders idly where his mouse pointer sprite has gone.
[07:43] <RAOF> era: Could you please kindly pastebin your /var/log/Xorg.0.log?
[07:43] <era> one sec
[07:45] <era> http://pastebin.ubuntu.com/479264/
[07:49] <RAOF> Hm.  Ok.
[07:49] <RAOF> A couple of weeks ago, you say?
[07:49] <RAOF> Could you check in Software Centre→History what got upgraded around then?
[07:49] <knittl> RAOF: how can i try the experimental dri drivers?
[07:50] <RAOF> knittl: Install the libgl1-mesa-dri-experimental package.
[07:51] <knittl> RAOF: and purge nvdia* und rm xorg.conf?
[07:51] <RAOF> Use the Hardware Drivers capplet; it'll do the required voodoo.
[07:51] <era> raof, this is a rather new install. wouldn't be reflected in the history and driver bisecting will be a pain in the ass.
[07:52] <era> it's either xinput or synaptic
[07:52] <RAOF> Depending on how long ago it was it'll either be synaptic or Xserver 1.9
[07:52] <RAOF> It's probably synaptic, indeed.
[07:53] <knittl> RAOF: no, jockey does not work at all for me
[07:53] <era> what's the best way to test aside from a daily?
[07:54] <knittl> use on a productive system, era ;)
[07:55] <era> i do. this is my primary laptop.
[07:55] <era> :)
[07:55] <knittl> haha, mine too
[07:56] <RAOF> knittl: Right.  That's a particularly unuseful backtrace.  You might get better luck attaching gdb (requires a second system to work reasonably).
[07:56] <RAOF> knittl: Jockey doesn't work at all?
[07:56] <knittl> RAOF: maybe related to my problems: is nvidia-kernel-common required?
[07:57] <knittl> RAOF: no, it installs the driver and then fails with »driver could not be installed, see log«
[07:57] <knittl> status of driver then switches from not installed to installed, but not in use
[07:58] <knittl> i also don't mind fixing jockey :D
[07:58] <knittl> sudo apt-get purge nvidia* jockey*
[07:58] <knittl> let's reinstall all that stuff
[07:58] <RAOF> Eh, give it a whirl.
[07:59] <knittl> so, what do i need to install, which pulls all the dependencies? only jockey-gtk?
[08:00] <LLStarks> raof, should i apport against synaptic?
[08:00] <RAOF> LLStarks: Go for it.
[08:00] <RAOF> knittl: jockey-gtk should do it, I think.
[08:00] <knittl> RAOF: should i restart first? because right now nvidia is in use
[08:00] <knittl> could cause conflicts?
[08:01] <knittl> so. purge – reboot – install jockey-gtk – reboot – install nvidia via jockey
[08:01] <RAOF> Yeah, give that a whirlygig
[08:01] <knittl> hell yeah! brb :)
[08:02] <LLStarks> raof, it was definitely working on june 24th.
[08:03] <RAOF> That's rather a long time ago :)
[08:04] <LLStarks> well, that's when i did this: http://ubuntuforums.org/showthread.php?p=9505892
[08:06] <knittl> hehe, nouveau feels snappier than nvidia with ignoreabi=true
[08:06] <knittl> now, install jockey and reboot again
[08:07] <LLStarks> raof, this works though: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/476866/comments/5
[08:08] <ubot4`> Launchpad bug 476866 in xserver-xorg-input-synaptics (Ubuntu) "two-finger scrolling does not work on Dell Studio 15 (1555) via gui config (affects: 12) (heat: 62)" [Undecided,New]
[08:08] <knittl> but blender works with nouveau again. i can tell from the slowness it's using software rendering
[08:08] <LLStarks> are you using gallium?
[08:09] <knittl> me? i'm using nouveau
[08:09] <LLStarks> or rather is it installed with nouveau
[08:09] <RAOF> Ah.  gnome-control-center bug, probably.  The synaptics driver is clearly exposing the required interfaces, gnome-control-centre doesn't seem to be using them properly though.
[08:09] <knittl> never heard of gallium
[08:09] <knittl> The following NEW packages will be installed: jockey-common jockey-gtk nvidia-173-modaliases nvidia-96-modaliases nvidia-common nvidia-current-modaliases
[08:09] <LLStarks> it's the 3d driver for nouveau
[08:09] <LLStarks> libgl1-mesa-dri-experimental
[08:10] <RAOF> knittl: Looks right.
[08:10] <knittl> no, i don't use the experimental dri thingy
[08:10] <knittl> $ apt-cache policy libgl1-mesa-dri-experimental
[08:10] <knittl> libgl1-mesa-dri-experimental: Installed: (none)
[08:10] <knittl> RAOF: ok, installing – rebooting :)
[08:11] <knittl> LLStarks: RAOF: i'll try dri-experimental later
[08:11] <knittl> how “experimental” is it? :D
[08:11] <LLStarks> enough on intel graphics hardware from my experience
[08:11] <LLStarks> very stable with nouveau though
[08:12] <RAOF> LLStarks: Except that we don't ship intel gallium (or, in fact, anything but nouveau) due to it being horribly unready.
[08:12] <LLStarks> i know, i was making a point.
[08:12] <LLStarks> i915 gallium is terrible
[08:12] <RAOF> Not as bad as i965 gallium :)
[08:12] <RAOF> knittl: It's unlikely to eat your dog, and it pretty much works in my testing.  It's called “experimental” mainly because I want to aggressively ignore any bugs filed about it.
[08:14] <RAOF> LLStarks: If you felt like a fun deep coding challenge, I understand that asac would quite like i965g to work :)
[08:14] <LLStarks> will gallium be ready for default inclusion in narwhal?
[08:14] <RAOF> Nouveau: ...unlikely, I think.  Radeon: yeah.
[08:14] <LLStarks> i suck at c. wish i could help.
[08:14] <knittl> RAOF: ok, that sounds good. i'm allergic to dogs though ;)
[08:15] <knittl> restricted drivers available {popup}
[08:15] <RAOF> Nothing says “you'll get better at C” like diving into mesa :)
[08:15] <knittl> i'll clear the log before
[08:16] <knittl> RAOF: 2010-08-17 09:14:52,995 DEBUG: handler xorg:nvidia_current previously unseen
[08:16] <knittl> is that normal, good or bad?
[08:16] <jcristau> RAOF: i thought it was "you'll get better at drinking"
[08:17] <jcristau> RAOF: my bad
[08:17] <jcristau> ;)
[08:17] <RAOF> :)
[08:17] <knittl> hehe
[08:17] <knittl>   File "/usr/share/jockey/handlers/nvidia.py", line 178, in __init__
[08:17] <knittl>     raise SystemError, 'does not currently work with xserver 1.9'
[08:17] <LLStarks> when i say i'm bad at c, i mean it. i couldn't even figure out how to do game of life.
[08:17] <RAOF> Hasn't Alberto uploaded the new nvidia yet?
[08:18] <knittl> don't know. where to get it? apt-get upgrade has no new packages
[08:18] <RAOF> knittl: Make sure you've got nvidia-current (256.44-0ubuntu1) available.
[08:18] <knittl> read: my system is up to date
[08:19] <RAOF> Hm.  I was sure that got fixed in the new nvidia-current.
[08:19] <knittl> gimme a sec, updating right now some other components
[08:19] <knittl> nvidia-current: Installed: (none) Candidate: 256.44-0ubuntu1
[08:20] <knittl> i'm on i386 if that matters
[08:20] <RAOF> jcristau: Incidentally, does Debian's -ati want the patch I've just added to Ubuntu's git branch?
[08:26] <knittl> 2010-08-17 09:14:50,771 WARNING: modinfo for module nvidia_current failed: ERROR: modinfo: could not find module nvidia_current
[08:26] <knittl> hrmmm, i think i'll try dri-experimental :>
[08:31] <knittl> hihi, quadrapassel works again
[09:17] <czajkowski> RAOF: that's not my bug, just a guy who was aking for help thanks though
[15:27] <apw> Sarvatt, RAOF, am wondering if either if you had looked at the ATI GPU hangs when booted with grub in graphics mode:  bug #605614
[21:49] <jono> hey folks
[21:49] <jono> now when I start X I get:
[21:49] <jono> Fatal server error:
[21:49] <jono> [    18.307] no screens found
[21:49] <jono> how do I fix this?
[21:50] <jono> log file is at http://www.jonobacon.org/files/Xorg.0.log
[21:50] <jono> it seems the intel driver is not loading
[21:51] <jono> ahhh somehow the package wasnt installed