[02:29] <scream> Is the backed data encrypted?
[12:34] <CardinalFang> aquarius, hi.
[12:34] <aquarius> CardinalFang, heya
[12:36] <CardinalFang> aquarius, I'm going to get pairing peers working this morning.  Kindly explain what oauth information must be exchanged and whence it comes.
[12:36] <CardinalFang> /dev/random?
[12:38] <aquarius> it comes from the desktopcouch.ini file
[12:39] <aquarius> to give a remote server access to this server, the remote server needs to have the consumer key, consumer secret, token, token secret, and which port you're running on
[12:39] <aquarius> I assume you're already dealing with the port thing :)
[12:39] <aquarius> so you need to pass back those four things
[12:39] <aquarius> (and maybe some sort of unique identifier so you can find the port again later)
[12:40] <aquarius> those bits of info are stored (a) in the keyring and (b) in the ini file; you can get them from either place, whichever is most convenient.
[12:41] <CardinalFang> Yes.  All four parts?  So, there's no assurance that one host is not malicious.  It can take the four parts of any paired peer and pretend to be that peer to others.
[12:41] <aquarius> basically, yes
[12:41] <aquarius> this is the issue with two-legged oauth; it's basically a complicated password
[12:42] <CardinalFang> I guess that was my block.  I decided that was too dumb to be true.
[12:42] <aquarius> CardinalFang, this is why three-legged oauth is normally the idea
[12:43] <aquarius> thisfred, I have Worked Something Out. The desktopcouch xdg changing stuff wasn't all being picked up by tests because desktopcouch is imported by "trial desktopcouch" *before* the xdg stuff happens, so local_files was imported first.
[12:43] <aquarius> thisfred, so I have, in the branch I'm working on, reloaded desktopcouch.local_files when we do the xdg override stuff
[12:43] <thisfred> aquarius: aha, but why did it work sometimes/at all then?
[12:43] <aquarius> and now it seems to work, I think.
[12:43] <thisfred> aquarius: ah, this I may have also done on my branch
[12:44] <thisfred> last night it all seemed to work
[12:44] <aquarius> ah, ok :)
[12:44] <thisfred> not sure though, so let's compare notes!
[12:44] <thisfred> CardinalFang, aquarius I do think I found the gremlins in my system:
[12:45] <thisfred> When testing adam's fix, I installed a version of couchdb from source
[12:45] <CardinalFang> Ah.
[12:45] <thisfred> and when that didn't change any behavior I was puzzled
[12:45] <thisfred> then I realized (actually, I was told) that installing from source of course installs to /usr/local
[12:46] <thisfred> but our startup scripts (at least for the server couch) seem to ignore that location and go directly to /usr/bin
[12:46] <CardinalFang> ...as it should.
[12:47] <thisfred> as it, indeed, should, but I'm still pretty much a linux newbie even after 5 years or so. That's the one downside of ubuntu: it makes it easy not to know/remember such things.
[12:47] <thisfred> I should have stuck with debian for a little longer ;)
[12:48] <thisfred> but now the funny part:
[12:49] <thisfred> starting couchdb in background should/can result in two processes, since the script recursively calls itself again (that explains the double processes on my system, but not that you guys don't see them)
[12:49] <thisfred> but the one in /usr/bin seemed to not start itself, but the one in /usr/local/bin
[12:50] <thisfred> which resulted in *really* strange behavior
[12:50] <thisfred> (this is mostly theory, but I did see them behave differently)
[12:50] <thisfred> anyhow, I think I may have had an earlier install in usr/local I forgot about that was messing with me sometimes
[12:52] <thisfred> after getting rid of that and applying the patch manually to /usr/bin/couchdb, I got chaining to work (after also fixing desktopcouch, because we were doing it wrong) and chaining now works again. Or at least it will when a new couchdb is packaged, and it will not break worse than it is now until then.
[12:52] <thisfred> elementary
[12:52] <CardinalFang> Ah.  Of course.
[13:29] <aquarius> grrrr! how can *some* but not *all* write accesses to an authenticate-required couchdb fail?
[13:32] <teknico> aquarius, is some load balancing among differently configured servers going on?
[13:32] <teknico> :-)
[13:32] <aquarius> teknico, this is talking to localhost :)
[13:37]  * rodrigo_ -> lunch
[13:45] <aquarius> thisfred, CardinalFang: we need to talk about turning on oauth by default
[13:46] <thisfred> aquarius: yeah we need quite a bit of work on the server side though
[13:46] <aquarius> ah, I mean in desktopcouch
[13:46] <thisfred> aquarius: ah for LAN repl
[13:47] <CardinalFang> Rgr.  aquarius, thisfred, can it wait 40 minutes?  I have to go afk.  It approaches 0900 here.
[13:47] <thisfred> It sucks, I had hoped to have the server done two days ago, except I've been wildly chasing geese. Or chasing wild geese.
[13:47] <aquarius> cheezit, I didn't realise it was so early
[13:47] <aquarius> go and do things and we'll talk in a bit :)
[13:47] <CardinalFang> Yah, The Kid wakes up now.  Brb.
[13:55] <urbanape_> morning, all
[13:57] <urbanape> aquarius, in case you didn't know about it: http://ted.mielczarek.org/code/mozilla/extensiondev/
[13:58] <urbanape> in-freaking-valuable.
[13:58] <aquarius> urbanape, heh. nice
[13:58] <urbanape> gives you a js shell with access to the FF internals
[13:58] <lucap> hi
[13:58] <urbanape> so you can interactively get the bookmarks, manipulate them, &c.
[13:59] <lucap> I have a problem with ubuntuone
[13:59] <lucap> on my account https://one.ubuntu.com/files/ I can't delete a file
[13:59] <lucap> why?
[14:01] <urbanape> lucap, I believe that's a known bug
[14:02] <clio_> ah
[14:02] <Chipaca> I think /files/old/ takes you to the old interface
[14:02] <Chipaca> and there you can
[14:02] <urbanape> yes, that works as well.
[14:03] <urbanape> for the time being
[14:03] <clio_> thank's guy
[14:04] <clio_> I am lucap
[14:04] <urbanape> yeah, I was gonna say you look like twins
[14:04] <clio_> by old interface I delete the file
[14:19]  * jblount thinks urbanape 's humor is underappreciated
[14:22] <urbanape> 'sokay
[14:22] <urbanape> dry, like a martini
[14:27] <didrocks> aquarius, thisfred: statik denounced you that you may have some doc on desktopcouch. I'm interested in it if it's the case :)
[14:27] <aquarius> didrocks, what would you like documented? :)
[14:28] <didrocks> aquarius: just some kind of getting start (apart from quickly's tutorial) and what's the functions available, etc. :)
[14:28] <aquarius> /usr/share/doc/python-desktopcouch-records/api/records.txt
[14:30] <statik> aquarius, didrocks is unstoppable and dangerous, one of the quickly developers along with many other things
[14:31] <didrocks> statik: dangerous is the right word ^^
[14:32] <didrocks> thanks aquarius and statik, I'll read this :)
[14:33] <aquarius> yep, I have discussed quickly with him before :)
[14:38] <CardinalFang> aquarius, thisfred, I'm ready to talk about desktopcouch auth.
[14:38] <thisfred> talk to me about desktopcouch
[14:39] <thisfred> while my tests silently weep
[14:40] <CardinalFang> "gently weep" would be better.
[14:40] <thisfred> ah yes
[14:41] <thisfred> although I prefer silent, especially in the case of weeping guitars
[14:41] <aquarius> right, good :)
[14:41] <aquarius> my thought is this: we need to turn on compulsory auth.
[14:42] <aquarius> this means doing three things: 1. make dc.records talk oauth, which I am doing right now
[14:42] <aquarius> (and is mostly done)
[14:42] <aquarius> 2. enable it in ini file creation
[14:42] <aquarius> 3. alter existing ini files
[14:43] <aquarius> my question is: do we need to do 3?
[14:43] <thisfred> nah
[14:43] <aquarius> so just tell existing DC users to delete their ini file?
[14:43] <thisfred> or at least: we shouldn't spend much time on it
[14:43] <thisfred> aquarius: yeah all three of em ;)
[14:44] <thisfred> or just do a hardcoded rm that we'll take out in the next release
[14:44] <thisfred> but that's sort of dangerous ground
[14:44] <thisfred> so no
[14:44] <thisfred> let's let em do it manually
[14:44] <CardinalFang> 3 is easy, right?  It should take less time than aquarius' #1.
[14:45] <CardinalFang> At start time, when we test ini existence, load it, if not set then set it.
[14:46] <aquarius> CardinalFang, it is if we bodge it. The thing is: we may need to alter ini files later. So, do we think about a better way of doing it, now?
[14:47] <thisfred> well a merge is gonna be tricky. Adding new options or deleting options should be doable
[14:47] <thisfred> perhaps the ini should live in a json document
[14:47] <CardinalFang> Maybe we should also consider that a user doesn't want oauth required.  Do we want to forece his preference to be disabled?
[14:48] <aquarius> yes.
[14:48] <thisfred> I would say giving the user that choice is a refinement we can add later
[14:48] <aquarius> No choice. in the same way, ssh does not give you the option of not having a password to log in.
[14:49] <thisfred> eh, I log into ssh without a password all the time ;)
[14:49] <thisfred> much more secure
[14:49] <aquarius> you know what I mean :)
[14:50] <thisfred> yes, I was being an ass
[14:51] <aquarius> I don't believe that people should have the option to not have oauth turned on.
[14:51] <aquarius> thisfred, have you totally disabled chaining?
[14:52] <aquarius> or can we chain to other ini files in our folder without chaining to /etc/* ini files?
[14:52] <thisfred> aquarius: interestingly no, because that breaks everything too
[14:52] <thisfred> we need default.ini
[14:52] <thisfred> so what I do is -n -a /etc/default.ini -a our.ini
[14:52] <aquarius> ok
[14:52] <thisfred> the hardcoded /etc/default.ini being rather horrid
[14:53] <aquarius> so we could do -a our.ini -a our-extra.ini or something?
[14:53] <thisfred> but I don't see a way round it
[14:53] <thisfred> aquarius: yes that would totally work
[14:54] <CardinalFang> aquarius, You anticipate needing to update the INI file later.  What problem or ugliness do you want to avoid?
[14:54] <aquarius> I want it to be relatively easy to do updates later on
[14:55] <aquarius> i.e., not having to read a file and alter certain lines, which, as  you say, will be tricky
[14:55] <CardinalFang> Not me.
[14:55] <thisfred> what I would like to prevent is to have -a original.ini -a 0.1.ini -a 0.2.ini -a adinf.ini
[14:55] <CardinalFang> I think it's easy.
[14:56]  * CardinalFang reads up on the ConfigParser module again.
[14:56] <aquarius> is the ini file in configparser format? I forget
[14:56] <thisfred> I believe so yes
[14:58] <CardinalFang> aquarius, your local_files.get_oauth_tokens() thinks so.  :)
[14:58]  * aquarius grins. I'd forgotten I did that :)
[15:00] <jblount> MEETING BEGINS
[15:00] <jblount> DESKTOP+ SAY ME SRSLY
[15:00] <urbanape> ME SRSLY
[15:01] <teknico> ME FCTSLY
[15:01] <aquarius> ME RLY
[15:01] <rodrigo_> ME SRSLY
[15:01] <statik> ME EHLO
[15:02] <jblount> ME O RLY?
[15:02] <dobey> meh
[15:02] <vds> me
[15:02] <aquarius> boring boring vds!
[15:02] <CardinalFang> ME! MEMEMEMEME!
[15:02] <vds> :)
[15:02] <urbanape> DONE: Marked #397390 as Fix Committed. Made some progress on each of #404193 #396186 #396183
[15:02] <urbanape> TODO: Finish up the branch for complete syncing of bookmarks, and hopefully move onto folder structure.
[15:02] <urbanape> BLOCK: None
[15:02] <urbanape> teknico, if you please
[15:02] <teknico> DONE: more upgrades to the 2a repo format, sorted the contacts name list in the web ui (#405915), work on adding and editing contacts (#406315)
[15:02] <teknico> TODO: talk with jblount about the new contacts web ui (#399664), more work on adding and editing contacts
[15:02] <teknico> BLOCK: none
[15:03] <teknico> next: aquarius
[15:03] <aquarius> ⚀ DONE: allow unpairing of servers (bug #419975)
[15:03] <aquarius> ⚁ TODO: get dc-records-oauth tested and merged into trunk (bug #415375); fix UnknownLoginError and make it be known (bug #376087); turn on oauth for desktopcouch by default (bug #416413); talk to thisfred and CardinalFang about that last one; test android phone sync
[15:03] <aquarius> ⚂ BLOCKED: well confused by the big bzr format change thing for ubuntuone
[15:03] <aquarius> ⚃ BUG COUNT:https://bugs.edge.launchpad.net/~sil/+assignedbugs?field.tag=ubuntuone-karmic - 4
[15:03] <aquarius> hit it, rodrigo_
[15:03] <rodrigo_> • DONE: IM addresses move to top level contact record. Released couchdb-glib and evo-couchb and submitted to Karmic. Face duty
[15:03] <rodrigo_> • TODO: Start upstream discussion for adding 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. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). openSUSE/Fedora packaging with aquarius. More tomboy syncing fixes. Vacation, back on Tuesday
[15:03] <rodrigo_> • BLOCKED: no
[15:03] <rodrigo_> statik: go
[15:03] <statik> DONE: Upgraded branches to bzr 2a format and broke the world.
[15:03] <statik> TODO: bug #402736 and bug #424023, along with some other couchdb fixes. Today is couchdb day for me.
[15:03] <statik> BLCK: Nope. https://bugs.edge.launchpad.net/ubuntuone/+bugs?field.tag=ubuntuone-karmic  has a lot of bugs though!
[15:03] <statik> jblount, your turn
[15:03] <jblount> DONE: tabs, upgrading to 2a stuff
[15:03] <jblount> TODO: teknico chat, figure out how to get tabs work into the correct format, onto lp for review
[15:03] <jblount> BLOCKED: Nope
[15:03] <jblount> dobey: tag
[15:03] <dobey> ☺ DONE: Spent half a day upgrading bzr formats on server branches, Worked on #403243 #419365
[15:04] <dobey> ☹ TODO: Finish #403243 #419365 (complicated rollout), Fix #397331, Release 0.95.0
[15:04] <dobey> 〠 BLCK: None.
[15:04] <dobey> vds: ciao
[15:04] <vds> DONE: updated working copy, updated wiki, sent email to support, investigated log problem
[15:04] <vds> TODO: fix log problems
[15:04] <vds> BLOCKED: no
[15:04] <vds> is that it?
[15:04] <CardinalFang> DONE: nearly finished with desktopcouch.  Merged aquarius' approved branch to local.
[15:04] <CardinalFang> TODO: Exchange oauth tokens among peers.  Commit and propose for merge.  Start using bug numbers here.  :)
[15:04] <CardinalFang> BLOCKED: '()
[15:05] <CardinalFang> - FIN -
[15:05] <jblount> MEETING ENDS ZOMGROFLMAO
[15:05] <jblount> teknico: skype?
[15:05] <teknico> jblount, skype it is
[15:06] <CardinalFang> aquarius, thisfred, I can handle #3.
[15:06] <statik> jblount, to get your work from an old-format branch out and into a new format branch, you have two options: 1) bzr upgrade --2a your in-progress branch. 2) bzr diff, save to a patch, go to a new branch in the new format and bzr patch to apply it, and do a new commit
[15:06] <aquarius> CardinalFang, having some good easy way to integrate/add new changes to it later would be nice
[15:07] <aquarius> I wonder if we should put files in /etc/desktopcouch/*.ini and chain to them? rather than merging.
[15:07] <CardinalFang> aquarius, It's trivially simple to add.  YAGN-an-infrastructure.
[15:07] <thisfred> aquarius: that would keep it more debuggable
[15:08] <aquarius> CardinalFang, it is, but you want some good way of specifying "this is the change to be merged in", which still makes sense six months from now when there are 25 such changes.
[15:09] <rodrigo_> aquarius: you could do something like gconf, look in the local file, and if the setting is not there, read it from the system wide one
[15:10] <thisfred> aquarius: I don't know about merge history: just keep the latest state of our official ini in /etc/desktopcouch, and chain the user's .ini in after that, so they get the last say/a chance to break stuff but also easily fix it
[15:10] <dobey> doesn't configglue do that for you?
[15:10] <aquarius> see, this is why I want to talk about it, since there are 82 ways we could attack the problem :)
[15:10] <dobey> oh or you can do that i guess
[15:10] <CardinalFang> aquarius, You're thinking like it's a diff and we want to avoid conflicts.  This is a data structure, and we can poke and update without problems.  I can't imagine anything more complex needed than to test to see whether there exists the key/value and if not then to add it.
[15:11] <aquarius> CardinalFang, changing an existing value; deleting an existing value
[15:11] <aquarius> thisfred, chaining is a little more awkward in the test environment, since you can't just hardcode /etc/desktopcouch
[15:11] <vds> jdo: what is the config file used in production  by the webui django instance?
[15:11] <thisfred> well we need to solve that problem then anyway
[15:12] <thisfred> aquarius: since we now hardcode /etc/couchdb/default.ini ;)
[15:12] <aquarius> thisfred, that's different -- that's a couch file, not a desktopcouch file.
[15:12] <CardinalFang> aquarius, config.set(section, option, value) , and  config.remove_option(section, option) , respectively.
[15:13] <thisfred> I think the only problem is when we set/remove an option that the user has changed locally
[15:13] <CardinalFang> And those are for operations we are only imagining we'll need someday.
[15:13] <aquarius> CardinalFang, yeah, I know how to actually make the changes, but I think there should be a better way of expressing what changes need to be made than lines of code
[15:13] <thisfred> we'll have no way to detect this (or we shouldn't want to) so we can either let the user win or let our change win
[15:14] <aquarius> since otherwise, to work out what our ini file ought to loo like, you need to walk throught he code by hand to see what it does.
[15:14] <thisfred> I say let the user win: if they broke it, they can fix it in their ini
[15:14] <thisfred> If we know we're breaking stuff in an update for a lot of people, we can tell them
[15:14] <aquarius> thisfred, agreed. this is why I'm thinking of chaining /etc/couchdb/default.ini, /etc/desktopcouch/default.ini, user ini
[15:14] <thisfred> aquarius: +1
[15:15] <CardinalFang> aquarius, So, does that solve the #3 problem, too?  Just put the requirement in the system, non-user-writable INI file?
[15:16] <aquarius> CardinalFang, I think so, yes. the stuff in the user ini that we generate is there because it's user-specific (actual oauth tokens, usernames, etc). I can't think of any other user-specific settings we'll need -- the rest are all system-wide things like oauth=ON
[15:17] <aquarius> and it solves the "what if a user doesn't want oauth, because security happens to other people" problem, because they just override it in their local ini
[15:22] <statik> hi CardinalFang, aquarius, thisfred: i have demands :) i would like an email today listing when the next desktopcouch upload to karmic will be, who is the core-dev sponsor that you have talked to in order to upload it, and the list of bugs that will be fixed in that upload. One of the things that I want to see fixed in that upload is that desktopcouch-tools is not installed by default, and this should not be the case - people can't pair wi
[15:22] <statik> thout that package. You probably need a new bug filed for that. I am available to answer questions you may encounter while dealing with my annoying demands ;)
[15:23] <CardinalFang> Aiee!
[15:27] <statik> you will probably want to consult the ubuntu release schedule when figuring all this out
[15:28] <jblount> statik: 2a == brisbane-core == super awesome fast new default format, yeah?
[15:28] <statik> jblount, yes. it's also rich root, so you no longer have to do the symlink tricks to keep desktopcouch, ubuntuone-client, ubuntuone-storage-protocol, and bindwood in a separate shared repo from the other branches
[15:28] <statik> everything can go in the same shared repo now
[15:29] <jblount> statik: My upgrade is running right now, given no new problems I should have your tabs up for review in minutes.
[15:30] <statik> jblount, i will press reload on  http://peopleofwalmart.com/ until i have your branch to review
[15:31] <jblount> heh
[15:34] <LordMetroid> CouchDB isn't particularly good for dependent files, right?
[15:36] <rodrigo_> LordMetroid: what do you mean?
[15:37] <statik> LordMetroid, couchdb does support attachments, but it's not really intended as a blob store. I think we need to figure out a good and standard way of referring to a binary blob stored as a file outside of couchdb from within a couch record
[15:37] <LordMetroid> I was watching this presentation by Chris Anderson at the London 2009 Erlang Factory
[15:37] <statik> like, i want to be able to have records in desktopcouch that refer to files i have in ubuntuone
[15:38] <LordMetroid> I personally would like my Couch to contain my software project workspace
[15:38] <statik> i think that would work, and would be a really interesting thing to do
[15:38] <LordMetroid> Having different versions of my files is something I should try to avoid.
[15:38] <statik> it starts to have some confusing overlaps with version contorl
[15:39] <urbanape> brb, rebootie after update
[15:39] <statik> and couchdb itself has versioning
[15:40] <rodrigo_> LordMetroid: sorry, but you mean storing source code files?
[15:40] <LordMetroid> yes
[15:40] <rodrigo_> hmm
[15:41] <LordMetroid> Hmm, I might need to write my own webapp/file server daemon for my needs anyway
[15:41] <rodrigo_> if the source is stored in couchdb, you'll need to retrieve them locally for editing them
[15:42] <rodrigo_> which is the same as having the code in git/bzr/svn/etc
[15:43] <dobey> well, you'll need to extract for compiling/running anyway
[15:43] <rodrigo_> right, that's what I mean
[15:43] <aquarius> CardinalFang, are you OK to take charge of producing the email for statik? I'm happy to help, but I'll be gone in a bit over an hour :(
[15:43] <dobey> so developing an ide that just stores everything in a couchdb seems a bit overkill
[15:43] <rodrigo_> yes
[15:44] <statik> aquarius, CardinalFang: tomorrow is fine for that email. my point mostly is that these things need figuring out
[15:45] <aquarius> statik, agreed that they need figuring out
[15:45] <aquarius> kenvandine, are you core-dev? I believe you were heading in that direction?
[15:45] <CardinalFang> aquarius, Er, maybe.  I will try, and if I don't have enough I will relay to you for tomorrow.
[15:45] <aquarius> CardinalFang, that sounds good
[15:46] <kenvandine> aquarius, not yet :)
[15:46] <aquarius> kenvandine, darn :) Who do we talk to to find a core-dev sponsor for a desktopcouch upload to karmic? Do we talk to you? ;)
[15:47] <LordMetroid> Hmm, yes it might be better to just have a git server running on my file server
[15:47] <kenvandine> pitti
[15:48] <kenvandine> aquarius, is it proposed?
[15:48] <aquarius> kenvandine, not yet. We're putting together what it will need to be, and one of the things we want to get sorted is who will be the sponsor. :)
[15:48] <rodrigo_> LordMetroid: or use gitorous or launchpad to store it
[15:49] <LordMetroid> But that would nullify one of the reasons to have my own file server...
[15:57] <rodrigo_> LordMetroid: then don't use a server, just git/bzr locally, and backup that to your file server
[15:58] <rodrigo_> LordMetroid: I do that for some private data
[15:58] <LordMetroid> I am traveling around so that is why I want my workspace to be accessible from wherever on the internet
[16:01] <statik> aquarius, CardinalFang: i recommend working with james_w or pitti, keeping in mind that they are in a european timezone
[16:01] <rodrigo_> so you want to access your files from everywhere?
[16:01] <rodrigo_> LordMetroid: in that case, the file storage of u1 might be of help, I guess
[16:02] <rodrigo_> LordMetroid: or do you want to access them in your local file server?
[16:02] <LordMetroid> Yes, I think I will want to do that
[16:02] <LordMetroid> I want someway to conviently have my files on the internet and just start coding wherever I am
[16:03] <rodrigo_> LordMetroid: you'll need to write a web page on top of it to access it from windows machines, I guess
[16:42] <statik> thisfred, was there a launchpad ubuntu bug # for the -n fix in couchdb?
[16:43] <thisfred> statik: yes, lemme look
[16:43] <thisfred> statik: bug #424330
[16:44] <statik> thisfred, thanks! we're preparing the new package now
[16:44] <thisfred> cool, thanks!
[16:44] <thisfred> I linked it against both dc and couchdb
[16:50]  * aquarius throws all his toys out of the pram. I hate programming
[16:53] <dobey> heh
[17:06] <urbanape> hmm, I just updated a bunch of packages and now Firefox, Bindwood, and Desktopcouch seem, erm, crashy.
[17:07] <urbanape> is desktopcouch crashing a currently known thing, or should I apport it?
[17:07] <urbanape> don't want to contribute noise
[17:07] <dobey> bugs aren't noise
[17:08] <dobey> unless you already know it's a duplicate, and you just set the summary to be the bug # your bug is a duplicate of...
[17:09] <urbanape> speaking of launchpad (peripherally to a tangent), how soon is "very very soon"?
[17:09] <dobey> context?
[17:09] <urbanape> Launchpad tells me it's going offline for maintenance "very very soon"
[17:10] <dobey> oh
[17:10] <dobey> weird
[17:11] <urbanape> seems gone?
[17:11] <urbanape> weird. oh wel/
[17:11] <dobey> i don't see that message
[17:12] <dobey> and i don't see any mail about lp going down for maint
[17:12] <urbanape> yeah, it's gone. maybe I had something cached?
[17:12] <urbanape> anyway.
[17:12] <dobey> heh, must have been cache, or just supe weirdness
[17:17] <urbanape> hmm, apparently, I have  outdated desktopcouch, &c.
[17:18] <urbanape> ah, I didn't do a dist-upgrade.
[17:18] <urbanape> wheeeeee
[17:22] <aquarius> aha!
[17:22] <aquarius> thisfred, CardinalFang, ping.
[17:22] <thisfred> pong
[17:22] <CardinalFang> aquarius, j0!
[17:23] <aquarius> have thought of a problem with the tests
[17:23] <thisfred> uhoh
[17:23] <aquarius> when you create a new couch (like the tests do) it writes a new ini file, and stashes the keys for that ini file in the keyring
[17:23]  * CardinalFang minimizes xchat and has a nice cup of tea.
[17:23] <aquarius> and then the tests read those keys back
[17:23] <aquarius> that's not gonna work, though.
[17:24] <thisfred> shoot
[17:24] <urbanape> tea solves most ills
[17:24] <aquarius> so...
[17:24] <aquarius> I think the tests need to get the oauth keys for this server back and then pass them to couchdatabase
[17:24] <aquarius> unless anyone's got a better idea
[17:25] <aquarius> my only potential better idea: couchdatabase doesn't hit the keyring. Instead, it parses the ini file
[17:25] <aquarius> since there is already a function for that.
[17:25] <CardinalFang> That's better, INI only.
[17:25] <CardinalFang> The replication daemon would like that.
[17:26] <aquarius> shitsticks.
[17:26] <aquarius> I've just tried it.
[17:26] <thisfred> I thought the keyring was only used once, to get the u1 keys out?
[17:27] <aquarius> we need to do what I've just described anyway, since running the tests will *override* your keyring keys
[17:27] <aquarius> but it doesn't actually solve my problem. damn
[17:27] <urbanape> and rebootie time again.
[17:27] <dobey> oh yeah
[17:27] <dobey> tests sticking stuff in user's keyring == fail :)
[17:28] <aquarius> dobey, yes, yes, I know :)
[17:28] <aquarius> dobey, it wasn't a problem before :)
[17:29] <thisfred> I didn't even realize we were stuffing keys in at all. They are stored in each user's .ini file, right? That sort of bypasses the keyring anyway?
[17:30] <thisfred> I'm probably misunderstanding in a new and exciting way :)
[17:30] <dobey> thisfred: no, or at least, the u1 token is in the user's keyring
[17:30] <aquarius> thisfred, desktopcouch.records retrieves keys from the keyring; it does not parse the ini file
[17:30] <thisfred> dobey: yes, but that's not the one I'm talking about
[17:30] <dobey> don't know why it's actually sticking stuff in my keyring though
[17:30] <aquarius> thisfred, because that's how other libraries like couchdb-glib will need to do it
[17:31] <thisfred> aquarius: right yeah
[17:31] <aquarius> and it's best to be consistent between libraries
[17:31] <thisfred> aquarius: why can't we be the only consumer! :)
[17:31] <thisfred> understood
[17:31] <aquarius> thisfred, if I could make everyone only write programs in Python I'd do it tomorrow.
[17:31] <aquarius> have to shoot dobey first though :)
[17:31] <thisfred> gag him, at least
[17:31]  * CardinalFang curses ^W in xchat.
[17:32] <thisfred> CardinalFang: works like in every other tabbed app, doesn't it?
[17:33] <CardinalFang> aquarius, thisfred, let's nail down the release.  I figure we must release 0.4 on Monday or before, before late in GMT.
[17:33] <thisfred> at least the ones I use, but that's not very many
[17:33] <thisfred> right
[17:34] <CardinalFang> aquarius, thisfred, I have a list of bugs I think we do fix or are about to fix.  What is missing?
[17:34] <CardinalFang> https://bugs.edge.launchpad.net/desktopcouch/+bugs?field.searchtext=&orderby=status&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field
[17:34] <CardinalFang> .assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=cmiller-k-alpha6&field.tags_combinator=ANY
[17:34] <CardinalFang> (Eek.)
[17:35] <CardinalFang> rmcbride can not handle the ampersands!  Buh bye.
[17:36] <thisfred> CardinalFang: care to tiny that up? :)
[17:38] <aquarius> I think that's right
[17:38] <CardinalFang> http://bit.ly/rZRVe
[17:44] <CardinalFang> aquarius, not on that list, I'm going to wrap your pairing-removal in a "O RLY?" dialog so it doesn't scare people.
[17:44] <aquarius> s'pose
[17:44] <aquarius> you don't need to for cloud ones -- they reappear in the top box
[17:45] <CardinalFang> Yes, but consistency says I must anyway, regardless of locality of other end.
[17:46] <aquarius> I think that's bad
[17:46] <aquarius> there's no reason to be consistent if it's easily undoable.
[17:52] <aquarius> thisfred, OK, am going mad. I'm getting 401s when requesting design documents but *not* when requesting ordinary documents.
[17:53] <thisfred> CardinalFang: I'm not sure that everything is on there
[17:53] <thisfred> should I have tagged stuff with cmiller-k-alpha6 ?
[17:53] <aquarius> thisfred, I need to get going, but if you get a chance can you try running an oauth-required couch and requesting (a) an ordinary document from it (b) a design document from it?
[17:53] <CardinalFang> thisfred, I did miss https://bugs.edge.launchpad.net/desktopcouch/+bug/397663  That's in now.
[17:54] <CardinalFang> thisfred, I just made that tag up to make this list.  What else?
[17:54] <thisfred> so how did you come up with the original list?
[17:55] <CardinalFang> thisfred, I looked at d-c bugs by mtime and picked them out.  I have no sure way.
[17:55] <CardinalFang> thisfred, These should be new changes since 0.3.1
[17:55] <thisfred> ok, well I think bug #424330 should be on there
[17:56] <CardinalFang> thisfred, Yes.  Okay, so that will be fixed?  I'll add it.
[17:56] <thisfred> CardinalFang: yeah, elliot is packaging a new couchdb today
[17:56] <thisfred> and my proposed branch fixes the dc end
[17:57] <aquarius> CardinalFang, or if you get a chance can you try the above request-a-design-doc-from-an-oauth-required-couch?
[17:57] <CardinalFang> aquarius, I will try to get to it, but I'm pretty swamped.  :(
[17:58] <aquarius> CardinalFang, yeah, I know, soz :(
[17:58] <aquarius> I am startig to believe it is a real couch bug, though
[17:58] <CardinalFang> aquarius, We need help.  statik!  We need debuggers. ^
[17:59] <aquarius> please god don't let it be a couch bug
[17:59] <thisfred> aquarius: design docs are admin only right?
[17:59] <aquarius> thisfred, yeah, but the oauth token is tied to an admin user
[17:59] <thisfred> ah
[18:00] <thisfred> aquarius: so you can't view the design doc, or execute the view? or both?
[18:00] <aquarius> thisfred, trying to request /db/_design/viewname
[18:00] <aquarius> and getting a 401
[18:01] <thisfred> is there a bug for this with reproducable setup? (I think I know the answer) ;)
[18:02] <thisfred> aquarius: also: it does work as expected with a regular authed admin?
[18:02]  * aquarius files a bug
[18:03] <aquarius> actually, I don't want to file a bug, because it's against a branch, not trunk.
[18:03] <thisfred> aquarius: ok, so I check out your branch, and then?
[18:03] <aquarius> in lp:~sil/desktopcouch/dc-records-oauth, run trial desktopcouch.records.tests.test_server.TestCouchDatabase.test_get_view_by_type_new_but_already
[18:03] <aquarius> it fails
[18:03] <aquarius> (I've made it print a shitload of stuff)
[18:04] <aquarius> but it's failing when it does self.db[doc_id]["views"] with a 401
[18:04] <aquarius> where doc_id is "design/anythingyouwant"
[18:06] <thisfred> aquarius: I get 15 errors all unauthorized, looks like when running plain trial desktopcouch. and a lot of printing yes
[18:07] <aquarius> yeah, that one test is a good one to run, since they all fail for the same reason
[18:08] <aquarius> it seems to be a problem with views
[18:08] <aquarius> but I don't know exactly what the problem is
[18:08] <aquarius> and I have to go :(
[18:08] <aquarius> if you get a chance to look I'd be dead grateful :)
[18:08] <aquarius> right, bye all, back tomorrow, later.
[18:08] <aquarius> sorry to bail.
[18:09] <CardinalFang> aquarius, we have no bug for forcing auth on, do we?
[18:09] <dobey> boooo
[18:09] <dobey> quitter.
[18:09] <CardinalFang> dang.
[18:10] <dobey> http://twitter.com/qZsYFa <- not at all a spam bot. obviously this person is real
[18:13] <urbanape> almost surely
[18:13] <urbanape> ah, good old qZsYFa. The times we used to have.
[18:14] <dobey> hrmm
[18:14] <urbanape> ick. I feel gross just having that page open.
[18:14]  * dobey stabs pulseaudio/totem
[18:15]  * dobey puts on fhqwhgads.mp3
[18:17] <dobey> urbanape is to the limit
[18:17] <dobey> come on fhqwhgads
[18:18] <urbanape> Wonder if we could dress Lex up as Cheat for Halloween. I could be Homestar and Amber could be Marzipan.
[18:18] <urbanape> although, as a Supervillain, he'd make a good Strong Bad, too.
[18:18] <dobey> that would be awesome
[18:25] <CardinalFang> thisfred, so, we decided to put the auth requirement in a system desktopcouch INI file?
[18:26] <CardinalFang> thisfred, Who's taking care of that?  Is that a packaging task?
[18:26] <thisfred> CardinalFang: not sure, I didn't think about it yet
[18:27] <thisfred> CardinalFang: it ties into packaging, yeah, since the install needs to put it there
[18:27] <CardinalFang> That file is new, I suppose.  Okay.
[18:27] <thisfred> CardinalFang: yeah we've used a local ini only up to now
[18:28] <CardinalFang> thisfred, Okay.  I'll own putting the file in /etc .  What path?  /etc/desktopcouch/default.ini  ?
[18:28] <thisfred> setup.py install can write the file to /etc/desktopcouch/ but I don't know what policies we need to follow there
[18:28] <thisfred> CardinalFang: that path sounds perfect
[18:28] <CardinalFang> Rgr.
[18:28] <dobey> urbanape: you should dress him up as mini-Lex Luther
[18:30] <urbanape> I've got a Superman tee-shirt.
[18:30] <urbanape> Amber could go as Lois Lane
[18:30] <urbanape> but I'd have to shave.
[18:31] <urbanape> Not sure if a couple hours of Halloween fun is worth itchy face for another month.
[18:31] <urbanape> I could be Zod
[18:32] <urbanape> And Amber could be Ursa
[18:33] <dobey> now you're thinking
[18:38] <statik> CardinalFang: the new package of couchdb has been prepared, and I've notified slangasek who agreed to sponsor if for me yesterday, so it should hit karmic later today. Additionally, I've dput ppa:ubuntuone/hackers couchdb_0.10.0~svn813472-0ubuntu1~ppa1_source.changes , so you can get early access to that package if it helps your debugging now
[18:39] <urbanape> anyone know if you can get Firefox's console to only show errors and messages? I really couldn't care less about CSS warnings and the like.
[18:40] <CardinalFang> statik, Okay, thanks.  aquarius smells a bug in couchdb, but I don't have details.  It may be bad news.
[18:40] <statik> awesome, i love bad news
[18:41] <statik> urbanape, one day i would love to do a screen sharing session with you and you can teach me all this firefox extension debugging stuff you do
[18:44] <urbanape> that reminds me.
[18:44] <urbanape> I'm gonna try to write up a bunch of this stuff on my blog.
[18:45] <jblount> urbanape: ++
[18:45] <urbanape> If only to help lay down a narrative for tackling what's left
[18:45] <jblount> (also note that mentally I still pronounce 'urbanape' as 'urban Ah-pay'
[18:46] <urbanape> "That Jim Williams went and shot himself someone. Urbanape?"
[18:46] <urbanape> Getting out the house for a bit.
[18:57] <leonel> updated today to the 0.94.0+r203-0ubuntu1~ppa1~jaunty and  I'm still getting  emtpy files
[19:28] <thisfred> CardinalFang: I can reproduce aquarius' oauth bug, but after deep pdb-ing I do fear it's in couchdb itself. Sent a mail to you both, and asked jasondavies on #couchdb
[19:29] <thisfred> OAuth is really unpleasant to debug, with the 20000 headers to get exactly right and that work only for a limited time and a single request
[19:29] <thisfred> Other than talking to jason, I'm giving up. Yet again more than half my day has been taken up with desktopcouch when I swore I would get to authentication on the server
[19:33]  * statik hugs thisfred
[19:42] <thisfred> :)
[19:45] <jdo> CardinalXiminez_, chad?
[19:46] <jdo> thisfred, are we having problems sending oauth requests to coucdb?
[19:48] <thisfred> jdo: not sure, it *seems* like couchdb is having the problem. When we do a GET to any design document, whether existing or no, we get a 401, while any request to a regular document succeeds.
[19:48] <dobey> jdo: i don't think he was expecting a spanish inquisition
[19:48] <jdo> dobey, nobody expects....
[19:49] <jdo> thisfred, is the handler different?
[19:49] <dobey> thisfred: oauth is fun... like shoving broken shards of glass in your ass, and sitting in a tub of tobasco sauce kind of fun.
[19:49] <jdo> thisfred, i mean between a design document and a regular document, is a different handler used
[19:49] <urbanape> nice visual
[19:49] <urbanape> ahhhhh, back to ERC.
[19:50] <dobey> heh
[19:50] <thisfred> jdo, I don't think so: I think it's related to admin vs non-admin rights. To be sure we authenticate as admin, (or so aquarius assures me) but it won't let us at _design/foo
[19:50] <jdo> _design is the handler :)
[19:51] <thisfred> I really don't know what you mean by handler, but I've never looked at the source code :)
[19:51] <dobey> thisfred: i wonder if it has separate tokens for those documents?
[19:51] <jdo> thisfred, _design = {couch_httpd_db, handle_design_req}
[19:51] <thisfred> dobey:  should not
[19:52] <dobey> thisfred: in any case, i'm happy to just blame aqu
[19:52] <dobey> arius
[19:52] <CardinalXiminez_> jdo, thisfred, sorry -- afk for 30 min.
[19:53] <CardinalXiminez_> I had wonky ISP and now I have to go anyway.  :(
[19:53] <thisfred> dobey: hehe, afraid he'd be pinged huh?
[19:53] <dobey> thisfred: no, sometimes my fingers type faster than my brain realizes tab complete will fail :)
[19:54]  * thisfred makes chicken sounds
[19:54]  * dobey turns on Smack My Bitch Up
[19:56]  * dobey also patiently waits for his $25 amazon e-certificate
[19:56] <jtatum> Hi U1 folks :) FYI... the retracer is incorrectly marking some U1 package bugs as dupes. I wrote this up against apport (bug 427488). Oauth failures should prolly be tweaked to return unique exceptions though. Should I write that up?
[19:58] <dobey> jtatum: hrmm
[19:59] <dobey> jtatum: well if it's not a duplicate, it should be unmarked as such (which i just did)
[20:00] <jtatum> There have been other dupes. The two oauth failures I know about are clock skew and the domain name change. Apport treats both of these as the same issue and dupes everything to bug 423383
[20:00] <dobey> well the failure is the same
[20:00] <jtatum> And if yet another oauth exception happens, apport will probably do the same thing
[20:00] <dobey> the token string is empty
[20:00] <jtatum> But they are different causes and fixes....
[20:01] <dobey> well, the problem with the redirection was that the code wasn't handling redirections (which weren't getting raised as errors from pycurl)
[20:04] <jtatum> right
[20:05] <jtatum> dobey: I guess I'm just saying it would be a much better user experience if users filing bugs through apport with clock skew got duped to the clock skew bug (which has the problem and a workaround in the comments) and users experiencing the domain issue got duped to their own bug which would similarly explain the issue in the comments...
[20:05] <dobey> so there is no unique error case for that, as the fix is to handle redirection
[20:06] <jtatum> as it stands, users experiencing the domain issue get duped into a clock skew bug and comment that their clocks are fine
[20:06] <dobey> jtatum: i'm not disagreeing
[20:06] <jtatum> ok :)
[20:06] <dobey> i'm just saying, that's not really going to happen, as releasing the fix for the domain bug just means the bug is gone, and nobody is going to see it unless they're running the old version, which is going to get dup'd wrong anyway :)
[20:08] <jtatum> dobey: gotchya. I guess I was just thinking towards the future when any subsequent oauth null tokens are going to get duped in the same place, even if the server returns a different message.
[20:09] <dobey> jtatum: well, it already raises a different error when the server sends back an error code. the problem is that HTTP 30x isn't an error :)
[20:13] <jtatum> dobey: So is the server not sending back an error code in the clock skew case?
[20:14] <dobey> jtatum: i don't know where the log message for the clock skew is coming from, i have to look and see
[20:16] <jtatum> dobey: OK thanks :) Just trying to help.
[20:21] <thisfred> http://www.readwriteweb.com/archives/facebook_open_sources_friendfeeds_real-time_web_fr.php
[21:10] <dobey> jtatum: hrmm. weird
[21:14] <dobey> and "pydoc pycurl" isn't helpful
[21:18] <dobey> well meh
[21:18] <urbanape> hmm, live music here at the coffee shop. Maybe I'd best walk back home.
[21:19] <dobey> hmm
[21:26] <CardinalFang> thisfred, should we panic yet?
[21:26] <CardinalFang> thisfred, any news from couchdb folks?
[21:26] <thisfred> never to early to panic. No response whatsoever on #couchdb
[21:27] <thisfred> I think jason is afk
[21:30] <dobey> jtatum: will have to chat with aquarius about it tomorrow i guess... he's supposed to fix another issue in that code, and part of the problem is that python-oauth does stupid blanket try:except: clauses, and just raises OAuthError for everything, so we can't really tell what it is, unless we go around parsing complex strings :(
[21:31] <CardinalFang> thisfred, trying to pull some personal strings there.
[21:32] <thisfred> I see, pinging damien directly, wow. Brave man :D
[21:35] <urbanape> okay, heading home. This is way too distracting.
[21:35] <jtatum> thanks for looking, dobey. You rock
[21:40] <dobey> jtatum: i try :)
[21:42] <thisfred> there is no try, there is only rock :)
[21:59] <jdo> CardinalFang, in trunk: ./utilities/web_api_tool.py  --url https://edge.one.ubuntu.com/api/account/
[21:59] <jdo> couchdb_root https://couchdb.one.ubuntu.com/u/45c/48c/9
[21:59] <CardinalFang> jdo, You are a rock star, sir.
[22:00] <jdo> well that's mine! hands off everyone!
[22:00] <thisfred> CardinalFang: statik bug confirmed, fix confirmed, jasondavies is writing a testcase
[22:00] <thisfred> the problem was encoding of slashes
[22:01] <thisfred> shame we couldn't have found this before packaging a new couchdb today...
[22:03] <CardinalFang> thisfred, rawk.
[22:19] <statik> thisfred, it's fantastic that the bug is found and fixed and testable
[22:20] <thisfred> yes, I agree, it's the next best thing to not having the bug :)
[22:37] <thisfred> CardinalFang:  statik: hmm, jason has trouble writing a test (seeing as the tests are all in browser, doing auth is hard) but he sent the patch http://friendpaste.com/5iB7rxvilb4TM1EKwUzOwR
[22:38] <thisfred> he doesn't have commit access himself, so hopefully someone else will land this ASAP
[22:49] <thisfred> statik: patch will be committed by tomorrow €morning latest
[22:49] <jdo> thisfred, it's good we're tickling these bugs now and not later
[22:49] <thisfred> jdo oh yes, couldn
[22:49] <thisfred> t agree more