[00:19] <lifeless> do we still use the keyring trust analyzer ?
[00:28] <wgrant> lifeless: I doubt it and I hope not.
[00:28] <wgrant> But it doesn't seem to log to scriptactivity, so we'll never know.
[00:28] <lifeless> hmm
[00:28] <lifeless> where is that cronscripts branch
[00:29] <wgrant> It's not in there.
[00:29] <lifeless> ah, you checked ?
[00:29] <wgrant> wgrant@lamuella:~/launchpad/lp-production-crontabs$ bzr grep email-clus
[00:29] <wgrant> wgrant@lamuella:~/launchpad/lp-production-crontabs$
[00:31] <wgrant> It was added in 2005 and hasn't really been touched since.
[00:31] <wgrant> I blame jamesh.
[00:31] <wgrant> Maybe he knows something.
[00:31] <wgrant> I suspect it's been obsolete for 5 years, but we'd best check.
[00:31] <lifeless> I think I had something to do with it too :P
[00:31] <lifeless> I'll just delete it.
[00:31] <wgrant> You appear too, yes.
[00:31] <wgrant>    * robert.collins@canonical.com/launchpad--keyring-trust-analyzer--0--patch-1
[00:31] <wgrant>      snapshotting current pgp work
[00:31] <wgrant> But jamesh is all the later stuff.
[00:31] <lifeless> IIRC I did the plumbing
[00:32] <wgrant> Gets rid of stupid tests from canonical.launchpad, too.
[00:32] <wgrant> Kill it!
[00:36] <wgrant> Ah, I didn't do too badly last week.
[00:36] <lifeless> ?
[00:36] <wgrant> My stale appserver pid file is from before EOD on the Friday before!
[00:37] <lifeless> class LogCollector(logging.Handler):
[00:37] <lifeless> -yet- -another- -yes-
[00:37] <wgrant> Heh.
[00:37] <wgrant> They're mostly cleaned up!
[00:44] <wgrant> lifeless: I guess there wasn't much fdt progress last week?
[00:47] <lifeless> you guess well
[00:52] <lifeless> not as much code as I hoped
[00:52] <lifeless>  7 files changed, 750 deletions(-)
[00:52] <wgrant> :(
[00:59] <lifeless> can has revooo https://code.launchpad.net/~lifeless/launchpad/bug-830789/+merge/72371
[01:02] <wgrant> Huh, only three gpghandler methods?
[01:02] <lifeless> indeed
[01:03] <lifeless> I'm not sure what to do with zeca
[01:03] <lifeless> it seems massively overkill for it to be a twisted daemon
[01:04] <lifeless> but I'd hate to have a transitive dependency on twisted for a web.py microservice
[01:04] <wgrant> Probably.
[01:04] <lifeless> so I need to either rewrite it, or have two entirely separate packages with gpg support stuff
[01:04] <lifeless> I'm thinking rewrite
[01:08] <wgrant> lifeless: Approved, but with lint.
[01:09] <lifeless> hah
[01:09] <lifeless> at least its valid
[01:09] <wgrant> Yes.
[01:10] <lifeless> wgrant: did you see privmsg ?
[01:12] <wgrant> Missed that, sorry.
[01:23] <jamesh> wgrant: I don't think we ever put the keyring trust analyzer code into production (at least, we didn't while I was working on LP)
[02:28] <wgrant> lifeless!
[02:28] <wgrant> You deleted the pygpgme sourcecode!
[02:28] <wgrant> Yay.
[02:28] <wgrant> Burn!
[02:30] <StevenK> Re-add it so we can delete it again!
[02:36] <lifeless> wgrant: yes, I did.
[02:38] <lifeless> wheee 1800  OOPS-2059AY24   POFile:+translate
[02:43] <StevenK> wgrant: It moves to an egg
[02:43] <wgrant> StevenK: Yes.
[02:43] <wgrant> But at least it's not a patched branch in sourcecode.
[02:44] <StevenK> Bah, why do I still have a sourcecode/shipit directory
[03:58] <jtv> I wish the test suite wouldn't leave my /tmp full of launchpadlib caches and my swap full of librarians.
[04:00] <lifeless> jtv: you're experiencing librarian leakage?
[04:00] <jtv> Yes.
[04:00]  * jtv had no idea such a word existed
[04:00] <lifeless> grah. I thought we'd squashed that
[04:00] <lifeless> jtv: does that happen when no failures happen?
[04:01] <lifeless> or only when you have failures / errors?
[04:01] <jtv> No idea.  Don't know what the lifetime of a librarian is currently supposed to be, so I have no basis for comparison.
[04:02] <jtv> I can tell you that the launchpadlib caches and the createdb templates (whatever those may be) are leaking with successful test runs.
[04:02] <lifeless> its meant to be the lifetime of the layer
[04:02] <lifeless> the createdb templaes - launchpad_ftest_template_1234 ?
[04:03] <lifeless> or launchpad_ftest_1234?
[04:07] <jtv> Trying it again now.
[04:08] <lifeless> the former has a lifetime of test-runner-process
[04:08] <lifeless> the latter is a lifetime of one-test
[04:08] <jtv> A limited test run just leaked lp.createdb.launchpad_ftest_template_13091 and lp.createdb.launchpad_ftest_template
[04:08] <lifeless> so the leak points for them are different
[04:08] <lifeless> jtv: oh, these are files in /tmp ?
[04:08] <jtv> Yes
[04:08] <StevenK> I would really like to squash the test suite creating odd files
[04:08] <lifeless> ok, please file a bug on them leaking;
[04:09] <lifeless> they exist to workaround postgresql behaviour on concurrent CREATE DATABASE calls
[04:09] <jtv> StevenK: so would I.  Passionately.
[04:09] <lifeless> the former we can fix leaks of easily - when the test runner cleansup the temp template db it can remove the lock
[04:09] <StevenK> One of the archiveuploader tests creates a strange file
[04:09] <lifeless> the latter file is a bit harder to nuke safely
[04:10] <jtv> lifeless: if the leak points are different, should they be the same bug?
[04:10] <lifeless> jtv: could go either way
[04:10] <jtv> StevenK: a big source of leaks on publisher tests for me has been the lack of publisher config pointing to temp directories.
[04:11] <jtv> I'm trying a passing test that uses the librarian now, to see if that leaks.
[04:11] <StevenK> jtv: I'm not really concerned about files in temporary directories -- I'm concerned about tests that dump random files into the source tree
[04:12] <jtv> StevenK: yes, that's what I'm talking about.
[04:12] <StevenK> steven@liquified:~% ls -1 /tmp/lp.createdb.* | wc -l
[04:12] <StevenK> 105
[04:12] <StevenK> RARGH
[04:12] <jtv> It's a good thing suspend and hibernate don't work, so I reboot regularly anyway.
[04:13] <jtv> lifeless: a successful test with the librarian just now did not leak a librarian.
[04:13] <lifeless> thanks
[04:13] <jtv> I wish I had time deal with that storm problem that broke the fake librarian.  :/
[04:16] <jtv> lifeless: bug 830845
[04:16] <_mup_> Bug #830845: Tests leak "lp.createdb" files in /tmp <Launchpad itself:Triaged> < https://launchpad.net/bugs/830845 >
[04:17] <StevenK> I bet it's nascentupload
[04:18] <jtv> I think I just got it from running registry browser tests.
[04:18] <StevenK> I can recall one from archiveuploader and one from code tests
[04:19] <jtv> lifeless: these look like empty marker files.  Would it help debugging to dump a stack trace into them?
[04:19] <wgrant> Hmm, the unlock is in a finally: :/
[04:21] <wgrant> lifeless: Do you understand sinzui's comment in bug #829105?
[04:21] <_mup_> Bug #829105: Able to target to release that I cannot upload to <disclosure> <regression> <target-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/829105 >
[04:22] <lifeless> jtv: no, they are just lock files
[04:22] <lifeless> jtv: we use a lock to prevent calling CREATE DATABASE with the same template concurrently, because doing that breaks postgresql
[04:22] <jtv> Exactly.  If you need to know where they are leaked from, it might help to know more about where they are created.
[04:23] <lifeless> jtv: there is only one place that makes them
[04:23] <lifeless> jtv: the stacktrace will be identical every time
[04:23] <jtv> OK
[04:24] <lifeless> the one without a number in it is made when we clone launchpad_ftest_template to a per-runner template
[04:24] <lifeless> that reduces contention on db cloning in parallel test environments
[04:25] <lifeless> the one with a number in it is made when we clone each concrete test db (because the same code runs each time)
[04:25] <lifeless> wgrant: which unlock ?
[04:26] <lifeless> wgrant: I think sinzui means 'before the recent retargeting work you could not do this' + 'if someone does it the impact is severe because of the inability to delete the task'
[04:27] <wgrant> lifeless: The recent retargeting work is unrelated.
[04:27] <wgrant> lifeless: The lp.createdb unlock.
[04:27] <lifeless> wgrant: I can't remember which lock system I used
[04:27] <lifeless> wgrant: but most won't delete the lock  because doing so can be racy
[04:27] <wgrant> Ah.
[04:28] <lifeless> e.g. with a lockdir, the lockdir itself is racy-as, but the object so locked can be locked reliably
[04:29] <nigelb> Morning!
[04:30] <wgrant> Hi nigelb.
[04:30] <nigelb> Can haz review? https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
[04:30] <nigelb> Morning wgrant
[04:30] <nigelb> (actually, is it afternoon for you?)
[04:30] <wgrant> It is 14:30
[04:31] <nigelb> Ah
[04:31] <lifeless> not its not, its 16:30
[04:32] <nigelb> woah, didn't know you were living that far ahead in the future.
[04:32] <wgrant> New Zealand doesn't exist.
[04:32] <StevenK> nigelb: I think 'Checks if links of the form /bugs/100' should be re-worded
[04:32] <_mup_> Bug #100: uploading po file overwrites authors list <iso-testing> <lp-translations> <Launchpad itself:Fix Released by carlos> < https://launchpad.net/bugs/100 >
[04:33] <nigelb> ah, yes.
[04:33] <stub> I had a branch that set $TEMPDIR etc. per test, but then made the mistake of trying to enforce stuff to clean up temp files and it never landed :-(
[04:34] <nigelb> StevenK: At, remove the first 'if'? :)
[04:34] <nigelb> *Aah
[04:34] <StevenK> That sounds better
[04:35] <wgrant> jtv: Your em dashes offend me.
[04:35] <jtv> Good.
[04:39] <StevenK> Dear bzr push, GO FASTER
[04:45] <stub> No problem here with the UK, but the US?
[04:47] <jtv> StevenK: well I found out why my dputs to dogfood didn't work.  Next questions are why, and what to do about it.  In dput config section [dogfood], "incoming = %(dogfood)s/ubuntu" translates to "ubuntu".
[04:47] <nigelb> StevenK: updated.
[04:48] <StevenK> jtv: If you just ran dput dogfood <changes>, then that would explain it
[04:49] <jtv> That's what I've always been told to run.  Is it wrong?
[04:51] <StevenK> It can be. Where do you want your uploads to go?
[04:52] <StevenK> If you say "Onto dogfood", I'll slap you
[04:54] <jtv> “Wherever on dogfood a test upload for an Ubuntu series is supposed to go.“
[04:55]  * jtv thinks he dodged that slap rather nicely
[04:55] <nigelb> heh
[04:56] <StevenK> jtv: It depends if you are uploading to a ppa as well, you see
[04:56] <jtv> I'm not
[04:56] <jtv> As far as I know.
[04:56] <jtv> I'm trying to upload to Ubuntu Ridiculous Rat
[04:58] <StevenK> I think /ubuntu should be okay then
[04:59] <jtv> Not /srv/launchpad.net/ubuntu-queue/ubuntu or somesuch?
[04:59] <jtv> I mean, the poppy log suggests it's trying to write to /ubuntu
[05:00] <jtv> (Unless it's not being very clear, which is also possible)
[05:00] <jtv> exceptions.OSError: [Errno Path not allowed:] /ubuntu/farewell_1.0-1.dsc.tmp.1313988369.200371027.15260.1143614958
[05:01] <StevenK> Hm
[05:01] <jtv> Something called rootpath seems to be empty for some reason.
[05:01] <jtv> But it's got to be something on my end, because it was working for Raphaël.
[05:01] <StevenK> It's been too long since I dealt with poppy
[05:02] <jtv> Oh, no, rootpath is okay; it's just that the path does not begin with it.
[05:03] <jtv> Maybe it needs a restart.  One of the line numbers in the traceback was off by one.
[05:03] <StevenK> jtv: My incoming = %(dogfood)s, and I think for distro uploads I use dogfood:ubuntu
[05:04] <jtv> I was told to set incoming = %(dogfood)s/ubuntu (and then I use just dogfood, not dogfood:ubuntu)
[05:04] <jtv> I see we have a script for starting poppy on dogfood.  How do we stop poppy though?
[05:05] <wgrant> kill;
[05:06] <jtv> There's no pidfile?
[05:07] <StevenK> ps aux | grep poppy
[05:07] <jtv> Grr
[05:11] <lifeless> there should be a pid file
[05:12] <StevenK> It could be created on prod by start-stop-daemon
[05:12] <wgrant> But poppy is a twistd.
[05:12] <wgrant> There should be one.
[05:12] <wgrant> But ps is easier than tracking it down.
[05:13] <StevenK> It's been running for 5 minutes, so I guess jtv has restarted it
[05:13] <jtv> Yup
[05:13] <jtv> But I'd much prefer to automate it.
[05:13] <nigelb> StevenK: One moreround of reviews? :)
[05:14] <jtv> wgrant: twistd generates pidfiles by default?  I didn't see anything in /var/run
[05:14] <StevenK> nigelb: I didn't review the last one?
[05:14] <StevenK> It does, yes. The default is ./twistd.pid
[05:14] <StevenK> Which has to be the most useless thing EVER
[05:14] <jtv> /var/tmp/poppy/poppy.pid!
[05:15] <nigelb> StevenK: Oh. If you're busy, should I wait for OCR?
[05:15] <StevenK> jtv: Which is wrong
[05:15] <jtv> Oh
[05:15] <jtv> It's definitely got the wrong pid in it, yes
[05:15] <StevenK> And was created over 18 months ago
[05:15] <jtv> Yup.  Delete.
[05:15] <StevenK> nigelb: It gets awkward when jtv starts arguing with himself
[05:16] <nigelb> Hehe
[05:16] <StevenK> jtv: So we can fix startpoppy.sh to write a pid file
[05:17] <StevenK> Personally, I don't care at all.
[05:17] <StevenK> I track it down via ps and shoot it in the face
[05:17] <jtv> Which is wonderful makework but personally I'd like to avoid participating in it.
[05:18] <StevenK> Then don't complain when poppy doesn't have a pid file :-P
[05:20]  * nigelb looks for another interesting bug to start work on.
[05:21] <jtv> StevenK: I'm not complaining that poppy doesn't have a pidfile, I'm trying to clean up one bit of the mess that dogfood has become by people personally not caring at all.
[05:21] <lifeless> wow, mega disrupted day. where did it go.
[05:24] <stub> How do I create a private branch again? Registering a branch before push only seems to let me do a +junk branch
[05:25] <wgrant> stub: code.launchpad.net/launchpad
[05:26] <lifeless> OTOH 2 branches landed
[05:26] <lifeless> stub: we should do a catchup call; we missed last week (but not right now)
[05:27] <stub> k
[05:27] <stub> Think we missed the previous week too :-)
[05:27] <nigelb> what's the recommended way to update devel?
[05:27] <nigelb> rocketful-get or just doign bzr pull inside it?
[05:29] <nigelb> I've done rocketful-get, but I don't know if its "The Right Way (tm)"
[05:29] <wgrant> rocketfuel-get is a good way to make sure sourcecode/download-cache/devel are up to date.
[05:30] <nigelb> hmm, wonder rif I can get two branches landed on same day. *tries*
[05:31] <lifeless> stub: we got the week before ;)
[05:32] <lifeless> anyhpw
[05:32] <lifeless> -> groceries
[05:35] <jtv> StevenK: the dogfood:ubuntu did do the trick after all, thanks!
[05:35] <jtv> I thought the "/ubuntu" in my config would obviate that.
[05:35] <jtv> BTW poppy has a pidfile now, and startpoppy.sh has a sibling stoppoppy.sh.
[05:35] <nigelb> all information related to user profile like timezone, go into registry, right?
[05:48] <stub> What changed with gpgme recently?
[05:49] <wgrant> We're using an egg instead of a branch.
[05:49] <StevenK> Which is good.
[05:50] <wgrant> No.
[05:50] <wgrant> It's just better than a branch.
[05:53] <stub> Make is failing until devel is merged in
[05:53] <wgrant> poolie: You no longer need to retarget to null.
[05:54] <wgrant> poolie: Expand the bugtask row and retarget to Ubuntu directly.
[05:54] <stub> (gpgme is gone from sourcecode, but buildout won't build the egg until versions.cfg etc. has the update)
[05:56] <stub> We don't test logout() anywhere. Fails when it attempts to redirect through codehosting to clear any secure codehosting auth cookie, which isn't running under the test suite.
[05:58] <nigelb> ok, small world. I just realized who the author of pytz is.
[05:59] <wgrant> stub: It's not tested end-to-end, no.
[05:59] <wgrant> stub: That would be difficult, as I don't think testopenid supports logout.
[06:00] <stub> Which would have been the next roadblock :-P
[06:00] <wgrant> (it doesn't support login)
[06:01] <stub> It doesn't? I thought it was the same as we use running a local dev instance.
[06:01] <stub> (And logout fails on my local dev instance because... no codehosting.)
[06:02] <wgrant> The redirect path is launchpad->codebrowse->OP
[06:02] <StevenK> stub: There's a special make run for codehosting on .dev
[06:02] <wgrant> I don't think testopenid.dev exposes a logout interface.
[06:02] <stub> Or is it just my setup that doesn't have a working bazaar.launchpad.net?
[06:02] <wgrant> Because it doesn't have authentication.
[06:02] <StevenK> run_codehosting or something
[06:03] <wgrant> Well, doesn't cache authentication.
[06:03] <stub> So it would be a noop
[06:03] <lifeless> we should move auth cookie maintenance to a microservice anway
[06:03] <wgrant> It's SSO all the way down?
[06:03]  * stub has a single line fix and no way to test it
[06:04] <wgrant> stub: Oh?
[06:04] <lifeless> wgrant: well, one possibility is to talk directly to sso; but that won't work with being openid consumer unless we teach sso about that too
[06:04] <stub> I'll try getting a codehosting setup running locally
[06:04] <stub> So the hardcoded redirect path works
[06:04] <lifeless> wgrant: another possibility is a microservice (xmlrpc on the main appservers initially) which maintains session cookies
[06:05] <jtv> StevenK, wgrant: any objections to a publish-ftpmaster run on dogfood?
[06:06] <wgrant> lifeless: Oh, you mean for codebrowse?
[06:06] <stub> lifeless: Not sure how that solves the problem, which is we need to clear cookies on a number of domains that are not always available.
[06:06] <StevenK> stub: 'make run_codehosting' rather than 'make run'
[06:06] <wgrant> jtv: None.
[06:06] <lifeless> stub: it removes the cookies from those domains
[06:06] <StevenK> jtv: Only that it will take EONS
[06:06] <jtv> StevenK: all the more reason to get started as soon as possible!
[06:07] <stub> lifeless: How does that work without requiring the authentication being treated as a web bug and blocked?
[06:07] <jtv> Also, this run shouldn't take as long as normal ones do.
[06:07] <lifeless> stub: let me check an assumption: these are all LP domains right ? *.launchpad.net ?
[06:08] <wgrant> lifeless: Not quite. We go all the way through to SSO.
[06:08] <stub> oh, yes. So no idea why we need to bounce through codehosting.
[06:08] <wgrant> Well, unless you count login.launchpad.net as *.launchpad.net, in which case get out.
[06:08] <lifeless> wgrant: I do
[06:08] <wgrant> Die.
[06:08] <lifeless> anyhow
[06:08] <wgrant> Don't mess with SSO.
[06:08] <wgrant> login.launchpad.net is hopefully not long for this world.
[06:08] <lifeless> redirecting to SSO isn't what I was mumbling about.
[06:09] <wgrant> We should treat it opaquely.
[06:09] <lifeless> it was codebrowser + the wikis
[06:09] <lifeless> which we only slightly log out of at the moment
[06:09] <wgrant> The wikis aren't part of LP yet.... I'm not sure we should go near them.
[06:09] <lifeless> anyhow, the real key point is we don't need to clear the cookie
[06:09] <lifeless> we need to invalidate the session
[06:10] <wgrant> Yes.
[06:10] <lifeless> which is really quite different
[06:10] <wgrant> We need to rewrite all our session management for everything.
[06:10] <wgrant> Because it's wrong and inconsistent and hard to manager.
[06:10] <lifeless> s/r\././
[06:10] <wgrant> Yes.
[06:10] <wgrant> I can't type.
[06:11] <lifeless> aiieee
[06:11] <lifeless> that paged in a phil collins song
[06:11] <stub> logout is still broken running run_codehosting
[06:11] <wgrant> Hah.
[06:11] <StevenK> stub: What happens in that situation?
[06:11] <stub> I don't seem to have bazaar.launchpad.dev
[06:11] <wgrant> StevenK: 503
[06:11] <lifeless> check your hosts
[06:12] <lifeless> StevenK: you don't get logged out
[06:12] <wgrant> Well, you only get logged out of LP.
[06:12] <wgrant> Rather than LP+codebrowse+SSO
[06:12] <StevenK> % grep bazaar.launchpad.dev /etc/hosts
[06:12] <StevenK> 127.0.0.99      bazaar.launchpad.dev
[06:12] <lifeless> which is still horribly partial
[06:12] <lifeless> do we invalidate api tokens too
[06:13] <lifeless> ?
[06:13] <wgrant> Not sure if serious.
[06:15] <lifeless> me? I am, logging out really should Log You Out.
[06:16] <wgrant> What if I want my many cronscripts to not need resetting every time I want to log out on some machine somewhere?
[06:16] <lifeless> provide an advanced partial logout
[06:16] <lifeless> sane defaults and all that
[06:16] <lifeless> your many cronscripts case is not the common case
[06:16] <wgrant> So logging out on one machine should log you out of *all* machines?
[06:16] <wgrant> There should be a way to revoke sessions and tokens, sure.
[06:16] <wgrant> But having that be the default is insane.
[06:17] <stub> INF [20110822-13:16:27.297] [47438788081408] loggerhead: Processed err https://bazaar.launchpad.dev/%2Blogout?next_to=https%3A%2F%2Ftestopenid.dev%2F%2Blogout [0.001 seconds]: ['TypeError: oops_start_response() takes exactly 2 arguments (3 given)\n']
[06:17] <wgrant> lifeless!
[06:17] <lifeless> stub: thank you!
[06:17] <wgrant> lifeless: Does any other webapp do the s/Log Out/KILL EVERYTHING/ thing you are suggesting?
[06:17] <lifeless> fixing
[06:17] <wgrant> I've never seen it.
[06:18] <lifeless> wgrant: its recommended by security folk AIUI
[06:18] <wgrant> I've seen revoking all sessions and tokens on *password changes* recommended.
[06:18] <wgrant> But never on logout.
[06:18] <lifeless> wgrant: the distinction between oauth, browser session and machine session is not well understood by casual users
[06:18] <wgrant> So we should make the default action blow everything up for advanced users?
[06:19] <stub> tokens should only be revoked that are being used by the web browser on logout, not the ones that have been setup for use by command line/desktop integration etc.
[06:19] <wgrant> Let me just log out...
[06:19] <wgrant> Oh fuck now I have to reauthorize 30 scripts on 10 servers.
[06:19] <lifeless> wgrant: don't conflate default-setting with UI
[06:20] <lifeless> we could fix the 'get /logout' logs you out bug, moving logout to an actual post; supply a confirmation form with everything checked and let you unselect stuff you want kept (with the current session having an 'online this session' option beside it for quick selection.
[06:20] <stub> Logout isn't logout everywhere - it is logout the web browser. Not logout on your laptop too, and deauthorize all your other clients.
[06:20] <lifeless> stub: this is exactly the point, that subtlety is lost on casual users.
[06:21] <lifeless> stub: they don't understand that e.g. the 'log in with gmail' button establishes a persistent 3rd party session
[06:21] <stub> It doesn't
[06:21] <stub> (ok - replace with twitter oauth argument)
[06:22] <wgrant> We should certainly fix the OAuth token view to be a general authentication session management view, and make that obvious and next to the logout button.
[06:22] <wgrant> But the browser logout button should log the browser out.
[06:22] <wgrant> Not destroy the world.
[06:22] <nigelb> from where does things go into the context?
[06:22] <stub> I don't think the subtleties are lost. Most of what I see is that people expect their tokens to be destroyed on password change, not logout.
[06:23] <wgrant> In a view, 'context' is normally the object that the view is on.
[06:23] <wgrant> nigelb: ^^
[06:24] <wgrant> stub, lifeless: Facebook doesn't do this, AFAIK.
[06:24] <wgrant> And if Facebook doesn't, then I think even non-technical users are probably not too terrible about this concept.
[06:24] <nigelb> wgrant: argh. So, how would I add a variable to that?
[06:24] <lifeless> ugh
[06:24] <wgrant> (replace "Facebook" with "99% of websites on the Internet" and it will still fit)
[06:24] <lifeless> its wsgi oops thats broken
[06:24] <lifeless> fixing
[06:24] <lifeless> who knew... http://www.python.org/dev/peps/pep-0333/#the-start-response-callable
[06:25] <stub> wgrant: No, which surprises people when they change their twitter password and linkedin is still connecting.
[06:25] <wgrant> nigelb: Find the class, add an attribute to it.
[06:25] <stub> wgrant: But that is password change
[06:25] <wgrant> stub: Yes.
[06:25] <nigelb> wgrant: the class I found from configure.zcml, but I can't find the other attributes defined there, which confuses me.
[06:26] <wgrant> stub: I think defaulting to reset stuff on password change may be permissible, as long as it's very obvious what is about to happen.
[06:26] <wgrant> But on logout is just insane.
[06:27] <stub> wgrant: yes, and reset tokens on password auth is what I've seen recommended. I don't think I've seen it recommended for logout either (I thought initially lifeless meant the tokens being used by the javascript api, but I'm not sure they actually exist?)
[06:27] <wgrant> stub: JS just uses the cookie for now.
[06:27] <wgrant> We should certainly make it easy to do.
[06:28] <wgrant> At present there's no way to revoke a remote machine's session.
[06:28] <wgrant> Unless you are stub.
[06:28] <stub> urg
[06:29] <wgrant> s/machine/browser/
[06:30] <stub> thought you meant an oauth token there :)
[06:31] <wgrant> No, those have had a view to manage them since day 1 :)
[06:36] <wgrant> Anybody up for a rather trivial review? https://code.launchpad.net/~wgrant/launchpad/bug-830803/+merge/72378
[06:36] <wgrant> And https://code.launchpad.net/~wgrant/launchpad/bug-830849/+merge/72379 is a little bigger.
[06:39] <StevenK> wgrant: r=me for the first.
[06:40] <StevenK> wgrant: For the second, r=me, if there are already tests for _syncSourcePackages
[06:40] <lifeless> stub: http://paste.ubuntu.com/672219/ should fix it for you
[06:40] <lifeless> stub: I'm working on a test now
[06:41] <lifeless> stub: (thats to python-oops-wsgi, easiest way is for you to checkout the trunk, set develop= . ../path/to/that/checkout and run bin/buildout again
[06:41] <stub> Nah, its easier to do something else until it winds its way through ;)
[06:42] <wgrant> StevenK: Thanks. It is tested somewhere (I ran into it some time in the last 15 branches), but I will add direct tests on transitionToTarget.
[06:43] <StevenK> wgrant: In that branch itself?
[06:43] <wgrant> StevenK: Yes.
[06:43] <nigelb> StevenK: review? https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575 :D
[06:44] <StevenK> nigelb: You know, stub is OCR today :-P
[06:45] <nigelb> Is there a page saying who's reviewing when?
[06:45] <wgrant> https://dev.launchpad.net/ReviewerSchedule
[06:46] <nigelb> ah
[06:46] <nigelb> stub: could you review the brach above?
[06:46] <nigelb> :)
[06:46] <stub> yo
[06:50] <stub> nigelb: Not sure I approve of calling a private bug a bug with an invalid link - seems a separate case to test to me.
[06:50] <wgrant> Hahahah
[06:50] <wgrant> He was doing that, but then lifeless said they were the same case :)
[06:50] <nigelb> That ^
[06:51] <nigelb> Also, its similar to what happens in the UI.
[06:51] <nigelb> I'm open to changing the text to make it clearer.
[06:53] <stub> I think it is better to be explicit. Saves fallout if we linkify private bugs (which we can do if it is client side).
[06:53] <nigelb> So, say "Bug 123 is either invalid or not visible to you"
[06:53] <_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
[06:53] <wgrant> nigelb: We treat invisible private bugs as not existing.
[06:54] <wgrant> Say something like "Bug 123 does not exist", perhaps.
[06:54] <_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
[06:54] <stub> nigelb: No, it is invalid if you don't have access. Same as we 404 private bug pages rather than a no-permission errorcode.
[06:54] <nigelb> I'm confused now.
[06:54] <wgrant> *Test* both cases.
[06:54] <nigelb> In one case, there's a private bug you have access to, it linkifies correctly.
[06:55] <wgrant> The cases behave the same way.
[06:55] <stub> nigelb: Simplest thing to keep me happy is a second invalid link, which is really invalid, in addition to the private bug, which is only invalid if you don't have permissions.
[06:55] <wgrant> But test both.
[06:55] <nigelb> stub: It does that.
[06:55] <nigelb> The private bug case linkifies correctly if you do have permission
[06:55] <stub> make_invalid_bug_links returns a single link, a link to a private bug.
[06:55] <nigelb> My test case, however, uses a user who doesn't have access.
[06:56] <nigelb> wgrant: Grar, lifeless told me to do the opposite.
[06:56] <stub> Right. So we are testing that we handle private bugs correctly, but not utterly broken urls
[06:56] <nigelb> Test one case since it should behave the same anyway.
[06:56] <wgrant> nigelb: Yes. Normally I would agree. but this is a bit of an odd case, and I disagree with him.
[06:56] <stub> Unless we defer that to searchBugs
[06:57] <nigelb> Ok, so how do I create an invalid bug for sure?
[06:57] <nigelb> (inside a test)
[06:57] <stub> Bug a helper called 'make_invalid_bug_links' that returns a perfectly valid bug would certainly need a comment to avoid a WTF.
[06:57] <nigelb> heh
[06:57] <stub> nigelb: make a bug and add one to its id would be good enough.
[06:58] <nigelb> okay, I'll update the test with both the cases.
[06:58] <stub> (or add 1000 - add one will only be invalid until the next makeBug call.
[06:58] <lifeless> jml: hi
[06:59] <lifeless> stub: wgrant: testing the behaviour of searchIds is inappropriate for a view test :(
[07:00] <wgrant> lifeless: It's a very unobvious implementation detail.
[07:00] <wgrant> I think it's reasonable to test it here, as long as it's not too long.
[07:00] <lifeless> mmm, this is really just exposing searchIds on an adhoc API
[07:00] <stub> lifeless: make_invalid_bug() that returns a valid bug is WTF.
[07:00] <lifeless> stub: the test being unclear ? sure :)
[07:01] <nigelb> wtf, gpgme error when I run tests.
[07:01] <stub> nigelb: Merge devel, run make.
[07:02] <nigelb> okay.
[07:02] <stub> nigelb: So lifeless and me sort of agree.
[07:02] <nigelb> okay
[07:02] <nigelb> so just add a comment to the test?
[07:03] <stub> That would work.
[07:04] <stub> 'As far as searchBugs() is concerned, this is an invalid bug to the currently authenticated user' or similar.
[07:04] <lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/extraction/+merge/72380 can has review
[07:04] <lifeless> stub: I'll land it with a version bump and do a new egg etc after the review
[07:07] <lifeless> actually I see you are distracted
[07:08] <lifeless> I will land a 0.0.2 tarball + lp simple tweak to use it, and you can review later.
[07:11] <wgrant> StevenK: Test added.
[07:11] <nigelb> stub: updated, could you land it as well?
[07:12] <jtv> lifeless: I'll review it.
[07:13] <lifeless> ok, man sensible-browser lies
[07:14] <nigelb> I'm trying to fix bug 188187, should I add another property to the view class for that? Is that the right way?
[07:14] <_mup_> Bug #188187: Please display offset to UTC with timezone info for profiles <easy> <feature> <lp-registry> <profile> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/188187 >
[07:15] <lifeless> jtv: thanks
[07:15] <lifeless> nigelb: I would do it in the formatting of the field
[07:16] <stub> nigelb: ok
[07:16] <nigelb> lifeless: hm, where do I look to find that. I've been unsuccessful in finding that. I traced the it from the configure.zcml file and then got lost.
[07:16] <nigelb> stub: Thanks!
[07:17] <jtv> lifeless: done
[07:17] <lifeless> nigelb: well, start with the view
[07:17] <lifeless> nigelb: see what it does, does it do a formatter call, or access an attribute of the timezone object..
[07:17] <nigelb> it access a context variable
[07:18] <lifeless> jtv: you may not know this , but pep8 mandates indent by 8 for function call continuation lines
[07:18] <jtv> I didn't, no.
[07:19] <jtv> So does that mean we're going to have a mess of inconsistent indentations now?
[07:19] <lifeless> its under code layout 'When using a hanging indent the following
[07:19] <lifeless>     considerations should be applied; there should be no arguments on the
[07:19] <lifeless>     first line and further indentation should be used to clearly distinguish
[07:19] <lifeless>     itself as a continuation line.'
[07:20] <lifeless> jtv: uhm, I don't know what we should do in LP itself; these new trees are pure PEP8 though
[07:20] <lifeless> jtv: so I wouldn't expect any inconsistency within a single project
[07:20] <jtv> Phew.  :)
[07:20] <wgrant> lifeless: You mean function definition?
[07:20] <jtv> Although I must say the 8-char indent would help the broken-if-condition situation.
[07:20] <jtv> wgrant: no, this is function call.
[07:21] <lifeless> wgrant: it applies to both
[07:21] <wgrant>           # Further indentation required as indentation is not distinguishable
[07:21] <lifeless> wgrant: function calls are listed as optional
[07:21] <wgrant>           def long_function_name(
[07:21] <wgrant> \    Optional:
[07:21] <wgrant>               var_one, var_two, var_three,
[07:21] <wgrant>               var_four):
[07:21] <wgrant>               print(var_one)
[07:21] <wgrant>           # Extra indentation is not necessary.
[07:21] <wgrant>           foo = long_function_name(
[07:21] <wgrant>             var_one, var_two,
[07:21] <wgrant>             var_three, var_four)
[07:22] <wgrant> I'mnot seeing the mandated indentation by 8 for function calls.
[07:22] <wgrant> Only function definitions.
[07:22] <lifeless> wgrant: its a contextual rule, not specific to function definition or calling
[07:22] <jtv> wgrant: just so you know, this isn't working very well in my IRC client.
[07:23] <wgrant>  and further indentation should be used to clearly distinguish
[07:23] <wgrant>     itself as a continuation line.
[07:23] <nigelb> please use etherpad?
[07:23] <wgrant> For a function call it is already clearly distinguished.
[07:23] <lifeless> wgrant: yes, thats what I quoted above:)
[07:23] <wgrant> There's no following block.
[07:23] <lifeless> wgrant: not always (e.g. call within an if)
[07:23] <wgrant> Huh?
[07:24] <wgrant> Oh, within an if statement, not an if block?
[07:24] <lifeless> correct
[07:24] <lifeless> jtv: the del exc_info is there to avoid circular references
[07:24] <lifeless> jtv: its advised by the wsgi pep
[07:25] <jtv> I thought the python gc had some special trick for dealing with circular references.
[07:25] <lifeless> jtv: it puts its hand up in the air, runs around and gibbers.
[07:25] <jtv> Oh, OK.  That makes sense.
[07:25] <lifeless> jtv: some of the time this works, other times it leaves uncollectable objects.
[07:26] <wgrant> lifeless: I still see nothing that suggests two levels of indentation for normal function calls.
[07:26] <lifeless> s/objects/cycles.
[07:26] <jtv> lifeless: don't forget the closing /
[07:26] <lifeless> jtv: a cycle of objects is uncollectable (today) if any have __del__
[07:27] <jtv> To avoid the horrors of object revival through finalization?
[07:27] <lifeless> jtv: so avoiding cycles is pretty important for library code.
[07:27]  * jtv loves constructors, hates finalizers
[07:27] <lifeless> jtv: to avoid race conditions or injecting altered state into the objects
[07:27] <lifeless> e.g. A -> B -> A, and A has a __del__
[07:28] <lifeless> if you delete B first, A's __del__ might use B and boom. if you delete A first, its ok.
[07:28] <lifeless> I don't recall if the gc handles one __del__ ok, or only fails when there are two involved.
[07:28] <jtv> Or as I put it, the horrors of object revival through finalization.  :)
[07:28] <lifeless> IIRC it just taints the cycle when it finds a __del__ and moves on.
[07:29] <lifeless> one common trick, while we're on this, is to have A -> B, C  then B->A and C has the __del__
[07:29] <lifeless> it handles that just fine
[07:31] <jtv> EPARSE
[07:31] <jtv> A→B, C?
[07:31] <lifeless> A holds a reference to B and C
[07:31] <lifeless> B holds a reference to A
[07:31] <jtv> Ah.
[07:31] <lifeless> 'points at' :)
[07:31] <jtv> Not what I meant.
[07:32] <jtv> "A → B, C then B→A and C has the __del__" is ambiguously scoped.
[07:33] <lifeless> jtv: how would you layout the dict better? even out of the assert those lines are just too long
[07:33] <lifeless> they are already only 4 characters in
[07:34] <jtv> One item per line, with comma after each item.
[07:34] <jtv> AHHHH
[07:35] <jtv> Ignore me.  I think I just figured out why I couldn't get something to work.
[07:36] <lifeless> jtv: so the problem bit isn't in the dict, its the expected start_response args
[07:36] <jtv> lifeless: could be—a bit hard to say given the current layout.
[07:37] <lifeless> jtv: how does this grab you
[07:37] <lifeless> http://paste.ubuntu.com/672245/
[07:37] <adeuring> good morning
[07:37] <jtv> lifeless: Gently and not altogether unpleasantly.
[07:38] <jtv> Even so, I may sue.
[07:38] <lifeless> is that +1?
[07:38] <jtv> hi adeuring.  I bet you're wondering what all that was about, but you missed it and now it's too late.
[07:38] <jtv> lifeless: yes
[07:38] <adeuring> ?
[07:39] <jtv> :-P
[07:42] <lifeless> hmm
[07:43] <lifeless> lxc-stop -n lucid-test-lp is dropping my box of the network for 60 seconds
[07:43] <lifeless> this is not coincidentally the default bridge watchdog timeout
[07:43] <lifeless> no liky
[07:44] <lifeless> stub:  all the bits you need are in trunk
[07:44] <stub> ta
[07:44] <lifeless> stub: I suspect loggerheads is further broken based on lp's qastaging behaviour
[07:45] <lifeless> stub: ... so please try before I sleep :)
[07:45] <mthaddon> lifeless: sorry, I'm stealing stub at the moment for some emergency U1 work
[07:45] <stub> Got u1 replication, then I need to guilt mthaddon into doing the pgbouncer LP config updates
[07:45] <mthaddon> heh
[07:53] <henninge> hm, was the StyleGuide overview page removed from the dev wiki on purpose?
[07:53] <henninge> https://dev.launchpad.net/StyleGuides
[07:53] <henninge> It's still linked from here https://dev.launchpad.net/PatchSubmission
[08:08] <lifeless> jml: ping
[08:15] <jtv> hi henninge!  Review?  https://code.launchpad.net/~jtv/launchpad/post-824553/+merge/72389
[08:16] <henninge> jtv: r=me
[08:17] <jtv> thanks
[08:17] <henninge> although I had to look up the exact meaning of "vestigial" ... ;-)
[08:18] <jtv> rvba: it prints None.
[08:18] <jtv> henninge: good, so we're all learning.  :)
[08:18] <rvba> jtv: arg ... thank you!
[08:18] <jtv> rvba: want me to make any changes?
[08:18] <mrevell> Hello
[08:19] <rvba> jtv: I'll change it a bit and ask you to run it again if you don't mind, thanks for the offer :)
[08:19] <jtv> OK
[08:19] <jtv> hi mrevell
[08:20] <rvba> jtv: http://paste.ubuntu.com/672274/
[08:20] <jtv> coming
[08:22] <jtv> rvba: pretty-printed for your convenience… http://paste.ubuntu.com/672278/
[08:23] <rvba> jtv: thank you!
[08:23] <jtv> rvba: by the way, the default argument for dict.get defaults to None.
[08:23] <jtv> So {}.get('x') == None.
[08:24] <rvba> jtv: ah, right :)
[08:24] <rvba> Thanks
[08:24] <jtv> rvba: I still have the shell open so if there's anything more you need from that variable, say the word.
[08:25] <rvba> jtv: great, I'll ask you if I need another execution on "real" data.
[08:30] <jml> lifeless: hi
[08:31] <jml> lifeless: got a call w/ rickspencer3 scheduled now. let me juggle a bit
[08:31] <lifeless> jml: FYI its now 2030
[08:31] <lifeless> jml: we're about to eat
[08:31] <jml> lifeless: oh, ok. then go eat.
[08:31] <lifeless> jml: in about 15 I'll be available
[08:31] <jml> lifeless: ok, thanks.
[08:38] <stub> AttributeError: https://api.launchpad.net/1.0/~nigelbabu/launchpad/4595-upgrade-bug-linking object has no attribute 'queue_status'
[08:38] <stub> Anyone else having issues with ec2 land?
[08:38] <StevenK> That's a branch
[08:38] <StevenK> Not an MP
[08:39] <stub> ahh
[08:39] <nigelb> er, do I need to do anything? :)
[08:39] <StevenK> nigelb: Yes. Tell stub he is a numpty :-P
[08:39] <stub> A better reviewer?
[08:39] <StevenK> Haha
[08:40] <StevenK> stub: It used to say "Entry" object has no attribute, which was ... handy
[08:40] <nigelb> heh
[08:40] <stub> raise PEBKAC("You suck")
[08:42] <stub> Thats better - back to the usual 3rd world ISP issues
[08:46] <nigelb> My first non-trival branch to LP! :)
[08:46] <nigelb> Meaning of course my code diff is comparable to the size of the tests diff.
[08:48] <lifeless> jml: ok
[08:51] <jml> lifeless: hi
[08:51] <jml> lifeless: skype?
[08:51] <lifeless> sounds good
[08:51] <lifeless> jml: except
[08:51] <lifeless> jml: its evening here and my isp is fail
[08:51] <lifeless> jml: can you ring my landline ?
[08:51] <jml> lifeless: oh. sure.
[08:52] <lifeless> e..g skypeout to that
[08:52] <jml> yeah, I have skypeout.
[08:52] <stub> nigelb: Have you done all the contributer's agreement stuff?
[08:53] <nigelb> stub: Yeah. Its my 6th branch :)
[08:53] <stub> Cool.
[08:53] <jml> lifeless: I dialled the number in the directory. Got a beep, then no sound.
[08:59] <jtv> jelmer: are you up to date on Q/A?  The production report seems a little behind the times but it looks like you're set to be the next blocker after bac gets his Q/A done.
[09:00] <jelmer> jtv: I checked up on it yesterday, but it appears that tellarium is down at the moment and that blocks my QA.
[09:00] <jtv> Ah.  Sometimes I wonder if IS sprints are organized just to remind us to appreciate our admins.  :)
[09:00] <jelmer> (-:
[09:02] <jamesh> lifeless: sorry for the late feedback, but I did find one obvious problem with python-oops-wsgi: https://bugs.launchpad.net/python-oops-wsgi/+bug/830931
[09:02] <_mup_> Bug #830931: python-oops-wsgi's proxy start_response callback does not handle a third argument. <python-oops-wsgi:New> < https://launchpad.net/bugs/830931 >
[09:11] <wgrant> jamesh: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops-wsgi/trunk/revision/9 might be relevant.
[09:12] <jamesh> ah.  probably should have checked that before filing the bug report
[09:12] <wgrant> It's only a couple of hours old :)
[09:14] <danilos> bigjools, hi, can you perhaps lend a hand with triaging bug 829253?
[09:14] <_mup_> Bug #829253: issues with virtualized buillds? <soyuz-build> <Launchpad itself:New> < https://launchpad.net/bugs/829253 >
[09:14] <bigjools> danilos: it's not a launchpad issue, it's either an RT or a buildd problem
[09:15] <StevenK> Or a Xen bug
[09:15] <bigjools> indeed
[09:15] <wgrant> Or a package bug.
[09:15] <bigjools> I'd retarget to buildd and raise an RT
[09:16] <danilos> bigjools, ok, I'll do that, but what should I put in the RT?
[09:16] <bigjools> danilos: link to the sme build pages as in the bug
[09:16] <bigjools> same*
[09:17] <bigjools> and ask if it's a buildd problem
[09:21] <nigelb> mrevell: hi!
[09:29] <mrevell> Hey there nigelb :)
[09:29] <nigelb> mrevell: Morning! Were you able to look into that bug? :)
[09:30] <mrevell> nigelb, Not yet but it is on my list for today. As Gary said last week, it's likely we'll want to do some testing on it.
[09:30] <nigelb> mrevell: Yeah, that sounds good.
[09:31] <mrevell> nigelb, At first it sounds pretty obvious that we need a "Subscribe me" button but, as Gary said, there are a few things to consider. I'll update the bug report and ping you when I've done something about it :)
[09:35] <danilos> bigjools, another one for you: in bug 798611 cjwatson asks if we could run the sync more frequently? (if you think we could, I'll file an RT or simply propose a merge against launchpad-production-configs)
[09:35] <_mup_> Bug #798611: Package Auto Sync seems to get ahead of +localdiff calculation <derivation> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/798611 >
[09:35] <bigjools> danilos: leave it with me
[09:35] <danilos> bigjools, ack
[09:35] <danilos> thanks
[09:35] <nigelb> mrevell: sounds good :)
[09:59] <allenap> those possessing Zope knowledge: Do you know if there's a standard way to test security proxies? I've done it by hand in some recent code (see https://code.launchpad.net/~allenap/launchpad/job-status-validator/+merge/62509, line 532) but it's the kind of thing for which I suspect someone else has already come up with a good solution.
[10:11] <bigjools> StevenK, wgrant: can you think of how we could possibly close LP bugs when syncing?  The current code requires a changes file.
[10:11] <bigjools> which ain't gonna fly for syncs
[10:13] <nigelb> gah @ qastaging timeouts
[10:15] <wgrant> bigjools: We'll have to parse them from the changelog-since-base manually.
[10:15] <bigjools> they are mentioned there?
[10:16] <bigjools> as in, Debian changlogs reference LP bugs?
[10:16] <wgrant> bigjools: Occasionally, yes. Most Ubuntu developers, and some Debian-only developers, put LP bug references in Debian uploads when they fix LP bugs.
[10:17] <wgrant> So they can sync through and the bugs sort themselves out.
[10:17] <bigjools> ok ta
[11:12] <rvba> henninge: Hi, could you have a look at these 2 (tiny) MPs?
[11:12] <rvba> https://code.launchpad.net/~rvb/launchpad/ids-fix/+merge/72398
[11:12] <rvba> https://code.launchpad.net/~rvb/launchpad/queue-bug-830983/+merge/72406
[11:12] <henninge> rvba: Hi! Having a look ...
[11:13] <rvba> ta
[11:14] <henninge> rvba: IDS = "Intrusion Detection System" ?
[11:14] <rvba> henninge: InitializeDistroSeries ;)
[11:14] <henninge> ;-)
[11:15] <henninge> First line of diff reveals it but it confuses in the cover letter ...
[11:25] <henninge> rvba: why did you move those methods in test_initialize_distroseries.py?
[11:26] <rvba> henninge: To put them in InitializationHelperTestCase which is the base class for the new tests in test_initderiveddistroseries.py.
[11:27] <rvba> henninge: And of course because the new tests use them.
[11:27] <henninge> rvba: ok
[11:28] <rvba> henninge: BTW, these branch depend on one another for no other reason than the fact that these are tiny fixes that I want to land in one go.
[11:28] <rvba> branches*
[11:29] <henninge> rvba: why did you add the "return true"
[11:29] <henninge> ?
[11:29] <henninge> rvba: did you just do it so you can use "assertTrue"?
[11:29] <rvba> henninge: Exactly.
[11:30] <henninge> rvba: no need for that
[11:30] <rvba> For the test to be more "explicit".
[11:30] <rvba> More "readable".
[11:30] <henninge> rvba: but it is not, it is more confusing ;-)
[11:30] <bigjools> better to assert the behaviour
[11:30] <rvba> henninge: The behavior is that no exception is raised.
[11:30] <henninge> I understand that
[11:31] <henninge> but your test does not mention that.
[11:31] <rvba> I could assert that it returns None.
[11:31] <henninge> it never returns "False" so there is no point in "assert True"
[11:31] <henninge> but that is not what you are testing ...
[11:32] <rvba> henninge: makes sense, so you would recommend changing that to assert that None is returned then.
[11:32] <rvba> ?
[11:32] <henninge> rvba: it is perfectly fine to just call  the method under test and add a comment like "This should not raise an exception"
[11:32] <henninge> rvba: no, assert nothing
[11:32] <henninge> (and remove the "return true")
[11:32] <rvba> Okay.
[11:33] <henninge> then everybody knows you are just running it to see if it won't raise an exception.
[11:33] <henninge> rvba: that's why we have "assertRaises" but we don't have "assertRaisesNot" ... ;-)
[11:38] <henninge> rvba: Same issue with the other branch.
[11:38] <rvba> henninge: Yep, I'm fixing this right now.
[11:38] <henninge> rvba: cool, thanks ;-)
[11:38] <henninge> r=me with those fixes.
[11:39] <rvba> henninge: thanks a lot!
[11:45] <bigjools> henninge, rvba: if something isn't raising an exception then presumably something else happened which can be tested?
[11:45] <henninge> bigjools: that is a good point!
[11:45] <rvba> bigjools: this is IDS.check() so completing without raising an exception is what I want to test.
[11:46] <bigjools> rvba: that's not a good test though
[11:46] <StevenK> I think .check() returns None if everything was fine
[11:46] <rvba> StevenK: exactly
[11:46] <StevenK> So assert that it did so, and you're good
[11:46] <bigjools> I could make a function return "wibble" and check for that.
[11:47] <bigjools> doesn't test much :)
[11:47] <henninge> No, I think a funtion should be clear about it's interface.
[11:47] <henninge> it either communicates by raising exceptions or by returning values.
[11:47] <StevenK> IDS.check() returns None if everything is good, or it raises an exception with the problem. What's the issue?
[11:48] <rvba> I agree with StevenK's question :)
[11:48] <henninge> if it communicates by raising exceptions, not raising one is a valid test according to the functions interface.
[11:48] <henninge> StevenK: because it changes nothing and does not improve the test.
[11:49] <henninge> the function will either raise an excpetion OR return None
[11:49] <henninge> but the None is useless
[11:49] <bigjools> if it returns None when everything is ok then the test needs to make sure everything is actually ok
[11:49] <bigjools> otherwise how do you know returning None was correct?
[11:50] <henninge> bigjools: I agree that the test could check for data that was changed by a function after it completed without an exception
[11:50] <rvba> bigjools: I see this the other way around: I setup data to test for a specific case, then I test that ids.check() does not raise an exception for this case.
[11:50] <henninge> only that a validation function should be definition not modify data ...
[11:50] <bigjools> rvba: I think that is a poor test
[11:51] <henninge> bigjools: it is no different to testing that a constant value is returned.
[11:51] <henninge> that is equally poor and misleading
[11:51] <rvba> and of course I have other tests to make sure the proper exceptions are raised when it's appropriate.
[11:52] <henninge> because reading the test you think the None (or True in rvba's case) has some meaning which it does not have.
[11:52] <bigjools> if there are other tests to make sure that certain inputs DTRT then that excuses this test, I was just taking the test in isolation
[11:52] <henninge> rvba: exactly, I expected those to be there.
[11:52] <rvba> henninge: bigjools these tests *are* already in the same file.
[11:53]  * rvba is ready to pull the "ec2 land" trigger on this.
[11:53] <henninge> rvba: I expected that, otherwise some previous reviewer did a poor job ;-)
[11:53] <henninge> rvba: go ahead, this reviewer approves ;-)
[11:54] <henninge> and goes to lunch
[11:55] <jtv1> Anyone here familiar with recipe builds?
[11:56] <jtv1> I pushed a change to meta-lp-deps and got some emails along the lines of "[recipe build #73739] of ~launchpad meta-lp-deps-on-demand in lucid:	Chroot problem"
[11:56] <_mup_> Bug #73739: unstoppable (probably) gnome-panel looping crash <gnome-panel (Ubuntu):Invalid by desktop-bugs> < https://launchpad.net/bugs/73739 >
[11:56] <jtv1> Shut up mup.
[11:56] <StevenK> Chroot problem is not a recipe problem
[11:56] <jtv> No, but I need to know what this implies.  Did something break fatally?  Do I need to push it again?
[11:57] <StevenK> No and no
[11:57] <jtv> Thanks.
[11:57] <StevenK> Something is broken, but you didn't break it
[11:57] <StevenK> Link me the URL in the body of the mail?
[11:57]  * jtv digs
[11:58] <jtv> Here's one: https://launchpadlibrarian.net/77594282/buildlog.txt.gz
[11:58] <jtv> And: https://launchpad.net/~launchpad/+archive/ppa/+build/2721413/+files/buildlog_ubuntu-natty-i386.launchpad-dependencies_0.98%7Enatty1_CHROOTWAIT.txt.gz
[11:58] <jtv> And: https://launchpad.net/~launchpad/+archive/ppa/+build/2721414/+files/buildlog_ubuntu-oneiric-i386.launchpad-dependencies_0.98%7Eoneiric1_CHROOTWAIT.txt.gz
[11:58] <StevenK> Certainly not your probnlem
[11:58] <jtv> There's also links in the sigs.  Need those?
[11:59] <StevenK> No, I have enough
[11:59] <jtv> OK
[12:02] <StevenK> jtv: When did you push, around now-ish?
[12:03] <bigjools> StevenK: when does the debian publisher run, exactly?  And do you know typically how long it takes to complete?
[12:04] <StevenK> bigjools: I have no idea.
[12:05] <bigjools> StevenK: ok :)  Do you know where I can find out?
[12:06] <StevenK> bigjools: Mail/bug Ganneff?
[12:06] <jtv> StevenK: Friday IIRC
[12:06] <soren> bigjools: https://answers.launchpad.net/launchpad/+question/161595
[12:07] <soren> bigjools: the last line is (if I'm reading it correctly) from Debian.
[12:07] <soren> bigjools: No idea how long it takes, though.
[12:09] <StevenK> So, based on that question, we give Debian 2 hours to run dinstall *and* for ftp.uk.debian.org to pulse and update. I don't think that's long enough.
[12:09] <bigjools> soren: thanks
[12:10] <bigjools> in fact 2h13m
[12:10] <StevenK> And in fact, there is another missing piece
[12:10] <bigjools> yes, our own rsync
[12:11] <StevenK> When does debmirror on iron run, since *that* is what gina pulls from
[12:12] <StevenK> jtv: Right. I think that mess has been sorted out.
[12:12] <jtv> Good, thanks.
[12:12] <bigjools> StevenK: 52 2,8,14,20
[12:12] <StevenK> Let me see if I can resurrect stuff
[12:13] <bigjools> so we give debian 1hr to publish and sync
[12:13] <StevenK> And sync from ftp.debian.org to ftp.uk.debian.org
[12:13] <StevenK> I don't think that's long enough
[12:13] <bigjools> StevenK: how do you know we get it from the uk mirror?
[12:13] <wgrant> ftp.uk.debian.org shouldn't sync from ftp.debian.org
[12:13] <wgrant> It'll sync direct from ftp-master.
[12:14] <StevenK> wgrant: Right
[12:14] <StevenK> bigjools: Since I had to help fix debmirror, and I *think* it pulls from ftp.uk.debian.org. A LOSA could confirm.
[12:14] <bigjools> StevenK: ok ta
[12:50] <jkakar> I've been doing some reviews in GH with pull requests... at first glance the thing where you add comments to a diff seems nice, but in practice I miss the simple textarea from Launchpad where I can copy and paste code and review my review before I send it.
[12:50] <jkakar> With GH the line items to add to a diff are visible, in realtime, to everyone else.
[12:50] <jkakar> Sometimes fancy isn't better.
[12:54] <soren> jkakar: I've never really used it, but it also seems to be that if the patch is revised based on the feedback, how will you be able to tell a) which line a comment pertains to now (since the line number and/or content might have changed) and b) whether it's still relevant.
[12:55] <soren> jkakar: I tend to prefer LP's e-mail interface for code reviews, though.
[12:55] <jkakar> soren: No idea.  I'm finding GitHub generally confusing so far and I miss a number of things from Launchpad.
[12:55] <jkakar> For example, there's on way to specify a prerequisite branch when you create a pull request... and it isn't smart enough to figure it out for itself.
[12:55] <wgrant> jkakar: Oh, I always assumed GitHub line-based comments were still done in sort of a single transaction, like Launchpad's.
[12:56] <jkakar> wgrant: No, they're not.  They're realtime... people can respond to your comments while you're reviewing.
[12:56] <nigelb> bah, test failure
[12:56] <jkakar> Which seems a bit useless really.  When a review is so important that you need that kind of response just phone someone and do it in person, or do it on IRC or something.
[12:57] <jkakar> Pull requests also have no state beyond open and closed.  I miss 'Needs Fixing' and 'Needs Information'.  I also miss the +activereviews page where you can see pull requests you can do, that need your attention, etc.
[12:57] <jkakar> GH does have a much more polished UI than Launchpad.  And being able to follow people is pretty cool.
[12:57] <jkakar> The biggest reasons we've switched to GH are (a) price (b) builtin wikis and (c) perceived easier UI.
[12:58] <jkakar> Probably in a, c, b order.
[12:58] <soren> GH looks much more like an OS X app than Launchpad, yeah.
[12:58] <jkakar> soren: Yeah.  It also has some wicked features, like builtin webhooks and builtin services like commit bots.
[12:58] <jkakar> But the things I use on a daily basis leave me feeling a bit underwhelmed after Launchpad (bugs + merge proposals).
[12:58] <nigelb> jkakar: I always like launchpad for its +activereviews page and overall better review panel.
[12:59] <jkakar> Maybe it'll just time to get used to it.
[12:59] <soren> jkakar: But as you point out, pull requests and issues lack of lot of metadata.
[12:59] <jkakar> nigelb: Yeah, me too.
[12:59] <nigelb> I constantly use both.
[13:00] <StevenK> I seem to be allergic to git. Every time I try and use it, I break out into bouts of vicious swearing.
[13:00] <nigelb> There's creams for that sort of thing now :P
[13:01] <nigelb> Achivement Unlocked: Broke a bucketload of tests on landing.
[13:03] <jkakar> StevenK: The sense that I have to punch someone in the face everytime I use it is dwindling with experience.
[13:04] <jkakar> StevenK: I don't find it any faster or slower than Bazaar, which is interesting since speed is the thing everyone goes on and on about.
[13:04] <jkakar> As far as I can tell they're the same: local operations are fast and network operations are slow.
[13:05] <wgrant> Two years ago bzr was really slow.
[13:05] <wgrant> And nobody has used it since then.
[13:06] <nigelb> I *think* most of what that git can do can be accomplished with bzr.
[13:06] <nigelb> But some are not out of the box.
[13:06] <nigelb> are co-located branches out of the box yet?
[13:06] <wgrant> Very nearly.
[13:06] <wgrant> jelmer has been working on that, I believe.
[13:07] <wgrant> But bzr-colo does a pretty damn good job.
[13:07] <nigelb> I agree. So, the last time I checked that was my only irk, except I learn that's around in bzr too.
[13:07] <wgrant> I find colocated branches to be a downside at times.
[13:07] <jelmer> yeah, colocated branches are slowly making their way into core bzr
[13:08] <Daviey> I've noticed bzr bisect doesn't seem as reliable as git bisect, but that is meerly a module.
[13:08] <nigelb> Launchpad UI though could use some work :)
[13:08] <Daviey> merely*
[13:08] <nigelb> I heard there was a whole bunch of work coming that way too.
[13:10] <jkakar> I was initially quite frustrated with colocated branches (in Git) after being used to Bazaar.  I'm getting used to it.
[13:10] <nigelb> when you work with the github workflow more, its fun
[13:10] <nigelb> you start doing the branching with git checkout -b, etc
[13:11] <jkakar> nigelb: I'm not having more fun yet.  Maybe that'll change.
[13:11] <jkakar> I guess so much of this is just about familiarity.
[13:12] <nigelb> jkakar: hehe, so some irritating bits in git include, things like "git st", "git co" not working. Create alias instead
[13:12] <nigelb> I got used to bzr st
[13:12] <jkakar> nigelb: I don't mind those things so much.  I can alias or adapt.
[13:13] <nigelb> some things in git is pretty rad.
[13:13] <jkakar> nigelb: But things like git remote are confusing.  I don't care (or want) the staging area.  I know about commit -a, but I just don't want to even care about it.
[13:13] <nigelb> heh
[13:13] <nigelb> I agree, coming from bzr, that's a bit confusing.
[13:13] <nigelb> I somehow would like to have that in bzr
[13:14] <nigelb> (please don't stab me :P)
[13:14] <jkakar> Heh :)
[13:14] <jkakar> I don't stab.
[13:14] <jkakar> I cut.
[13:14] <nigelb> hehe
[13:14] <nigelb> jkakar: do you use zsh? There's some neat plugins to show to you which branch you're in.
[13:14] <nigelb> Many times I've commited to the wrong branch.
[13:15] <jkakar> nigelb: No, I use bash.
[13:15] <jkakar> nigelb: You probably wouldn't commit to the wrong branch with a directory-per-branch. ;b
[13:15] <nigelb> ah, so there's something I wrote which shows you which branch you're in
[13:15] <nigelb> hah
[13:15] <nigelb> I like the colocated feature
[13:15] <jkakar> Anyway, it's interesting to be a longtime Launchpad/Bazaar user trying tools from "the other side".
[13:16] <nigelb> It happens to me every so often that I type bzr commit in a git repo or vice versa
[13:16] <jkakar> I've heard a lot of GH/Git users complaining about Launchpad being hard to use... so far, I miss LP, but as I said, perhaps it's just familiarity.
[13:16] <jkakar> nigelb: Yeah, I do that a lot too. :)
[13:16] <nigelb> heh :)
[13:17] <nigelb> jkakar: Did you move from Canonical or does Canonical have stuff in GH now?
[13:17] <jkakar> nigelb: I left Canonical in March.  I'm at Fluidinfo now.  We've just moved from Launchpad to GitHub this week.
[13:18] <nigelb> jkakar: Ah. Yeah, github has a pretty healthy eco-system :)
[13:18] <jkakar> nigelb: Canonical putting stuff in GH would be a pretty bad sign. :)
[13:18] <nigelb> hehe
[13:22] <nigelb> GAH! I broke tests all over the place including soyuz.
[13:23] <jkakar> :)
[13:24] <StevenK> nigelb: Welcome to Launchpad
[13:24] <nigelb> StevenK: haha
[13:24] <wgrant> Don't let Soyuz consume your soul.
[13:24] <nigelb> ok, I need some help with the soyuz tests because I'm not sure if parts of is my breakage
[13:25] <nigelb> http://dpaste.com/600458/
[13:25] <nigelb> I don't understand the first bit
[13:25] <nigelb> lines 6 to 9
[13:25] <StevenK> Ah yes, doctests are fun
[13:25] <nigelb> and lines 21 to 25
[13:26] <StevenK> nigelb: Right, so 6-9 are red herrings
[13:26] <wgrant> nigelb: Look at the ++++++++ bits.
[13:26] <wgrant> Those are yours.
[13:26] <StevenK> The meat is 14 and 17
[13:26] <nigelb> I got those
[13:26] <nigelb> I fixed too.
[13:26] <StevenK> nigelb: "..." means some text
[13:26] <StevenK> And doctest errors suck
[13:26] <bigjools> doctests show all diffs even if you didn't change it
[13:27] <bigjools> IYSWIM
[13:27] <wgrant> Right, only the expected text is elided.
[13:27] <StevenK> Oh God, it's xx-sourcepackage-changelog.txt
[13:27] <StevenK> Kill it, it's moving!
[13:27] <nigelb> the 20 to 21 is weird, cos it shows lines added
[13:27] <wgrant> The actual text is shown in full, which makes the diffs rather difficult to interpret.
[13:27] <nigelb> StevenK: haha
[13:27] <bigjools> nigelb: fix 14/17 and you're done
[13:27] <nigelb> phew, okay
[13:27] <wgrant> nigelb: 21-24 are normally captured by the '...' on 20.
[13:28] <nigelb> aaah.
[13:28] <StevenK> Which is what is also going on with lines 6-9
[13:28]  * nigelb moves on to next set of tests
[13:28] <bigjools> doctests with more than a couple of lines out output  to match are a nightmare
[13:28] <nigelb> So much breakage.
[13:28] <bigjools> s/out/of/
[13:28] <nigelb> should I have run throw the entire tests before my MP?
[13:28] <nigelb> or is this sort of breakage common?
[13:28] <bigjools> nigelb: BTW have you see utilities/paste?
[13:29] <StevenK> nigelb: Did you get a mail from ec2 with a subunit stream?
[13:29] <nigelb> StevenK: yes, I'm fixing breakage from that.
[13:29] <nigelb> bigjools: no, does it pastebin whatever I want it to paste?
[13:29] <bigjools> nigelb: yes, takes stdin
[13:29] <nigelb> (in thise case, its from my mail, so entirely useful)
[13:29] <StevenK> nigelb: testr init ; zcat <subunit> | testr load ; testr run --failing
[13:29] <bigjools> so bzr diff|utilities/paste is v useful :)
[13:30] <StevenK> testr failing --list # if you want to see how many tests you broke
[13:30] <wgrant> bigjools: --syntax=diff!
[13:30] <nigelb> that's for doctests?
[13:30] <StevenK> nigelb: No, that's in general for failures from ec2
[13:30] <nigelb> but shouldn't I need some sort of access to see that?
[13:31] <StevenK> nigelb: As in, "Aiee, I broke 100 tests, how can I be sure if I fixed them all"
[13:31] <wgrant> nigelb: To see what?
[13:31] <nigelb> StevenK: ah.
[13:31] <nigelb> wgrant: to see the out put of what StevenK said :)
[13:31] <wgrant> nigelb: It's in the email.
[13:31] <bigjools> wgrant: I'm sure it could use file magic to do that
[13:31] <wgrant> bigjools: Probably.
[13:32] <nigelb> StevenK: subunit = bugs/soyuz etc?
[13:32] <StevenK> nigelb: Sorry, the subunit stream is the gzipped file that was attached to the mail from ec2
[13:32] <bigjools> nigelb: watching the cricket?
[13:32] <nigelb> StevenK: AH!
[13:32] <nigelb> bigjools: No, I gave up :P
[13:33] <bigjools> nigelb: :D
[13:33] <StevenK> nigelb: So you can zcat it into testr load and then testr can tell you exactly which tests failed without you having to read 500,000 lines of librarian log
[13:34] <wgrant> StevenK: I think that bug is fixed now, actually.
[13:34] <StevenK> bigjools: Oh, so England has discovered that they can actually hit the ball properly if they hold the padded bit of the bat?
[13:34] <wgrant> Saw something fly past a day or two ago.
[13:35] <bigjools> StevenK: #1 test team.  Suckit.
[13:35] <StevenK> [r=bac][bug=828151][no-qa] Truncate the librarian log before each test run.
[13:35] <StevenK> bigjools: That would require caring about cricket. Which I don't.
[13:35] <bigjools> StevenK: ah so you just care about trolling about it? :)
[13:36] <StevenK> OH, ALLENAP. Come here, so I can have your babies.
[13:36] <StevenK> bigjools: Exactly!
[13:36] <bigjools> what did allenap do?
[13:37] <bigjools> to deserve your generous offer
[13:37] <allenap> StevenK: I always hoped to get an invitation like that from an attractive woman, but it's been a long time so I guess you'll have to do.
[13:37] <StevenK> allenap: Haha
[13:37] <nigelb> lol
[13:37] <bigjools> not sure I'd be that desperate allenap
[13:37] <nigelb> And here I thought StevenK was married :P
[13:37] <StevenK> allenap: IOW, *thank you* for fixing the librarian log truncation.
[13:37] <StevenK> nigelb: I am
[13:38] <allenap> StevenK: No worries, it sounds like it bothered me as much as it did you.
[13:38] <nigelb> StevenK: I know :)
[13:38] <nigelb> StevenK: btw, testr is in LP? Or do I install it separately?
[13:38] <nigelb> python-zope.testing?
[13:39] <allenap> nigelb: Separate, python-testrepository.
[13:39] <nigelb> thanks allenap :)
[13:39] <abentley> bug 823850
[13:39] <_mup_> Bug #823850: AssertionError raised upgrading a branch that doesn't need upgrade <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/823850 >
[13:40] <nigelb> fuuu, looks england might win by an innings
[13:40] <bigjools> nigelb: again
[13:41] <StevenK> So India needs to hold the padded bit of the bat?
[13:41] <nigelb> bigjools: The best quote about India's perfomance was "India is like a faithful husband. Only performs at home"
[13:41] <nigelb> StevenK: Yeah :|
[13:41] <nigelb> grar, no testr still.
[13:41] <bigjools> ;0
[13:41] <StevenK> % dpkg -S /usr/bin/testr
[13:41] <StevenK> testrepository: /usr/bin/testr
[13:42] <StevenK> nigelb: ^
[13:42] <nigelb> I installed everything but that. WIN.
[13:42] <StevenK> Haha
[13:43] <nigelb> StevenK: when I do that, tests are supposed to pass?
[13:43] <nigelb> or does it just show me the ones that failed in EC2
[13:44] <StevenK> nigelb: When you did which?
[13:44] <nigelb> testr init ; zcat ~/Downloads/4595-upgrade-bug-linking-r13582.subunit.gz | testr load; testr run --failing
[13:44] <gary_poster> Thank you for the galapagos hint, StevenK
[13:45] <StevenK> gary_poster: Welcome.
[13:45] <StevenK> nigelb: The last command is what runs the failing tests
[13:46] <StevenK> nigelb: If tests aren't failing, you've already fixed them? :-)
[13:46] <nigelb> ok, so seeing everything fail is probably not a good thing.
[13:46] <StevenK> nigelb: Well, it's probably the expected thing
[13:47] <nigelb> wait, I know I fixed these.
[13:47] <nigelb> does the fix have to be committed?
[13:47] <StevenK> nigelb: You might be seeing testr load output
[13:47] <StevenK> It spams everything to stdout
[13:48] <nigelb> ah
[13:48] <gary_poster> deryck, sw your reply.  perfect, thanks
[13:48] <nigelb> failures 7
[13:48] <nigelb> bah
[13:48] <deryck> gary_poster: np! Thank you for putting the email notes together.
[13:48] <gary_poster> welcome
[13:56] <nigelb> I can run make test to be extra sure right? (worse case)
[13:57] <StevenK> nigelb: make check, but yes
[13:57] <StevenK> nigelb: It will take AGES
[13:57] <nigelb> gah
[13:57] <StevenK> nigelb: Or you can ask someone to resubmit it to ec2
[13:57] <nigelb> the testr is showing me false positives.
[13:58] <nigelb> fffffuuuu, brb, production server at work died.
[14:01] <nigelb> ok. back.
[14:01] <nigelb> let me look at the diff to see if I caught them all. If so I'm just going to ask someone to submit it again
[14:07] <nigelb> ok, so can someone re-land https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
[14:13] <jelmer> henninge, benji: can I add a MP to your queue?
[14:13] <benji> jelmer: sure; I can do one now.
[14:14] <jelmer> benji: thanks - it's at https://code.launchpad.net/~jelmer/launchpad/re-enable-test_import_bzrsvn/+merge/72411
[14:14] <nigelb> benji: could you re-view and re-land my branch?
[14:14] <benji> nigelb: sure, which one?
[14:14] <nigelb> https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
[14:16] <benji> jelmer: done
[14:17] <jelmer> benji: merci !
[14:23] <bac> hi jelmer, your branch for bug 826136 is now next on the QA hot seat.
[14:23] <_mup_> Bug #826136: dictionary changed size during iteration <oops> <qa-needstesting> <loggerhead:Fix Committed by jelmer> < https://launchpad.net/bugs/826136 >
[14:24] <jelmer> hi Brad
[14:24] <bac> jelmer: just letting you know since i got my blocker done
[14:24] <jelmer> bac: Thanks
[14:24]  * henninge is done reviewing
[14:24] <jelmer> bac: I'm waiting for tellarium (storage space for code imports) to come back up, once that happens I'll be able to do the QA
[14:24] <bac> jelmer: great
[14:27] <benji> nigelb: I'm afraid that revision is essentially unreviewable, the diff is over thirteen thousand lines long.
[14:27] <nigelb> benji: wait, what
[14:27] <benji> do you have a diff of just the changes you made to fix the failures?
[14:27]  * nigelb checks
[14:27] <nigelb> benji: ah, I merged in devel as well.
[14:27] <nigelb> The changes are more easily reviewed on the merge page
[14:28] <nigelb> My initial code only touched 3 files
[14:29] <benji> I'll do that.  It would have been nicer if I knew what had been changed to fix the test failures instead of having to re-review all the changes.
[14:30] <benji> You could have accomplished that by merging from devel in one revision and making your changes in another.
[14:31] <nigelb> benji: I should have. Noted for next time.
[14:31] <benji> cool
[14:38] <benji> nigelb: the branch looks good, I'm starting the landing process now
[14:39] <nigelb> benji: thanks! Sorry again for the messed up diff.
[14:39] <benji> no worries
[14:52] <rvba> Thanks for the review benji.
[14:52] <benji> my pleasure
[15:09] <nigelb> bigjools: its all over :(
[15:09] <bigjools> nigelb: a while ago :)
[15:10] <nigelb> bigjools: I wasn't actually watching. my roommate has it on and I just realized I'm listening to the presentation ceremony
[15:42] <henninge> good bye
[15:57] <sinzui> jcsackett, do you have time to mumble?
[16:21] <jcsackett> sinzui: i can mumble now.
[16:22] <jcsackett> sinzui: are you still free?
[18:27] <LPCIBot> Project devel build #982: STILL FAILING in 6 hr 10 min: https://lpci.wedontsleep.org/job/devel/982/
[18:48] <abentley> deryck: could you do a review for me?  The OCR is offline, and it should be pretty straightforward: https://code.launchpad.net/~abentley/launchpad/unnecessary-upgrade/+merge/72480
[18:53] <LPCIBot> Project db-devel build #815: STILL FAILING in 6 hr 33 min: https://lpci.wedontsleep.org/job/db-devel/815/
[18:57] <deryck> abentley: I can do it.
[18:58] <abentley> deryck: thanks!
[18:58] <deryck> abentley: I have to go pick up my daughter from school in 15 minutes, so if I'm not done by then, I'll finish when I return.
[18:58] <abentley> deryck: that's cool.
[19:25] <lifeless> morning
[19:33]  * jelmer waves to lifeless
[19:43] <gary_poster> hiya lifeless
[19:44] <gary_poster> abentley, could you take a look at https://answers.launchpad.net/launchpad/+question/168602 and either give me some advice or take it yourself, as you see fit?
[19:44] <abentley> gary_poster: looking
[19:44] <gary_poster> thank you
[19:46] <abentley> gary_poster: I doubt it's because a particular revision takes a long time.  I bet it's just because the whole branch takes a long time.
[19:47] <gary_poster> abentley, that's certainly what the log looks like.  So should I toss it to Jelmer, or say "so sorry," or...?
[19:47] <abentley> gary_poster: I think canonical staff may have done one-off imports like he's requesting in the past.
[19:47] <gary_poster> ah
[19:48] <gary_poster> ok abentley, I'll check with a losa if that is something they are familiar/comfortable with then
[19:48] <abentley> gary_poster: Okay.
[19:49] <abentley> gary_poster: comparing to "hg clone" isn't really the right comparison.  You'd want to compare to "bzr branch" with bzr-hg installed.
[19:51] <gary_poster> ok abentley, I guess I could try that locally for the heck of it...
[20:18] <deryck> abentley: looks good to me.  Sorry it took me so long.
[20:18] <abentley> deryck: no worries.
[20:36] <lifeless> gary_poster: jelmer_: hiya
[20:39] <jelmer_> does anybody have an idea what this sort of thing might indicate:
[20:39] <jelmer_> Fault: <Fault -1: 'Unexpected Zope exception: DisconnectionError: FATAL:  database "launchpad_ftest_9581" does not exist\n'>
[20:40] <jelmer_> not enough layers?
[20:43] <lifeless> that should be set up by your test process
[20:44] <lifeless> whats it coming from ?
[20:45] <jelmer_> a twisted callback
[20:45] <jelmer_> hang on, I think I know what might be happening
[20:45] <lifeless> sounds like you have a test helper running after the main test process is shutdown
[20:46] <jelmer_> leftover launchpad processes; I suspect it was tlaking to one of them
[20:46] <jelmer_> killing them seems to fix the problem
[20:46] <jelmer_> lifeless, yeah, indeed
[21:08] <lifeless> flacoste: oh, I remembered one thing
[21:08] <lifeless> flacoste: you're probably gone though ...
[21:09] <flacoste> lifeless: no, i'm still here for an hour
[21:09] <lifeless> flacoste: what do you think of us having a launchpad-sites or launchpad-deployments or something project - no code, but a place for bugs that are filed by community folk but really about how things have been deployed.
[21:10] <flacoste> lifeless: you mean for things related to Launchpad deployment outside of launchpad.net?
[21:10] <lifeless> flacoste: e.g. things like the help wiki needing moin upgrades would sit there
[21:11] <flacoste> lifeless: we already have a project for the help wiki though
[21:11] <flacoste> and dev
[21:11] <lifeless> or python-openid upgrades on lp-oops, or new haproxy or apache versions being needed
[21:11] <lifeless> things like needing a shared ssl session cache
[21:11] <flacoste> we track those usually through RTs
[21:11] <lifeless> right, *we do*, but if a community member files a ticket in any of these spaces
[21:11] <flacoste> which is obviously not community accessible currently
[21:11] <lifeless> we have nowhere to leave it as a placeholder
[21:12] <lifeless> e.g. our moin projects are labelled 'themes'
[21:12] <lifeless> which does involve code changes; I'm purely talking stuff with no code
[21:12] <lifeless> anyhow, its a thought
[21:12] <flacoste> lifeless: i'm not hot on the idea, but i wouldn't mind trying it out, we can assess if this pulls its weight after a while
[21:13] <flacoste> which reminds me
[21:13] <lifeless> I'll let it percolate
[21:13] <flacoste> we should probably kill the lp-<old-team> tags
[21:13] <flacoste> we said we would eventually
[21:13] <flacoste> doesn't look like anybody misses the projects
[21:13] <lifeless> :)
[21:51] <lifeless> allenap: lol! love your review cover letter.