[07:56] <ceramicm> Anyone know where I can find "ubuntuone.platform.linux.tools"? I'm trying to compile ubuntuone-client-1.7.1 on Fedora 15.
[07:58] <duanedesign> hello ceramicm
[07:59] <ceramicm> Hello.
[08:00] <duanedesign> let me see if i can help
[08:01] <ceramicm> Alright, thanks.
[08:03] <duanedesign> ceramicm: looks like that is the package  python-ubuntuone-client
[08:04] <ceramicm> duanedesign: Yes, but isn't ubuntuone-client the source package for the Ubuntu python-ubuntuone-client?
[08:07] <ceramicm> If so, since I've successfully run "configure", "make", and "make install" on the ubuntuone-client package, I would assume that the module would be installed as well, no?
[08:08] <rogerk_> Anyone know if there's a new Windows version coming soon? :)
[08:08] <duanedesign> hmm, i think you are right
[08:08] <rogerk_> of U1, that is.
[08:08] <duanedesign> rogerk_: yes, very soon their will be a major update to the Windows Beta
[08:09] <rogerk_> duanedesign: whee! are we talking hours, days or weeks? :-)
[08:09] <rogerk_> Having trouble with unpredictable sync..
[08:09] <ceramicm> When I try to run "u1sdtool" in terminal, I get an "ImportError: No module named ubuntuone.platform.linux.tools"
[08:10] <duanedesign> rogerk_: i would guess days to weeks
[08:10] <rogerk_> duanedesign: ok, thanks :)
[08:11] <duanedesign> rogerk_: if i get a less broad answer i wil let you know :)
[08:13] <Chipaca> ceramicm: hi
[08:13] <ceramicm> Chipaca: Hello.
[08:14] <Chipaca> ceramicm: could you open a python console session please?
[08:16] <ceramicm> Chipaca: Ok. Done.
[08:17] <Chipaca> ceramicm: do 'import ubuntuone'
[08:17] <Chipaca> ceramicm: then, 'ubuntuone'
[08:17] <Chipaca> and paste the output of that last one
[08:18] <ceramicm> Chipaca: I got another ImportError, and then a NameError: name 'ubuntuone' is not defined.
[08:18] <Chipaca> ah, ok
[08:19] <rogerk_> duanedesign: great!
[08:19] <Chipaca> ceramicm: are you wanting to package ubuntu one, or simply to get it working?
[08:20] <Chipaca> ceramicm: i can probably help you with the latter, but i don't know enough of fedora's quirks, nor of rpm packaging, to help you usefully with the former
[08:20] <ceramicm> Chipaca: Get it working. I only have a bit of experience packaging.
[08:21] <Chipaca> ok
[08:21] <Chipaca> what have you done so far?
[08:22] <ceramicm> Downloaded the source of ubuntuone-client from launchpad, unzipped it to /opt, ran "configure", "make", and "sudo make install", and then tried "u1sdtool".
[08:23] <ceramicm> I installed imake (to provide lndir) and python-twisted also, to satisfy dependencies.
[08:24] <Chipaca> did you install ubuntuone-storage-protocol?
[08:24] <ceramicm> Chipaca: No.
[08:24] <Chipaca> ok
[08:24] <Chipaca> http://askubuntu.com/questions/10271/is-running-ubuntu-one-on-debian-possible
[08:25] <Chipaca> that might be a good place to start
[08:25] <Chipaca> as it lists all the dependencies, even though the package names are in debianese you should be able to follow it
[08:25] <ceramicm> Chipaca: That looks very helpful. Thanks!
[08:26] <Chipaca> don't do the sed bit, unless you know your gtk doesn't have a spinner
[08:26] <Chipaca> in fact, in python console, import gtk; gtk.Spinner
[08:26] <Chipaca> if that dies, then you need the sed
[08:26] <ceramicm> No, I have a gtk.Spinner
[08:27] <Chipaca> also, i think fedora uses site-packages instead of dist-packages
[08:27] <Chipaca> so ignore comments about moving things :)
[08:28] <ceramicm> Would you recommend using the latest bzr branches of each component, or the most recent release tarballs?
[08:29] <Chipaca> the latter
[08:29] <Chipaca> no sense in having that many moving parts until you know it works :)
[08:29] <Chipaca> oh, hold on, are you using gnome 3?
[08:29] <ceramicm> Yes. Problem?
[08:30] <JamesTait> Good morning all!
[08:30] <Chipaca> ceramicm: the latest tarball is 1.7.something, right? if so you're ok
[08:30] <ceramicm> Chipaca: 1.7.1, yes.
[08:31] <ceramicm> JamesTait: Good morning.
[08:31] <Chipaca> ceramicm: gnome broke several dbus interfaces with their move to 3, and older versions break
[08:31] <Chipaca> ceramicm: also make sure ubuntu-sso-client is 1.3.x
[08:34] <JamesTait> Good morning ceramicm. :)
[08:34] <ceramicm> Is ubuntuone-storage-protocol 1.6.0 ok?
[08:49] <mandel> morning!
[08:50] <ceramicm> mandel: Good morning.
[08:50] <mandel> ceramicm: hello :)
[08:52] <Chipaca> ceramicm: please mention my name when asking questions otherwise i might delay quite  abit in replying
[08:53] <Chipaca> ceramicm: make it 1.7 also please
[08:53] <ceramicm> Chipaca: Ok. Thank you for the help! I'm compiling the various components now, and I'll let you know how it works out.
[09:08] <karni> Good morning!
[09:17] <mandel> karni: morning!
[09:17] <karni> hi mandel :)
[09:32] <gatox> mandel, did you receive your reviews from yesterdy
[09:32] <gatox> ?
[09:32] <gatox> or do you want me to do it now?
[09:35] <mandel> gatox: I had one from alecu, if you fancy taking a look at the ACE issue yet he gave me a nice needs fixing ;)
[09:35] <mandel> gatox: will only be useful for you if you want to see a dirty trick win the windows fs hehehe
[09:36] <FxIII> hi all
[09:37] <gatox> mandel, ok... so, i think not yet :P
[09:37] <FxIII> can ubuntuone sharing folders ability be used without gui?
[09:37] <FxIII> I mean on a computer without the X server, using only the commandline
[09:38] <mandel> FxIII: if you have dbus running you should not have a problem, we have a command line to interact with the daemon
[09:39] <mandel> FxIII: let me find out the exact command
[09:39] <FxIII> mandel: where i can find documentation?
[09:39] <mandel> FxIII: u1sdtool —help
[09:39] <FxIII> mandel: i can use python api too
[09:40] <mandel> FxIII: yes, you can and even use the dbus calls too if you need to :)
[09:41] <mandel> FxIII: there is a wrapper with useful functions that we use in the control panel, you can do a from ubuntuone.platform.tools import *
[09:42] <mandel> FxIII: take a look at the code of the u1sdtool which uses those, you can find it in trunk under /bin
[09:42] <FxIII> u1sdtool gives error related to the DISPLAY variable to me
[09:42] <mandel> FxIII: hm… lame can I see the error?
[09:42] <FxIII> I'm rebooting
[09:43] <FxIII> (armel device with a little problem with power supply :D)
[09:44] <FxIII> mandel: I can try with my netbook using ssh to emulate the display absence
[09:46] <mandel> FxIII: sure, give it a try, if you need any help I'll be here :)
[09:46] <FxIII> mandel: ok
[09:47] <FxIII> whre i can post the error?
[09:47] <FxIII> *where
[09:48] <FxIII> mandel: http://pastebin.com/vRx2qr9r
[09:48] <mandel> FxIII: paste.ubuntu.com :)
[09:48] <FxIII> mandel: too late :D
[09:48] <mandel> FxIII: hehe is the same, the diff is the url heheh
[09:50] <FxIII> i dont understand how signup is intended to be used when in command line
[09:50] <mandel> FxIII: hmm as I suspected Dbus is asking for the x-server… let me see if there is a way to work around that
[09:50] <mandel> FxIII: can you use any other dbus service?
[09:50] <FxIII> mandel: i cant tell, i'm new to dbus
[09:52] <mandel> FxIII: oh, wait you do not have the credentials… there is a call from sso that will do that for you
[09:53] <mandel> FxIII: can you set in your env DEBUG=true and cat the output, lets see what is the issue
[09:53] <mandel> FxIII: but I suspect that sso is trying to get the credentials and for that it need a UI and it goes bannanas, I know there is a way to get the creads with no UI but we would need to ask ralsina
[09:54] <mandel> gatox: do you know something about that ^ maybe you talk with ralsina about it while working on the windows installer
[09:54] <FxIII> mandel: I basically need to run the sync at the startup/on-connection wihtout the user log in (then i will like to remove the X server at all)
[09:54] <FxIII> mandel: http://paste.ubuntu.com/662506/
[09:55] <FxIII> mandel: i cant see differences
[09:56] <mandel> FxIII: ok, so we have to do some smart work around the issue of sso. The problem here is that you do not have the credentials for that machine which means that the sso daemon will launch to try and get them and that uses a UI
[09:56] <mandel> FxIII: do you have another machine with u1 installed (lets try first by copying the creds to the machine with no x11)
[09:56] <FxIII> mandel: if i set the DISPLAY it works whitout asking anything (no credentials form or other)
[09:57] <FxIII> I did the test using my netbook over an ssh connection
[09:57] <FxIII> mandel: the error is the same
[09:58] <FxIII> mandel: and no ui appears if i export DISPLAY=:0
[09:58] <gatox> mandel, FxIII the problem i used to have was with the ipc-client (in windows) and it's fixed deleting the metadata
[09:59] <gatox> mandel, FxIII a branch was approved last week solving some issues about credentials...
[09:59] <mandel> gatox: here we have an other problem, he is not using x11 :P
[10:00] <gatox> mandel, mmm
[10:00] <mandel> FxIII: yeah, the daemon will work yet it would be getting any real data, which is a pain since you need to be connected, can you run u1 like you mentioned and then look for the logs in xdg_cache
[10:01] <mandel> FxIII: also lets ping rye he is the one that does more crazy things with u1 than anyother :)
[10:01] <FxIII> mandel: sorry, i dont understand what i have to do
[10:02] <mandel> FxIII: ok, what is happening is the following, the ubuntu one dameon is launched with no creds, the guy does not care because he will be waiting for you to log in, so although you can get it to run it is doing nothing
[10:03] <mandel> FxIII: what we need to do is to make sure that the daemon gets the creds so that it performs the sync, the problem is that the other daemon that takes care of that (ubuntu.sso) does use a display, which is a PITA
[10:03] <mandel> FxIII: do I make sense so far?
[10:04] <FxIII> mandel: ooooh ok
[10:05] <FxIII> mandel: there is a problem about this
[10:05] <FxIII> mandel: is the credential asked at each request?
[10:05] <mandel> FxIII: there is an option in the daemon to pass the keys, the bin is called ubuntuone-syncdaemon
[10:05] <mandel> FxIII: no, creds are just asked once :)
[10:06] <mandel> FxIII: so, lets stop the daemon (ubuntuone-syncdaemon) and run it with ubuntuone-syncdaemon —oauth [CONSUMER_KEY:CONSUMER_SECRET:]KEY:SECRET
[10:06] <FxIII> mandel: because i have a display running on my netbook and the sync service is active, where is the problem if i ask the list of shared by commandline?
[10:06] <mandel> where [CONSUMER_KEY:CONSUMER_SECRET:]KEY:SECRET is your sso creds
[10:06] <mandel> FxIII: hm, I think I'm getting confused hehe
[10:07] <mandel> where is u1 running, in the machine with no x11 or the netbook?
[10:07] <FxIII> mandel: does the sync ask the sso and the sso ask the DISPLAY?
[10:07] <FxIII> mandel: the netbook
[10:07] <FxIII> mandel: the error is the same
[10:10] <FxIII> mandel: welcome back :D
[10:10] <mandel> FxIII: sorry irc client fail :(
[10:10] <mandel> FxIII: you are right, sync asks sso and sso asks DISPLAY
[10:11] <FxIII> mandel: you want my syncdaemon to use its own sso credentials
[10:11] <FxIII> mandel: right?
[10:11] <mandel> FxIII: that is what I was considering starting the sync passing the creds so that the sso is not used
[10:11] <FxIII> mandel: how can I obtain theese credentials?
[10:11] <mandel> FxIII: yes, more or less is that :)
[10:11] <mandel> FxIII: do you have a machine already using u1?
[10:12] <FxIII> mandel: yes
[10:12] <mandel> FxIII: that does work ofcourse hehehe
[10:12] <FxIII> mandel: i think it works :D
[10:12] <mandel> FxIII: in your keyring you will find the creds
[10:12] <mandel> FxIII: haha
[10:12] <FxIII> mandel: can i get it by using some python api?
[10:13] <FxIII> mandel: I will have problem with the one wihtout X later
[10:13] <FxIII> mandel: anyway i can use the creds on keyring just to try (alas i dont know how :D)
[10:18] <mandel> FxIII: well in the one without X11 you can change the way syncdaemon is started and always pass the oauth from the command line, so no problem :)
[10:18] <FxIII> mandel: I found consumer_secret=SB[...]oT&token=mZ[..]YT&consumer_key=R[...]S&name=Ubuntu+One+%40+eeec171&token_secret=HUF[...]QQ
[10:18] <mandel> FxIII: you can get the creds using seahorse, are you using Unity (I was going to give you the path in gnome-2 hehe)
[10:18] <mandel> FxIII: yes, that would be it :)
[10:19] <mandel> FxIII: start the syncademon with --oauth
[10:19] <mandel> and the creds
[10:20] <FxIII> mandel: how to kill the syncdaemon? is not in /etc/init.d/
[10:20] <FxIII> mandel: ok found and killed
[10:20] <mandel> FxIII: get the pid and kill it form the terminal, right?
[10:21] <mandel> FxIII: cool
[10:22] <FxIII> mandel: -oauth or --oauth?
[10:22] <mandel> FxIII:  —oauth
[10:23] <mandel> FxIII: shit, sorry the stupid irc client is merging - - into one :(
[10:23] <mandel> puto irc client!
[10:23] <mandel> FxIII: is with two - :)
[10:23] <FxIII> mandel: ok
[10:24] <FxIII> mandel: have I to use the []?
[10:25] <fagan> <3 when mandel goes on his spanish cursing rants :D
[10:26] <mandel> FxIII: no need you can do CONSUMER_KEY:CONSUMER_SECRET:KEY:SECRET
[10:26] <FxIII> mandel: ok!
[10:26] <mandel> fagan: yeah, stupid irc client, why would it merge two - there is no way to do ascii art like this!
[10:27] <fagan> mandel: well it isnt really a proper IRC client
[10:28] <FxIII> mandel: are key and secret respectively token and token_secret?
[10:28] <mandel> fagan: well, yeah, but neverthless… puto mac!
[10:29] <fagan> mandel: I still have yet to put ubuntu onto mine should figure that out because I think it would be nice on it
[10:31] <rye> FxIII, crazy things with ubuntuone?
[10:31] <FxIII> mandel: welcome back
[10:31]  * mandel back and cursing in spanish to adium
[10:31] <mandel> hehe
[10:31] <FxIII> rye: hi ryem quite crazy
[10:32] <FxIII> mandel: i run the syncdaemon
[10:32] <FxIII> mandel: you will not like my pastebin
[10:32] <FxIII> http://paste.ubuntu.com/662540/
[10:32] <mandel> I think that the adium crashes everytime I run the u1 tests on windows...
[10:33] <mandel> rye: can you give FxIII a hand to get sd running without x11, I think that passing the creds to syndaemon from the command line should do the trick
[10:33] <mandel> FxIII: dammed… rye any idea ^
[10:33] <rye> FxIII, what version of ubuntu are you running on?
[10:34] <rye> mandel, sd always wants dbus
[10:34] <mandel> FxIII: I leave you will 'the mane' (rye) I'm just a code monkey :P
[10:34] <FxIII> rye: Ubuntu 11.04
[10:34] <mandel> rye: I know it wants dbus, but not that it needs x11 for dbus
[10:34] <FxIII> mandel: ty! :D
[10:35] <rye> FxIII, you may want to do the following - run "dbus-launch bash" - there you will have the dbus session, within this session you should try running ubuntuone-syncdaemon --oauth a:b:c:d --debug
[10:35] <rye> FxIII, i am worried about the notification that want X badly
[10:35] <FxIII> mandel: hehehe hidden dependencies on ipc ...
[10:36] <FxIII> rye: bad news...
[10:36] <FxIII> rye: does the sync daemon uses the notification system directly?
[10:37] <rye> FxIII, it uses pynotify to show the pretty bubbles, let me see how it is wired
[10:38] <rye> FxIII, by the way, what is your usecase for headless ubuntuone?
[10:38] <mandel> rye: I really hate the fact that the named the bloody thing pynotify… I confuse it with pyinotify
[10:38] <FxIII> rye: an beagleboard like with an ubuntu-armel
[10:38] <rye> mandel, yes, me too.
[10:39] <rye> FxIII, do you need a daemon or a command line application to upload/download files?
[10:39] <rye> FxIII, to U1
[10:39] <mandel> rye: if the notifications are running is because the libs are there, so maybe removing them does the trick
[10:39] <rye> mandel, yeah, there is a conditional import of pynotify, in case it fails to import then we should not use it
[10:40] <FxIII> rye: i whould like to run the sync on boot or on connection without user log in
[10:40] <rye> FxIII, ok, so full sync, so syncdaemon should be ok.
[10:41] <ralsina_> mandel, FxIII: there is a way to get credentials without UI but it's not fullly implemented on Linux ye
[10:41] <rye> FxIII, re: bad news - has something been printed by sd?
[10:41] <ralsina_> yet*
[10:41] <rye> ralsina_, ubuntuone-sso-login.py :-P
[10:41] <rye> ralsina_, in my ubuntuone-scripts
[10:41] <ralsina_> rye: hehe, ok, that's better :-)
[10:42] <FxIII> rye: the syncdaemon seams to go after dbus-launch
[10:42] <rye> FxIII, could you please copy the output?
[10:43] <FxIII> rye: terminal full....
[10:43] <rye> FxIII, umm ok, stop it and start w/o --debug
[10:43] <FxIII> rye: I can redirect the stdout
[10:44] <rye> FxIII, w/o --debug it should not print a lot, but you will find the logs in ~/.cache/ubuntuone/log/
[10:44] <FxIII> rye: whitout debug it gtkwars it can open the display
[10:45] <FxIII> rye: http://paste.ubuntu.com/662552/
[10:48] <mandel> I need to move to a developed country… bloody internet connection, puto pais, mierda, me cago en su padre!
[10:49] <rye> mandel, where are you?
[10:49] <mandel> ralsina_: do you have issues accessing http://msdn.microsoft.com/en-us/library/aa374924(v=vs.85).aspx
[10:49] <rye> FxIII, is there any more info for the stack trace?
[10:49] <mandel> rye: in spain… in the isands (Balearic)
[10:50] <ralsina_> mandel: yes, so it seems microsoft has to move to another country :-)
[10:50] <rodrigo_> is desktopcouch supposed to work now on oneiric? because it has never worked for me, it's crashing all the time
[10:50] <rodrigo_> mandel, hey, are you in Mallorca?
[10:50] <FxIII> rye: do you still  need the output with --debug?
[10:51] <rye> FxIII, no, i don't
[10:52] <FxIII> rye: there is not errors after the dbus-launch
[10:53] <rye> FxIII, ok, could you please open another terminal and look at ~/.cache/ubuntuone/log/syncdaemon.log file, does it have any errors?
[10:55] <FxIII> rye: no errors
[10:55] <Chipaca> rodrigo_: yes, it should be working just fine
[10:55] <Chipaca> rodrigo_: what is crashing?
[10:56] <rodrigo_> Chipaca, desktopcouch-service as soon as I connect to it from evolution
[10:56] <rodrigo_> let me get a stacktrace
[10:58] <FxIII> rye: it seams to go, i uploaded a file on webUI and i get this on my folder, with a terminal notification
[10:58] <FxIII> rye: touched a file and saw in the webUI
[10:58] <rodrigo_> Chipaca, first, when starting it, I always get this -> http://pastebin.com/ZdqC4NXA
[11:00] <nessita> good morning everyone!
[11:00] <FxIII> rye: how can i obtain the credential when i will try on my device?
[11:00] <FxIII> good moring nessita
[11:00] <rye> FxIII, look at http://people.canonical.com/~roman.yepishev/us/ubuntuone-sso-login.py
[11:02] <rye> FxIII, this is a script which will output OAuth credentials after registering with SSO and will ask U1 serve to fetch the credentials from SSO. Feel free to modify to your needs (e.g. making it write the oauth = parameter in __main__ section of ~/.config/ubuntuone/syncdaemon.conf
[11:03] <rodrigo_> Chipaca, now it doesn't crash anymore, but I always get this unauthorized errors
[11:03] <FxIII> rye: wonderful!
[11:04] <rodrigo_> Chipaca, wasn't there a keyring bug or something iirc?
[11:04] <Chipaca> rodrigo_: maybe, i'll check
[11:04] <FxIII> rye: I will try it with the syncdaemon on my device as soon as i get it work again :D
[11:05] <FxIII> rye: anyway how can i run the dbus-run bash at boot time?
[11:05] <FxIII> rye: *dbus-launch
[11:07] <rye> FxIII, hm, interesting question... basically you would need to start dbus-launch ubuntuone-syncdaemon after system finished booting (as some user), - dbus-session will go to background and so will ubuntuone-syncdaemon.
[11:08] <FxIII> rye: cant i simply run dbus-launch ubuntuone-syncdaemon --oauth [...] & ?
[11:09] <rye> FxIII, yep, and you can write oauth info to the user's config file so that it won't be a long command line... actually you may do it in a better way
[11:10] <rye> FxIII, if you have oauth in the config file then you won't need to do anything to ubuntuone-syncdaemon directly, do "dbus-launch u1sdtool --start" - this will ask dbus to start syncdaemon in background and will exit quite immediately
[11:11] <FxIII> rye: and this will not use some X related service?
[11:13] <FxIII> rye: i may try but i have no syncdaemon.conf file, how to write it down?
[11:16] <rye> FxIII, see /etc/xdg/ubuntuone/syncdaemon.conf for the template
[11:16] <FxIII> rye: ok
[11:26] <FxIII> rye: I have to run the dbus-launch u1sdtool -start as normal user? the boo scripts run as root but i should avoid this,right?
[11:30] <mandel> FxIII: are you using boo?
[11:52] <fagan> ralsina_: any intern sized work
[11:52] <fagan> Oh he isnt around yet :/
[11:59] <mandel> fagan: I might have some work for you later in the afternoon/evening. I need to test RO shares to see if my crazy ACE idea works and what happens without it. I'll write a script (as in a things to follow) and would be nice to have it someone else to execute it too :)
[12:00] <mandel> anyway I need to move back home, will be back in 30 mins or so
[12:00] <mandel> nessita, ralsina_: FYI ^
[12:00] <fagan> mandel: nice :D
[12:01] <nessita> mandel: ping
[12:01] <rodrigo_> Chipaca, so, if I remove the tokens from the keyring and restart desktopcouch-service, it adds a new entry to the keyring but with invalid tokens, it seems
[12:02] <nessita> mandel: if you haven't left already, there are conflicts in the shutil-move branch
[12:03] <nessita> verterok: hey there, can I have a review for https://code.launchpad.net/~nataliabidart/ubuntuone-client/tritcask-shutdown/+merge/71030 ?
[12:05] <rye> FxIII, boot scripts run as root, yes, but you need to start as regular user, either as sudo -u username or su username -c 'commandline'
[12:07] <Chipaca> rodrigo_: fun for the whole family!
[12:17] <nessita> ralsina_: good morning! can I have some reviews please?
[12:31] <nessita> ralsina_: ping?
[12:35] <ralsina_> nessita: pong
[12:35] <ralsina_> nessita: sure, I can do as many reviews as you want. URLs?
[12:35] <nessita> ralsina_: hey there. pasting urls now...
[12:35] <nessita> https://code.launchpad.net/~nataliabidart/ubuntuone-client/tritcask-shutdown/+merge/71030
[12:35] <nessita> https://code.launchpad.net/~nataliabidart/ubuntuone-client/skip-filesystem-logger/+merge/71031 (trivialish!)
[12:36] <ralsina_> nessita: ok, starting with the trivial one
[12:37] <nessita> thanks!
[12:41] <verterok> nessita: done
[12:41] <nessita> verterok: gracias!
[12:49] <ralsina_> nessita: approved both
[12:49] <nessita> thanks!
[12:57] <nessita> mandel: ping
[12:58] <nessita> mandel: shutil-move has conflicts, can you please fiX?
[12:58] <mandel> nessita: sure! on it right now
[12:58] <nessita> mandel: same for access-can-write
[12:59] <mandel> nessita: will merge shutil, pump and see if there are more issues
[13:00] <nessita> mandel: right, and can you also answer last alecu question in that MP?
[13:00] <nessita> me
[13:00] <mandel> nessita: which mp?
[13:00] <fagan> me
[13:00] <ralsina_> me
[13:00] <nessita> mandel: https://code.launchpad.net/~mandel/ubuntuone-client/access-can-write/+merge/70896
[13:01] <nessita> mandel, dobey, alecu?
[13:01] <nessita> gatox: ?
[13:01] <mandel> nessita: ok, I had an lp error and did not notice (I wrote the same as the email)
[13:01] <gatox> me
[13:01] <alecu> me
[13:01] <mandel> nessita: doing it now
[13:01] <mandel> me
[13:01] <nessita> fagan: go
[13:01] <ralsina_> The mailman arrived, I'll go last
[13:01] <nessita> I mean, I should go :-)
[13:02] <nessita> DONE: bug #823336, bug #823316, reviews
[13:02] <nessita> TODO: bug #823884, bug #823895, bug #823896, bug #823903, reviews
[13:02] <nessita> BLOCKED: nopes
[13:02] <nessita> NEXT: fagan
[13:02] <fagan> DONE
[13:02] <ubot4> Launchpad bug 823336 in ubuntuone-client "Tritcask tests does not always shutdown the instance (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/823336
[13:02] <fagan> * looked more at some of the windows client code while I had some down time
[13:02] <fagan> TODO
[13:02] <fagan> * mandel said he had something for me to test
[13:02] <fagan> BLOCKED
[13:02] <fagan> * nope
[13:02] <fagan> ralsina_: go
[13:02] <ubot4> Launchpad bug 823316 in ubuntuone-client "Windows: there is no filesystem_logger implementation (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/823316
[13:02] <ubot4> Launchpad bug 823884 in ubuntuone-client "Share names and UDF suggested paths should be always unicode while testing (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/823884
[13:02] <ubot4> Launchpad bug 823895 in ubuntuone-client "Windows: test_action_queue does not clean the env properly in tearDown (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/823895
[13:02] <ubot4> Launchpad bug 823896 in ubuntuone-client "test_hashqueue should open all file with "wb" mode (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/823896
[13:02] <ubot4> Launchpad bug 823903 in ubuntuone-client "Windows: fix local rescan tests (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/823903
[13:02] <nessita> fagan: ralsina_ said he'll go last
[13:02] <nessita> gatox: go!
[13:02] <gatox> DONE:
[13:02] <gatox> Several bugs fixed on Installer UI.
[13:02] <gatox> TODO:
[13:02] <gatox> Finish fixing Windows-Installer broken tests in order to be able to propose my branch.
[13:02] <gatox> BLOCKED:
[13:02] <gatox> No.
[13:02] <fagan> nessita: ah didnt see that
[13:02] <gatox> alecu, go
[13:03] <gatox> alecu, ping and go
[13:03]  * alecu writing notes....
[13:03] <mandel> alecu: I go then
[13:03] <mandel> DONE: more fixes for shutil.move. Added tests for move to trash on windows. Tested using ctypes for the move_to _trash methods, they do not brin anything to the table and could have more issues.
[13:03] <mandel> TODO: fix merge issues with trunk for both branches. Write script for testing RO for trunk and my branch and send a report about it.
[13:03] <mandel> BLOCKED: no
[13:03] <mandel> next: alecu
[13:04] <alecu> DONE: lots of reviews and IRL testing of r/o proposed solution, researched a new proposal, irl of recyclebin issues as well
[13:04] <alecu> TODO: discuss with mandel, find more issues
[13:04] <alecu> BLOCKED: no
[13:04] <alecu> NEXT: dobey
[13:04] <alecu> mandel, so: the trash with W don't take literal paths?
[13:05] <mandel> alecu: no :(
[13:05] <ralsina_> DONE: day off to try(and probably fail) to get a visa, published another build  TODO: help with reviews, fix some smallish bugs, work on installer details, publish a build, BLOCKED: no
[13:05] <mandel> alecu: I think it has to do with the length of the path, remember when the shell (explorer) would complain about it and would say is to long to be moved to the trash?
[13:06] <alecu> ralsina_, why "probably fail" ?
[13:07] <ralsina_> alecu: my mother in law and brother in law live there, so that makes my wife an "illegal immigration risk" and since I am her husband and telecommute to england....
[13:07] <ralsina_> alecu: so, they have provisionally denied it, and asked us for more documents
[13:07] <alecu> :-(
[13:08] <nessita> ralsina_: *ouch*
[13:08] <ralsina_> nessita: well, at least we *do* have the extra dcs they want, and it's not "really" denied so maybe it will work itself out. Or maybe not. Not in my hands, so I refuse to care.
[13:09] <nessita> ralsina_: when do you have to go back there?
[13:09] <mandel> ralsina_: visa to wherE?
[13:09] <ralsina_> mandel: USA
[13:09] <ralsina_> nessita: I don't, it's via email now
[13:09] <alecu> to the US of A
[13:09] <mandel> ralsina_: oh, do we know who goes to UDS?
[13:10] <ralsina_> mandel: not a definitive list, we will wait for parrino to come back from vacations
[13:10] <ralsina_> mandel: also, if I don't get the visa, that means the list may have to be changed, so... next week.
[13:10] <ralsina_> same about gatox, who has his visa interview next week
[13:11] <mandel> ralsina_: ok :)
[13:11] <ralsina_> but if it helps, I was one of three denied in the 3 hours I was waiting there, so he should have no problems.
[13:11] <gatox> ralsina_, yes... don't make me get nervous! :P
[13:12] <gatox> ralsina_, i have my interview monday at 8am :S
[13:12] <mandel> nessita: before I go for lunh, is everyone ok to delay mumble 15 min so I have time to go to the internet cafe ?
[13:12] <nessita> mandel, ralsina_, alecu, gatox, Chipaca: mumble in 30 miuntes?
[13:12] <gatox> nessita, ack
[13:12] <dobey> me
[13:13] <alecu> mandel, ok with me
[13:13] <dobey> λ DONE: released u1client, uploaded u1client, updated u1client nightlies, live testing some small tarmac fixes
[13:13] <dobey> λ TODO: u1client-gnome/ubuntuone-installer releases/uploads, administrata
[13:13] <dobey> λ BLCK: None.
[13:13] <nessita> mandel: fine by me
[13:13] <ralsina_> so, is it in 30 or in 45?
[13:13] <gatox> mandel, fine by me
[13:13] <nessita> ralsina_: seems like in 45'
[13:13] <ralsina_> I'm ok with both anyway ;-)
[13:13] <mandel> sweet, then I'll see you at o'clock :)
[13:16] <ralsina_> gatox: how's your branch going? Need a hand with anything?
[13:16] <nessita> dobey: could you please help me with tarmac's failures here https://code.launchpad.net/~nataliabidart/ubuntuone-client/tritcask-shutdown/+merge/71030 ?
[13:17] <nessita> dobey: error is
[13:17] <nessita>   File "/usr/lib/pymodules/python2.7/ubuntuone-dev-tools/ubuntuone/devtools/testcase.py", line 228, in setUp     != os.path.dirname(os.getcwd()): exceptions.OSError: [Errno 2] No such file or directory
[13:17] <nessita> dobey: seems like the FS where the tests run has been umounted? :-/
[13:17] <gatox> ralsina_, the branch is ready... BUT there is about 30 tests that are failing in windows-installer (even before my branch), so i'm fixing that in order to be able to propose my branch
[13:17] <ralsina_> 30 tests????
[13:17] <nessita> ralsina_: the errors that gatox is having are the same that I had
[13:18] <gatox> ralsina_, yep
[13:18] <ralsina_> nessita: hmmm weird
[13:18] <nessita> ralsina_: seems like there is a "bad" thing happening and I think the threads are involved
[13:18] <nessita> ralsina_: I think lisett-e log file also shows something in that direction
[13:18] <ralsina_> nessita: the only thread stuff is about space calculation, that should not cause 30 tests to fail. It may even be worth doing differently :-(
[13:18] <dobey> nessita: it appears the tests hit the memory ulimit
[13:19] <nessita> ralsina_: well, if the space calculation is triggered in each test (as a side effect), we can easily have 30 tests failing
[13:19] <ralsina_> nessita: could be, in which case we need to fake some bits
[13:19] <gatox> ralsina_, nessita there is errors about unclean reactor stuff too..... i'm reviewing everything if some callLater is called without returning a deferred or something...
[13:20] <nessita> dobey: can we do something about that?
[13:20] <nessita> gatox: the reactor unclean is a "generic" errors that happens when the test finished and th reactor was dirty (ie it had stuff to process still)
[13:21] <gatox> nessita, yes... but that couldn't be causing the other tests to fail?
[13:21] <dobey> nessita: make the tests not use so much memory. they have gotten much slower and use a lot more mem recently it seems :(
[13:21] <nessita> dobey: in my experience, the first run is extremely fast
[13:22] <nessita> dobey: but each new run is slower and slower
[13:22] <nessita> dobey: and the part that slows down si the dbus
[13:22] <nessita> dobey: so I would guess we're dirtying dbus without proper cleaning. You can confirm this rebooting your tarmac machine
[13:23] <dobey> that makes no sense
[13:24] <nessita> dobey: ok, not sure what else propose then. We really need to land branches, though :-/
[13:24] <dobey> branches have been landing
[13:24] <nessita> dobey: yes, that's true. I rephrase: we need to keep landing branches ;-)
[13:25] <nessita> dobey: I base my comments in the fact that I've run suites during this morning and I've had these results:
[13:25] <nessita> Ran 2306 tests in 321.738s
[13:25] <nessita> Ran 2306 tests in 738.723s
[13:25] <nessita> Ran 2307 tests in 1010.917s
[13:25] <nessita> dobey: as you can see, the time sued increases
[13:26] <dobey> yes. but why?
[13:26] <dobey> there is a new dbus session each time you run the tests, so it shouldn't be that, unless you've got some tests hitting the real dbus
[13:26] <dobey> which would never be the case for tarmac, as it's run under cron, so only the test dbus session would be available
[13:26] <nessita> dobey: there are no tests hitting the real dbus
[13:27] <nessita> dobey: maybe the test dbus session gets alive and using resources?
[13:28] <dobey> no i don't think so
[13:28] <dobey> it's u1trial that's eating up all the ram (which means it's the tests themselves)
[13:28] <nessita> dobey: ok, I'm not sure what else can be making each run go higher in time. If I reboot, time goes down again
[13:29] <dobey> nessita: going deeper into swap each time?
[13:29] <nessita> dobey: I have 8g of ram, swap has not been touched
[13:31] <nessita> ralsina_: any ideas? ^
[13:32] <ralsina_> nessita: nope
[13:33] <ralsina_> nessita: I would check stray processes, but that should not happen
[13:33] <nessita> dobey: will branches keep landing?
[13:33] <ralsina_> nessita: also, instead of rebooting, restarting the session, to see if it's the dbus getting weird, or something else
[13:34] <dobey> well there's nothing still running
[13:34] <dobey> nessita: they should, except for maybe the broken utf8 path being left around i guess
[13:34] <nessita> dobey: ok, thanks, I'll re approve mine then
[13:34] <dobey> nessita: the interesting thing is that the dbus session isn't even still running; so it at least cleaned up some stuff
[13:35] <nessita> dobey: right, I confirmed that as well...
[13:35] <dobey> and there's no trial_temp dir
[13:36] <dobey> nessita: i mean on the tarmac machine. if u1trial suddenly gets killed then it doesn't do the right stuff. but this is like the tearDown worked fine and it stopped the service and cleaned up
[13:37] <nessita> dobey: ah... so is not like the os killed the process but something else?
[13:37] <dobey> well i think python raised MemoryError and the trial test runner handled it correctly, as does the service stuff in u1trial
[13:39] <dobey> which is nice
[13:40] <nessita> dobey: are we logging the MemoryError handling?
[13:40] <dobey> not exactly, no
[13:41] <nessita> ralsina_: can I haz another review for https://code.launchpad.net/~nataliabidart/ubuntuone-client/share-name-unicode/+merge/71045, please?
[13:41] <ralsina_> nessita: already doing it :-)
[13:42] <dobey> you know. i think maybe we should set ulimit in our test running things
[13:42] <nessita> ralsina_: great! I resubmitted the proposal becasue I forgot the pre-requisite
[13:42] <nessita> dobey: what does that mean? I'm not very familiar with ulimit
[13:42] <nessita> dobey: I mean, what are the consequences of that? more killed test runs?
[13:44] <dobey> nessita: we can set ulimit -m and -v to some reasonable value (like 384MB), inside Makefile.am, run-tests, etc; that will set limits for the Resident and Virtual memory usage during the test runs. and make it more visible to developers when tests are using too much memory
[13:45] <nessita> dobey: hum, I found that a bit drastic  since until someone actually reviews this mem usage we'll get a lot of branches refused, right?
[13:45] <nessita> dobey: I'm +1 once we get the mem issue controlled...
[13:45] <dobey> nessita: no. you will see it when you do 'make test' on your machine
[13:46] <nessita> dobey: but tarmac will run that as well, right?
[13:46] <dobey> nessita: yes, but you shouldn't be setting your branches to approved that don't pass tests on your own machine.
[13:47] <dobey> nessita: think of it as a 'lint check' for memory usage :)
[13:47] <nessita> dobey: right, the thing is if we add this now, it will be very difficult to propose branches because it will be hard to have mem usage controlled, and most of the time will be out of the scope of the branch to fix that. I agree with the lint memory check, but only once we have the current issue solved
[13:48] <nessita> dobey: ATM we can't debug mem issues while trying to land branches
[13:49] <ralsina_> nessita: +1 on share-name-unicode
[13:50] <nessita> ralsina_: thanks!
[13:50] <dobey> nessita: well, tarmac is already doing this. i set the ulimit values, because a couple times in the past few days my machine has suddenly had u1trial using 1.4G+ of RAM
[13:50] <dobey> and i can't have that
[13:50] <nessita> this does not escale :-/
[13:51] <dobey> what do you mean?
[13:55] <dobey> in fact a branch just landed
[13:56] <nessita> dobey: I mean that I think we should not be depending on your server to land branches. I know why we're doing it, and I really appreciate the work you do in this regard, and I understand that we can't be killing your server with our tests mem usage. But I keep thinking we should not be using your personal server for this stuff.
[13:56] <nessita> dobey: I know, is the best option we have ATM
[13:57] <dobey> it doesn't matter where the server is
[13:57] <nessita> dobey: right. I would love to have someone (even me) debugging mem usage, but is not doable any time soon, which is a big :-(
[13:57] <ralsina_> if we had this running on EC2 and it used 2GB of ram it would fail anyway
[13:58] <dobey> ralsina_: and cost a fortune
[13:58] <ralsina_> yeah, that too
[14:00] <nessita> ralsina_: right, I mean we can't be killing someone's personal server with our test eating ram bug
[14:00] <ralsina_> dobey: I have a chance to hire a "VIP" 4GB of RAM VPS for U$S30 / month. Would that run tarmac?
[14:00] <ralsina_> because if it does, then I buy that for a month and we thingk it again after that
[14:00] <nessita> alecu, ralsina_, Chipaca: mumble?
[14:01] <ralsina_> nessita: ack!
[14:01] <dobey> nessita: we can't be killing any server with it.
[14:01] <nessita> dobey: agreed, but I prefer to kill a company's server than a employee's server. Anyways, I know we're not changing this any time soon.
[14:02] <dobey> ralsina_: i'd rather not move everything just to try it for a month and then have to move it all back. and i'd rather not put private ssh/gpg keys in an arbitrary cloud/vps/whateverbuzzword server
[14:03] <ralsina_> dobey: ok
[14:04] <mandel> nessita: we do have mumble, right?
[14:04] <nessita> Chipaca: you coming to mumble?
[14:04] <ralsina_> Chipaca is probably in the futures mumble
[14:04] <ralsina_> so let's start
[14:04] <mandel> ok
[14:04] <nessita> alecu: you fell?
[14:05] <alecu> nessita, my mumble is using 100% cpu and showing a grayed out window
[14:05] <nessita> alecu: :-/
[14:05] <nessita> alecu: shall we skype?
[14:06] <nessita> alecu: skype!
[14:06] <alecu> nessita, I just deleted the .conf and seems to be working
[14:06] <nessita> alecu: oh!
[14:06] <nessita> ralsina_: ^
[14:06] <ralsina_> alecu: we are moving to skype, I will be calling you all in 1'
[14:06] <alecu> damn
[14:06] <ralsina_> ok, back to mumble then :-D
[14:06] <alecu> it
[14:06] <alecu> I see the root but can't see any channels
[14:07] <ralsina_> ok, skype
[14:07] <alecu> "the remote host closed the connection"
[14:07] <alecu> damn mumble
[14:07] <nessita> alecu: you have the same issue I have in my laptop
[14:07] <ralsina_> and let's try a google hangout tomorrow ;-)
[14:07] <gatox> ralsina_, jejjeje
[14:07] <nessita> alecu: you should be prompt for your password, and you're not
[14:07] <gatox> diversity
[14:08] <ralsina_> alecu, mandel: I don't see you online in skype
[14:09] <mandel> nessita, ralsina_: who makes the call?
[14:09] <nessita> mandel: ralsina_
[14:09] <alecu> nessita, I remembered: "disable QoS in the advanced network settings"
[14:09] <ralsina_> I will call you again
[14:09] <alecu> and right, now mumble works for me :-(
[14:09] <alecu> opening skype anyway
[14:16] <dobey> thisfred: can you look at bug #823649 please?
[14:16] <ubot4> Launchpad bug 823649 in ubuntuone-client "continuous "Invalid UTF-8" notifications (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/823649
[14:16] <thisfred> dobey: not really
[14:18] <mandel> nessita: conflicts fixed and pushed for shutil.move
[14:20] <dobey> thisfred: :(
[14:21] <thisfred> dobey: what I can say, is that it's not likely in the notification code at all
[14:22] <thisfred> dobey: I did a quick search, and it's not there.
[14:23] <dobey> thisfred: i bet it's libnotify :(
[14:23] <thisfred> dobey: unless notifications themselves substitute that string when we send invalid bytes
[14:23] <thisfred> dobey: yeah, could well be
[14:23] <dobey> thisfred: well it can't be notify-osd i guess, because you can't send invalid utf-8 over dbus very easily :)
[14:24] <thisfred> dobey: we could do an .encode('utf-8', replace=True)
[14:24] <thisfred> or whatever that's called
[14:24] <dobey> so i suspect libnotify is parsing strings with pango or something
[14:24] <thisfred> dobey: so it'll send '?'s or boxes for the characters it can't parse
[14:25] <dobey> thisfred: i'm not sure. i also have seen bugs about syncdaemon not handling invalid utf8 filenames at all, and just ignoring them. so would be odd for notifications to happen with them
[14:25] <dobey> unless that's been fixed
[14:26] <thisfred> well, I wonder if we're not sending the wrong thing to libnotify. Maybe it wants utf-8 strings rather than unicode?
[14:27] <thisfred> dobey: pitti said his filenames were improperly encoded, so if that's true, sd does pick them up apparently
[14:27] <dobey> it certainly wants utf-8
[14:27] <dobey> that's poolie not pitti
[14:27] <dobey> no?
[14:27] <dobey> yes
[14:27] <thisfred> sry yeah
[14:27] <thisfred> TooManyMartins
[14:27] <dobey> right, hrmm
[14:28] <thisfred> well, I don't think we encode anything before calling libnotify
[14:28] <dobey> hrmm, facundo says it doesn't sync them
[14:29] <dobey> so anything that's not valid utf-8 really shouldn't be going to notifications at all
[14:29] <thisfred> but maybe we still get events for the file being added to the queue?
[14:36] <rodrigo_> I've just submitted a new evo-couchdb to oneiric, and it works ok with the system couchdb instance, but not with desktopcouch, so I'd appreciate some testing
[14:36] <rodrigo_> rye, ^
[14:38] <thisfred> dobey: the pynotify docstrings say nothing about it needing utf-8 rather than unicode
[14:39] <dobey> thisfred: no, but it's a glib/gtk app. and glib/gtk expect/use utf-8 for everything
[14:39] <thisfred> dobey: and it works perfectly when sending unicode, just tested
[14:39] <thisfred> a = pynotify.Notification(u'ö', u'ö', None)
[14:39] <thisfred> >>> a.show()
[14:39] <dobey> thisfred: were you sending unicode that was not utf-8?
[14:39] <dobey> no
[14:40] <thisfred> unicode is unicode, and not utf-8
[14:40] <rodrigo_> dobey, do we really want to keep supporting old e-d-s versions in evo-couchdb?
[14:40] <dobey> utf-8 is unicode, but all unicode is not utf-8
[14:40] <rodrigo_> dobey, the code is starting to look too ugly with so many #ifdef's
[14:40] <thisfred> dobey: false: in python, a unicode string is unicode and emphatically not utf-8
[14:40] <dobey> rodrigo_: yes; we have to support lucid for like 21 more months :(
[14:41] <dobey> thisfred: 'unicode' doesn't mean anything
[14:41] <rodrigo_> dobey, right, can't we just support it with the old evo-couchdb versions?
[14:41] <thisfred> dobey: it can be encoded to utf-8, and utf-8 can be decoded to unicode
[14:41] <thisfred> dobey: in python it definitely does
[14:41] <rodrigo_> dobey, apart from the ugliness, the API chjanges are introducing new bugs, I think
[14:41] <dobey> apparently not
[14:41] <rodrigo_> dobey, new bugs in versions I don't test at all
[14:41] <dobey> because what you pasted in irc was valid utf-8
[14:42] <thisfred> dobey: I suspect what we are sending to pynotify is not unicode but encoded strings
[14:42] <dobey> rodrigo_: we need to provide the latest ubuntuone expereience on all supported versions of ubuntu
[14:42] <rodrigo_> ok, then someone needs to do testing on old ubuntu versions
[14:42] <dobey> thisfred: try to shove KOI8-R in a python unicode object and send it to pynotify
[14:43] <thisfred> dobey: that's because it had to be encoded before it was printed. python keeps an internal representation for unicode strings, that is not utf-8
[14:43] <dobey> rodrigo_: yes, we try to keep building the nightlies on them, but have been failing lately for various reasons. and i haven't had time to fix the couchdb-glib/evo-couchdb nightly builds :(
[14:44] <thisfred> dobey, I don't know what that means. If it's decoded into unicode that will work.
[14:44] <rodrigo_> dobey, the build failure because of the not applying patch should be fixed now, in the oneiric branch
[14:45] <dobey> rodrigo_: did you make a new patch?
[14:45] <rodrigo_> dobey, yes
[14:45] <thisfred> dobey: anyway, I stand by my analyses: we somehow get filenames from sd that are still encoded, in an unknown encoding. We can't print those
[14:45] <dobey> rodrigo_: ok, thanks. hopefully i'll be able to fix that build soon then :)
[14:47] <dobey> thisfred: aren't those getting logged somewhere now?
[14:48] <thisfred> we can do unicode(filename.encode('utf-8', 'replace'), 'utf-8')
[14:49] <dobey> thisfred: and those files shouldn't end up in a queue that would get notifications sent anyway, since they would get dropped in local rescan, afaik
[14:49] <thisfred> true
[14:51] <nessita> ralsina_, mandel: can you please review https://code.launchpad.net/~nataliabidart/ubuntuone-client/clean-env-aq/+merge/71052 ?
[14:51] <dobey> oh well
[14:51] <dobey> it's not fatal
[14:51] <gatox> ralsina_, this is the last trace that i'm receiving from run-tests in ubuntuone-windows-installer: http://paste.ubuntu.com/662697/
[14:51] <ralsina_> nessita: on it!
[14:52] <gatox> if i removed LocalFoldersTestCase and MainWindowTestCase everything works ok
[14:52] <gatox> ralsina_,
[14:52] <gatox> ^^
[14:52] <ralsina_> gatox: give me 1' to see...
[14:52] <gatox> ralsina_, np
[14:53] <ralsina_> gatox: the localfolders tests we should probably redo from scratch because they have weird race conditions
[14:53] <dobey> unlike bug #823648
[14:53] <ubot4> Launchpad bug 823648 in ubuntuone-control-panel (Ubuntu) "ubuntuone-control-panel-gtk crashed with ImportError in /usr/lib/python2.7/dist-packages/ubuntuone-control-panel/ubuntuone/controlpanel/logger.py: cannot import name LOGFOLDER (affects: 4) (dups: 3) (heat: 32)" [Undecided,Confirmed] https://launchpad.net/bugs/823648
[14:53] <gatox> ralsina_, ok
[14:54] <ralsina_> and the others are clearly trying to tcp-activate something and they shouldn't
[14:54] <gatox> ralsina_, yep!
[14:54] <ralsina_> gatox: I think I know what
[14:54] <mandel> ralsina_: can you send me a private message with the url of the installer?
[14:55] <gatox> ralsina_, :D YEY!
[14:55] <ralsina_> gatox: if you check the MainWindow class, it does a find_credentials to see which pages to display
[14:55] <ralsina_> we should fake that
[14:55] <ralsina_> gatox: just a wild guess though ;-)
[14:55] <ralsina_> mandel: sure!
[14:56] <gatox> ralsina_, ok! MainWindowsTestCase has only 3 fails if i remove LocalFoldersTestCase anyhow... so, the major problem is in LocalFoldersTestCase, which one we should do from scratch as you mentioned
[14:56] <ralsina_> gatox: try commenting the find_credentials and rerun
[14:57] <gatox> ralsina_, did you mean to fix MainWindow tests?? or LocalFolders?
[14:57] <ralsina_> gatox: in the MainWindow class itsel
[14:57] <ralsina_> itself
[14:58] <ralsina_> if removing the find_credentials call fixes the tests, then that's what we have to fake :-)
[14:58] <gatox> ralsina_, ok... i'll try... but in MainWindow now that i remove LocalFolders, only the test for the overlay are failing
[14:58] <ralsina_> gatox: then, that's even better :-)
[14:58] <gatox> ralsina_, yep... there is no need to remove find_credentials from the MainWindow tests
[14:59] <gatox> ralsina_, i need to fix the test for the overlay....... and then redo LocalFolders
[14:59] <ralsina_> gatox: right
[15:00] <gatox> ralsina_, ok, on it!
[15:03] <dobey> nessita: interesting
[15:04] <dobey> nessita: so i just ran u1client tests twice in a row
[15:04] <nessita> dobey: I'm listening
[15:04] <dobey> Ran 2307 tests in 433.207s
[15:04] <dobey> Ran 2307 tests in 415.249s
[15:04] <nessita> oh
[15:04] <nessita> :-/
[15:04] <dobey> the second run is faster :P
[15:04] <ralsina_> dobey: that makes more sense than slower in most cases
[15:05] <dobey> nessita: and that is also with having ulimit set to 384M for resident, and 768M virtual
[15:06] <nessita> dobey: was that run with your regular user or inside "tarmac"'s env?
[15:06] <dobey> nessita: as tarmac
[15:06] <nessita> mandel: your shutil-move will not run tests on linux due to lint issues...
[15:06] <dobey> well as tarmac user, not under tarmac script
[15:06] <nessita> mandel: can you please confirm all tests passes in linux and re-ping me?
[15:07] <dobey> hmm
[15:08] <dobey> nessita: and those times match the times for successful runs in the tarmac logs
[15:10] <mandel> nessita: ahh, I keep forgetting, on it, sorry!
[15:10] <nessita> dobey: so, maybe when running several branches for landing we get another variable in place that is messing with our mem?
[15:11] <nessita> ralsina_: another review whe you have a slot: https://code.launchpad.net/~nataliabidart/ubuntuone-client/wb-test-hashqueue/+merge/71054
[15:11] <dobey> nessita: i think i found a bug in bzr...
[15:12] <nessita> dobey: related to this?
[15:12] <dobey> nessita: yes
[15:12] <nessita> dobey: I'm all ears and eyes
[15:12] <ralsina_> nessita: in about 15'
[15:12] <dobey> nessita: i am doing some testing on it. will get back to you :)
[15:12] <nessita> dobey: great
[15:12] <nessita> ralsina_: sure! thanks
[15:14] <nessita> mandel: can you please review https://code.launchpad.net/~nataliabidart/ubuntuone-client/clean-env-aq/+merge/71052 ?
[15:17] <mandel> I need something to run the tests on all platforms
[15:19] <dobey> nessita: maybe not. but i added some extra logging to tarmac, to get a little more info next time this happens
[15:20] <dobey> and will get some lunch now. am hungry hungry hacker
[15:20] <dobey> bbiab :)
[15:22] <thisfred> facundobatista: can you please remove your needs fixing? Others can you please review this so it can land?  https://code.launchpad.net/~thisfred/ubuntuone-client/reset-filenames/+merge/67386
[15:23] <alecu> nessita, do you want me to start by reviewing your previous branches?
[15:23] <mandel> nessita: is already fixed, sorry for that
[15:24] <nessita> alecu: that would be great, you know :-)
[15:24] <nessita> alecu: they are not complicated, most of the changes are "expected"
[15:24] <facundobatista> thisfred, done
[15:25] <thisfred> thx!
[15:32] <ralsina_> nessita: +1 on wb-test-hashqueue
[15:34] <ralsina_> nessita, mandel, alecu: we need to add a generic loggin exception hook for all windows binaries because of this: http://www.py2exe.org/index.cgi/StderrLog
[15:34] <ralsina_> nessita: would it be evil if I add that for windows too, in the cases where the binary is the same?
[15:34] <ralsina_> mandel, alecu: ^
[15:34] <ralsina_> s/for windows too/for linux too/
[15:38] <alecu> ralsina_, we should not be printing anything to stdout nor stderr, unless the DEBUG env var is set
[15:38] <alecu> ralsina_, if we are, shame on us :-)
[15:39] <ralsina_> alecu: it happens for uncaught exceptions
[15:39] <alecu> ralsina_, well, they *should* be handled by our loggers.
[15:39] <ralsina_> which on Linux are happily ignored, but on windows trigger a dialog either about the file where you can see them, or about how that file could not be created :-)
[15:39] <alecu> ralsina_, if they don't we should fix
[15:40] <ralsina_> alecu: exactly, we should use sys.excepthook to catch and log them
[15:40] <nessita> ralsina_: I think there is a twisted thingy to log all errors
[15:40] <nessita> ralsina_: shouldn't we use that?
[15:40] <ralsina_> nessita: even better
[15:43] <mandel> ralsina_: ping
[15:43] <ralsina_> mandel: pong
[15:43] <mandel> ralsina_: I get a permission denied when trying to write on the logs of the control panel on windows
[15:43] <ralsina_> mandel: check 5 lines above here ^  ;-)
[15:44] <ralsina_> mandel: it's harmless and I intend to fix it right now
[15:45] <mandel> ralsina_: did you get my last messagE?
[15:45] <ralsina_> mandel: yes. We have uncaugh exceptions, and then that happens
[15:45] <ralsina_> mandel: I was just asking about that 2 minutes ago here :-(
[15:45] <mandel> ralsina_: and I cannot longer start the control panel or sd :(
[15:45] <ralsina_> oops, :-)
[15:46] <ralsina_> mandel: what happens if you try to start them?
[15:46] <mandel> ralsina_: hehe, the problem is easy to solve, you should not be trying to write the logs there, they should go to AppData since the process is running under my user name and probably it does not like to write things in program files :)
[15:47] <mandel> ralsina_: the control panel got blocked, I killed it like an animal, then the sd was killed and I'm here
[15:47] <mandel> I think cleaning the metadata might fix it
[15:47] <ralsina_> mandel: yes, but that's actually done by py2exe
[15:47] <mandel> ralsina_: the logging?
[15:48] <ralsina_> mandel: tyes
[15:48] <mandel> ralsina_: what exactly does py2exe do ?
[15:48] <ralsina_> mandel: let me pastebin it ;-)
[15:48] <mandel> that is what she said!
[15:49] <ralsina_> mandel: http://pastebin.ubuntu.com/662757/
[15:49] <ralsina_> basically, it replaces stderr with a logfile
[15:49] <ralsina_> mandel: since it's stupid about where the logfile should be: :-P
[15:50] <mandel> ralsina_: let me take a look :)
[15:50] <ralsina_> mandel: so, I will avoid it by using sys.excepthook or some twisted thing nessita mentioned, which google is not finding for me
[15:50] <mandel> ralsina_: I have not been able to see the the code yet, internet is miss behaving...
[15:54] <mandel> ralsina_: funny thing http://pastebin.ubuntu.com/662757/ did not work for me but http://paste.ubuntu.com/662757/ did :P
[15:54] <mandel> ralsina_: is that sick thing coming from py2exe?
[15:54] <mandel> as in their code?
[15:55] <ralsina_> mandel: py2exe puts it on every "windows" exe
[15:56] <ralsina_> mandel: but we should work on our side not to trigger that crap, and presto, problem solved
[15:58]  * mandel is sad his windows u1 is very broken… :(
[15:59] <ralsina_> mandel: broken how?
[15:59] <mandel> ralsina_: there is an issue with that idea, if the los is written there we will have info from diff users which is a terrible idea
[15:59] <mandel> @ping
[15:59] <ubot4> pong
[16:00]  * nessita -> lunch
[16:00] <ralsina_> mandel: worse, since on any modern win that folder is read only :-)
[16:01] <ralsina_> so I either change this to be silent, or implement an excepthook. nessita, I can't find that twisted thing to log all errors :-(
[16:02] <nessita> ralsina_: facundobatista knows about that
[16:02] <ralsina_> facundobatista: nessita mentioned there is a thing in twisted to catch all exceptions and log them?
[16:02] <nessita> facundobatista: have a pointer to the thingy that we need to configure in twisted so everything, even unhandled error, are logged?
[16:03] <ralsina_> nessita: keep in mind that if the exc is logged and re-raised, it fixes nothing here
[16:04] <nessita> ralsina_: what kind of things you get logged to stdout/stderr?
[16:04] <nessita> ralsina_: have an example?
[16:05] <ralsina_> nessita: sure, here is one from the installer (which is stupid easy to fix): https://bugs.launchpad.net/ubuntuone-windows-installer/+bug/823655
[16:05] <ubot4> Launchpad bug 823655 in ubuntuone-windows-installer "no _next_id attribute in the license page (affects: 1) (heat: 6)" [Medium,Triaged]
[16:05] <facundobatista> ralsina_, nessita, yes
[16:06] <nessita> ralsina_: leaving the stderr thing aside, that is valid error, is it? so we do want the "error" dialog pop up in cases like this
[16:06] <ralsina_> nessita: yes, we want to know if these things happen. On test builds. On production builds... maybe just log them.
[16:07] <facundobatista> nessita, ralsina_, see "deferror_handler" here: http://bazaar.launchpad.net/~chicharreros/magicicada/trunk/view/head:/magicicada/logger.py
[16:07] <ralsina_> facundobatista: looking...
[16:08] <ralsina_> facundobatista, nessita: that's just for unhandled errors in deferreds, right?
[16:08] <facundobatista> ralsina_, yeap, but see that the very same module does something else for unhandled errors at normal Python level
[16:08] <ralsina_> nessita: what facundo shows is sys.excepthook, which is what I was about to use
[16:09] <ralsina_> facundobatista: yeah, got it
[16:09] <facundobatista> ralsina_, you need both
[16:09] <ralsina_> facundobatista: right
[16:10] <ralsina_> so, I would add something like this to every "bin" we have, for all operating systems. Is that a reasonable thing to do? nessita, alecu, mandel?
[16:10]  * ralsina_ is slightly scared about the change, though
[16:15] <ceramicm> Chipaca: I followed that guide, and now ubuntuone-syncdaemon is running. A window popped up and allowed me to sign up for Ubuntu One. An Ubuntu One folder was created in $HOME.
[16:16] <ceramicm> But the file I created there was not synced. And I don't have any Ubuntu One-related context menu entries in nautilus.
[16:22] <alecu> ceramicm, oh, the same happened to me today after I updated ubuntu. I had to manually install the ubuntuone-client-gnome package.
[16:22] <alecu> dobey, do you have any idea about this? ^
[16:22] <dobey> about what exactly?
[16:23] <nessita> ralsina_: so, I'm not sure why we're trying to "hide" the failures we might be having....
[16:23] <nessita> ralsina_: I think is best to have the failures popping up in our faces, unless until we do the final release
[16:23] <alecu> dobey, "I had to manually install the ubuntuone-client-gnome package"
[16:23] <ralsina_> nessita: it's not hiding, is that currently instead of seing the failures you get a popup telling you a log failed because of permissions
[16:23] <dobey> need more context
[16:23] <dobey> alecu: it probably got removed earlier; i presume you're running nightlies?
[16:24] <alecu> dobey, yes, nightlies
[16:24] <ralsina_> nessita: agreed that until release warning of exceptions is good
[16:24] <nessita> ralsina_: so, how can we be aware of all the failures if we add default handlers for them? that part is unclear to me
[16:24] <dobey> alecu: a couple weeks ago, it became uninstallable in nightlies, as the code was moved out to a separate project. so there was a version conflict. it became instalalble again yesterday, when i did the new release
[16:25] <dobey> alecu: but now, there is no ubuntuone-client-gnome in ubuntu, until i make a release of it and get it accepted in there
[16:25] <ralsina_> nessita: logging them and showing a dialog when they happen or at closing
[16:26] <dobey> alecu: transitions can be bumpy. :)
[16:26] <alecu> dobey, makes sense... thanks!
[16:27] <nessita> ralsina_: question: can't we just fix the log error for now?
[16:27] <ralsina_> nessita: not really because it's being created by py2exe in a very bad location. Unless I patch my py2exe, of course
[16:27] <ralsina_> which I would be happy to do
[16:28] <nessita> ralsina_: ah, I think I understand the issue... let me re-think this
[16:28] <ceramicm> alecu: I am not running Ubuntu. I am trying to compile and run Ubuntu One on Fedora.
[16:28] <alecu> ceramicm, cool!
[16:29] <alecu> ceramicm, you surely tried restarting nautilus after "make install", right?
[16:30] <ceramicm> alecu: Yes. Then I completely restarted the computer, to be sure.
[16:30] <ceramicm> alecu: Is nautilus 3 unsupported?
[16:30] <nessita> ralsina_: if we hook to default error handlers (both sys and twisted), can we raise the "something bad happened" windows-style-popup?
[16:30] <ralsina_> nessita: yes
[16:31] <ralsina_> nessita: not sure about twisted, unless it runs on the main thread
[16:31] <nessita> ralsina_: twisted *is* the main thread, isn't it?
[16:31] <alecu> ceramicm, the nautilus extensions in my natty are in /usr/lib/nautilus/extensions-2.0/libnautilus-ubuntuone.so
[16:31] <ralsina_> nessita: should be!
[16:31] <alecu> ceramicm, I don't know if nautilus 3 is supported. dobey, do you know about that?
[16:32] <alecu> nessita, ralsina_: twisted runs in the main thread, yes.
[16:32] <nessita> ralsina_: then I guess that sounds like a good things, if there is any unhandled error, open the "report problem" windows-dialog. Though if you will be modifying the bin scripts, we should make that multiplatform?
[16:32] <dobey> alecu: depends
[16:33] <dobey> ceramicm: can you be more specific about what you're trying to build exactly?
[16:33] <dobey> alecu: the gnome bits are no longer in ubuntuone-client tree
[16:33] <ralsina_> nessita: yes, and it would need a gtk implementation
[16:33] <nessita> ralsina_: why gtk?
[16:34] <ceramicm> dobey: I would like to sync my files using Ubuntu One (using whichever components are necessary) on Fedora 15.
[16:34] <nessita> ralsina_: aren't we using the default  error hooks from each system? ie apport in ubuntu, <something> in windows?
[16:34] <ralsina_> nessita: the exact same thing happens on linux + gtk except since it does nothing visible we are ignoring it :-)
[16:34] <ceramicm> dobey: per Chipaca's suggestion, I have used the guide here as a starting point: http://askubuntu.com/questions/10271/is-running-ubuntu-one-on-debian-possible
[16:34] <ralsina_> nessita: I don't know on linux. On windows there is no default error hook except "print to stderr"
[16:35] <dobey> oh
[16:35] <alecu> ralsina_: if we make the twisted logger to also write to stderr (in addition to the log files) we can get the dialog to appear automatically
[16:35] <dobey> ceramicm: i suppose that might be a bit out of date now
[16:35] <nessita> ralsina_: but I just asked if we can bind the  error to the "something bad happened" windows dialog, and I thought you said yes
[16:36] <dobey> ceramicm: also, it points at some very old branches, which wouldn't even build on fedora 15
[16:36] <ralsina_> nessita: ok, I misunderstood you. No, no standard for that, but I can put a generic message for that, and py2exe has one.
[16:36] <ralsina_> py2exe intercepts stderr, sends to a (misplaced) log, and if anything happens there, it shows a dialog.
[16:37] <ceramicm> dobey: After installing various dependencies, I compiled ubuntuone-client, configglue, lazr.restful, lazr.restfulclient, lazr.uri, ubuntuone-storage-protocol, and ubuntuone-sso-client.
[16:37] <dobey> ceramicm: from where exactly?
[16:38] <ceramicm> dobey: I downloaded the most recently released tarballs from each project's launchpad page.
[16:38] <dobey> ceramicm: ok. for ubuntuone-client that was 1.7.1?
[16:38] <ceramicm> dobey: Yes.
[16:39] <nessita> ralsina_: can we do something to have the windows error message appears on error, when running "via" py2exe?
[16:40] <dobey> ceramicm: that tarball does not have the nautlius extension in it any more. the gnome plug-ins have been moved out to the ubuntuone-client-gnome project instead. and there are still a couple of things in ubuntuone-client that are going to move out elsewhere as well, but are still there for the moment
[16:40] <dobey> ceramicm: so you will need ubuntuone-client-gnome as well, which i am about to release a tarball of today
[16:40] <nessita> ralsina_: I mean, can we tell py2exe do not write to anywhere, raise the exception?
[16:40] <ralsina_> nessita: not on error, without installing an excepthook. With an excepthook: yes.
[16:40] <ralsina_> nessita: yes, with an excepthook in the app, py2exe will not get the write in stderr and thus it will do nothing
[16:41] <ceramicm> dobey: Ok, thanks. That explains why the packages.ubuntu.com page for ubuntuone-client-gnome still points to source package ubuntuone-client.
[16:41] <nessita> ralsina_: so, I'm getting confused, this is what I asked before and I think I understand that you said no... maybe we can mumble about this after I finish my lunch, which I haven't gotten into yet to keep talking about this :-)
[16:41] <ralsina_> nessita: jeje, yes, of course :-)
[16:42] <ralsina_> nessita: buen provecho!
[16:43] <nessita> thanks!
[16:46] <dobey> ceramicm: right. well, that is correct for older versions of ubuntu, but will change in oneiric, as soon as i get the new source package uploaded.
[16:46] <ceramicm> dobey: Should items placed in my $HOME/Ubuntu One folder sync even without ubuntuone-client-gnome?
[16:47] <dobey> ceramicm: yes, assuming ubuntuone-syncdaemon is actually connected to the server; you can use u1sdtool -s to check the status. and u1sdtool -c to connect if it's not already connected
[16:49] <dobey> nessita: btw, ping loudly if you see another odd branch failure like the previous one, and i'll check the logs. it seems the only way to debug this is in production :)
[16:52] <mandel> nessita: ping
[16:52] <ceramicm> dobey: Interesting. ps -ef | grep ubuntuone-syncdaemon shows that the daemon is running, but after a u1sdtool -s it stops.
[16:53] <ceramicm> dobey: and I get an error: Failure: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[16:55] <dobey> ceramicm: check your ~/.cache/ubuntuone/log/syncdaemon-exceptions.log
[16:55] <dobey> ceramicm: should have an error in it, as it seems syncdaemon is crashing for some reason :(
[16:55] <mandel> nessita: I fixed the issued with the branch and ran the tests on windows and linux, I'll be here a couple of mins more
[16:56] <ceramicm> dobey: Yes, pastebin'd here: http://pastebin.com/wKvV2kjt
[16:57] <dobey> ceramicm: that's interesting. do you have an Ubuntu One token in your keyring?
[16:58] <nessita> mandel: ok
[16:58] <nessita> dobey: sure! thanks
[16:59] <ceramicm> dobey: How can I tell?
[17:00] <dobey> ceramicm: if you run seahorse, and search for ubuntu, it should show up in the list
[17:00] <mandel> @ping
[17:00] <ubot4> pong
[17:02] <nessita> mandel: docstrings are not accurate, they talk about "...can't monkeypatch gio.File.trash..."
[17:03] <ceramicm> dobey: Yes, there is one called "Ubuntu One". The token-name is "Ubuntu One @ <mycomputer>" and the key-type is "Ubuntu SSO credentials".
[17:03] <nessita> mandel: also, I would like to have a test that assert that the removed file/dir is actually inside the recycle bin
[17:03] <mandel> nessita: that is very very hard to do...
[17:03] <nessita> mandel: in linux or both?
[17:04] <mandel> nessita: in both, we do not have that test even on linux...
[17:04] <nessita> mandel: also, use ope_file instead open()
[17:04] <mandel> nessita: ok, on it
[17:04] <nessita> mandel: maybe in linux is too complex, is it also impossible in windows?
[17:04] <mandel> agg  should now all this I started the stupid os_helper!
[17:05] <nessita> mandel: also, os.path.dirname(self.testfile) is self.basedir....
[17:05] <nessita> mandel: any reason to call dirname instead of self.basedir?
[17:05] <dobey> ceramicm: interesting
[17:06] <dobey> ceramicm: can you check the logs in ~/.cache/sso/ to see if there any errors in them as well?
[17:06] <mandel> nessita: give me a sec, I'm looking into the trash issue
[17:06] <nessita> mandel: ok
[17:07] <nessita> alecu: how are reviews going? can I help somehow?
[17:09] <ceramicm> dobey: Everything looks normal in ~/.cache/sso/sso-client.log. And there are no other files in ~/.cache/sso
[17:11] <ralsina_> nessita: gatox has the tests under control except for the LocalFolders test case, which I will redo since it has been broken because of race conditions for a while. So, I think, after he has tests for the new code, we should land that   branch
[17:11] <mandel> nessita: I could translate the following http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/05e3628d-5d08-4cea-8821-d5302139cc0d/ to python using either ctypes or pywin32 and we could find that an item in the recycle bin had the same path when it was deleted, but that does not guarantee that is the correct one
[17:11] <dobey> ceramicm: no ERROR lines at all? :(
[17:11] <nessita> ralsina_: can I review?
[17:12] <mandel> nessita: where did you see the use of open?
[17:12] <dobey> ceramicm: if you run u1sdtool -s again, does it start up and show you status, or same error again?
[17:13] <nessita> mandel: no need for now, thanks for researching
[17:13] <ceramicm> dobey: I did a cat .cache/sso/sso-client.log | grep -i "error" to be sure. Still no errors in that log.
[17:13] <nessita> mandel: setUp for the new test case
[17:14] <dobey> ceramicm: ok, quite odd. this stuff is all installed correctly, yes?
[17:14] <alecu> nessita, left the test running, and forgot to approve. I'm reviewing the last one, but I'm going to the bank right now.
[17:15] <ceramicm> dobey: Same error with u1sdtool -s. I believe so, but could I have missed a step when I compiled?
[17:15] <nessita> alecu: ack
[17:15] <ralsina_> nessita: of course, when he proposes. He is writing the tests for pages 18 and 19 now
[17:15] <nessita> mandel: question, why would you use this: shutil._destinsrc(path_from, path_to) instead of path_from == path_to?
[17:15] <nessita> ralsina_: great
[17:16] <nessita> mandel: I'm not comfortable using "private" things from shutil....
[17:16] <alecu> nessita, I'm setting the first one to globally "Approved", we should do it in the second when the first lands.
[17:16] <nessita> alecu: I'll do it, thanks a lot!
[17:17] <dobey> ceramicm: maybe. can you pastebin all the commands you ran to build/install the various pieces?
[17:17] <mandel> nessita: well I could reimplement the exact same method with no worries, I just wanted so make sure we use the same logic
[17:18] <nessita> mandel: but what logic is needed besides path_to == path_from?
[17:18] <nessita> mandel: I'm basing my assumption in the error message, that reads: 'Cannot move %r to %r since its the same path'
[17:19] <mandel> nessita: the error message is wrong, is should say the same or child path of
[17:19] <mandel> that code ensure that we do not move the path in itself, take a look at the shutil implementation
[17:20] <nessita> mandel: what else do we need to check other than path_to == path_from?
[17:23] <mandel> nessita: give me a min
[17:23] <nessita> mandel: shall we pick up this tomorrow? you're passed your eod
[17:23] <mandel> nessita: let me check the path_to and path_from and we can continue tom
[17:25] <nessita> mandel: I added some more needs fixing to the MP (easy ones, I think)
[17:25] <mandel> ok
[17:26] <nessita> mandel: you're about to break some records in this MP ;-)
[17:27] <mandel> nessita: haha for needs fixing? yeah I'm starting to feel stupid hehe
[17:27] <nessita> lol
[17:28] <mandel> nessita: the logic that we need is the following: http://paste.ubuntu.com/662837/
[17:29] <mandel> nessita: is not terribly complicated, but I did not want to copy the code and wanted to ensure that we did use the exact same one just in case
[17:29] <mandel> and if it changes, our test will brake, right?
[17:29] <nessita> mandel: dumb question.... why don't we use shutil.rmtree ourselves?
[17:30] <nessita> mandel: it works (TM)
[17:30] <mandel> nessita: I'm going, but mainly because I'm running out of credit in the cafe :)
[17:30] <mandel> nessita: the error message is wrong, is should say the same or child path of
[17:30] <mandel> 19:19
[17:30] <mandel> that code ensure that we do not move the path in itself, take a look at the shutil implementation
[17:31]  * mandel leaves 
[17:31] <dobey> that is weird logic in that pastebin, mandel
[17:31] <nessita> mandel: ok, let's talk tomorrow, I'll leave this question in the MP
[17:31] <mandel> dobey: is piss easy I know :)
[17:31] <mandel> dobey: I just did not want to copy it
[17:31] <dobey> mandel: just weird, "if ends with /, add another /" doesn't make sense to me :)
[17:31] <dobey> anyway
[17:31] <nessita> mandel: I think we should use shutil.rmtree in the windows implementation, but let s talk tomorrow
[17:32] <dobey> mandel: go have a beer :)
[17:32] <nessita> dobey: if it does not end with... add...
[17:32] <nessita> if not src.endswith(os.path.sep):
[17:32] <mandel> nessita: issue there is that shutil.rmtree uses os.remove which will brake
[17:33] <nessita> mandel: why will it break?
[17:33] <dobey> nessita: oh right. but that still seems broken
[17:33] <dobey> since if you pass a path to an actualy file, it will try to remove fiename/
[17:34] <mandel> nessita: nothing, I understood you wanted it to use it dirrectly, but I guess you want to add a decorator…
[17:34] <mandel> nessita: I had a brain fuck
[17:34]  * mandel needs to go
[17:34] <ceramicm> dobey: I think this is everything (took it from yum history and ~/.bash_history): http://pastebin.com/1KnvAyWp
[17:34] <nessita> mandel: go!
[17:34] <nessita> dobey: maybe that code is meant to be use only for dirs, is a private method
[17:34] <mandel> nessita, dobey: I'l; see you tom :)
[17:35] <dobey> nessita: well, rmtree() on not a dir should fail, yes; but should fail with "not a directory" rather than "directory doesn't exist", i think :)
[17:35] <dobey> nessita: that code is in shutil or proposed in mandel's branch?
[17:35] <nessita> dobey: inside shutil inners
[17:36] <dobey> ceramicm: thanks, i will review it, and let you know if i see anything odd
[17:36] <dobey> nessita: eww
[17:36] <nessita> dobey: but is taken out of context
[17:36] <dobey> although it's in corelib, so i guess it probably hasn't been touched since it was added to python core :)
[17:38] <ceramicm> dobey: When I cleaned up the bash_history, I left out a cd u1. New paste: http://pastebin.com/Q0Ysh3aa
[17:38] <dobey> ceramicm: ok. thanks
[17:39] <ceramicm> dobey: Thank you for the help.
[17:58] <dobey> ceramicm: hrmm. i don't think this is the problem, but you probably want to use --sysconfdir=/etc with ./configure in ubuntuone-client
[17:58] <ceramicm> dobey: Ok.
[17:58] <dobey> and that command for running it from the tree isn't exactly correct
[17:59] <dobey> but no matter, since you don't need to run it from the tree, if you've installed it
[17:59] <ceramicm> dobey: In other words, I don't need the PYTHONPATH commands?
[18:00] <dobey> hrmm, i need to do an ubuntuone-storage-protocol release too
[18:00] <dobey> ceramicm: you don't need to do any of that to run it. and in fact, if you've installed it, then it should start up when you log in, given you've authenticated and have token in the keyring
[18:01] <dobey> or well, it should after re-building with --sysconfdir=/etc and installing again
[18:02] <dobey> but i don't see any obvious reason why this specific error would happen through your build/install process :(
[18:02] <dobey> facundobatista, nessita, verterok: ^^ any ideas why syncdaemon would raise NoAccessToken error when there is a token in the keyring?
[18:03] <nessita> dobey: there could have been a failure, like not being able to connect to sso
[18:03] <nessita> dobey: have logs? both syncdaemon's and sso's
[18:04] <dobey> nessita: ceramicm grepped for 'error' (case insensitive) in the sso logs and no results. and syncdaemon-exceptions.log is thus: http://pastebin.com/wKvV2kjt
[18:05] <dobey> ceramicm: can you post syncdaemon.log somewhere maybe?
[18:05] <dobey> ceramicm: ~/.cache/ubuntuone/log/syncdaemon.log
[18:05] <nessita> dobey: ah, so, since we get a CredentialsNotFound, that means SSO answered and there are no crendetials (at least that is what SSO thinks)
[18:05] <nessita> dobey: I would need the sso log, ~/.cache/sso/*.log
[18:06] <nessita> dobey: confirmed there was no error between sso and syncdaemon
[18:07] <dobey> nessita: which is odd, because he looked in seahorse and the token is there; weird.
[18:07] <dobey> ceramicm: ^^ can you give nessita the files she's asking for please? :)
[18:07] <nessita> dobey: then maybe the gnome-keyring service is failing to retrieve it?
[18:07] <ceramicm> dobey: I deleted it because I am reinstalling right now, but I can still get it from trash if you'd like.
[18:08] <dobey> nessita: no idea
[18:08] <dobey> ceramicm: please. and let us know if it works again after installing with --sysconfdir=/etc. thanks
[18:09] <ceramicm> dobey: Ok. I deleted the key from seahorse, and deleted "~/.local/share/ubuntuone", "~/.cache/ubuntuone", and  "~/.config/ubuntuone". Then I recompiled and installed all of the components I listed.
[18:09] <dobey> ceramicm: ok
[18:09] <dobey> ceramicm: same error?
[18:10] <ceramicm> Restarting now.
[18:16] <ceramicmm> Rebooted and ran u1sdtool -c. Results: http://pastebin.com/ZirMg0H7
[18:16] <ceramicmm> There is no Ubuntu One key in seahorse now, though, because I deleted it before reinstalling.
[18:17] <dobey> ok
[18:18] <dobey> ceramicmm: can you please get the logs nessita asked for?
[18:19] <ceramicmm> dobey: Sure. Which logs again?
[18:19] <nessita> dobey: he said there is no Ubuntu One key in seahorse, shouldn't we first fix that? :-)
[18:19] <dobey> nessita: and there never will be if sd can't talk to sso, which appears to be the problem now, with that latest paste
[18:19] <dobey> ceramicmm: ~/.cache/sso/*.log
[18:20] <dobey> ceramicmm: also, can you paste the contents of /usr/share/dbus-1/services/com.ubuntu.sso.service ?
[18:22] <nessita> dobey: is tarmac, by any chance, "stucked"? https://code.launchpad.net/~nataliabidart/ubuntuone-client/clean-env-aq/+merge/71052 is been approved for an hour now
[18:22] <ceramicmm> ~/.cache/sso/sso-client.log: http://pastebin.com/ThQKNyGY
[18:23] <dobey> nessita: there is a weird bug indeed, with the logging i added it seems. stupid python ''.format()
[18:24] <ceramicmm> /usr/share/dbus-1/services/com.ubuntu.sso.service: http://pastebin.com/CHLCYqgK
[18:24] <nessita> dobey: thanks. Once that lands, would you please do me a favor an approve https://code.launchpad.net/~nataliabidart/ubuntuone-client/wb-test-hashqueue/+merge/71054 ? I need to run to the university in 5 minutes
[18:25] <dobey> nessita: is it dependent on the first?
[18:25] <nessita> dobey: yeah...
[18:26] <ralsina_> nessita: do you have 2' for mumble about the stderr/exception/etc situation before leaving?
[18:26] <dobey> nessita: oh, ok. boo. :)
[18:26] <ralsina_> nessita: should be really quick
[18:26] <nessita> ralsina_: oh, right!
[18:26] <nessita> yes
[18:27] <nessita> ralsina_: I'm there
[18:27] <dobey> ceramicmm: is ubuntu-sso-login running currently?
[18:27] <ralsina_> nessita: starting mumble, is taking a bit
[18:27] <dobey> oops, i see a typo
[18:27] <dobey> in the log messages
[18:27] <dobey> but not related to the bug
[18:28] <ceramicmm> dobey: "bash: ubuntu-sso-login: command not found..."
[18:28] <ceramicmm> dobey: That's weird. Is that a byproduct of my recent attempt at reinstallation?
[18:28] <dobey> ceramicmm: right, it should be installed as /usr/lib/ubuntu-sso-client/ubuntu-sso-login
[18:28] <dobey> ceramicmm: no, it's not installed in $PATH, because it's not something users are supposed to run randomly
[18:29] <ceramicmm> dobey: Ok, makes sense. It is installed at /usr/lib/ubuntu-sso-client/ubuntu-sso-login. Should I run it?
[18:30] <dobey> ceramicmm: try to run it and see what happens please, yes
[18:34] <ceramicmm> dobey: It is running without any feedback. I pasted ~/.cache/sso/sso-client.log here: http://pastebin.com/xtE3pGaK
[18:34] <dobey> ceramicmm: ok, in another terminal, can you try u1sdtool -c again?
[18:36] <ceramicmm> dobey: Same error as before. System Monitor shows both ubuntuone-syncdaemon and ubuntuone-sso-login running.
[18:37] <ceramicmm> dobey: syncdaemon just quit.
[18:38] <dobey> ceramicmm: ok, can you pastebin ~/.cache/ubuntuone/log/syncdaemon.log and ~/.cache/ubuntuone/log/syncdaemon-exceptions.log please?
[18:39] <ceramicmm> dobey: Neither file exists.
[18:40] <ceramicmm> dobey: ~/.cache/ubuntuone/log is completely empty.
[18:40] <dobey> huh
[18:40] <dobey> weird
[18:41] <ceramicmm> Yes, because it had files before I installed.
[18:41] <ceramicmm> *reinstalled
[18:41] <nessita> ok, I gotta run!
[18:41] <nessita> bye all
[18:42] <dobey> ceramicmm: right, from the previous run of ubuntuone-syncdaemon
[18:43] <ceramicmm> dobey: Correct.
[18:43] <dobey> ceramicmm: can you run /usr/libexec/ubuntuone-syncdaemon --debug (i think that's where it is), in a terminal?
[18:45] <ceramicmm> dobey: Lots of output: http://pastebin.com/9mprxczJ
[18:46] <dobey> ceramicmm: ok, great; and it's still running then?
[18:46] <ceramicmm> dobey: More was just added to the end: 2011-08-10 13:45:41,449 - ubuntuone.SyncDaemon.Main - NOTE - ---- MARK (state: <State: 'READY'  (queues WORKING  connection 'Not User With Network')>; queue: 2; hash: 0) ----
[18:46] <ceramicmm> dobey: Yes.
[18:49] <ceramicmm> There are various logs in ~/.cache/ubuntuone/log now. Should I post any?
[18:53] <dobey> ceramicmm: no, it's ok for the moment. can you open another terminal and run u1sdtool -c in it, and let me know what happens in the terminal where ubuntuone-syncdaemon is running?
[18:54] <ceramicmm> dobey: The Create Ubuntu One account window popped up.
[18:54] <dobey> ceramicmm: hooray. log in then :)
[18:56] <ceramicmm> dobey: I did, and got a message saying that the connection was successful. Then a gnome notification popped up saying that my file "testfoo" was being uploaded to my personal cloud.
[18:57] <dobey> ceramicmm: hooray! and ubuntuone-syncdaemon keeps running?
[18:58] <ceramicmm> dobey: No. There was an error that terminated it. System Monitor continued to display the process for a while, but it just removed it as well.
[18:59] <dobey> ceramicmm: ok, can you pastebin the errors please?
[19:01] <ceramicmm> dobey: This is the ubuntuone-syncdaemon terminal output from the time I ran u1sdtool -c: http://pastebin.com/81LkeAEQ
[19:03] <ceramicmm> dobey: And although the Ubuntu One Client claimed that "testfoo" was uploaded, I don't see it in one.ubuntu.com/files
[19:07] <dobey> ceramicmm: "is being uploaded" != "was uploaded successfully" it means it was in the queue. if syncdaemon died, then it won't show up
[19:08] <dobey> ah-hah
[19:08] <ceramicmm> dobey: My mistake. Wishful reading.
[19:08] <dobey> he request 'oauth_authenticate' failed with the error: oauth_authenticate() takes exactly 3 arguments (4 given) and was handled with the event: SYS_UNKNOWN_ERROR
[19:08] <dobey> that's not good
[19:09] <ceramicmm> dobey: I installed python-oauth for dependencies. Should I have installed python-oauth2 instead? Should I install liboauth and liboauth-devel?
[19:09] <dobey> no
[19:10] <dobey> what version of python-oauth do you have?
[19:10] <ceramicmm> dobey: 1.0.1-3.fc15
[19:14] <dobey> ok, that should be ok then
[19:21] <dobey> ceramicmm: could you file a bug against ubuntuone-client at https://bugs.launchpad.net/ubuntuone-client/+filebug please, and attach your syncdaemon-exceptions.log and syncdaemon.log?
[19:21] <ceramicmm> dobey: Sure.
[19:23] <dobey> ceramicmm: sure. i'm sorry it's not working for you. i'm pretty sure a couple of people have gotten it working on F15 before, but there have been lots of changes lately that might affect that. hopefully we can get things working for you in the next couple days.
[19:37] <ceramicmm> dobey: Bug filed here: https://bugs.launchpad.net/ubuntuone-client/+bug/824143 Thank you for all your help!
[19:37] <ubot4> Launchpad bug 824143 in ubuntuone-client "ubuntuone-syncdaemon crashes with oauth error on Fedora 15 (affects: 1) (heat: 6)" [Undecided,New]
[19:37] <dobey> ceramicmm: great, thanks!
[19:59] <ralsina_> gatox: trivial branch -- https://code.launchpad.net/~ralsina/ubuntuone-windows-installer/fix-823655/+merge/71105
[20:01] <gatox> ralsina_, on it
[20:45] <dobey> ceramicm: hi
[20:45] <ceramicm> dobey: Hello.
[20:45] <dobey> ceramicm: can you install http://launchpad.net/ubuntuone-storage-protocol/trunk/1.7.0/+download/ubuntuone-storage-protocol-1.7.0.tar.gz ? i think it fixes your problem
[20:47] <ceramicm> dobey: I think you are probably right. I was reading through old irc logs for #ubuntuone (http://irclogs.ubuntu.com/2011/08/04/#ubuntuone.txt) and found the same error. It seems that a new version of ubuntuone-storage-protocol fixed it in that case.
[20:48] <dobey> ceramicm: yes, i remembered today that there were some changes that required new version, and i forgot to make a release of it yesterday along with ubuntuone-client. but just made a tarball release
[20:54] <ceramicm> dobey: It works! Thanks dobey!
[20:54] <ceramicm> dobey: I'm closing the bug now.
[20:54] <dobey> ceramicm: please don't close it
[20:55] <ceramicm> dobey: Ok. I added a note that ubuntuone-storage-protocol version 1.7.0 fixes the issue.
[20:57] <ceramicm> dobey: Is there any more information I should add to the bug?
[20:57] <dobey> ceramicm: nope. i got it under control. thanks :)
[20:59] <dobey> ceramicm: is your /tmp full of files created by ubuntuone-syncdaemon?
[21:00] <nessita> hello everyone!
[21:00] <ceramicm> nessita: Hello.
[21:00] <ceramicm> dobey: I don't think so. What would such files be named?
[21:01] <dobey> ceramicm: i'm not sure. probably not since it just quit for you
[21:03] <nessita> alecu: hey there, how is it going?
[21:12] <gatox> ralsina_, i'm almost finishing with the test... and i'll let you know for the review
[21:12] <ralsina_> gatox: cool. I will include that branch in the installer tonight
[21:13] <gatox> ralsina_, awesome
[21:41] <gatox> ralsina_, FINALLY REVIEW: https://code.launchpad.net/~diegosarmentero/ubuntuone-windows-installer/ui-improves/+merge/71116
[21:42] <ralsina_> gatox: will try to do it later tonight :-)
[21:42] <gatox> ralsina_, great! ask if you have any doubt or there is something that needs fixing... i'll probably be connected :P
[21:42] <nessita> gatox: I'll review as well!
[21:43] <gatox> nessita, great!
[21:43] <dobey> alright all, have a good evening!
[21:43] <gatox> dobey, good bye
[21:43] <ralsina_> I will add it to the build anyway for ui feedback
[21:43] <nessita> bye dobey
[21:43] <ceramicm> dobey: Bye, thanks again!
[21:44] <gatox> nessita, ralsina_ now i can say that i understand tests better!
[21:44] <nessita> gatox: we'll keep throwing hard things at you so you keep learning! :-D
[21:44] <gatox> nessita, nice! :D
[22:05] <ralsina_> gatox: if you saw the movie "dodgeball", it's like that ;-)
[22:09] <nessita> bye all!
[22:09]  * nessita -> gone
[22:37] <gatox> ralsina, yes, i watched it... but the crazy old man throw tools to the face! :P
[22:38] <gatox> scary.... jjee
[22:40] <ralsina> same general concept, but with code ;-)
[22:42] <gatox> ok...... EOD... i'll be back after the cinema if anyone needs something! bye!
[22:42] <gatox> ralsina, ^ ... like fixing something in my branch :P
[22:43] <ralsina> gatox: STOP WORKING SO MAY HOURS. Thanks :-)
[22:43] <gatox> ralsina, okok...... but i'm always connected... so it doesn't bother me if i have to take a look at something jeje
[22:43] <gatox> byebye
[23:40] <ceramicm> Should I have a libsyncdaemon-1.0.so somewhere after compiling ubuntuone-client?
[23:46] <fagan> ceramicm: all the devs are off the clock at this time
[23:47]  * fagan is only on because IRC is in the background 
[23:47] <ceramicm> fagan: Ok, thank you.