[01:29] heya, statik [01:29] hey [01:29] so, what's the word in the new world order about merging bindwood branches to trunk? [01:30] now that it's under the auspices of ubuntuone-control-tower [01:30] you just propose for merge to trunk and set the commit message, and then it gets marked approved after reviews [01:31] k, did that [01:31] we don't have tarmac in cron yet, so i have to kick it off manually [01:31] i can do that now [01:31] not sure about the commit message, though. [01:31] does it need to be formatted specially? [01:31] nope, nothing special [01:31] just hopefully somewhat descriptive [01:32] so if you set the commit message here https://code.edge.launchpad.net/~urbanape/bindwood/thorough-debugging/+merge/10928 i can run tarmac on it [01:33] huh, the ancestry on that branch is odd [01:33] it looks like it was branched from the packagebranch rather than from trunk [01:33] hrm. [01:34] also, should I be able to edit the commit message? I see no edit icon or link [01:34] yeah, there should be a pencil icon next to the commit message, at least if you are logged in [01:34] https://code.edge.launchpad.net/~urbanape/bindwood/thorough-debugging/+merge/10928/+edit-commit-message [01:35] ah, weird. yeah, somehow I got logged out. [01:36] k [01:37] I recall branching after we had done some changes, but I thought it was still cut from trunk. [01:38] i don't think it will hurt anything [01:38] packaging branches are basically a long-lived branch from trunk [01:38] that never gets merged to trunk [01:38] but trunk is merged to it for every release [01:39] in this branch, we're merging the packaging branch to trunk but you've deleted the packaging stuff from it [01:39] i think bzr will be smart enough to handle it [01:40] urbanape, alright, tarmac has merged it. thanks for the great branch! [01:41] so, for my local copy of trunk, its source is... [01:42] ~ubuntuone-control-tower/bindwood/ubuntu/ [01:42] is that correct? [01:42] yep, that should be right [01:42] the shortcut for that is lp:bindwood [01:42] it's entirely possible that i had already made the branch history funky, i'll run bzr qviz on it tomorrow [01:44] urbanape, do you know if it's possible to put 8gb of ram in the older macbook pros, or only the new ones? [01:45] how much older? [01:46] statik, I'm pushing desktopcouch my changes to lp now. [01:46] the first unibody MBP could take 8, I believe. [01:46] ah, mine won't work then [01:46] CardinalFang, awesome! [01:46] the previous MBP I think maxed out at 6GB [01:46] urbanape, statik, https://code.edge.launchpad.net/~cmiller/desktopcouch/get_port_not_stale [01:47] I think it's close to right. My brain is mush now. [01:47] Please eyeball it if you have any cycles left. [01:47] * CardinalFang sends message to aquarius to see it. [01:48] CardinalFang, sure. want to propose it for review? or you just want a pre-review review? [01:49] statik, proposed for merge, so reviews are online. [01:49] Thx! [01:49] Good night, all. [01:49] gnight [01:50] Oh, and beware that teh test suite screws around with couchdb and leaves one running that isn't what you expect. the port-finding code freaks out at it half the time. :( Much time wasted there. :( [01:50] * CardinalFang collapses. === CardinalFang is now known as CardinalFangZzzz [02:28] What's the best way to run the desktopcouch tests? [02:35] urbanape: first, you take a young rooster [02:36] urbanape: I'm not too sure how it goes from there, but you should probably not wear a suit [02:40] Chipaca: I think it involves vaseline and a pair of electric shears [02:40] and... that's probably why I blanked it out [02:42] Hmm, all my Tyvek suits are at the cleaners. From the last time I ran hairy tests. [02:44] "trial desktopcouch" [02:57] lots of waiting for couch to start... [03:03] will noodle on it in the morning. [03:03] night, folks. === teknico is now known as teknico_away === teknico_away is now known as teknico === teknico is now known as teknico_away === teknico_away is now known as teknico [13:14] goedemorgen === teknico is now known as teknico_away === teknico_away is now known as teknico [14:07] Yo, yo, yo, yo [14:13] yoyo. [14:15] aquarius: yo yo, yo? [14:16] jblount, Yo. Yo-yo, ya? [14:19] aquarius: yo. :) === teknico is now known as teknico_away === teknico_away is now known as teknico [14:24] aquarius, has thisfred convinced you that d-c log reading isn't as good? [14:26] CardinalFangZzzz, not quite. I'd like to hear your reasoning too :) [14:26] aquarius, the absolute best approach is to make couchdb emit its info on request. -b starts, -k kills, -I (!) prints JSON information about the running process, including ports and addresses used. TODO: implement -I === CardinalFangZzzz is now known as chad === chad is now known as CardinalFang [14:27] CardinalFang, yes. The couch people have talked about that, too, but it hasn't happened yet, and it won't for karmic :( [14:27] brb, have to reboot === teknico is now known as teknico_away === teknico_away is now known as teknico [14:33] aquarius, We never know if the port is correct. The log file can be stale; it always exists, regardless of process' existence. We can add the additional check of trying to connect to a port, but we don't even know if we really connect to someone else's couchdb (unless we check auth too). [14:34] but you have to wait to see if couch started up properly *anyway*, before doing anything to establish the port. [14:35] since we need to do that regardless, if you've done that check, then you know the logfile won't be stale === gafton_ is now known as gafton === yofel_ is now known as yofel [14:36] aquarius, I don't know if I need to start couchdb at all. Log file is there. Is it from last month? [14:36] that's what find_pid is for. [14:37] you need to check the pidfile, and see if it's stale, and if it is, then start couch. === teknico is now known as teknico_away [14:38] CardinalFang: that's where I messed up: I thought I kept the calling structure intact, and that I checked that everywhere find_port was called, find_pid was called first, but apparently I messed up [14:39] Perhaps I should have let find_port continue to require a pid argument, even though it's not used [14:39] thisfred, I added that. === teknico_away is now known as teknico [14:44] CardinalFang: aquarius and I discussed earlier that we (I) need to fix the tests, so that they use the find_port and find_pid again, while not starting up the real couchdb, by hacking into local_files in a different way. Have you tested your branch manually, because the current tests don't actually exercise the find_port and find_pid code at all... [14:45] which is how I managed to slip up and create logfilegate [14:45] CardinalFang, my suggested approach is to lie to xdg about where your base directory is. That's what the start_local_couchdb test does. and then everything shoudl work :) [14:46] aquarius: yeah, that part I'm starting a branch for now. My concern is that we should get CardinalFang's branch landed ASAP if we know for sure it works, since the current code doesn't [14:46] agreed [14:47] but...having the code landed doesn't actually help, since what we need to do is get that code into a package and then into a PPA so people can start testing it [14:47] But I do want to know it works. I'm not having much luck with importing find_port [14:47] and I don't want to hassle kenvandine into building a package more than he has to, since he's busy :) [14:48] true [14:49] aquarius: ok, then I'm starting the branch to fix the tests first, since we need to get that landed at the same time, and then package [14:50] aquarius: CardinalFang and we can use it to verify the correctness of any solution to the find_port issue you guys come up with === teknico is now known as teknico_away === teknico_away is now known as teknico [14:54] aquarius, thisfred, CardinalFang: if you have some proposed branches... i can merge them together into a ppa build for testing [14:55] aquarius: open question: starting couch before, and stopping it after each test will be too slow, I think. Any good suggestions on a testcase wide 'teardown'? [14:56] You didn't like my stochastic method. [14:56] * CardinalFang hugs the word 'stochastic'. [14:56] CardinalFang: no, randomness in tests, I dislike :) [14:57] CardinalFang: I prefer having a single test that tests the stopping and restarting [14:57] CardinalFang: then run all the other tests against a running couch [14:57] CardinalFang: also, the stochastic method leaves the couch running at the end of the tests, so it doesn't solve this problem [14:59] thisfred, teardown is just stopping couch. call desktopcouch-stop, that's what it's for [14:59] is it madness to stop couch from the testcase class' __del__ ? [14:59] thisfred, yes it is. [15:00] aquarius: teardown is run after each test [15:00] thisfred, There's a container for test cases. Can 'trail [15:00] MEETING BEGINS [15:00] 'trial' use test suite code? [15:00] ZOMG! If you are a desktop+ person, this is your time. "me" get's your voice heard, hopefully your voice sounds like "DONE / TODO / BLOCKED" [15:00] dagn. [15:00] me [15:00] thisfred, what? no it isn't, is it? setup runs at the start, teardown runs at the end [15:00] aquarius: of each test [15:00] me [15:00] me [15:00] me [15:00] me [15:01] (continue after) [15:01] me [15:02] me [15:03] CardinalFang: It's go time [15:03] DONE: desktopcouch replicate to u1. desktopcouch getPort() fixups. desktopcouch pairing fixups. reviewed aquarius' talk notes. [15:03] TODO: get reviews. package d-c? [15:03] BLOCKED: Nein. [15:03] aquarius, if you please.... [15:03] ⚀ DONE: bank holiday, reviewed chad's port branch; work with jan to fix oauth problem [15:03] ⚁ TODO: continue piston oauth in snowy; finish DC talk for Ubuntu Developer Week; look at doing username URL at U1; discussions with thisfred/cardinalfang about DC port stuff [15:03] ⚂ BLOCKED: nothing (woo!) [15:03] doo-do-do-do, doo-doo, doo-doo, you can't touch jblount [15:04] DONE: Tiny branch to fix tiny bugs, resolved (and landed) weird issue with pqm not liking my overlays-skin branch, slapping my VMs into shape. [15:04] BLOCKED: Nope (although need statik to tell me if I should submit a RT about hooking up blog.ubuntuone.com or some other address setup DNS style) [15:04] TODO: Add tabs to website (again) with some re-thinking about nav, get wordpress.com blog into shape [15:04] teknico: rocknroll [15:04] DONE: worked on a Funambol deployment problem with pfibiger and mattgriffin, implemented the list_all template tag for the contacts CRUD web ui, improved the options handling of the create_couch_contacts.py script [15:04] TODO: implement the details view for the contacts CRUD web ui [15:04] BLOCKED: none [15:04] next: rodrigo_ [15:04] DONE: More tomboy syncing fixes. oAuth request signing in couchdb-glib. Attended some ubuntu developer week talks. Prepared couchdb-glib basic info for Wednesday's aquarius talk [15:04] • 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). [15:04] • BLOCKED: none [15:04] next aquarius [15:04] ugh next statik [15:04] or thisfred, sorry :D [15:05] rodrigo_, fail :) [15:05] DONE: New snapshot package of couchdb 0.10.x with a handful of bugfixes including cascading auth. [15:05] TODO: desktopcouch bugfix release and packaging branches reorg [15:05] BLCK: not-blocked-just-yet but anxiously awaiting versions of desktopcouch, bindwood and couchdb-glib which use oauth by default. And a version of couhcdb with SSL! [15:06] me [15:06] dobey: Your turn [15:06] ☭ DONE: Released poauth 0.1, Packaged poauth 0.1, Pushed poauth to REVU, Fixed some small issues in poauth, Fixed ubuntuone-client to use poauth, Fixed ubuntuone-storage-protocol to use poauth [15:06] ☭ TODO: Backport poauth to jaunty/hardy, Fix ubuntuone-storage-server to use poauth, Fix #409281 [15:06] ☭ BLCK: None. [15:06] erm, okay [15:06] you lied [15:06] DONE: Most of the way through the design for Bindwood to talk to Couch via OAuth. [15:06] TODO: Finish that up and push and propose. Also, I'm Face and On-Call Reviewer today. [15:06] BLOCK: Getting my desktopcouch branch to actually expect OAuth. Need a little help. [15:06] standup.next() -> StopIterationError [15:06] urbanape, I can help with that [15:06] aquarius: Zope TestCases have a way of doing testcase wide initialization and cleanup, but I don't think basic python unit tests do. (which is more in keeping with unit testing as it's meant to be, but a pain in cases like this) [15:07] aquarius, I'd like that. [15:07] urbanape: hugs, sorry I get confused keeping things in order. [15:07] *sniff* it's okay. [15:07] MEETING ENDS (somewhat tentatively) [15:08] oh, I missed: talk to someone who's interested in DC but uses fedora, so there might be some work to make that happen going on over the next week or so. :-) === urbanape changed the topic of #ubuntuone to: Help contact: urbanape | 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:09] aquarius: the opensuse build service builds stuff for fedora also, so we could try finishing my work there and provide packages for all those RPM distros [15:09] rodrigo_, rawk! really? I didn't know t hat. [15:09] aquarius: yes, and for debian and ubuntu also [15:10] although for .deb it needs more work, and it doesn't make sense for us [15:10] rodrigo_, certainly DC doesn't do anything Ubuntu-specific, so it shold work elsewhere, assuming you have a hysterically up-to-date couchdb ;-) [15:10] but for RPMs, we should be able to do one .spec with very few changes for both [15:10] aquarius: yeah, I was a bit blocked on my opensuse packaging work because of erlang and couchdb [15:10] I'm looking forward to the results of someone running DC on fedora to confirm that it works, work out which dependencies are required, etc [15:11] but once that is done, it should be easy to package the client stuff [15:11] aquarius: so when you're going to work on it, let me know and we'll see how to do it there if you want [15:13] rodrigo_, someone else is working on it, I hope, rather than me, but yeah :) [15:14] aquarius: ah, cool, we can just then publish the .spec in OS build service, and have the packages for both distros built there [15:14] nice :) [15:15] aquarius: so, if I poke the right XDG values into env, and force reload xdg.BaseDirectory (siC(amelCase)) it just works? And *that* doesn't mess with the rest of my system? Really? [15:15] it doesn't mess with the rest of your system because the environment you've set goes away once the process ends. (doesn't it? it does, right?) [15:16] aquarius, Rgr. [15:16] I hope so, because they're not explicitly unset :) SO, probably we would have found out [15:16] yep. So we're golden. :) [15:16] aquarius: coolness [15:17] that's simple enough, wish I'd seen that [15:17] aquarius, this process and all its children, (unless exec* is packed with a explicit environment). [15:17] CardinalFang, that's what I thought. (Sudden clenching fear that I might have been wrong ;)) [15:17] only open problem: how/when to stop the test couchdb [15:17] in shutdown. [15:17] thisfred, How evil do you want to be? "import atexit" [15:17] although I admit for that we need test-suite-wide setUp and tearDown. Someone must surely have solved this problem though! [15:18] aquarius: indeed, zope testcase has, perhaps twisted as well [15:18] CardinalFang: evil in tests I can live with [15:18] if it doesn't, then have each setUp call test_suite_wide.setUp, which starts couch and then sets an envar. If the envar is set, don't start couch again [15:18] i was just checking for suite setUp and tearDown, and didn't find it. :( [15:19] aquarius: yeah, the starting is easy [15:19] we need to be a little cleverer because you might want to run a subset of the test suite [15:19] aquarius: the *stopping* however [15:19] thisfred, "atexit" will let you stop at exit. [15:19] CardinalFang: I'm fine with that [15:19] ah, yeah, stopping is harder because an individual tearDown can't look into the future to know whether there are other tests coming. atexit is probably the way, although it's horrid :) [15:19] I'll leave refining it to people with more developed sensibilities ;) [15:20] being Dutch means never saying sorry, even if you have to :) [15:20] * aquarius applies for a dutch passport. [15:21] so...thisfred, you're redoing the tests? [15:21] aquarius: yes, should not be much work, mostly throwing code away [15:21] aquarius: you can never go on holiday again [15:21] thisfred, cool [15:22] thisfred, I am beginning to get that impression. I suck at organising things :( [15:22] aquarius: nah, I should have dug 1 mm farther [15:23] (hrmpf! does "couchdb -s" do nothing?) [15:24] dpends on your definition of nothing [15:30] aquarius, so, I'm modifying the script that we had been using that generates the CouchDB port (dbus.sh) to get our overall environment necessary. So that script will spit out the port and the OAuth bits we need to communicate with Couch. [15:31] urbanape, cool. Can you talk to the keyring from the shell? [15:31] I've got your dc-records-oauth branch checked out, but there's nothing that's seeding my keyring. [15:31] yes, I can, but there's no match (obviously) [15:32] ah, you want DC trunk, I think :) [15:32] k, I can do that, too. [15:33] also, I seem unable to kill my system-installed desktopcouch. should I remove the package altogether while this is under development? [15:34] run desktopcouch-stop [15:34] er, /usr/lib/desktopcouch/desktopcouch-stop [15:34] yeah, did that. [15:34] killall beam.smp is the nuclear option :) [15:35] killed it hard and dead [15:41] thisfred, aquarius, so what's the state of getPort fixing? Testing, and if pass, merge, and then release as 0.3.1? [15:42] yes, that would have my +1, I'm working on the testing now [15:44] CardinalFang, if we can get the tests in before releasing a 0.3.1 I'd lie that [15:45] aquarius: fail [15:45] aquarius: the xdg stuff looks nice in theory, but it doesn't quite work yet [15:45] what doesn't work? [15:45] everything, including the test_design docs, still talks to .cache [15:46] it's probably an import order problem. [15:46] might have to explicitly override xdg.cache_dir or whatever it is too [15:46] I think local files is loaded before the tests start poking [15:46] and so the dirs are never recomputed [15:48] let's see what effect moving the imports around has [16:03] aquarius: I don't understand: why do you use a mocker if the tests are supposed to talk to a fake database? [16:03] I mean real database, but not the user's [16:05] look at the client tests. we override some env vars so stuff gets written to _trial_temp/foo instead of ~/.foo [16:05] dobey: thanks, will do [16:05] thisfred, I'm using the mocker for belt-and-braces security. We'll need to actually start a real couch for testing couch-startup [16:06] or rather, our problem was that it was trying to write to /.cache, because the env was empty for the tests, given the way we run them in ubuntuone-client [16:08] aquarius: so the one test that does this poking to start up a new database doesn't actually talk to it, right? [16:08] I knew we'd need it... [16:09] aquarius: oh yeah, and I think it works almost, or sometimes, so I'm happy you did most of the work ;) [16:10] eh, i don't think "can we actaully start a db" is a particularly good test [16:10] I just should learn to never ever say again in any context: "should not be much work" ;) [16:10] heh [16:11] license revoked :) [16:12] dobey, why? [16:12] dobey: starting a database in itself is a good test, because we do it in a very complicated way. Also: that's not so much at issue here, since that test doesn't actually exist: we need to start a database for all the tests to talk to. [16:13] aquarius: because it's going to fail for anyone that doesn't have a specific version of couchdb, and might fail due to configuration differences [16:13] dobey, that's the point. We want to know that the startup scripts properly cope with bad situations, and properly actually start up couch, so we know that we haven't broken them with a checkin. [16:15] i am quite happy that in poauth, i completely avoided using a BaseHTTPServer to test the code/protocol [16:17] aquarius: we should totally use what the client does. Shame we can't depend on it, so I'm gonna steal its testcase runner [16:18] dobey: yes of course, faking and mocking is great for unit tests, but we're talking functional/integration tests here, really [16:19] dobey, this isn't testing the protocol (I mock CouchDatabase, and we can continue doing that). This is testing that the scripts that start up couchdb actually work [16:21] aquarius, chad: stupid question: what actually is 'trial' and why do we use that rather than the five million other arbitrary ways to run tests? (I'm not saying we shouldn't, it works just fine, genuinely curious since I hadn't come across it before) [16:22] is it twisted? [16:22] trial is the twisted test runner [16:22] right [16:23] ubuntuone client seems to actually patch that into the regular test runner [16:24] aquarius: I'm also asking since I think we may set the env vars at the start of the test run, and do cleanup at the end, but I need to find out where I can hook in [16:25] thisfred: ubuntuone-client has its own test runner which inherits from the twisted one [16:26] thisfred: trial has nicer output than just running the standard python unit test thing [16:26] dobey: no, it does not inherit from it, it imports it and uses it though [16:27] thisfred: well that's what i mean by "inherits". we don't just run "trial" but imported the twisted test runner independently [16:27] and do some other stuff on top [16:27] like the env magic and start up a dbus session bus [16:27] thisfred, not to be too much of a distraction, but where is the service I use to map OAUTH to usernames or database-names ? [16:27] CardinalFang: this jdo would know :) [16:28] CardinalFang, it has not been deployed yet [16:28] CardinalFang: I can also look up the branch in my mail [16:28] ah [16:29] jdo, okay. Out of curiosity, what does it yield? [16:32] CardinalFang, User info: ID, username, first/last name [16:32] email [16:36] aquarius, SteveA, thisfred: did we decide on a naming scheme for the desktopcouch database names on U1? "%(username)s/%(databasename)s" ? [16:36] CardinalFang, I think it's a bit more complex than that, for easier HTTP sharding. thisfred knows though :) [16:38] aquarius: the http sharding is an open issue. We're using u/xxx/xxx/[userid]/[databaseid] where the xxxs are the first six characters of the hash of the user id. this is to spread the dbs evenly over directories, but I don't know that it will scale out over multiple servers as is [16:39] so anyone have any idea how I can hook into the start of a twisted trial run? are there plugins you can register or something? [16:40] thisfred: you probably want to do stuff in setUp() normally, but dbus seems to fail at that [16:41] dobey: but there should be a way to hook into the test run, rather than each individual test, right? [16:41] so if you need to start a dbus session bus, then you basically need to do what ubuntuone-client does (which is have its own test script), and run that instead of trial [16:41] yeah, I was afraid that was the answer [16:42] you might be able to do less work in a shell script, instead of python, but i'm not sure what all you need to do exactly [16:42] and i'm off to get some lunch :) [16:43] * aquarius ahahahahas at thisfred and CardinalFang over tcole's comment about the logfile on CardinalFang's branch :) [16:49] so, for reading port info from the logfile: me and tcole. For reading it from /proc: CardinalFang and thisfred. And tcole's got the coolest beard, so he wins. [16:50] the main thing is dealing appropriately with stale information [16:50] once we get the info from the log file, actually try talking to the process to verify [16:51] ironically, I shaved the beard off some time ago [16:52] aquarius: and I'm working on mine, or at least have been too lazy to shave since I moved. Also: I'm totally +1 on logfile, but +10 on what we can get working now. Which in my case seems to be absolutely nothing, mostly. [16:54] CardinalFang, thisfred: it would be interesting to get tcole's perspective on your technical issues with using the logfile [16:55] aquarius: no technical issues, AFAIK: we just reverted to the working proc file, because the logfile code was broken [17:08] aquarius, thisfred, I'm happy with using the logfile if you can get it working as well. [17:08] Lunch! Back in 1h! [17:13] thisfred, I need to get going -- have to meet up with some people this evening :( [17:13] aquarius: ok, keep you posted by mail [17:14] sorry to have to bail [17:19] aquarius: no problem, I will sort it! I'm sure === yofel_ is now known as yofel [17:55] statik, you about? [18:12] or anyone else hip to the new Couch DB + OAuth? [18:35] j0! [18:36] heya, CF === teknico is now known as teknico_away [18:49] CardinalFang: heads up: I think I'm near a solution for the tests, at least it's now completely broken, and not seemingly working but talking to the wrong db. I understand you will be working on the packaging, so I will tell you when I'm done, and hopefully get some other people to review it. [18:49] thisfred, Roger. [19:05] CardinalFang: bah: I think the problem may be: 1. tests poke in env settings to point to test couchdb 2. tests initiate code that talks to couchdb 3. code that talks to couchdb gets info from DBUS 4. DBUS finds couchdb not running and starts it, but at this point I'm not sure it looks at the test ENV anymore [19:06] It's a Kind of Magic [19:06] thisfred, well, the dbus call only works because bin/desktopcouch-service is running. [19:07] CardinalFang: ah, right, I could start my own from the tests. That would break the user's normal operations, but at least we don't screw up their real data, though they could screw up our test data, or lose some writes to our temporary db [19:09] Man, this is a fine ball of twine though. [19:09] I want test driven development. At least for everyone else's code! :) [19:29] thisfred, I say just kill your running desktopcouch-service and start it where you're testing. Don't get bogged down in making trial work directly. Just make a shell script, "run-tests" that does what you need. [19:30] thisfred, any eta on a dc release? [19:30] * gafton_ begs xchat to stop quitting [19:30] CardinalFang: yeah, I'll do that, I think. [19:32] kenvandine: not sure no, but I'm not sure how much work we'll be bugging you for, as CardinalFang and statik have changed the release process for dc substantially, so probably CardinalFang can answer your question better than I [19:32] kenvandine: if we're all waiting on my tests fix, then, eh, as soon as I get a clue... :( [19:33] i am mostly concerned with getting it in time to have an uploader still awake [19:33] right [19:33] statik, CardinalFang: when you guys work on the packaging branch... make sure you merge in my changes in ~ubuntu-desktop [19:33] thisfred, yeah... it's pitti who is in germany === rmcbride changed the topic of #ubuntuone to: Help contact: urbanape | File Sharing for Ubuntu | https://ubuntuone.com | https://launchpad.net/ubuntuone | Current Beta Client Revno is 194, Protocol Revno is 69 | Release 0.93 [19:33] getting late there now [19:34] CardinalFang: the critical bugs are fixed yes? [19:34] CardinalFang: perhaps we should let perfecting the tests not keep us from releasing then [19:36] kenvandine, I think we've done that. Thanks! [19:36] CardinalFang, good... just make sure desktopcouch depends on python-desktopcouch-records :) [19:37] kenvandine, It does. [19:37] good [19:41] thisfred, so are the tests at least passing? [19:43] kenvandine: the tests always pass, and test the real code, the only part that is undertested is the stuff that starts couch. That is how the logfile reading bug slipped through. [19:43] ah [19:44] CardinalFang: can I get an ack on the portnumber issue being done? [19:44] ow, it's still waiting on review [19:44] I wish stuart hadn't abstained. That resulted in everyone else avoiding it [19:46] CardinalFang: I'll do a review, but can you tell me the best way to manually test that the code actually finds the port and if not starts couch? [19:48] thisfred, confirming. [19:48] ... [19:52] thisfred, fwiw... i did build a deb of your branch and ran it... seemed fine [19:54] kenvandine: mine, or chad's? [19:54] oh [19:54] chad's [19:55] lp:~cmiller/desktopcouch/get_port_not_stale [19:55] right, that's good news. I'll look through the code, and approve asap, and cajole someone else into doing the same [19:56] hrmm [19:59] thisfred, Okay: Confirmed that https://bugs.edge.launchpad.net/desktopcouch/+bug/420911 is avoided with /proc searching. [19:59] Launchpad bug 420911 in desktopcouch "Cannot getPort - desktop-couchdb.log doesn't exist" [Critical,New] [19:59] Added comment about it. [20:00] So, the other bug, hrm.... [20:02] https://bugs.edge.launchpad.net/desktopcouch/+bug/422127 Added comment. [20:02] Launchpad bug 422127 in desktopcouch "getPort succeeds when desktopcouch isn't running" [Critical,New] [20:02] kenvandine, Are those ^ the two very big bugs we should fix now? [20:02] yes [20:03] Rock. [20:15] CardinalFang: branch is approved as you probably noticed, but if not, now you know [20:15] ;) [20:15] and let me know what else I can do to help [20:16] thisfred, Okeh! Dank. [20:27] statik, You around? [20:32] hi CardinalFang, i am now. did my mail go through this time? [20:33] statik, Yes. Now I see both. Weird. [20:33] Thanks! [20:48] statik, i need to run out pretty soon... can you prepare the upload for the dc release? [20:48] and ping pitti if he is still around? [20:49] statik, I can't find where to upload the orig.tar.gz . Should it be a link on https://edge.launchpad.net/ubuntu/karmic/+source/desktopcouch ? [20:54] statik, ok... pitti is still around and awaiting your ping :) [20:54] when you guys are ready [20:56] I am a horrible Face. [20:56] statik, i am heading out for a bit.. call my cell if you have any urgent needs [20:57] kenvandine, I'm uploading. [20:57] Well, I am trying. [21:11] kenvandine, statik, "A release requires a corresponding milestone that is not attached to another release." Wtf? [21:12] yes [21:12] CardinalFang: just make a new milestone called 0.4 or 0.3.1 or whatever you are numbering the release [21:12] Okay. [21:28] statik: re:ssl kocolosk reports back that it *does* seem to be a simple oversight, and that a workaround would be 5 minutes work (let's inflate that a lot to include landin testing and packaging) but he's talking to überstream to see what solution mochiweb would prefer [21:28] rawk, thisfred. [21:29] CardinalFang: indeed :) [21:31] kenvandine, james_w had agreed this morning to sponsor, we are going to try doing a merge proposal to lp:ubuntu/desktopcouch [21:31] will definitely ping pitti if we can't get james_w for some reason [21:32] thisfred, that is great news [21:32] * dobey wonders if james_w got to look at poauth today [21:38] thisfred, as soon as SSL support is committed to the 0.10.x couchdb branch i will build a new package [21:39] statik: I will immediately dispatch a pigeon when that happens [21:39] forthwith! [21:40] awesome [21:40] i'm going to see about backporting erlang and xulrunner and couchdb to hardy for the data center now [21:41] dobey, any exotic packages you uploaded to karmic that should go on our watchlist for bugs other than icontool? [21:43] i'm trying to get poauth uploaded into karmic [21:43] ok, i've got that on my list [21:43] it's still on the fence [21:46] statik: i hope we can get it in though [21:46] me too [21:49] dc0.3.1release$ bzr bd -S [21:50] dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 [21:50] debuild: fatal error at line 1334: [21:50] dpkg-buildpackage -rfakeroot -d -us -uc -S failed [21:50] bzr: ERROR: The build failed. [21:50] statik, ^ Hrm. [21:50] CardinalFang, you might need to specify which key to sign with [21:50] does debuild -S -sa do any better? [21:51] also, i have DEBSIGN_KEYID=NNNNN set in ~/.devscripts [21:51] statik, same. Exactly the same, I thinkj. [21:51] which overrides which key is chosen to sign with [21:52] otherwise devscripts tries to find the key based on the email address in the changelog, which doesn't always work the way you want it to [21:53]