[00:10] <wgrant> mars: I don't understand your assertThat suggestion.
[00:10] <wgrant> I've not seen it before.
[00:10] <mars> wgrant, it's something newish that testtools ported from Java.  You write a custom matcher and pass it into the assertThat() method along with the object to be asserted
[00:12] <mars> wgrant, so you would write a matcher that does the "assertEqual(expected, list(object._myMethod()))" dance for you, as if you were writing a helper function or something
[00:12] <mars> then you pass that matcher and the object under test into assertThat:  assertThat(myobject, PassesMyTest(foo))
[00:13] <wgrant> Ah, I see.
[00:14] <mars> The Java guys came up with it as a hack because assertEquals in Java just prints "True" or "False", which is really lame.  So they created the assertThat() method so that it can actually print nice test failure messages.
[00:14] <mars> However, it also serves as a nice way to pull common custom test conditions together as readable wrapper for helper functions
[00:17] <mars> wgrant, here's the code: http://bazaar.launchpad.net/~testtools-dev/testtools/trunk/annotate/head:/testtools/matchers.py
[00:19] <wgrant> I see it's not used anywhere in LP.
[00:19] <wgrant> I'm not sure how to write a matcher.
[00:21] <mars> wgrant, ok, maybe don't worry about it.  I'm just reading the code now, and you have to define a new class to do it.
[00:21] <wgrant> mars: Do you object strongly enough to NascentUpload's conditional __init__ that I should change the several dozen callsites which pass in a path?
[00:21] <lifeless> wgrant: give me a few minutes and I can help; or you can look at at testtools.matchers, bzrlib.test.matchers, or james' external matcher project
[00:21] <wgrant> I suppose it's nicer.
[00:22] <poolie> hi mars, wgrant
[00:22] <wgrant> Morning poolie.
[00:22] <mars> lifeless, I was thinking it was a nice way to wrap a repeated one-line assertEquals(), but I don't think the matchers are light enough to do that yet
[00:22] <mars> Good morning poolie
[00:23] <poolie> i've been meaning to try joining up multiple related assertions under an aggregating matcher
[00:23] <poolie> so you get a better message when they fail
[00:24] <mars> A decorator to somehow turn a helper function into a matcher would do the trick, but it's just a fancy way of writing a self.checkThat(foo) method.
[00:26] <lifeless> mars: wgrant: whats the MP that this is being discussed on ?
[00:26] <poolie> i think there's a social effect here that we don't normally have tests failing very much
[00:26] <wgrant> lifeless: https://code.edge.launchpad.net/~wgrant/launchpad/test-ddeb-matching/+merge/31482
[00:26] <poolie> so having nicer failures is only a transient benefit
[00:26] <mars> poolie, here as in Launchpad, or here as in Python?
[00:30] <poolie> in bzr, and probably in lp
[00:30] <poolie> maybe you get more failures in buildbot in lp
[00:30] <lifeless> wgrant: ok, matchers will definitely be cleaner. let me sketch you a story
[00:31] <wgrant> lifeless: Cleaner than a domain-specific assertion method?
[00:31] <poolie> yeah, they would be
[00:31] <lifeless> yes
[00:31] <wgrant> Hm.
[00:31] <poolie> definitely cleaner than inventing a per-test way of factoring it out
[00:33] <lifeless> wgrant: you also have some dead code AFAICT
[00:34] <wgrant> Hm, there's an 'except KeyError' that probably shouldn't be there any more.
[00:34] <wgrant> But what else?
[00:34] <wgrant> Oh, no, that should be.
[00:35] <wgrant> What's dead?
[00:39] <lifeless> wgrant: http://paste.ubuntu.com/472863/
[00:39] <lifeless> wgrant: I didn't quite get the intent of your function initially
[00:40] <lifeless> wgrant: thats a sketch of a matcher : use it as self.assertThat(self.changes, HasCorrectDebugDebs())
[00:40] <lifeless> it has the following properties; it is itself testable
[00:40] <wgrant> lifeless: Um, matchDDEBs is production code.
[00:40] <wgrant> Not just for tests.
[00:41] <lifeless> wgrant: thats interesting :) this can still fit in that context - matchers are not test-only code.
[00:42] <lifeless> anyhow, if it fits - great; if it doesn't, thats fine too.
[00:46] <mars> lifeless, poolie, in your 'switchable sandbox' workflow, does 'bzr push' still work as normal from within the tree'd branch you are working in?
[00:46] <james_w> wgrant, lifeless, mars: there will be lp.testing.matchers landing very shortly
[00:46] <mars> or do I have have to cd out and into the branch I am switched to?
[00:46] <james_w> I would encourage lp.<app>.testing.matchers or similar too
[00:46] <mars> james_w, cool, be sure to write the list when it does
[00:47] <mars> very nice
[00:47] <james_w> I think it's either in PQM's queue, or got lost between ec2 and pqm
[00:49] <thumper> :(
[00:49] <thumper> I want to update the pre-requisite branch of a merge proposal
[00:49]  * thumper tweaks todo list
[00:54]  * mwhudson waves at james_w 
[00:55] <lifeless> Ursinha-afk: doh, I misse dyou
[00:55] <james_w> hi mwhudson
[00:56] <mwhudson> james_w: i was going to ask how things were going, but maybe we should do that in #linaro
[00:58] <wgrant> How is stable ever going to get deployed in the new QA model?
[00:58] <wgrant> If it has to be fully QAd...
[00:59] <james_w> where do I find launchpad pqm's web interface?
[01:00] <mars> james_w, https://pqm.launchpad.net, but it won't help you much
[01:00] <mars> james_w, you might have to grep the server logs to find your branch
[01:00] <mars> oh, or not
[01:01] <mars> the branch is in the queue
[01:04] <lifeless> wgrant: a specific rev of stable is fully qa'd, not tip.
[01:04] <lifeless> wgrant: I'll make that clearer
[01:04] <wgrant> lifeless: Ah, I see.
[01:04] <lifeless> mars: yes, it still works.
[01:05] <wgrant> lifeless: flacoste's email this morning confused me.
[01:05] <lifeless> yes
[01:05] <wgrant> >      Is there a facility to roll out just the QAd stuff?
[01:05] <wgrant> No. Un-qaed revisions blocks deployment.
[01:05] <lifeless> what he means is
[01:05] <wgrant> It'll roll out an earlier revision.
[01:05] <lifeless> we can only rollout qa'd stuff; and that means we can't skip a revision
[01:05] <lifeless> if you have ABCDEF and A,C are QA'd we can only deploy A
[01:06] <lifeless> B needs to be either rolled back, or QA-ok.
[01:07] <wgrant> Right.
[01:08] <lifeless> anyone seen ImportError: No module named debian on ec2 recently ?
[01:08] <wgrant> That rev was just rolled back.
[01:08] <wgrant> But I thought buildbot was broken -- not ec2.
[01:09] <mars> wgrant, he may have fired up ec2 before the fix landed
[01:11] <jelmer> lifeless: You need to merge in a more recent lp:launchpad/devel, which adds me to the list of valid image owners. Though it's not relevant anymore since that revision has indeed been reverted.
[01:13] <lifeless> jelmer: into where - the ec2land running branch, my branch being submitted, or the target ?
[01:13] <jelmer> lifeless, the ec2land running branch
[01:13] <lifeless> ugh
[01:13] <lifeless> but ok
[01:26] <lifeless> is there a bug about the hot bugs list not updating bug status ?
[01:26] <poolie> lifeless: yes, is memcache misuse bug
[01:27] <lifeless> poolie: yes, but whats the bug #
[01:27] <wgrant> The milestone view is still broken too :(
[01:27]  * poolie looks
[01:28] <poolie> ah bug 599614 is the milestone page
[01:28] <_mup_> Bug #599614: bad caching in milestone page <qa-ok> <trivial> <Launchpad Registry:Fix Released by sinzui> <https://launchpad.net/bugs/599614>
[01:28] <wgrant> It's a lie.
[01:28] <wgrant> Ah, different bug.
[01:28] <poolie> lifeless: i wonder if we should 1- just turn them all off; 2- turn them right down to be unobjectionably low; 3- push expiry; 4- force browser refresh
[01:30] <wgrant> Bug #601051 is one.
[01:30] <_mup_> Bug #601051: Caching of primary data sources reduces utility <Launchpad Registry:Triaged> <https://launchpad.net/bugs/601051>
[01:30] <poolie> so this is an interesting case to use approximation
[01:30] <poolie> if you say "about 200 open bugs" it's a bit more tolerant of being out of date,
[01:31] <poolie> but not really, because i could speedily close many of them, and then it would still be wrong
[01:31] <poolie> wgrant: that's a nice description of a general cause
[01:31] <poolie> is it really a registry bug?
[01:32] <wgrant> Well, the problematic cases are mostly Registry.
[01:32] <wgrant> But possibly not.
[01:32] <poolie> bug 604530 too
[01:32] <_mup_> Bug #604530: brower refresh button should refresh TAL caches <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/604530>
[02:29] <james_w> is http://paste.ubuntu.com/472894/ not broken?
[02:31] <wgrant> I'd say so.
[02:31] <wgrant> It's been BPPH for yeeeears.
[02:31]  * mwhudson hasn't internalized the soyuz model well enough to say off hand
[02:32] <james_w> there's no distroarchseries on BinaryPackageRelease or its interface
[02:32]  * thumper has connection issues
[02:32] <james_w> make that three classes that don't implement the interface
[02:32] <thumper> there are people outside messing with wires
[02:33] <wgrant> james_w: The idea is right. It's joining BPR to DAS via BPP.
[02:33] <wgrant> Except that BPP is BPPH and has been for a long time.
[02:34] <james_w> does this imply that the "packages" attribute isn't used anywhere?
[02:34] <wgrant> I would hope that was the case.
[02:35] <mwhudson> james_w: is it in the interface?
[02:35] <james_w> mwhudson: yes
[02:36] <mwhudson> sigh
[02:36] <james_w> delete it or write tests for it?
[02:37] <james_w> I'm inclined to delete it
[02:37] <mwhudson> delete it
[02:37] <mwhudson> if it's not used
[02:37] <mwhudson> which it seems like it can't possibly be
[02:38] <lifeless> thumper: telecomnz seems to have had an outage
[02:45] <spm> someone let that wet string dry out again?
[02:51] <lifeless> :P
[02:58] <james_w> the first set of changes to wean SoyuzTestPublisher off the sampledata is now in ec2 to generate a list of fallout for me to work through
[02:58] <wgrant> That could be amusing.
[02:58] <james_w> I'm doing it piecemeal
[02:59] <wgrant> I'm considering demolishing parts of builder.txt.
[03:00] <james_w> this doesn't just make it ignore sampledata. There's one pipe to make the SoyuzTestPublisher back on to the factory, and another to give an API to avoid sampledata, with minimal changes to existing test paths.
[03:00] <wgrant> Soyuz tests seem to be getting a bit of a makeover at the moment.
[03:00] <wgrant> Ah, excellent!
[03:00] <james_w> that will allow us to gradually migrate
[03:01] <james_w> if it turns out there isn't much fallout then I'll just switch the existing code paths. The branch I just sent to ec2 does this for all the tests in test_publisher, just to get a feel for the fallout.
[03:04] <lifeless> wgrant: so, I think I've captured what you wanted in bug https://bugs.launchpad.net/launchpad/+bug/601051
[03:04] <_mup_> Bug #601051: memcache is used as a bandaid for responsiveness <Launchpad itself:Triaged> <https://launchpad.net/bugs/601051>
[03:04] <lifeless> wgrant: if instead you meant to say 'page X is cached and shouldn't be', please change it to say that and put it on the right product.
[03:05] <wgrant> lifeless: Indeed, thanks.
[03:05] <wgrant> There are a few around now, so your changes sound good.
[03:13] <thumper> OMFG, my code is actually working
[03:14] <spm> thumper: that's the beauty of statistics; eventually that million to one chance comes up!
[03:14] <thumper> haha
[03:14] <spm> (I am *so* dead at the next allhands...)
[03:14] <thumper> fcuking aussies think they are better than the rest of us
[03:15] <spm> s/think/know/ ;-)
[03:15] <thumper> I was amused to read an article on the sydney morning herald website
[03:15] <thumper> about how australia was going to beat the all blacks last weekend
[03:16] <thumper> one of his 10 reasons was "because australians are better than kiwis at everything"
[03:16] <spm> ah yes. The SMH. Purveyor of Kwality Journalism.
[03:16] <wgrant> Excellent reasoning.
[03:16] <thumper> another was "because it is about time"
[03:16] <thumper> and "we have too good a coach to lose to the all blacks 8 TIMES IN A ROW"
[03:17] <spm> I gather the AllBlacks won then?
[03:17] <thumper> heh, by lots
[03:17] <spm> ha! nice.
[03:17] <thumper> 49 to something small like 14
[03:17] <spm> orsum!
[03:17] <spm> was it a decent match depsite the score diff? or just embarrassing?
[03:17] <thumper> wallabies got someone red carded for the first time ever against the ABs
[03:17] <spm> Ahh. Biased ref eh?
[03:17] <thumper> no
[03:18] <thumper> stupid player
[03:18] <spm> (zing. trolled!)
[03:18] <thumper> ABs had a player yellow carded for not using arms in a tackle (read as shoulder charge)
[03:18] <lifeless> oof
[03:18] <thumper> Wallabies got a player yellowed for exactly the same reason with 5 minutes
[03:19] <thumper> ref warned both captains to stop slowing the ball down and he would move to yellow cards for anyone who continues
[03:19] <lifeless> I wonder
[03:19] <lifeless> for tag clouds
[03:19] <spm> hrm. ok, It's been about 25 years since I last played rugby; but we were taught to more or less hit with the shoulder and wrap the arms around to pull 'em down. that no longer the case?
[03:19] <lifeless> if using just the last 10K modified or something to summarise would be good
[03:19] <lifeless> rather than 'all open'
[03:19] <thumper> wallaby player gets yellow carded for slowing the ball down, but it was the same guy, 2 yellows = red
[03:19] <lifeless> (which we don't even do today)
[03:20] <thumper> spm: that's kinda OK as long as the arms are up and out at the time of shoulder contact :)
[03:20] <spm> lifeless: I'd suspect it would be  - if only for 'most recent ~= most relevant'
[03:20] <wgrant> lifeless: Don't we use 'all open' at the moment?
[03:20] <wgrant> lifeless: Apart from the dupe bug.
[03:20] <spm> thumper: roight
[03:20] <lifeless> wgrant: bug 404*** - tags from closed bug sshow in the cloud
[03:20] <lifeless> wgrant: that might be dupe related, I dunno
[03:20] <wgrant> Hmm.
[03:20] <lifeless> wgrant: check your bug mail ~ 2am
[03:21]  * thumper is making bzr push lp:project work when there isn't yet a trunk
[03:21] <lifeless> thumper: orsum
[03:23] <wgrant> lifeless: Ah.
[03:26] <lifeless> losa ping
[03:26] <spm> yo
[03:26] <lifeless> whats the unit on https://lpstats.canonical.com/graphs/MemcachedServersAll/
[03:26] <lifeless> requests per ??? ?
[03:26] <spm> tribble
[03:26]  * lifeless trouts spm
[03:26] <thumper> spm: there is something I'm supposed to be talking to you about...
[03:26]  * thumper thinks
[03:27] <spm> lifeless: I think it's seconds tbh.
[03:27] <lifeless> spm: and https://lpstats.canonical.com/graphs/MemcachedTotal/
[03:27] <lifeless> spm: does that mean, as I think it does, that we're getting 20% hit rate?
[03:27] <spm> lifeless: 5 min average, or possibly 1 min avg; per second.
[03:28] <spm> lifeless: I guess so - I'd suggest verifying with stub tho; he's more across the fine details of those than me
[03:29] <lifeless> meh, I'll shoot my foot off, its fine.
[03:29] <spm> fwiw, the serversall is a tad busy, but somewhat by (my) choice. was thinking that if we note server X is showing numbers wildly different to A, B & C, then there is "A Problem™"
[03:30] <spm> but by and large, they all track fairly close together, which is a good thing
[03:31] <thumper> mwhudson: please tell me that if the xmlrpc server returns a fault it aborts the transaction
[03:33] <mwhudson> thumper: i think so, you should be able to confirm by looking at the publication code
[03:33] <thumper> mwhudson: where is the xmlrpc publication code?
[03:33] <thumper> do you know?
[03:40] <mwhudson> thumper: otp
[03:43] <thumper> ack
[03:45] <thumper> :(
[03:45] <thumper> lp.codehosting.inmemory is going to make my life hard
[03:47]  * lifeless sets up a flamefest on lp-dev
[03:48] <thumper> lifeless: about?
[03:49] <lifeless> memcached
[03:49] <mwhudson> is the set up you need to pqm-submit launchpad branches documented somewhere?
[03:49] <mwhudson> i know it used to be on launchpad.canonical.com
[03:50] <lifeless> if this is wgrant's stuff, use ec2land ;)
[03:50] <mwhudson> it's just generally trying to recover my set up
[03:50] <mwhudson> i didn't lose much data, but i hadn't backed up lots of configuration :(
[03:51] <lifeless> here is what I used:
[03:51] <lifeless> echo "star-merge bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad/malone  bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel" | gnome-gpg --cl | mail launchpad@pqm.canonical.com -s "[r=mwhudson,thumper][ui=none][bug=607776] Further trade off ideal dup detection for speed, with an eye to bring back in ideal detection soon."
[03:51] <lifeless> when I had something that I needed to do directly :P
[03:52] <thumper> I just use the pqm-submit plugin, and have an alias for db-submit
[03:52] <thumper> mwhudson: you need (or should have) the canonical smtp server set up for outgoing email
[03:53] <thumper> mwhudson: [/home/tim/repo/canonical/launchpad]
[03:53] <thumper> pqm_email = Launchpad PQM <launchpad@pqm.canonical.com>
[03:53] <thumper> submit_branch = /home/tim/repo/canonical/launchpad/devel
[03:53] <thumper> mwhudson: and set a public location for the submit branch
[03:54] <mwhudson> thumper: ta
[03:56] <lifeless> hmm
[03:57] <lifeless> my memcached mail seems to have gone awol ?
[03:58] <lifeless> either that or lp list handling has gone boom ?
[03:58] <lifeless> spm: ^?
[03:58] <spm> I've got your email. ?
[03:58] <spm> "So, we've got a partial deployment of memcache in place..."
[03:59] <lifeless> ok cool. just gmail being stupid I guess
[03:59] <lifeless> not showing me what I sent ...
[04:00] <mwhudson> thumper: the publication code is in canonical.launchpad.webapp.servers
[04:00] <james_w> mwhudson: please add to https://dev.launchpad.net/LandingChanges
[04:00] <mwhudson> thumper: and yeah, inmemory doesn't support transactions
[04:02] <mwhudson> james_w: actually maybe i am just being very antiquated in wanting to use pqm-submit
[04:04] <wgrant> lifeless: One concern: as of 10.08 the front page makes requests to the blog to retrieve the feed. That's stored in memcached.
[04:04] <wgrant> I'm not sure if that's going to be a problem, though.
[04:05] <lifeless> well
[04:05] <lifeless> we can keep that one page I guess.
[04:05] <lifeless> (that said, the blog is local in the DC isn't it ?)
[04:05] <wgrant> I think so.
[04:06] <lifeless> remember that right now memcache isn't 'production available' - its not rated as a sev 1 when its down.
[04:07] <lifeless> poolie: you said the other day that we could talk feature flags
[04:07] <lifeless> poolie: did we? I forget
[04:07] <poolie> hey
[04:08] <poolie> i did say that; we didn't talk; talking now could be good
[04:08] <poolie> this is a good time for me actually
[04:08] <poolie> skype?
[04:08] <lifeless> sure
[04:19] <lifeless> poolie: https://bugs.edge.launchpad.net/ubuntu/+filebug-show-similar?title=lifeless%20is%20excited%20by%20the%20speed
[04:20] <j24> hi
[04:21] <j24> is there any doc howto install and configure launchpad dev?
[04:22] <poolie> j24: dev.launchpad.net
[04:25] <j24> I've read it but not clear
[04:25] <j24> I've install it
[04:28] <j24> poolie: I've install by apt-get
[04:28] <j24> and now want to run it
[04:28] <j24> but it never start
[04:29] <poolie> what did you install?
[04:32] <j24> launchpad-integration
[04:32] <j24> $ co
[04:32] <j24> & co
[04:33] <poolie> and what are you trying to accomplish
[04:33] <j24> I want a local launchpad
[04:33] <j24> to manage our own projects
[04:33] <poolie> ok
[04:34] <poolie> the "launchpad-integration" package isn't the launchpad source
[04:34] <j24> I've install this
[04:35] <poolie> https://dev.launchpad.net/Running
[04:35] <j24> http://paste.ubuntu.com/472926/
[04:35] <poolie> yeah, that's not actually launchpad
[04:35] <poolie> as the name says, they're the dependencies and integration code
[04:37] <j24> how can I install it so?
[04:37] <j24> I want to install how own launchpad server
[04:37] <poolie> read that wiki page
[04:38] <j24> is there any package that can do it on ubuntu?
[04:38] <j24> with have to install the source
[04:38] <j24> I've read the wiki but they always talk about manual settings
[04:39] <j24> not howto install your own launchpad
[04:47] <j24> poolie: if I download the source ok
[04:47] <j24> it work if I run make run
[04:47] <j24> but to setup a server it not good
[05:03] <j24> poolie: how can people will use bazar for them self when it's not friendly at all
[05:03] <j24> and ditto for launchpad
[05:09] <wgrant> j24: Launchpad's not designed for you to install it yourself.
[05:09] <wgrant> What is the prolbem that you have with Bazaar?
[05:09]  * mwhudson can't remember if he used to use gnome-gpg or seahorse
[05:12] <thumper> j24: I use bzr locally without launchpad for most of my work, what is it you are trying to do?
[05:14] <thumper> StevenK: ping
[05:22] <lifeless> spm: yo! OSError: [Errno 2] No such file or directory: '/var/lock/launchpad-codeimportdispatcher.lock'
[05:42] <StevenK> thumper: Pong
[05:43] <cody-somerville> Is this how adapters are intended to be used?: http://www.muthukadan.net/docs/zca.html#adapters
[05:45] <thumper> cody-somerville: not necessarily how we do it
[05:46] <thumper> cody-somerville: you might want to take a look at BranchTarget as an example of how lp.code does it
[05:49] <cody-somerville> Does launchpad use invariants, handlers, or subscription adapters?
[05:50] <mwhudson> i don't know what a subscription adapter is
[05:50] <mwhudson> i don't think we use invariants
[05:50] <mwhudson> what do you mean by handlers?
[05:50] <mwhudson> we do use zope.event a bit
[05:50] <spm> lifeless: huh. so I see. two of 'em on diff servers. curious....
[05:50] <cody-somerville> mwhudson, handlers are subscription adapter factories that don't produce anything.
[05:51] <cody-somerville> mwhudson, http://www.muthukadan.net/docs/zca.html#subscription-adapter
[05:51] <lifeless> cody-somerville: no, we use a somewhat simpler thing
[05:51] <lifeless> notify(event)
[05:51] <lifeless> even implements some IFoo
[05:51] <lifeless> and things that have register(IFoo) get called back
[05:54] <mwhudson> cody-somerville: ok, no i don't think we use subscription adapters
[05:56] <lifeless> they look like a solution looking for a problem, to me ;)
[05:59] <wgrant> We probably use them for publication hooks, but that's all I know of.
[05:59] <StevenK> lifeless: O hai, no review?
[05:59] <lifeless> grah
[05:59] <lifeless> url me up
[05:59] <lifeless> I shall do
[05:59] <StevenK> lifeless: https://code.edge.launchpad.net/~stevenk/launchpad/move-ifp-from-idistroseries/+merge/31520
[06:01] <lifeless> StevenK: so
[06:01] <lifeless> INSERT INTO is one case
[06:02] <StevenK> I've since converted these calls to store.execute(), by the by
[06:03] <lifeless> StevenK: I'm looking at store.execute on the merge page :P
[06:03]  * StevenK kicks his browser
[06:03] <lifeless> _copy_lucille_config can be done with the GenericCollection stuff
[06:03] <lifeless> its a set-wide mutation, which it supports.
[06:04] <lifeless> right
[06:04] <lifeless> so - INSERT INTO needs a storm feature, please file one (it needs INSERT INTO support, which AFAIK is not yet available)
[06:05] <lifeless> the UPDATE can be done already without writing SQL.
[06:06] <StevenK> I'm suprised Storm can't do INSERT
[06:06] <lifeless> INSERT yes
[06:06] <lifeless> INSERT INTO no
[06:07] <lifeless> sorry, I should be clear INSERT INTO ... SELECT
[06:07] <StevenK> lifeless: So it's an insert with a sub-select?
[06:08] <lifeless> yes
[06:08] <lifeless> it performs a query and inserts the result into a table
[06:10] <StevenK> lifeless: Bug filed, #613300
[06:10] <_mup_> Bug #613300: Storm needs to support INSERT INTO ... SELECT <Storm:New> <https://launchpad.net/bugs/613300>
[06:36] <mwhudson> setting up the functional layer takes 25 seconds on this machine :(
[06:37] <lifeless> hah
[06:37] <lifeless> :(
[06:38] <StevenK> lifeless: Anything else, re: that MP?
[06:38] <lifeless> not at the level you were asking about
[06:38] <StevenK> mwhudson: What is it, a coal-fired 486?
[06:38] <lifeless> which was just 'why the raw sql'
[06:39] <mwhudson> StevenK: netbook
[06:39] <StevenK> lifeless: Well, the other question was is the ducking underneath and all that still necessary?
[06:40] <lifeless> what do you mean 'ducking underneath' ?
[06:40] <StevenK> lifeless: In regards to the comment at line 108 in the MP diff
[06:42] <lifeless> ah
[06:42] <lifeless> well while INSERT INTO...SELECT is used; yes.
[06:54] <mwhudson> TWENTY FIVE SECONDS
[06:54] <lifeless> spm: how about rt 40685 - is that blocked ?
[06:56] <wgrant> mwhudson: What sort of hardware is that?
[06:56] <cody-somerville> interesting
[06:56] <mwhudson> wgrant: it's an aspire one, some atom thing at 1.66 ghz
[06:57] <cody-somerville> https://code.edge.launchpad.net/django <-- the first branch lists two series, one of the series doesn't even belong to the django project - is that a feature or a bug?
[06:58] <spm> lifeless: only on resourcing afaict
[06:59] <lifeless> spm: ok.
[06:59] <lifeless> spm: wanna bikkit!
[06:59] <lifeless> spm: you might like to eyeball https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone
[07:00] <wgrant> mwhudson: Haha.
[07:01]  * mwhudson having defeated zope again for the moment, retires for the evening
[07:02] <wgrant> mwhudson: Did you get around to sending those branches off, or did the Atom defeat you?
[07:02] <mwhudson> wgrant: i didn't send your branches, sorry
[07:02] <wgrant> mwhudson: No worries.
[07:05] <lifeless> wgrant: Are they all totally good to go /
[07:06]  * StevenK kicks IArchiveSet.getByDistroPurpose()
[07:08] <wgrant> lifeless: All except test-ddeb-matching are reviewed. I should probably get that one re-reviewed, since there were some changes made.
[07:08] <wgrant> StevenK: Why?
[07:08] <wgrant> StevenK: ArchiveCollection may interest you.
[07:08] <j24> wgrant: thumper: I want a local bazarr management tool
[07:08] <j24> and take a look on launchpad
[07:08] <j24> it look good
[07:09] <j24> but it's seems impossible to use for local projects management
[07:09] <StevenK> wgrant: Because I'm calling it from a doctest, and it's printing a security proxied IArchive, and it gets called from the script, and it's None
[07:09] <wgrant> StevenK: Awesome.
[07:09] <StevenK> wgrant: FSVO
[07:20] <lifeless> spm: any concerns about that wiki page from your perspective ?
[07:24] <spm> lifeless: in stage 1, it might be worth raising the idea of switching app servers in/out of the pool of available services on the LB's
[07:24] <lifeless> spm: isn't that whats done ?
[07:24] <spm> nope
[07:24] <lifeless> ...
[07:25] <spm> tbh, short of config file changes and reloads of the LB's, it may not even be possible.
[07:25] <lifeless> ok
[07:25] <lifeless> I'm going to ostrich this one
[07:26] <spm> heh
[07:26] <lifeless> if it fuads
[07:26] <lifeless> we'll stop moving through the process and address it
[07:26] <spm> @ $job-1; we were able to switch servers on/off in the web ui; but as we only had 3 app servers to worry about; and rollouts were light; it wasnt hard to do so.
[07:29] <spm> heh, and the idea of automated config changes to the running config of the LB's gives me the willies. switching set A in; out; B in etc. It may work; but *wince*.
[07:30] <spm> it'd be nice if haproxy (it may, i just don't know) had some sort of remote push notify that a service was going down. vs it's current detect that service is down.
[08:32] <adeuring> good morning
[09:15] <wgrant> bigjools: Morning.
[09:18] <mrevell> Hellooo
[09:23] <bigjools> morning
[09:24] <wgrant> bigjools: Any progress on the log parser setup?
[09:24] <bigjools> I asked for it to be re-instated
[09:25] <bigjools> about a week ago in fact
[09:25] <bigjools> not sure if it got done though
[09:30] <StevenK> wgrant: O hai?
[09:31] <StevenK> wgrant: I'm working on moving initialiseFromParent() out of IDistroSeries, and I've stopped it creating archives that don't exist. What should it do if the debug archive doesn't exist?
[09:31] <wgrant> StevenK: Hi.
[09:31] <wgrant> StevenK: Why would iFP be creating archives?
[09:32] <StevenK> It currently does
[09:32] <wgrant> What.
[09:32] <bigjools> it's bogus code
[09:32] <StevenK> For example, ArchivePurpose.PARTNER
[09:32] <wgrant> Ah, I guess it's designed to work cross-distro.
[09:32] <wgrant> And it will need to soon... but I'd just drop that code until we know what it actually needs to be extended to do.
[09:33] <StevenK> wgrant: I'm not sure I follow. Have iFP ignore debug archives?
[09:34] <wgrant> StevenK: iFP is currently used within a single distro.
[09:34] <wgrant> If there's no archive to publish to, there isn't one to copy from either.
[09:35] <StevenK> Right
[09:36] <wgrant> Hmm.
[09:36] <wgrant> The current code is reasonable, though.
[09:36] <StevenK> wgrant: Have you seen my MP?
[09:37] <wgrant> StevenK: I looked at it around 6am this morning, so didn't really take in much...
[09:37]  * wgrant looks again.
[09:38] <wgrant> Hm.
[09:38] <wgrant> Does it really belong in scripts/?
[09:38] <wgrant> We have stuff like the copy infrastructure in there... but then we call it from outside. I think it should be somewhere else.
[09:38] <wgrant> But anyway.
[09:39] <bigjools> it's a script
[09:39] <bigjools> it should live in scripts
[09:39] <wgrant> StevenK: Ah, so you're fixing it to not blindly copy PARTNER any more?
[09:40] <wgrant> In that case, yes, whitelist DEBUG along with PRIMARY.
[09:40] <wgrant> They need to be copied together at all costs.
[09:40] <bigjools> debug doesn't exist yet though does it?
[09:41] <wgrant> It doesn't, no.
[09:41] <wgrant> Oh, blah. That creates it even if there are no publications.
[09:42] <wgrant> Oh, no. It doesn't.
[09:42] <wgrant> So that's fine.
[09:42] <bigjools> so the script should only copy ddebs if the debug archive exists
[09:42] <wgrant> There are only ddebs to copy if the debug archive exists, so it won't copy them unless it exists.
[09:43] <bigjools> exactly :)
[10:58] <wgrant> bigjools: Ah, thanks for fixing that.
[10:58] <bigjools> you're such a stalker :)
[10:59] <wgrant> I just subscribe to (db-)devel!
[11:00] <StevenK> Haha
[11:15] <lifeless> wgrant: ping
[11:15] <lifeless> wgrant: Can you find more memcaching bugs - I can't find a solid list of them.
[11:25] <wgrant> lifeless: Grep the tree for tal:cache, take most of the results!
[11:25] <wgrant> (I can't do it myself right now, sorry)
[11:26] <lifeless> hah, lol, thanks.
[11:28] <jml> hello
[11:28] <lifeless> hai
[11:29] <jelmer> moin
[11:29] <bigjools> g'tag
[11:36] <jtv> sinzui, hi!  Say, would you mind having a look at how the FakeLibrarian currently installs itself and say whether I'm on the right track?  Whether we want layers or test resources to take care of actually invoking it is for later.  WIP MP: https://code.launchpad.net/~jtv/launchpad/fake-librarian/+merge/30907
[11:40] <lifeless> anyone from bugs around ?
[11:40] <lifeless> jml: you wanted to catch up on testr; was there other stuff? should we have a brief call?
[11:41] <jml> lifeless, just testr. need coffee before call.
[11:49] <jml> lifeless, hello
[11:49] <lifeless> hello
[12:00] <wgrant> lifeless: I received an email about one of those branches, but not the other two.
[12:00] <lifeless> no idea why :)
[12:00] <wgrant> Yay.
[12:34] <lifeless> jml: this is a core example of the sort of thing I was talking about re: storm etc - https://bugs.edge.launchpad.net/launchpad-foundations/+bug/251284
[12:35] <_mup_> Bug #251284: Building a representation of one entry should not take more than 1 database request <api> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/251284>
[12:39] <deryck> Morning, all.
[12:41] <jelmer> hey Deryck!
[12:45] <deryck> lifeless, you around?
[12:45] <lifeless> hai
[12:46] <deryck> so I'm a little aggravated that the caching of the hot bugs list as been held up as the poster boy for the horror of memcached.  But I certainly don't mind if the caching is removed.
[12:46] <lifeless> sorry :( its only one case
[12:48] <deryck> For the record, I did not do it to fix performance problems on the bugs home page.  You can see two MPs for bug 590992, where I fixed the root cause of that issue first and then added caching to try to buy overhead in times of trouble again (i.e. back when the db was on fire).
[12:48] <_mup_> Bug #590992: https://bugs.launchpad.net/ubuntu times out consistently <qa-ok> <timeout> <Launchpad Bugs:Fix Released by deryck> <https://launchpad.net/bugs/590992>
[12:48] <deryck> So I don't appreciate the "developers don't know how to cache" meme going around the bugs and email thread.
[12:48] <lifeless> sorry!
[12:49] <lifeless> It has definitely got overpersonal and a bit insulting
[12:49] <lifeless> and thats sad, because I don't feel that way about our team
[12:49] <deryck> I agree there are problems with memcached usage currently.  And perhaps it's better to focus our efforts on root cause of timeouts than getting the memcached infrastructure where it needs to be....
[12:50] <deryck> and fixing specific bad uses of caching, of course, fine....
[12:50] <deryck> but we'll never get memcached working if we don't try somehow.  and I think it is useful if used well.
[12:51] <lifeless> I totally agree
[12:51] <lifeless> I had tried to make that clear; its a tricky subject :(
[12:53] <deryck> Yes, I agree it's tricky.  And I agree with your perceptions, but not your conclusions.  In other words, yes, we have issues, yes, we need to do better, and priorities need to be accessed.  But I don't think backing out the facility completely, thereby preventing any further use, is the right approach.
[12:53] <lifeless> I've just re-read the thread, and I'm unhappy that you're unhappy - neither of my mails talks about motivation or knowledge at all.
[12:55] <deryck> lifeless, "message and developer actions are mismatched" in response to memcached not being about timeouts implies developers motivations are just to fix timeouts....
[12:55] <deryck> in the bug on this hot bugs issue you quote the great unsolved quote as if I don't know that and tell me to fix performance some other way
[12:56] <lifeless> deryck: for that one I apologise wholeheartedly
[12:56] <deryck> no worries, I'm not *that* upset about it. :-)  and look, I'm not trying to be a cry baby about it.  It's not that big a deal in the end....
[12:56] <lifeless> deryck: it was out of line, I was a bit unhappy at it being low I think.
[12:57] <deryck> fair enough.  I would rather us fix the memcached infrastructure to have some basic invalidation capabilities, rather than revert the usage.  I could use a feature flag to cache for edge now, when I couldn't before.
[12:57] <lifeless> deryck: so, I have a few things I want to ensure; I want to ensure that root causes are fixed first. Its great that you're doing that; I know via direct observation that it is not universally the case.
[12:58] <deryck> totally agree that we should fix that first.  I've not chatted with anyone to know others are doing differently, but I certainly believe you :-)
[12:59] <deryck> And I'm happy to have this one case reverted if it makes everyone happier.
[12:59] <lifeless> I want to ensure that we don't have coherency issues that users percieve - I'm all for decreased consistency to increase performance - but we can get a lot of mileage from just a little inconsistency
[13:00] <lifeless> bah, perc*ei*ve - its midnight
[13:00] <deryck> right.  Sorry to get you so late.  I appreciate you chatting with me about it.
[13:01] <lifeless> I have a concern - possibly entirely unjustified - that we're missing a huge slab of infrastructure to do invalidation at all well : rabbit may help, but its pretty tricky knowing *all* the places that something can have been cached in.
[13:03] <lifeless> anyhow, I'm not talking about pulling the plug from memcached in the datacentre; I'm talking about making sure that where we use it, its transparent to the user, and beneficial to us: we should be saving more time than we spend putting stuff in it during our current peak-load events
[13:04] <deryck> ok, if we're talking about "let's use it better, here's how..." then I'm completely supportive of that.  I read "propose to turn memcached off Friday" as taking away the facility completely.
[13:04] <lifeless> slightly hyperbole, and I didn't talk implementation details - I should have.
[13:05] <lifeless> I think memcache is a wonderful tool (I'm upstream on squid FWIW - I *really* like my caches)
[13:05] <bigjools> jml: I'd like a chat with you later about derived distros so I can bounce some issues off you if you're ok with that
[13:06] <jml> bigjools, sure. a bit later though, not really feeling 100%
[13:06] <lifeless> deryck: while we're talking
[13:06] <bigjools> jml: no prob, me neither tbh.
[13:06] <lifeless> deryck: https://bugs.edge.launchpad.net/launchpad-project/+bugs - search for 'caching' then click on next to get to the second page.
[13:07] <deryck> ok, looking....
[13:07] <lifeless> deryck: I see the first bug listed twice
[13:07] <lifeless> and the 10th and 11th rows are duplicates too
[13:08] <deryck> lifeless, because you're searching on a project group and the project is different.  See the project column.
[13:08] <lifeless> yeah
[13:08] <lifeless> is that deliberate?
[13:09] <deryck> Honestly, I'm not sure.  It's been that way awhile, so I don't know.  There's a bug about duplicates in series or package listings, but not about project groups, I don't think.
[13:09] <lifeless> if you don't consider it a feature, I can find-or-file a bug on it tomorrow
[13:10] <deryck> lifeless, yeah, I think it would be better to list the bug individually, and have each project affected listed in the project column.
[13:11] <lifeless> that would be really nice
[13:11] <deryck> it makes no sense for us to list multiple projects, since we're mostly one project.  But for other project groups, it could be nice to see a bug affects multiple projects.
[13:11] <lifeless> have you looked at the LEP/Search yet and made sure your use cases are well listed ?
[13:12] <lifeless> I realise you're flat out :), but I do hope to move that forward soon.
[13:13] <lifeless> deryck: I don't know if you've heard this, but apparently many users in the distro do their bug searching via +filebug
[13:14]  * jml -> lunch
[13:14] <deryck> lifeless, I did look at it.  I thought it was well covered but will look again.  I did know the distro used filebug.  I often do the same. :-)
[13:15] <lifeless> deryck: how would you feel if I put up a patch consolidating the search logic for them at some point ?
[13:15]  * deryck thinks....
[13:16] <deryck> lifeless, I think that would be fine.  My only concern is that filebug can be a bit aggressive and show odd results sometimes that make you think "now how is that related?"
[13:16] <lifeless> deryck: I think we've pretty much fixed that :)
[13:16] <deryck> ah, right :-)
[13:16] <deryck> lifeless, so then, yeah.  Please do it! :-)
[13:17] <lifeless> well, ECycles, but I'll keep it in my scratch list
[13:18] <lifeless> by which I mean, I won't commit to it, because that would impede someone else doing it, but if I happen to have some slack I'd certainly like to shrink the code base a little and that seems like a place with some overlap
[13:21] <deryck> yeah, definitely.  I'm happy for it to be done, and fine if anyone does it.  I doubt another bugs team dev would have time for a while either.  Unless there own itch itches. :-)
[13:21] <lifeless> who runs http://twitter.com/launchpadbugs ?
[13:22] <stub> deryck: Should https://code.edge.launchpad.net/~stub/launchpad/bug-602936-hotbug-caching/+merge/31735 be rejected? I see no other way of addressing the bug in the short term, so it depends if you think the solution is better or worse than the problem (low priority, so I guess not much of a problem)
[13:22] <lifeless> it seems very selective about what it retweets
[13:23] <deryck> lifeless, hmmm, I didn't even know that existed.  Not sure who runs it.
[13:24] <lifeless> :)
[13:24] <lifeless> the miracles of doing a search to see if anyone complained about the filebug change
[13:24] <lifeless> matsubara: hi
[13:24] <lifeless> man, this is great, If only it wasn't 12:30
[13:24] <matsubara> lifeless, hi there
[13:25] <deryck> stub, no, I think reverting the memcached usage there is fine.  For some reason, I thought you were still working on memcached in the sense of trying to get a simple invalidation mechanism....
[13:25] <deryck> if not, then yes, we should clearly remove this usage.
[13:25] <lifeless> matsubara: have you seen the fresh https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone
[13:25] <matsubara> lifeless, nope
[13:25] <lifeless> matsubara: if I can divert you for a few minutes
[13:25] <lifeless> and ask you to look at it
[13:25]  * matsubara reading now
[13:26] <stub> I don't think we have gotten as far as deciding on an approach for invalidation, let alone ready to code.
[13:26] <stub> I'm in favour of seeing what we can do with what we have, because that is less work ;)
[13:28] <deryck> heh, fair enough :)
[13:37] <matsubara> lifeless, ok. do you need any specific feedback on it?
[13:37] <lifeless> matsubara: yes; where are you guys up to with respect to the shepard ?
[13:40] <matsubara> lifeless, mars is leading that. Last I heard there's: https://dev.launchpad.net/QAShepherd and mars registered https://edge.launchpad.net/qa-shepherd
[13:40] <lifeless> ah
[13:40] <lifeless> I shall chat with gary and mars then
[13:41] <deryck> bigjools, hi.  6 or 7 of the QA items for bugs are my markAsDuplicate work that was reverted, so I'm trying to get that back in today and qa'ed ASAP....
[13:41] <lifeless> that seems rather more than I had expected.
[13:41] <deryck> bigjools, as for the rest, I'll chase them up or nudge others today.
[13:41] <mars> lifeless, have had a day or two of coding on it, and also hammered out a list of stories outlining the minimum viable feature set.
[13:41] <bigjools> deryck: thanks man.
[13:42] <deryck> np!
[13:42] <lifeless> deryck: for that thing, you need a new storm; danilo says our custom one is just a few commits from trunk
[13:42] <bigjools> and the thought of QA makes me hungry
[13:42] <lifeless> deryck: so grabbing the latest release if it has the caching bug fixed will do it
[13:42]  * bigjools -> lunch
[13:42] <lifeless> deryck: I'd say ask jkakar but hes on a plane, therve may know.
[13:43] <lifeless> mars: well, its nearly 1am, but perhaps you gary matsubara and I can have a call right after the team leads meeting ?
[13:43] <deryck> lifeless, ah, ok.  I will.  I was also experimenting with other ways to force the update.  transaction.commit() works, muhahahah! ;)
[13:43]  * deryck kids obviously
[13:43] <lifeless> :P
[13:43] <lifeless> deryck: it was a pita - spent the whole day tracking the thing down :(
[13:44] <lifeless> took a bit of demonstrating to convince the storm guys :)
[13:44] <mars> lifeless, that is at 1400?
[13:44] <deryck> lifeless, yeah, sorry.  I thought it was well tested and working well when I left it.   When you say "the caching bug," is there a bug number for storm?
[13:44] <lifeless> deryck: oh, I dunno if we got that far
[13:44] <lifeless> deryck: uhm, ask therve, its my best advice
[13:44] <deryck> lifeless, ok, thanks.
[13:45] <lifeless> mars: I don't know my 7am. Its nearly my 1am now.
[13:46] <mars> lifeless, oh, ok.  So we should talk in 6-8 hours then.  Perhaps your 9am, depending on matsubara's EOD
[13:46] <mars> TL call is 2pm here
[13:46] <matsubara> mars, lifeless: after the TLs meeting sounds good to me
[13:49] <lifeless> thanks, that will be great.
[13:49] <lifeless> mars: < 9am would be good, asiapac reviewers meeting is at 930
[13:49] <lifeless> anyhow, ciao, sleep
[13:50] <mars> Ursinha, good morning!  I had a question about the qa-tagger/shepherd handoff: the shared DB would contain revno/branch URL, right?
[13:51] <Ursinha> mars, yes, and mentioned/linked bugs, if possible
[13:51] <Ursinha> well, that's possible :)
[13:54] <mars> Ursinha, so branch name and a list of linked bugs?  Or the revno and branch name?  (I can get the list of linked bugs from the branch, can't I?)
[13:54] <Ursinha> mars, revision number, linked bugs and branch name
[13:54] <Ursinha> mars, yes, you can, but I think we could avoid requiring checking the branch again if the tagger can do that already
[13:55] <mars> ok, thanks
[13:55] <Ursinha> s/can do/will do/
[14:28] <gary_poster> benji___ (________!) mars matsubara Ursinha (stub): kanban now, mumble in 2
[14:31] <wgrant> mars: When you have a moment, could you look at my changes to https://code.edge.launchpad.net/~wgrant/launchpad/test-ddeb-matching/+merge/31482 and land it?
[14:31] <mars> wgrant, certainly
[14:32] <maxb> Do the Canonical ISD hackers have any IRC presence? I was hoping to poke them about potentially making their workalike to launchpad-dependencies public
[14:33] <wgrant> I've looked for one several times, but have always failed.
[14:34] <wgrant> AFAICT they do not have a public presence of any kind.
[14:36] <mars> maxb, maybe ask flacoste about if they might open it up?  He knows all :)
[14:37] <flacoste> mars, maxb: i'll tell stuartm
[14:40] <maxb> flacoste: thanks - I believe I have located the project: https://code.launchpad.net/canonical-isd-web-framework - and by subtle hints in the UI I can tell there's a private branch there :-)
[14:40] <Ursinha> lifeless, hello
[14:48] <james_w> How would I test that a row was removed from the DB?
[14:48] <james_w> remember it's id and then try and get it and catch NotFound?
[14:49] <jelmer> james_w: that seems like a reasonable approach
[15:39] <Ursinha> bigjools, hi :)
[15:39] <Ursinha> bigjools, have you seen this before/do you know what this means? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1672EA4370
[15:41] <bigjools> ummm
[15:41] <bigjools> that's an odd one
[15:42] <bigjools> Ursinha: I suspect he had the page open for a while and it finished building in the mean time
[15:42] <bigjools> because if you go to the page now it redirects back to the build
[15:42] <Ursinha> bigjools, I've seen some of those last days, but couldn't reproduce
[15:43] <bigjools> Ursinha: yes, that's exactly what I see
[15:43] <Ursinha> bigjools, want me to file a bug?
[15:43] <mars> wgrant, I haven't forgotten your branch, but I have been bound by meetings
[15:43] <bigjools> Ursinha: yeah, we can make a nicer message to the user
[15:51] <Ursinha> bigjools, bug 613480, sorry for the poor bug title
[15:51] <_mup_> Bug #613480: CannotBeRescored OOPS instead of a more friendly message <oops> <Soyuz:New> <https://launchpad.net/bugs/613480>
[15:51] <bigjools> that's cool, thanks
[15:52] <Ursinha> bigjools, np :)
[15:54] <bigjools> sinzui: is "version" mandatory for a distroseries?
[15:54] <sinzui> I think so
[15:56] <sinzui> bigjools, remember that version is is in the URL, it is what we traverse to see the istroseries
[15:56] <bigjools> sinzui: the name is in the url not the version
[15:57] <bigjools> sinzui: I am wondering if it could be optional for derived one-shot distroseries
[16:00] <sinzui> bigjools, I think we need to answer this in the context of bug 547082 and bug 419788
[16:00] <_mup_> Bug #547082: LTS series are not designated as such <Launchpad Registry:Triaged> <https://launchpad.net/bugs/547082>
[16:00] <_mup_> Bug #419788: Display name for distribution series doesn't follow vendor conventions <Launchpad Registry:Triaged> <https://launchpad.net/bugs/419788>
[16:01] <sinzui> bigjools, some of the discussion to address these bugs imply version is guaranteed. If we are certain version is optional in these cases, then we can make the field optional
[16:02] <bigjools> sinzui: that latter bug only applies to Ubuntu
[16:02] <sinzui> not so
[16:02] <bigjools> the way it's written makes it sound like it's for all of them
[16:02] <sinzui> the issue apparently related to debian
[16:02] <sinzui> I am wary of making series parent None per another bug. I think we should admit the Lp is for Ubuntu and sometime debian.
[16:02] <bigjools> I can't believe that all distros we'd ever host would somehow want to change from a codename to a version when released
[16:03] <bigjools> well, the changes I am making is going to make it for Ubuntu and a metric asshat load of derivatives :)
[16:04] <sinzui> Lets be honest. We host one distro. There are several derivative distros like baltix that do little because we do not let them do anything
[16:04] <bigjools> we should not allow ourselves to be painted into a corner by Ubuntu
[16:04] <bigjools> at some point in the very near future we will be hosting more derivatives
[16:05] <sinzui> We are still getting complaints from fedora and gentoo user that they cannot register a sourcepackagename. We should remove these distros we registering in our exuberant maddness thinking we could support them in a few months of creating Ubuntu
[16:06] <sinzui> bigjools, We have IDerivativeDistribution now because I refused to let Ubuntu dictate how other distros work
[16:07] <bigjools>  /o\
[16:07] <bigjools> sinzui: can you please take a look at https://dev.launchpad.net/LEP/DerivativeDistributions
[16:07] <bigjools> and if you have time, https://dev.launchpad.net/LEP/DerivativeDistributions/UserTestingRound1
[16:08] <bigjools> but I am currently making mockup changes based on user feedback
[16:08] <bigjools> I feel a great disturbance in the Force around making this fit for Ubuntu-derived distros, and Ubuntu's derivation from DEbian
[16:22] <jelmer> gary_poster: Hi!
[16:23] <jelmer> gary_poster: As promised yesterday I've just sent an email to the list about the PPA, EC2 images.
[16:33] <barry> bigjools: hi
[16:33] <bigjools> barry: hi
[16:34] <barry> bigjools: i'm happy to talk about anything you want, including the net-snmp builder hang.  i'd like to get some lunch first though.  will you be around for a little while?
[16:34] <bigjools> barry: I leave in 1.5 hours
[16:35] <barry> bigjools: ok.  i will ignore the rumble, if this is a good time for you
[16:35] <bigjools> barry: one thing though, for your FTBFS display, you should use the "show builds" page
[16:35] <bigjools> your "want to know newer versions" is an interesting one
[16:35] <barry> bigjools: is that the "view all builds" link, i.e. +builds?
[16:35] <bigjools> and I can see why you were interested in my work on derivatives :)
[16:35] <bigjools> yes, +builds
[16:35] <barry> :)
[16:36] <bigjools> it will fit your use case perfectly
[16:36] <bigjools> barry:  see https://dev.launchpad.net/LEP/DerivativeDistributions
[16:36] <deryck> adeuring, r=me, with minor changes.
[16:37] <adeuring> deryck: thanks!
[16:37] <deryck> np
[16:37] <bigjools> barry: BTW are you the one making lots of calls to getBuildRecords on the API at the moment?
[16:37] <bigjools> I see thousands of soft oopses :(
[16:37] <barry> bigjools: it's close, but not perfect.  i.e. i really want a !successfully-built view, but currently there are a number of failing states you'd have to select individually.  with the script i can see all the failures and (optionally) the reasons
[16:37] <bigjools> barry: ah ok interesting
[16:37] <bigjools> we should fix that
[16:37] <bigjools> can you file a bug please!
[16:37] <barry> bigjools: i read that LEP, and indeed i'm very interested in that :)
[16:37] <barry> bigjools: will do!
[16:38] <barry> bigjools: re: gBR.  could be.  i only run those scripts once in a while though (< 4 times a day at most)
[16:38] <bigjools> ok
[16:42] <barry> bigjools: bug 613501
[16:42] <_mup_> Bug #613501: Wishlist: one !successful-built status for a ppa's +build page <Launchpad itself:New> <https://launchpad.net/bugs/613501>
[16:44] <barry> bigjools: do you want to look at the net-snmp builder hang?
[16:45] <bigjools> barry: I suspect it's a bad job, it stuck on 2 arches
[16:45] <bigjools> we reset the amd64 one, let's see if it repeats
[16:45] <barry> bigjools: cool, thanks.  is there anything i should do about stuff like that in the future, other than ping you or a losa?
[16:46] <bigjools> barry: so ideally not me in the future, but I appreciate there's not many people with the knowledge :)
[16:46] <barry> bigjools: :)
[16:46] <bigjools> if a losa would like to look at this problem with me now we can do some knowledge transfer
[16:47] <barry> bigjools: cool.  just let me know what the s.o.p. is and i'm happy to follow it
[16:47] <bigjools> I don't think this has a sop :)
[16:48] <barry> awesome.  i love to blaze trails, in both senses of the word :)
[16:49] <bigjools> barry: you mean leaving a smoking mess behind you? :)
[16:50] <Chex> bigjools: I can work with you on this
[16:50] <barry> bigjools: i seem to be (too) good at that
[16:50] <bigjools> barry: :)
[16:50] <bigjools> Chex: great!  So, we have a problem where a build was on a builder for 2 days.  In this case that's not expected so we need to work out what's going on.
[16:51] <bigjools> barry: how long would you normally expect it to take?
[16:51] <barry> bigjools: i'm not sure.  i haven't built that package locally (it was a resync request).  let me do that and see how long the sbuild takes
[16:51] <bigjools> Chex: therer are 2 builds that look stuck, we reset the amd64 one to see if it does it again.  The i386 one is here: https://edge.launchpad.net/~pythoneers/+archive/py27stack4/+build/1901035
[16:52] <Chex> bigjools: ok, looking there
[16:52] <bigjools> Chex: there's usually one of three outcomes to this problem: 1. the job really does take a long time, 2. the job is stuck, 3. the builder has got stuck
[16:53] <Chex> bigjools: I have to break soon for a shortish meeting, but can pick up with you uafter that
[16:53] <bigjools> Chex: ok ping me when you're back.  I will be gone in an hour though.
[16:54] <Chex> bigjools: ok, so how do I know its one of the 3?
[16:55] <bigjools> Chex: for (1) we can ask a packager how long he expects it to take normally
[16:55] <bigjools> Chex: for the others, the first thing is to reset the builder which forces the build onto a different builder.  If it does it again, the job is a bad one and we need to kill it.  That needs SQL at the moment until we do some UI work.
[16:56] <bigjools> it's nearly always a bad job.
[16:56] <bigjools> Chex: do you know how to reset the builders?
[16:57] <barry> Chex, bigjools i'm building net-snmp locally now
[16:57] <Chex> bigjools: no I dont find any wiki notes on how to do that
[16:58] <barry> Chex, bigjools oh shit, i know what the problem is
[16:58] <barry> Chex, bigjools you might as well kill the build, it will never finish
[16:59] <Chex> bigjools: I need to step away for my meeting now, but I will pick up with you again in a bit, hopefully before you leave
[16:59] <bigjools> Chex: ok, if it's a non-virtual builder we have to get a GSA to reset it.  if it's virtual (a PPA builder) we can run the same reset script that the buildd-manager runs.
[16:59] <bigjools> Chex: ok
[16:59] <barry> Chex, bigjools i saw this on monday, but doko has not yet fixed it.  'apt-get install python-pkg-resource' from ppa:doko/toolchain will hang forever.  i think it's waiting for stdin.  this is clearly my biggest priority to fix
[16:59] <bigjools> barry: ewwwwww :/
[17:00] <barry> bigjools: indeed. :( :(
[17:00] <barry> it's basically a blocker now for everything else i need to do
[17:01] <barry> so... i'm going to get some lunch, and then work on this as a top priority.  it's possible other py27stack4 and py27stack5 builds will hang for the same reason.  feel free to kill them all, and i will not request retrys/resyncs until i've fixed this particular problem.  i may request a priority bump on this package at that point, or get doko to do so
[17:03]  * barry -> lunch
[17:05] <bigjools> barry: I'm going to disable your PPA until we kill the builds
[17:06] <bigjools> the farm is DOSed with stuck builds
[17:06] <barry> bigjools: do the losas know how to re-enable it?
[17:06] <bigjools> yes
[17:06] <bigjools> but we'll also need to kill all the builds
[17:06] <barry> bigjools: cool.  yes, kill them all.  i've emailed doko (he's not online atm).  i'll ping the losas when i know i have a fix for this blocker
[17:18] <Ursinha> bigjools, hey, I have another oops question for you
[17:20] <Ursinha> bigjools, I've seen timeouts in DistroSeries:EntryResource:getBuildRecords, I wonder if you're aware of those
[17:23] <Ursinha> bigjools, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1676EB950 and
[17:23] <Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1676EB2797
[17:24] <jml> jelmer, hello
[17:24] <jelmer> jml: Hi
[17:24] <jml> jelmer, you might want to try out the testrepository branch https://code.edge.launchpad.net/~jml/testrepository/show-failures-incrementally-613152/+merge/31765 to see if it addresses your bug 553240
[17:25] <_mup_> Bug #553240: Please provide --passthrough / --tee option to 'testr run' <testr-run> <Testrepository:New> <https://launchpad.net/bugs/553240>
[17:25] <jelmer> jml: ah, nice!
[17:25] <jelmer> jml: I'll give it a whirl.
[17:26] <jml> jelmer, thanks.
[17:27] <bigjools> Ursinha: yes, the foundations team are fixing it, there's a performance issue in lazr.restful
[17:28] <Ursinha> bigjools, ah, nice
[17:28] <Ursinha> bigjools, last oops for you:  https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1676K716
[17:28] <mars> could someone please lp-land lp:~wgrant/launchpad/test-ddeb-matching ?  My lp-land command is busted :(
[17:29] <jelmer> mars, sure
[17:29] <mars> thanks jelmer
[17:30] <jelmer> jml: I guess it doesn't display anything for successful testruns?
[17:30] <jelmer> for individual tests I mean?
[17:30] <jml> jelmer, right. that's the current behaviour of "testr load"
[17:31] <jml> jelmer, the difference in this branch is it displays errors/failures as it gets them.
[17:31] <bigjools> barry: before I enable your PPA again we need to kill all those pending jobs, sorry.  I can't take the chance of it DOSing the farm again.
[17:32] <jelmer> jml: Yeah, I agree that's a big improvement over what we had previously.
[17:32] <jelmer> jml: Like that one time I ran "testr run" on lp only to find out I had broken the testfactory *after* about an hour of running tests...
[17:32] <jml> jelmer, :(
[17:33] <jelmer> mars: It seems busted here as well
[17:33] <jelmer> mars: ValueError: Cannot determine Bazaar host. "https://api.edge.launchpad.net/1.0/" not a recognized Launchpad API root. is what I get
[17:33] <mars> Heh, I get AttributeError: 'Entry' object has no attribute 'source_branch'
[17:34] <jelmer> mars: You're specifying the branch URL rather than the MP URL perhaps?
[17:34] <mars> jelmer, yep, that might do it
[17:35] <mars> argh, and now ec2 test -b lp:~wgrant/launchpad/test-ddeb-matching breaks too
[17:36] <mars> why don't all of our commands take the lp:~foo form by default?
[17:36] <jelmer> mars: why the -b ?
[17:36] <mars> jelmer, because it is not my branch.  I want to test William's branch.
[17:37] <jelmer> mars: IIRC I've run "ec2 test lp:~wgrant/..." without problems before.
[17:37] <jelmer> -b seems to be for including extra branches in sourcecode/
[17:38] <mars> argh, yep
[17:38] <james_w> anyone seen http://paste.ubuntu.com/473160/ during test setup?
[17:39] <mars> jelmer, I would have preferred '-s', for '--sourcecode-branch='
[17:40] <mars> james_w, might be related to some work with the twisted logger henning did recently?
[17:41] <jelmer> mars: I agree that'd make more sense, given the -b option to "ec2 land" also takes a branch but has a different purpose.
[17:41] <james_w> mars: I think it's environment as it just started happening in two different branches at the same time, without me merging in anything.
[17:41] <james_w> it's just that the output is so damn unhelpful
[17:42] <mars> james_w, yes.  Check /var/tmp for librarian pidfiles and the like
[17:42] <henninge> mars, james_w: that is not related to my work because that just changed buildd-manager.tac.
[17:42] <james_w> I can run daemons/librarian.tac under ./bin/twistd without an issue
[17:42] <mars> james_w, and maybe kill the librarian log files too, and check your process tree for dead librarians
[17:42] <mars> henninge, ok, thanks for the clarification
[17:43] <james_w> mars: stale librarian process apparently, thanks.
[17:44] <james_w> any idea where I would look to get it to say "port already in use" rather than the junk you get now?
[17:44] <mars> start with the librarian.tac file, see if you can work down through the callstack
[17:44] <jml> james_w, I'll race you :)
[17:44] <mars> something must be catching and masking the real error
[17:46] <jml> oh man, TacHandler
[17:48] <jml> what's happening is it's spawning a subprocess and then looking for a magic token in the logfile
[17:48] <jml> without regard to what the process dumps to stderr/out
[17:49] <jml> tachandler should be completely destroyed and rewritten as a series of good patches to Twisted.
[17:51] <james_w> jml: tachandler runs a subprocess?
[17:51] <jml> yeah.
[17:51] <jml> it spawns "twistd" directly
[17:52] <james_w> TacTestSetup?
[17:52] <james_w> that does read something from stdout/stderr though
[17:52] <jml> james_w, yeah, it does
[17:53] <jml> but only oncee.
[17:56] <james_w> jml: something like http://paste.ubuntu.com/473176/?
[17:57] <jml> james_w, that ought to do it
[18:00] <bigjools> barry: ping
[18:00] <bigjools> barry: going to nobble all outstanding builds in your 2 PPAs
[18:00] <bigjools> last chance to stop me
[18:01] <barry> bigjools: do it
[18:01]  * bigjools hits the red button
[18:04] <bigjools> barry: it's done
[18:04] <bigjools> you can re-enable your PPAs yourself
[18:04] <bigjools> in the +edit page
[18:05] <bigjools> g'night!
[18:05] <barry> bigjools: nod, and g'nite!
[18:05] <bigjools> and don't break the build farm again or I'll break your legs!
[18:05] <bigjools> ;)
[18:06] <james_w> jml: didn't fix it
[18:06] <jml> james_w, a shame.
[18:07] <james_w> twistd returns 0 and doesn't print anything?
[18:07] <jml> oh, huh.
[18:07] <jml> it might.
[18:07] <jml> easy enough to check, I guess.
[18:07] <jml> actually, it definitely would
[18:07] <jml> it daemonizes before opening the port.
[18:09] <james_w> ah, it daemonizes
[18:10] <jml> yeah, that's what the -y is for, also why tachandler does crazy logging stuff
[18:13] <james_w> so we need to wrap the .tac in a big try/except and try and log the exception before raising it?
[18:13] <james_w> twistd doesn't have any support for backchannel fds after it has forked or anything?
[18:32] <jml> james_w, no, I don't think it has such support.
[18:33] <james_w> using twisted.python.log and calling log.error in an except block around the entire .tac doesn't work
[18:33] <james_w> so I'm at a loss
[18:38] <jml> james_w, I'm sorry :(
[18:39] <james_w> it only means that we will have to continue to scratch our heads when daemons fail to start
[18:40] <jml> right
[18:41] <jml> the _real_ solution to all of this is to give Twisted more APIs to do what twistd does.
[18:41] <jml> james_w, on another note, do you need a hand landing https://code.edge.launchpad.net/~james-w/launchpad/no-more-sampledata-1/+merge/31493
[18:42] <Ursinha> sinzui, hello
[18:42] <james_w> jml: nope, just about to do that now the prerequisite is landed
[18:42] <jml> james_w, cool :)
[18:42] <Ursinha> sinzui, do you have a clue on why are we having lots of timeouts in MailingListApplication:MailingListAPIView recently? on staging, that is
[18:43] <Ursinha> sinzui, I also see a bunch of informational oopses, DisconnectionErrors, related to MailingListApplication:MailingListAPIView, but no idea if they're related
[18:44] <sinzui> Ursinha, recently? They go back months
[18:44] <sinzui> There are timeouts syncing large numbers of users
[18:44] <Ursinha> sinzui, I meant much more than usual
[18:45] <sinzui> Ursinha, Reduced the number in a branch he landed a few weeks ago
[18:45] <Ursinha> right
[18:45] <Ursinha> sinzui, I saw lots of timeouts like this one, two days ago: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1675S1478
[18:46] <sinzui> yes, I see those everyday
[18:46] <Ursinha> my question is, is this raise in the number "expected" somehow
[18:46] <sinzui> I am ignoring them
[18:46] <sinzui> They are not a high priority at this time
[18:47] <sinzui> I did ask an engineer to fix the issue, and he did take 3 days to reduce the issue
[18:48] <sinzui> Ursinha, We see a rise because we decided that syncing staging to lpnet is a priority. We used to sync once a month, (every 6 weeks in reality) We now sync every week
[18:53] <Ursinha> sinzui, ah, that explains
[18:54] <sinzui> Ursinha, it is a scary explanation though...it means staging has never been able to deal with the sync
[18:55] <Ursinha> sinzui, I see that, I see those timeouts since I joined canonical, I guess
[18:55] <sinzui> Ursinha, This is the second implementation of the sync. This one is designed to recover from timeout failures because we believe timeouts were happening in lpnet and that would block all other mailman sync procs
[18:56] <sinzui> Ursinha, There was a proposed spec (salgado maybe) about getting efficient user sets. I think it was intended to address situations like this
[18:57] <Ursinha> sinzui, hm, I see
[18:59] <lifeless> moin
[19:00] <Ursinha> hey lifeless
[19:01] <lifeless> hey Ursinha
[19:01] <lifeless> 'pong'
[19:01] <Ursinha> :)
[19:15] <lifeless> sinzui: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/74680 is the only accountmerge bug I can see atm
[19:15] <_mup_> Bug #74680: +accountmerge page should present the option to discard the merge request <Launchpad Foundations:Confirmed> <https://launchpad.net/bugs/74680>
[19:16] <sinzui> Oh sweet, a new bug for me to move into launchpad-registry
[19:18] <lifeless> :)
[19:21] <jml> lifeless, please review my testr branches :)
[19:21]  * jml runs away
[19:22] <lifeless> jml: thanks
[19:22] <lifeless> jml: also for the reminder to look at incremental and unblock you
[19:22] <jml> lifeless, I've actually already come up with a patch
[19:23] <sinzui> lifeless, I am reporting a new timeout bug for person merge. I think the one I care about was marked as a dup and some aspect of the master bug lead someone to mark it as closed.
[19:23] <lifeless> oh cool
[19:24] <lifeless> sinzui: makes sense to me.
[19:24] <lifeless> so, gary_poster, mars : I want to catch up on the qa shepard stuff; there's now a calendar slot for a voice call in a bit; or would now be better?
[19:25] <lifeless> I had thought to have matsubara or Ursinha there too, given its for qa :)
[19:25] <gary_poster> lifeless, mars: now is fine with me
[19:25] <mars> lifeless, either for me
[19:25] <mars> lifeless, mumble?  Foundations channel?
[19:25] <lifeless> we'll give mumble a shot, though NZ + mumble generally equals epic fail
[19:26] <gary_poster> heh
[19:26] <gary_poster> skype is fine too
[19:26] <Ursinha> I'm there already
[19:26] <mars> lifeless, I thought you were in Perth?
[19:26] <lifeless> can you hear me ?
[19:26] <lifeless> I can hear you ok :P
[19:30] <Ursinha> lifeless, gary_poster, huge echo
[19:30] <lifeless> I've turned my mic off for now
[19:30] <Ursinha> thanks :)
[19:32] <lifeless> project exists
[19:32] <lifeless> mars: ^
[19:33] <matsubara> for some weird reason I can't connect on mumble
[19:36] <deryck> sinzui, ping
[19:38] <lifeless> gary_poster: mars: https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone <-
[19:38] <lifeless> stage 2 there is what we're looking at
[19:39] <sinzui> hu deryck
[19:42] <mars> lifeless, Ursinha, gary_poster, https://dev.launchpad.net/QAShepherd
[19:50] <lifeless> gary_poster: please do
[19:51] <lifeless> (avoiding my mic for your sanity)
[19:53] <lifeless> gary_poster: small lemma; its a revision we have, not a branch right? because buildbot lands stuff in stable asynchronously from qa happening ?
[19:55] <lifeless> mars: right
[19:55] <lifeless> mars: thats exactly what I was thinking
[19:57] <lifeless> mars: for now, I only want to *aim* at being able to tell the losas what to deploy
[20:02] <Ursinha> lifeless, mars, gary_poster, matsubara's internet just dropped
[20:02] <Ursinha> and he's back, it seems :)
[20:02] <matsubara_> and it's back again. minor hiccup it seems
[20:02] <gary_poster> mars, Ursinha, matsubara_ mumble is a Zope question fwiw
[20:03] <gary_poster> I don't think you need to hang around unless you want to
[20:03] <Ursinha> ah, ok gary_poster
[20:10] <lifeless> yeah, new topic :)
[20:10] <lifeless> sorry guys
[20:15] <mars> lifeless, first two items in place.  The old list didn't have end-user concerns first: oversight on my part.  https://dev.launchpad.net/QAShepherd
[20:16] <lifeless> I think thats great
[20:16] <lifeless> I'd be happy with just a number coming back from a DB :P, but having it as html is ok too - we can screen scrape to get the revision
[20:17] <lifeless> [mostly teasing there, the use cases are fine]
[20:17] <mars> lifeless, regarding the project: yes, it's set up.  I'm waiting on getting a shared branch so we can use the LP merge workflow.  The other alternative is to run Tarmac locally.
[20:17] <lifeless> mars: what do you mean ?
[20:18] <lifeless> [what is a shared branch in this context]
[20:18] <mars> lifeless, I have ownership of mainline right now.  It would be nice if launchpad-pqm owned it instead
[20:18] <mars> and if Tarmac could handle landing
[20:19] <mars> Since there will be three people hacking on it
[20:19] <mars> simultaneously
[20:19] <lifeless> ok, so you're blocked on two things
[20:19] <mars> but I can see about running Tarmac here instead
[20:19] <lifeless> a) a branch for 'trunk'
[20:19] <lifeless> and b) a tarmac in the D/C
[20:19] <lifeless> if I may suggest somethinhg
[20:20] <lifeless> create a team - lp-qa-shepard-committers
[20:20] <mars> we already have that: lpqateam
[20:20] <lifeless> no
[20:20] <lifeless> In that team, put everyone that should be able to *bzr push* to trunk.
[20:21] <mars> right
[20:21] <lifeless> and make the trunk branch yourself, owned *by the team*, not by *launchpad-pqm*
[20:21] <mars> yep
[20:21] <lifeless> that gives you a)
[20:21] <lifeless> and the branch url will be stable when you get a tarmac instance in the D/C
[20:22] <lifeless> because launchpad-pqm will be part of the team, you simple take yourself, Ursinha & matsubara_ out of the team at that future date
[20:22] <lifeless> its a bit of a bug our current lp branches are owned by launchpad-pqm, rather than by a team
[20:22] <lifeless> oversight some years back
[20:23] <mars> It might easier for now if I just set up Tarmac locally.  That way it is automated, but there are also no accidental overwrites from multiple pushers.
[20:23] <lifeless> it should be clear why its not the lpqateam
[20:23] <lifeless> mars: bzr won't permit overwrites
[20:24] <lifeless> mars: you can do what I suggest *and* setup tarmac locally.
[20:24] <mars> lifeless, so not reusing lpqateam - is that so commit access can be controlled later via team membership?
[20:25] <lifeless> yes
[20:25] <mars> so a hack then
[20:25] <lifeless> using the model
[20:25] <lifeless> is lpqateam a private team ?
[20:26] <mars> https://edge.launchpad.net/~launchpad-qa
[20:26] <mars> just restricted
[20:26] <lifeless> right, its moral owner, not committers
[20:27] <mars> committers actually
[20:27] <lifeless> I don't think its a hack, given LP's branch permission model, to have a -committers team : many many projects do this.
[20:27] <lifeless> mars: there is a bot in there
[20:28] <mars> lifeless, yep, but you also need to be a member to work on a few of the QA projects
[20:28] <mars> I have no idea why the bot is in there
[20:28] <lifeless> mars: anyhow, its a suggestion. Its what I'd do - if its not helpful, thats ok, don't do it :)
[20:29] <mars> ok, well if overwrites from multiple team members are not a problem, the great - that's what I would have liked to do in the first place
[20:29] <mars> thanks lifeless
[20:30] <lifeless> mars: set append_revisions_only=True in the branch.conf
[20:30] <lifeless> and it will also prevent mainline wobbles
[20:31] <lifeless> (bzr help configuration)
[20:33] <lifeless> Ursinha: lp-oops being openid is nice, but its a _very_ short timeout - like only an hour or so : can we make it something reasonable, like LP? (several months would be nice :P)
[20:34] <matsubara_> lifeless, losas control that
[20:34] <lifeless> matsubara_: ah
[20:35] <Ursinha> hehe
[20:38] <lifeless> sinzui: I've linked the bug in the oops for you
[20:45] <mars> matsubara_ or Ursinha, are you able to push code to the ~launchpad-qa team space?
[20:45] <Ursinha> mars, yes
[20:46] <matsubara_> mars, I don't think I tried, but I assume I can
[20:46] <Ursinha> if you're subscribed to the branch, I guess you can
[20:46] <Ursinha> don't remember trying to push to a branch without being directly subscribed to it
[20:47] <mars> ok, I'm trying to push a branch, lp:~launchpad-qa/qa-shepherd/devel, and it spits it back at me saying "you don't have permission to do that"
[20:47] <mars> even though I am a member of the team
[20:49] <lifeless> mars: its because of the branch policy
[20:49] <lifeless> mars: you need the right permissions on qa-shepard
[20:49] <lifeless> losa ping
[20:59] <Ursinha> lifeless, which would be the right permissions in that case?
[21:03] <lifeless> Ursinha: you need a private branch policcy that permits anyone in the launchpad-qa team to make a new branch; but we're about to open it so that won't matter at all in a few minutes
[21:03] <lifeless> Ursinha: as soon as my losa ping is answered ;P
[21:04] <Ursinha> lifeless, hehe, right
[21:04] <mbarnett> lifeless: hellos
[21:06] <lifeless> hellos
[21:07] <lifeless> we have a project, qa-shepard
[21:07] <lifeless> that is currently canonical-private, we'd like to open it please ;)
[21:13] <mbarnett> lifeless: when you say open, you mean set the default branch visibility to public?
[21:13] <lifeless> yeah, remove all the privacy-bits
[21:14] <lifeless> open bugs, open branches
[21:20] <mbarnett> lifeless: i am not seeing that project
[21:20] <lifeless> mbarnett: https://edge.launchpad.net/qa-shepherd
[21:21] <mbarnett> ah
[21:21] <mbarnett> sheepherd
[21:21] <mbarnett> lifeless: Default branch visibility for all branches in qa-shepherd  is Public.
[21:22] <lifeless> mbarnett: great, thanks.
[21:22] <lifeless> mars: should be good to push now.
[21:23] <mars> lifeless, cool, thank you
[21:30] <Ursinha> that gives us the ability of using lp:qa-shepherd again :)
[21:49] <lifeless> hey
[21:49] <lifeless> is there a wiki page that documents db patch workflow ?
[21:50] <mars> no idea
[21:58] <thumper> morning
[22:24] <mwhudson> i'm not the only person who gets mails from ec2 with attachments doubly gzipped am i?
[22:25] <mwhudson> thumper: good morning
[22:43] <wgrant> mwhudson: Morning.
[22:43] <mwhudson> hello
[22:43] <mwhudson> so wifi doesn't entirely work on this laptop, apparently
[22:43] <wgrant> mwhudson: You reviewed https://code.edge.launchpad.net/~wgrant/launchpad/per-archive-build-debug-symbols/+merge/29671 yesterday, but didn't click the button, apparently.
[22:43] <wgrant> Is it using iwlagn? I find that flakes out sometimes for me.
[22:44] <wgrant> But normally only once it's been up for a week or so.
[22:44] <mwhudson> how do i tell?
[22:45] <mwhudson> this had been up for a few days with a few suspends
[22:45] <wgrant> 'lsmod | grep iwl' should give you the driver, assuming it's Intel, which it probably is.
[22:46] <mwhudson> wgrant: reviewed
[22:46] <wgrant> mwhudson: Thanks. Can you ec2 it yet?
[22:46]  * ajmitch had that happen last night with iwlagn, had to rmmod & modprobe again
[22:46] <mwhudson> wgrant: it's ath9k
[22:46] <mwhudson> so that explains the flakiness probably
[22:47] <mwhudson> wgrant: yes
[22:47] <mwhudson> well maybe
[22:47] <mwhudson> boto.exception.BotoServerError: BotoServerError: 500 Internal Server Error
[22:47] <wgrant> Yay.
[22:53] <mwhudson> seems a bit better now
[23:03] <james_w> hi mwhudson
[23:03] <mwhudson> james_w: hi
[23:03] <james_w> did you see that the vostok branch failed?
[23:04] <mwhudson> wgrant: ec2 is headless
[23:04] <mwhudson> james_w: yeah
[23:04] <mwhudson> i guess i should do something about that
[23:04] <wgrant> mwhudson: Thanks.
[23:04] <james_w> the failures didn't mean a lot to me
[23:05] <james_w> well, the second did, but the first didn't
[23:07] <mwhudson> webapp-publication was pretty clear
[23:07] <mwhudson> some of the others were pretty mysterious
[23:07] <mwhudson> i haven't re run them locally yet
[23:08] <wgrant> mwhudson: 25 seconds? :P
[23:08] <mwhudson> yeah\
[23:14] <wgrant> Can someone please ec2 https://code.edge.launchpad.net/~wgrant/launchpad/bug-612157-ppa-quota-ddebs/+merge/31471, https://code.edge.launchpad.net/~wgrant/launchpad/test-ddeb-matching/+merge/31482, and https://code.edge.launchpad.net/~wgrant/launchpad/bug-241129-queue-binary-scaling/+merge/31604?
[23:14] <lifeless> wgrant: Didn't I do those ?
[23:14] <wgrant> lifeless: Two of them, but they vanished.
[23:14] <wgrant> Well, you did three, two of which are in that set because they vanished.
[23:16] <james_w> wgrant: I will
[23:17] <wgrant> james_w: Thanks.
[23:18] <james_w> wgrant: ppa-quota-ddebs might want a merge with devel
[23:18] <james_w> my apologies for that
[23:19] <lifeless> thumper: https://code.edge.launchpad.net/~jml/testtools/patch-310770/+merge/31666
[23:19] <lifeless> thumper: that used to have a diff; I think perhaps we're updating diffs after things merge now? So you can't see what was merged :(
[23:21] <wgrant> james_w: Heh, yes, true.
[23:22] <wgrant> james_w: Is the other one going to land soonish?
[23:23] <james_w> wgrant: my next sampledata branch?
[23:23] <wgrant> james_w: That's the one.
[23:23] <james_w> wgrant: the next is in ec2 now
[23:23] <james_w> I'm currently churning through fallout from making STP return proxied objects
[23:24] <wgrant> Ah.
[23:25] <lifeless> aaron is about to land a 'make it optional' patch
[23:25] <james_w> one of the things that I'm sad about is requiring more tests to be in LPZopelessLayer, where DBFunctional was fine before.
[23:25] <wgrant> I think james_w is about to squash most of the remaining warnings, though.
[23:25] <james_w> wgrant: does each SPR require a PackageUpload?
[23:26] <wgrant> james_w: Only for some purposes.
[23:26] <james_w> right
[23:26] <wgrant> Lots in production don't.
[23:26] <wgrant> So we know it works.
[23:26] <wgrant> (gina doesn't create them)
[23:26] <james_w> ok, Julian said it should
[23:26] <james_w> I'll probably revert that change to the factory, but leave it in STP, and then maybe go through another time and push it up in to the tests
[23:27] <wgrant> It doesn't.
[23:27] <wgrant> It'd need to forge a changesfile, for one thing.
[23:28] <james_w> sorry, I meant that Julian said that all test code should ensure that each SPR had a PU
[23:28] <james_w> though I may have misread
[23:29] <wgrant> james_w: Conflict resolution pushed, and the other two are OK.
[23:29] <wgrant> james_w: Most tests don't need a PU, so I don't see the point.
[23:30] <james_w> ok, I'll back that change out of the factory, but leave the behaviour of STP the same
[23:30] <james_w> this branch is already big enough as it is
[23:30] <wgrant> Yep.
[23:32] <lifeless> wgrant: so packagepublication
[23:32] <wgrant> lifeless: You mean publishedpackage?
[23:32] <lifeless> wgrant: can you suggest, in bug ..
[23:32] <lifeless> wgrant: yes
[23:32] <lifeless> https://bugs.edge.launchpad.net/malone/+bug/602360
[23:32] <lifeless> and
[23:32] <_mup_> Bug #602360: timeout on source package bug filing page <timeout> <Launchpad Bugs:Triaged> <Ubuntu:Invalid> <https://launchpad.net/bugs/602360>
[23:33] <lifeless> https://bugs.edge.launchpad.net/malone/+bug/609012
[23:33] <_mup_> Bug #609012: +distrotask timeout <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/609012>
[23:34] <lifeless> https://bugs.edge.launchpad.net/launchpad-answers/+bug/608037
[23:34] <_mup_> Bug #608037: timeouts in Question:+edit <oops> <timeout> <Launchpad Answers:Triaged> <https://launchpad.net/bugs/608037>
[23:34] <lifeless> all on the same unmaterialised view
[23:34] <lifeless> stub says 'nuke the use, or we have to materialise it.'
[23:34] <wgrant> So, anyone using that is probably buggy.
[23:34] <mwhudson> wgrant: my recipe build didn't build yesterday
[23:35] <mwhudson> it says 24 minutes to build now though!!
[23:35] <wgrant> lifeless: I need to leave in a sec, but I'll look on the train.
[23:35] <wgrant> mwhudson: Isn't the build farm great?
[23:35] <mwhudson> wgrant: it's certainly popular
[23:35] <lifeless> wgrant: thanks!
[23:36] <james_w> I have yet to have a recipe build
[23:36] <james_w> sorry, an automated recipe build
[23:36] <mwhudson> yeah certainly none of them
[23:37]  * wgrant → uni
[23:38] <sinzui> lifeless, I think the answers bug can be addresses by snapshots. I was going to work on it this or next weekend.
[23:39] <lifeless> sinzui: snapshots ?
[23:40] <sinzui> on a creation or change event objects  are snapshotted (copied) so that we can report changes to the object in logs and emails....
[23:41] <sinzui> lifeless, We often see non-intrinsic data, often lists in the snapshot that we know cannot have been changed.
[23:41] <lifeless> sinzui: oh right, so to paraphrase 'look at less data when snapshotting'
[23:41] <lifeless> not 'add a snapshotting facility'
[23:41] <lifeless> ?
[23:41] <sinzui> right. as a rule anything we export as a collection field should not be snapshotted
[23:42] <lifeless> sinzui: that would be cool
[23:42] <lifeless> sinzui: I was simply correlating the same view showing up in lots of places
[23:43] <sinzui> ah
[23:43] <lifeless> lots of timeouts, I mean
[23:43] <sinzui> doNotSnapshot() is needed on lots of fields that cannot be directly modified on a object. We also use it when we see a shortlist exception
[23:44] <lifeless> is that a decorator ?
[23:45] <sinzui> no, it is a function we wrap around field
[23:45]  * sinzui looks for example
[23:45] <lifeless> I'll grep
[23:45] <lifeless> and follow my nose - thanks for telling me about it
[23:45] <sinzui> I used it recently to stop api timeouts working with teams
[23:47] <lifeless> should collections auto-do-this ?
[23:50] <thumper> lifeless: it shouldn't be updating the diff after it is merged
[23:51] <lifeless> thumper: I agree
[23:51] <thumper> lifeless: as in the code says it shouldn't
[23:51] <thumper> lifeless: so something strange happened
[23:51] <thumper> lifeless: probably a race condition
[23:52] <thumper> lifeless: branch pushed, update diff job created, merged, pushed, diff job runs