=== gafton_ is now known as gafton === Bolle1961_ is now known as Bolle1961 [13:50] desktopcouch group therapy session start [13:50] * aquarius grins [13:51] Problem: we want to restrict users from writing/replicating specific views to the cloud [13:52] Not because we like restricting people, but the views we actually execute on the cloud could bring our whole system to its knees if a clever person put some bad JS in them [13:52] that is probably the *only* thing we want to restrict though [13:52] got an example of one that needs to be blocked? [13:52] and that seems to be hard [13:52] we're not restricting _utils? [13:52] hi [13:53] hola jan [13:53] statik: not sure yet [13:53] statik: would be awesome if we didn't have to [13:53] statik, the views that funambol exchange uses, for example; we don't want someone to hack that view so it loops infinitely, hanging our funambol exchange process and eating our cpu time [13:53] statik, I'd really like people to have access to futon in the cloud, if we can't think of a reason why they shoudln't have it [13:54] jan____, the problem we're discussing is as thisfred says above: we want to give a user control over all their DBs in the cloud, but we don't want them to be able to edit views that we put in those DBs [13:54] jan____, but I don't know how to limit an admin, cos they're, well, an admin [13:54] aquarius, because they can replicate their db and use futon on the desktop [13:54] they might start building websites that use it as a datastore, and traffic might get too big [13:55] statik, part of the point of the web UI is that you can get at data from other platforms, no? [13:55] statik, and from computers that aren't yours. Else, why have a web UI at all? We don't need to do extra work to create futon, it already exists. [13:56] aquarius: I'd block view URLs GET requests via nginx [13:56] statik: I'm not saying that we should open _utils, just that it'd be kinda cool if we could. The real problem is: how do we use validators in a way that admin users can't get around them. [13:57] jan____, GETting a view isn't a problem, I don't think, it's PUTting a view... [13:57] we will be running apache as a proxy already to unwrap the SSL and do load balancing, so jans suggestion seems pretty good [13:58] and since replication is as yet unfiltered, blocking PUT isn't a solution if I understand everything (which I may not) [13:58] aquarius: putting a view doesn't burn any CPU cycles. indexes are generated on-read [13:59] jan____: the problem: we run views on the cloud, if a user maliciously or stupidly modifies that view, we're hosed [13:59] so we want a validator [13:59] jan____, ah, but we do need to GET the view. What I mean is, the user PUTs a view which eats CPU time when executed, and then later we GET it (not protected by nginx because we're already in the cloud) [13:59] that disallows specific views to be written to the cloud [14:00] which is hard, if the user is an admin, or isn't it? [14:00] creating a view means updating a design doc. [14:00] perhaps not, if we block all write access to the user database [14:01] jan____: 1. can I create a write validator that only allows write from a single specific user? [14:02] and 2. what happens if validation fails during replication? I read some disturbing messages on the mailing list that seemed to imply replication fails entirely in that case? [14:05] thisfred: this was probably mattetti, we don't have a bug report yet. [14:05] thisfred: validate_doc_update has userCtx to work with. [14:06] thisfred: replication is supposed to skip docs it isn't allowed to write. if there's a crash, that's a bug. but I've seen it work correctly [14:07] jan____, if we protect "our" views with a validator, can that validator also protect itself (so the admin user can't overwrite or remove the validator itself?) [14:08] ok, so that's good news [14:09] hey kenvandine, i want the ubuntuone hackers to get a lot more hands on with packaging of our stuff, especially with desktopcouch so that we are handing off stuff that is ready to be uploaded by a sponsor directly. currently Vcs-Bzr points to a branch that I don't have commit access to, and I want to change that. any thoughts? [14:09] aquarius' question is a good one, though, but I think the validate_doc can protect itself [14:10] aquarius: thisfred: I'd put "admin" views into their own design doc [14:11] jan____, and then check for (and prevent) updates to that design doc in validate_doc_update, unless those updates come from a specific user (us, not the db owner) [14:11] jan____: and then protect them to be only writable by the "superadmin" and all other admins would not be able to sneak anything past, right? [14:11] thisfred, jan____, did you guys figure out the SSL thing? without that, we won't be exposing couchdb to any users at all [14:12] statik: do what we do with ubuntuone-{storage-protocol,client} [14:12] jan____, if we (our user, not the user's user :)) are an admit, does the actual user have to be an admin as well in order to write documents and create databases? [14:12] dobey, what's that? [14:12] statik: I don't know of any "that SSL thing" [14:12] dobey, tell me more! [14:12] ah, right, another question (I asked on #couchdb before, but at a bad moment I guess) can we use https for replication at all? [14:12] aquarius: no, but to create design docs he needs to be [14:13] there is no SSL in couchdb [14:13] there's a patch to mochiweb that enables it [14:13] statik: lp:~ubuntuone-control-tower/ubuntu/karmic/$PROJECT/karmic <- this is what we have in Vcs-Bzr for them, and it's where i do the packaging [14:13] but I don't know how good it is [14:13] dobey, that sounds perfect [14:13] poauth will be the same [14:13] jan____, ah, ok, which means that if he creates a design doc in his local couch and then replicates it to the cloud, he'd need to be an admin [14:13] yes [14:14] so he needs to be an admin, OK. :) [14:14] (because apps that use desktopcouch will write views into their DBs, especially in the New World Order of no _temp_view :)) [14:14] aquarius: but we do want to allow all design docs to be replicated that we *don't* run [14:14] jan____, the patch is in the bugtracker or something? the thing about https is that we won't be allowing anyone to replicate couchdb from ubuntuone.com except via https, we sorta assumed all http clients also supported https. so this could block the whole thing from being turned on for karmic [14:15] s/could/will/ [14:15] dobey, do those branches have just the debian/ dir or everything? [14:16] statik: I remember talking to you guys about SSL and it wasn't an issue before [14:16] that may have been a miscommunication then [14:17] we can't send stuff over the net in the clear, especially things like contacts information [14:17] statik: the contents of the release tarball, plus the debian dir [14:17] statik, what you want to do is always pull from the branch in Vcs-Bzr and make your changes and push it somewhere [14:17] statik: as that is how james_w explained to me that source package branches work [14:17] statik, then propose that branch fro sponsoring [14:17] thisfred: you need ssl client support for the replicator then? [14:17] statik, hopefully we will start using merge proposals :) [14:18] jan____, it's not an issue for peer-to-peer replication (two machines on the same network), but it is for desktop-to-cloud [14:18] kenvandine, so i want to change the package so the official Vcs-Bzr branch is not pointing to an ~ubuntu-desktop owned branch [14:18] jan____: yep, most importantly, the server we could handle in a proxy I guess [14:18] * dobey wonders if anyone actually uses OAuthClient [14:18] statik, also when you do that, you always want to set the release to UNRELEASED [14:18] statik, ideally the branches in Vcs-Bzr is a branch maintained by the distro team [14:18] so core-dev, desktop, etc [14:18] why? [14:19] thats not how it's been explained to me in the past [14:19] thisfred: i.e. POST /_replicate {"source":"user", "target":"https://ubuntuone.com/user"} should work? [14:19] statik, well everyone seems to have different opinions [14:19] jan____: yes [14:20] statik, hang on a few [14:20] sure [14:20] thisfred: lessee [14:21] kenvandine, btw i'm planning to put desktopcouch into debian so i might delete Vcs-Bzr completely depending on how discussions go with debian [14:21] statik, well our's will need Vcs-Bzr [14:21] but in debian no [14:23] so my understanding is that using sourcepackagebranches is totally optional, and there is a daemon somewhere that is automatically making sourcepackagebranches based on what is uploaded to the archive [14:24] thisfred: for SSL in the past, I think SteveA talked about a transport thingie that you guys have (forgot the name) that makes an SSL tunnel to the server and give couchdb a local http endpoint [14:24] jan____, thats on the server side. we don't want to set up stunnel on every single ubuntu desktop [14:25] jan____: ah yes, that was an earlier plan, we didn't end up having that channel though [14:25] * thisfred kicks self [14:27] alright, I didn't know that [14:27] of course nobody thought the implications through when we abandoned that, because there wasn't an actual point in time where we sat down and made the decision [14:28] that would be far too practical [14:28] who's not here that we can blame? [14:28] /kick stevea [14:28] :D [14:29] I'll be gone in a few hours if you need a scapegoat. :) [14:29] hehe [14:29] aquarius: I'd like to resolve the oauth issue [14:30] jan____, yes. Does my test script correctly exhibit the problem for you? (that users from the ini file are not read by the oauth handler?) jasondavies acknowledged that that was an issue with the original code, and his patch was meant to fix it, but it doesn't work for me [14:31] aquarius: whoops, I missed that link [14:34] * aquarius pokes dobey in the eye about the wireless power comment :) [14:36] haha [14:38] dobey, by wireless power I mean: I can make it work in my living room, so if I'm anywhere in that room my phone is being charged. WHlie the Touchstone is sweet, it's not what I was talking about :) [14:38] jan____, got the link now? (sorry) [14:38] Ah you have a big tesla coil then? [14:39] * rmcbride stabs his router [14:39] aquarius: yeah [14:39] rmcbride, I did not mention there: I can walk about in my living room without (a) my skeleton flashing on and off and (b) being infertile for a month afterwards [14:39] fucking autotools, btw [14:39] jan____, there is a reason I hack Python. ;) [14:39] aquarius: you can't get around it though :/ [14:40] aquarius: yes, sure. but the touchstone doesn't fill the room with EMR either :) [14:40] aquarius: yea but with a tesla coil you can cackle like a mad scientist convincingly. Add a Jacob's Ladder and you can build golems out of body parts [14:40] statik, yes source package branches are optional... but far easier to deal with :) [14:42] every time you want to get something sponsored, you should rebase your branch on what is in Vcs-Bzr and merge in your changes... being careful to maintain the changelog entries [14:42] kenvandine, for sure! i need to get the dozen or so packages that ubuntuone-hackers are maintaining into a cohesive state, and having the official packaging branch owned by ~ubuntu-desktop doesn't fit into that plan very well [14:42] statik: i'm guessing any packages that become straight imports from debian will continue to be automatically stuffed into source package branches [14:43] so the changelog is identical to the latest source package, with no ~ppa versions... etc [14:43] statik: whether or not ~ubuntu-desktop owns the "official (as in ubuntu)" branch is irrelevant [14:43] statik, actually i think it should make it easier [14:43] statik, you probably want a ppa packaging branch too [14:44] so you maintain that, then when you need to get a version sponsored for ubuntu [14:44] statik: in the end the "official (ubuntu)" one should just be a copy of our "official (u1)" branch [14:44] you checkout the official one, merge in your branch... and clean up the changelog [14:44] just collapse all the changelog entries since the last version in ubuntu [14:44] into one [14:44] and set the release to UNRELEASED [14:45] kenvandine: eh, our PPA builds are going to be totally automated soon enough [14:45] push it somewhere, create a bug for it and link your branch [14:45] yeah. so what is the problem with ~ubuntuone-hackers owning the official one? if someone fixes a bug in the packaging they can just propose it for merge, right? [14:45] statik: nothing. we should be maintaining the packages :) [14:45] well [14:45] not really a problem [14:45] ~ubuntuone-control-tower should own it [14:45] as long as you don't generate lots of noise [14:46] right [14:46] you want the changelog to be pristine [14:46] kenvandine: we don't stick PPA build changelog entries into the package branch [14:46] dobey, good [14:46] dx team does :) [14:46] what does it mean to generate lots of noise? [14:46] and dxteam doesn't maintain their official packaging branches [14:46] jan____, is there anything I can do to help you track down the oauth issue? [14:46] statik, changelog entries for versions never in ubuntu [14:47] so versions that only got published to your ppa [14:47] statik: "stuff we don't do anyway" :) [14:47] well, the difference is that the dxteam has no interest in becoming ubuntu developers, while ubuntuone guys have specific goals assigned to earn ubuntu developer privileges. so i want to remove all layers of indirection [14:47] dx team always have like 50 versions i collapse into one [14:47] statik, that is good to hear :) [14:48] aquarius: in a bit, need to get autotools to cooperate first [14:48] jan____, kk [14:48] although... if the uploader doesn't have perms to push to your branch, i guess you can't set it to UNRELEASED [14:48] dobey, do you do that? [14:49] i don't even know what that means :) [14:49] hehe [14:49] kenvandine, your work has been AWESOME with helping us. i woke up last night worrying that we are not progressing as fast as we should be toward earning upload privileges because you have been fixing things for us, i think we need to learn that stuff [14:49] with the branches we maintain, we set it to UNRELEASED instead of karmic [14:49] then the uploader changes it when they upload it [14:49] oh [14:49] thats what we do in the debian erlang team too [14:50] but the difference is they gave me commit rights to the packaging branch :) [14:50] that way only versions actually uploaded to karmic get tagged as karmic [14:50] well seb/pitti never complained about it [14:50] so you know if you see a branch that says "karmic" you know if you need to make a change, you have to create a new version [14:51] i need to talk to pitti about it... but i think it would be a good practice for you to do the same [14:51] i guess i just need to get upload rights sooner :) [14:51] use UNRELEASED until you request sponsoring [14:51] kenvandine, i think what we are saying is that if the uploader needs to make a change, they should be telling us to fix it [14:51] then set release [14:51] * kenvandine doesn't have upload rights yet :) [14:51] soon i hope :) [14:51] statik: well, in my experience, that's what has happened [14:51] statik: seb bugs me to fix things, and then i fix them :) [14:52] i look forward to the day that none of this matters [14:52] well [14:52] all the source and packaging is in one branch... :) and you just request merging into the distro [14:52] using merge/review system [14:52] the source and packaging is in one branch [14:53] yes... for your's [14:53] no, for all source package branches :) [14:53] kenvandine, i think thats part of the problem. we need to be working directly with sponsors. For example, the couchdb and desktopcouch packages I worked on this week show up in launchpad as uploads credited to you (and you did great work on them), but when it comes time to apply for MOTU the measurement is based on how many good uploads you've done, so those will be ignored for the purposes of my MOTU application [14:53] dobey, no... many of them are packaging only branches... of course not want james_w is working on [14:54] statik, true... well ... that was cause we used my changelog i already prepared :) [14:54] the couchdb upload did too? [14:54] i thought i had preserved your's when i collapsed the changelog [14:54] kenvandine, yes [14:55] sorry about that [14:55] i collapsed all the changes since the last karmic version into one version [14:55] kenvandine, i promise i'm not trying to give you a hard time about it :) just trying to work out how the ubuntuone team can get more directly engaged with ubuntu devlopment, particularly for these packages [14:56] i am all for that :) [14:56] dobey already does a great job with his packages :) [14:57] cool [14:58] i think it's a shame that even the guys who built soyuz don't have upoad rights [14:58] so i'm trying really hard to push this team into becoming ubuntu devs [14:58] great [14:58] * kenvandine needs to apply for motu [14:59] * dobey is trying really hard to make it so he doesn't have to actually do any work for packaging :) [15:00] MEETING BEGINS [15:00] or does it? Say "me" if you want to choose your own adventure. Typical format is DONE / TODO / BLOCKED, but feel free to switch it up. [15:00] me [15:00] me [15:00] me [15:00] kenvandine, i've been rejected once already and gotten comments this week about how i don't have enough uploads. so i'm fixing it :) [15:00] me [15:01] me [15:01] mi [15:02] DONE: FACE duty, which felt productive until I look at the email I wrote to tell everyone what I did. [15:02] TODO: Review day (which seems like it will be relatively lightweight), I'd like to throw together a 'fixes' branch that has 10 or 12 small 1-line fixes in it, finish work on human readable machine names [15:02] BLOCKED: Nope [15:02] * jblount tags rodrigo_ [15:02] • DONE: Looked at Tomboy syncing certificates exception. More _changes polling [15:02] • TODO: Add more tests in couchdb-glib test suite. Add social services accounts config to about-me. Talk to Ara about writing mago tests for evo-couchdb. Propose couchdb-glib/evo-couchdb for GNOME 2.29. Store UUIDs for postal addresses. Conflict resolver tool in pair tool. oAuth authentication and signing of all couchdb-glib requests. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Tomboy syncing fixes [15:02] • BLOCKED: none [15:02] teknico: bai signore [15:02] me [15:02] DONE: discussed the contacts CRUD web ui with matt, fought with encrypted partitions not working anymore in karmic (#420355), worked on the contacts CRUD web ui [15:02] TODO: more work on the contacts CRUD web ui [15:02] BLOCKED: none [15:02] next: CardinalFang [15:02] DONE: Gwibber debugging. Car-tag hassle. Harassed IBM. [15:02] TODO: Greet IBM repairman in about 5 minutes, and go offline for a few. Gwibber fixes. 3 new d-c bugs, each easy. [15:02] BLOCKED: None [15:02] aquarius, prithee sir, what news have you? [15:02] rodrigo_, bai? :-) [15:02] ⚀ DONE: discussions with couch people about various couchish things like 301 redirects, admin accounts, doc validators [15:02] ⚁ TODO: continue piston oauth in snowy; write DC talk for Ubuntu Developer Week; work with jan to fix oauth problem; look at doing username URL at U1; make pairing not offer to repair [15:02] ⚂ BLOCKED: couchdb patch which lets OAuth read users from the ini file doesn't seem to work (this is being worked on, yay!) [15:02] dobey, dobey, pudding and pie, kissed the girls and made them cry [15:03] teknico: "go" in Italian? how do you spell it? [15:03] rodrigo_, "vai" [15:03] teknico: ah :) [15:03] ☭ DONE: Dealt with minor catastrophe with latest packages, released 0.93.1, started OAuth fork, Fixed infinite respawning [15:03] ☭ TODO: finish OAuth forking, Reviews [15:03] ☭ BLCK: None. [15:04] statik: you have the power [15:04] CardinalFang, thought number II -- pairing app should not suppress already-paired servers from the list, it should display them in a new "unpair" list whichis hidden if you have no pairings [15:04] aquarius, Agreed. [15:05] CardinalFang, I'd update the bug but for some reason I can't find it? [15:05] rodrigo_, also, "vai" is confidential, and "signore" is deferential, so it's either "vada, signore" or "vai, amico" (but you probably did that on purpose) :-) [15:05] DONE: worry about contacts sync missing feature freeze. [15:05] TODO: worry about couchdb not supporting SSL. unify packaging stuff [15:05] BLCK: nope [15:05] Bug #419973, Bug #419975, Bug#419969. [15:05] teknico: ok, "vai amico" is what i wanted :D [15:06] Launchpad bug 419973 in desktopcouch "in replication daemon, be sure local couchdb bind address is not 127/8 ." [Medium,Confirmed] https://launchpad.net/bugs/419973 [15:06] Launchpad bug 419975 in desktopcouch "for pairing, do not display hosts or servers that are already paired" [Medium,New] https://launchpad.net/bugs/419975 [15:06] teknico: my Italian is very rough, specially written :) [15:06] MEETING ENDS [15:07] rodrigo_, are you still adding stuff to about-me? will that be a problem since we are past feature freeze? [15:07] rodrigo_, so you almost unlimited improving potential! (as I have with spanish) :-) [15:07] so you *have [15:07] brb [15:07] statik: haven't had time to do it, I think I'll leave it for upstream gnome 2.30 [15:07] statik: unless we really need it for karmic [15:07] statik: which I don't think, since only gwibber uses it, right? [15:08] rodrigo_, 2.30 is perfect [15:08] statik: I'll start the upstream discussion then this weekend [15:09] teknico: I only learnt a bit Italian when living in the UK, working in Italian restaurants, so very basic stuff, and having an Italian brother-in-law doesn't help me improve, since he speaks in Spanish, with some words in Italian, and he understands all my Spanish [15:10] teknico: but will be back to Italy for the 2nd time this next December, so hope to improve, yeah :) [15:10] rodrigo_, will you be around Rome, by any chance? [15:10] teknico: no, Cervinia, in Aosta [15:10] rodrigo_: "che cazzo dici?!" is all you need to know, as i'm told [15:10] oh, december, snow, right :-) [15:10] teknico: Rome next time :) [15:11] dobey: :) [15:11] dobey: "va fan culo" is also useful :) [15:11] dobey, try that with police, or mod ;-P [15:11] heh [15:11] or however you spell it :D [15:11] rodrigo_, that's usually one word :-) [15:11] fanculo? [15:11] yes, both with and without the "va" [15:12] * dobey knows a little more than that though [15:12] ehm, that was "...police, or mob" [15:12] statik: so, you're applying for MOTU then? [15:13] teknico: you live around Rome? [15:13] rodrigo_, i will apply once i have a lot more uploads. i'm also trying to work on debian packages, dunno how hard it will be to become a DD [15:13] statik: ah, you need lots of uploads to apply? [15:14] rodrigo_, yes, in the countryside though [15:14] teknico: nice, really want to go there, but I always get holidays in winter, for skiing. Need to get some "normal" holidays one of these days :) [15:14] rodrigo_, you need several advocates who are comfortable with your knowledge of packaging and policy, and who can trust that you know when to say no and will keep garbage out of the archive. usually the way people gain confidence in your abilities is sponsoring uploads for you where they can review your work [15:15] statik: ok, only dholbach suggested me to apply, apart from you, so I guess I need to send more packages before trying to apply [15:15] rodrigo_, try to avoid july and august though, usually too hot and crowded [15:15] the equivalent of a branch review in code is a sponsored upload in ubuntu. [15:15] teknico: yeah, same here, summer is better spent at home with air conditioning [15:15] rodrigo_, maybe not if dholbach thinks you are ready [15:16] statik: ah, ok, I'll ask him [15:16] rodrigo_, or an adequately insulated and shaded home :-) [15:16] teknico: yeah, that works also :D [15:17] rodrigo_, i have been able to ship code in mission critical backup systems, in MySQL core, in launchpad, all without as much work as i've had to do to try and prove myself to be able to upload a 4 line rubber-stamp rules file to ubuntu ;) [15:19] :) [15:19] heh [15:20] lol [15:23] statik, don't you get karma for an upload if you are referenced in the changelog? [15:23] like [Elliot Murphy] [15:28] * dobey hopes 0.93.1 gets uploaded soon === facundobatista_ is now known as facundobatista === rmcbride changed the topic of #ubuntuone to: Help contact: | File Sharing for Ubuntu | https://ubuntuone.com | https://launchpad.net/ubuntuone | Current Beta Client Revno is 191, Protocol Revno is 69 | Release 0.93 [15:30] dobey, yeah... me too [15:30] we need an uploader :) [15:30] there is nobody on my team around with upload rights :/ [15:31] Testing packages are now current. Enjoy [15:33] ok, back to OAuth pain [15:34] * kenvandine is trying to find a core-dev [15:39] dobey, i am trying to get james_w to do the upload [15:39] cool [15:39] we have no uploaders on my team today :/ [15:39] james_w hasn't responded yet though [15:46] battery life fail [15:47] kenvandine, launchpad only looks at the email address in the changelog, not at who signed the package when figuring out 'uploaded by' [15:48] the gpg signature is used to guard the package actually going into the archive though [15:49] kenvandine, so if you look at https://edge.launchpad.net/~ken-vandine/+related-software you will see all your uploads, even though you aren't motu yet :) you have been working hard! [15:51] statik, interesting list... i hadn't looked at that... kind of all over the place :) [15:51] it is reviewed by the motu council when you apply, you are probably in good shape to apply now! [15:52] i'm going to be working on getting debian back in sync with our couchdb and erlang stack [15:52] good [15:52] that will make life easier [15:52] right now we're very divergent from debian, which is extra work for everyone [16:13] there's 45 minutes of my life I won't get back. stupid wifi. [16:16] aquarius: maybe if you up the wattage on it enough, you can charge your phone with it :) [16:16] dobey, heh :) [16:23] aquarius, "Karmic fail" has a rather dramatic ring to it. [16:24] Or you deserved it. [16:25] urbanape, yeah, that's what I was thinking :) [16:27] ok, lunch and then finishing up the initial release of poauth [16:29] dobey: po boys oauth? [16:29] deep fried [16:32] jblount: exactly [16:36] right, gang, I'm off. Will try and be around over the weekend at least a little. [16:37] Can one create an UbuntuOne host on one's own server? [16:45] ubuntuone sucks [16:45] it keeps crashing my whole system [16:46] anyone who is able to assist? [16:46] that's probably the best way to get help, too. [16:46] :-) [16:46] What part is crashing? What version of Ubuntu? [16:46] karmic [16:47] login probably [16:47] gkey_: yes [16:47] 1st time I set it up - didn't complete the whole sign-up sequence [16:47] gkey_: the applet and the syncdaemon brought the system down [16:47] gkey_: it's already fixed in the beta [16:48] gkey_: in the beta ppa, I mean [16:48] since then been trying to completely remove it from my system and start all over again [16:48] just can't get back to the part where I couple my system to the ubuntuone account [16:49] bugs the hell out of me - 1st time ever I just can't figure out where to fix this [16:50] gkey_: u1sync --authorize should do that - although I understand you should no longe rneed to do that [16:50] gkey_: we log a lot of info, in ~/.cache/ubuntuone/log [16:50] gkey_: that usually helps us fix things / figure out what broke / etc [16:50] I know - that crashes karmic too [16:51] gkey_: what crashes karmic? [16:51] It is a known problem and a fix has been submitted [16:51] LordMetroid: the fix is already in the beta ppa [16:51] Will the update-manager pull it? [16:52] LordMetroid: at least, the applet restarting the syncdaemon in a loop, that brought karmic down, that is fixed [16:52] LordMetroid: if u1sync also brings down karmic, that's new [16:52] LordMetroid: depends on if you're using the ppa or not :) [16:52] I simply installed the alpha 4 by doing -d [16:53] LordMetroid: ok, it'll be a while until you get the update (a day? two? I dunno) [16:53] the apport logging - gnome slows down to a grinding halt [16:53] gkey@Madrid:~$ u1sync --authorize [16:53] Traceback (most recent call last): [16:53] File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 576, in msg_reply_handler [16:53] reply_handler(*message.get_args_list(**get_args_opts)) [16:53] File "/usr/lib/python2.6/dist-packages/ubuntuone/oauthdesktop/auth.py", line 241, in got_state [16:53] self.acquire_access_token(description, store) [16:53] File "/usr/lib/python2.6/dist-packages/ubuntuone/oauthdesktop/auth.py", line 311, in acquire_access_token [16:53] LordMetroid: if you're as impatient as I am, you can add the beta ppa; in software sources, you can add ppa:ubuntuone/beta [16:53] self.open_in_browser(oauth_request.to_url()) [16:53] File "/usr/lib/python2.6/dist-packages/ubuntuone/oauthdesktop/auth.py", line 222, in open_in_browser [16:53] raise Exception(errors) [16:53] Exception: [16:53] (gnome-open:5626): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed [16:53] Er is een fout opgetreden bij het tonen van url: Uitvoeren van dochterproces ‘https://ubuntuone.com/oauth/authorize/?oauth_token=042NC0DSWPFqzN74f55q&description=Madrid&oauth_callback=http%3A%2F%2Flocalhost%3A33812%2F%3Fnonce%3D2949292’ is mislukt (Bestand of map bestaat niet) [16:53] gkey_: please use a pastebin [16:54] ok, I shall do that [16:54] gkey_: also, you just told us some secret stuff, there [16:54] gkey_: :-/ [16:54] gkey_: ok... let's do it slowly [16:55] gkey_: first, do this: gnome-open http://google.com [16:55] gkey_: does that open google in your web browser? [16:57] gkey_: second, go to http://ubuntuone.com/, log in, and clear all tokens from your account, so that what you pasted above can't be used to get at your files [16:57] gkey_: are you reading me? [17:00] done that [17:01] gkey_: did it work? [17:01] gkey_: also, I told you to do two things; did you do both? :) [17:07] dobey, james_w is uploading u1 client [17:07] LordMetroid: ^ [17:08] sorry - how do you remove tokens? [17:08] jblount: can you walk gkey_ through that? [17:09] good thing - I don't seem to have any tokens yet - [17:09] gkey_: also: what kenvandine said just now means that you should have a fixed client soon, even if you _aren't_ using the beta ppa [17:09] gkey_: sweet :) [17:10] so now - how am I going to get one connected? [17:10] Obviously with a different token [17:10] it might take a couple hours to get built, etc [17:10] but the fix is out there :) [17:10] gkey_: did gnome-open work? i.e. did it open firefox with google? [17:11] gkey_: because we use xdg-open, which uses gnome-open (in gnome, at least :) ), and if you don't have that configured right, things won't work [17:12] (gnome-open:8002): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed [17:12] so no gnome-open failed [17:12] gkey_: I don't know how it's labelled in Nederlandse, but in Engish it's "Preferred Applications", under System -> Preferences [17:13] Chipaca, ? [17:13] got-it [17:13]