[00:32] <huwshimi> Do we use the main loggerhead branch in launchpad? Do we make any modifications to the template or is it just a vanilla deploy?
[00:33] <lifeless> huwshimi: no, yes
[00:33] <lifeless> huwshimi: I want yours and sinzuis opinion on this actually
[00:33] <lifeless> I'd love it if we used releases without modifications, and did our tweaks outside the loggerhead tree
[00:35] <lifeless> huwshimi: theres a merge proposal / bug that shows the upstream loggerhead theme, and ours.
[00:36] <lifeless> huwshimi: do we need a custom theme, or perhaps we should just run the original - thats even simpler than doing some custom css for it in our tree and glueing them together.
[00:37] <huwshimi> lifeless: Do you know which bug that is?
[00:37] <lifeless> not offhand
[00:37] <lifeless> start with launchpad-project/+activereviews
[00:37] <lifeless> follow the loggerhead mps, you'll find it pretty quickly
[00:38] <huwshimi> lifeless: I don't really know the history of loggerhead. Is it mostly just a launchpad project and therefore we can do what we like with the main branch?
[00:38] <lifeless> no
[00:38] <lifeless> its a bzr community project we earnt commit rights too
[00:38] <lifeless> and was then abandoned upstream, so was adopted by mwhudson/lp-code for a while
[00:38] <lifeless> then he left and they lost cycles
[00:39] <lifeless> most recently, flacoste, poolie and I agreed that the LP team will maintain it, as we maintain lazr-js etc
[00:39] <lifeless> which means:
[00:39] <lifeless>  - do the right thing for it
[00:39] <lifeless>  - fix bugs affecting us in sensible ways
[00:39] <lifeless>  - do code review and bug triage for contributions by other users, whatever the their purpose
[00:42] <huwshimi> lifeless: OK, so I've been tasked with making it look like Launchpad. Somehow I need to do that in a way that is maintainable.
[00:44] <lifeless> huwshimi: interesting, cool.
[00:44] <lifeless> huwshimi: so, we *could* change trunk to look like LP
[00:44] <lifeless> huwshimi: but if we do that, we should still keep it looking and feeling nice for standalone users.
[00:44] <poolie> hi lifeless
[00:45] <poolie> re removing the oauth.py copy and using the system one instead:
[00:45] <lifeless> huwshimi: And we'd not want to have assests that prevent it being easily deployed.
[00:45] <lifeless> huwshimi: we can definitely add dependencies on this that LP also uses if that helps
[00:46] <lifeless> huwshimi: we can also make it more modular/pluggable and change out integration glue
[00:46] <poolie> do you know how i persuade buildout to import oauth from the system pythonpath, rather than trying to get it from an egg?
[00:47] <lifeless> poolie: it should just do it; make sure to remove the existing egg and tarball
[00:47] <huwshimi> lifeless: If it is a separate entity it probably shouldn't change design every time LP does. But having said that if it is our devs doing all the work then they would have to maintain two sets of templates/css.
[00:47] <lifeless> huwshimi: it is our devs
[00:48] <poolie> hm apparently not http://pastebin.ubuntu.com/566810/
[00:48] <poolie> maybe there's still something cached somewhere that makes it think so?
[00:49] <huwshimi> lifeless: So doing it in trunk means less work, but means we can't have any LP specific stuff right?
[00:49] <lifeless> did you delete the eggs/oauth* dirs ?
[00:49] <wgrant> poolie: Ah, give up now.
[00:50] <wgrant> You have to use the egg.
[00:50] <wgrant> Since our other eggs require it.
[00:50] <lifeless> wgrant: EWHAT
[00:50] <wgrant> Ah, lazr.restfulclient doesn't actually require a particular version.
[00:51] <wgrant> So you may be able to make it happy with the system version.
[00:51] <lifeless> huwshimi: so, the constraint is 'trunk must still be a viable standalone code browser'
[00:51] <lifeless> huwshimi: that doesn't mean 'no lp stuff' but its likely easiest to frame it that way
[00:52] <lifeless> huwshimi: *however* we can quite straightforwardly make hook points that our glue in lib/launchpad_loggerhead uses to combine with the generic stuff in trunk
[00:52] <wgrant> poolie: Perhaps try lifeless' suggestion of removing the built eggs. But I don't like your chances; I've given up trying to fix things like this before.
[00:53] <lifeless> huwshimi: that is a little more engineering, but certainly not twice.
[00:54] <huwshimi> lifeless: How does this decision get made?
[00:54] <poolie> wgrant, thanks for the advice
[00:54] <lifeless> huwshimi: engineers doing the work
[00:54] <poolie> seeing as it's only removal of cruft my perseverence is not going to be very high
[00:54] <poolie> it's just a principle thing
[00:55] <wgrant> Heh.
[00:55] <wgrant> buildout gets a bit messy sometimes :/
[00:57] <thumper> wgrant: hey
[00:57] <thumper> wgrant: I'm going through your review comments
[00:57] <thumper> wgrant: it isn't very easy to use the same text in the initial form
[00:57] <thumper> wgrant: I have changed to "Built daily" rather than "Build daily" though
[00:59] <wgrant> thumper: Hmm.
[00:59] <wgrant> I still do not like the two completely different UIs.
[00:59] <thumper> wgrant: the original form had "Built daily" with a checkbox
[00:59] <thumper> wgrant: it was changed to make it more descriptive
[01:00] <thumper> wgrant: I suppose we could change it back and add the help link
[01:00] <thumper> wgrant: what do you think?
[01:00] <wgrant> thumper: I think that would be best.
[01:00]  * thumper goes to poke the code
[01:01] <wgrant> Except in that case it could possibly be better as "Build daily"
[01:01] <wgrant> We have no definition that I can see for the style of checkbox labels.
[01:03] <thumper> wgrant: what do you mean?
[01:05] <thumper> :(
[01:05] <thumper> not a fan of the boring grey titles
[01:06] <wgrant> thumper: Some of our checkbox labels are imperative, others indicative.
[01:06] <wgrant> It makes me sad.
[01:06] <poolie> turning into mpt?
[01:06] <poolie> wbn to have a style guide for that
[01:06] <thumper> someone needs to make sure we're consistent
[01:06] <thumper> I think we did have a style for it
[01:06]  * thumper goes to look
[01:07] <wgrant> Uhoh.
[01:07] <wgrant> Debian is considering source-only uploads again.
[01:08] <thumper> wgrant: what is the impact of that?
[01:08] <wgrant> thumper: Flamewars, probably.
[01:08] <wgrant> Ubuntu has mandated source-only uploads from day 1.
[01:08] <wgrant> Someone in Debian proposes it every so often.
[01:09] <wgrant> But it inevitably gets nowhere.
[01:09] <wgrant> Besides massive threads.
[01:09] <thumper> wgrant: https://dev.launchpad.net/UserInterfaceWording is the page, feel free to edit
[01:10] <wgrant> thumper: It's not very thorough, unfortunately.
[01:10] <wgrant> We need UI review :(
[01:10] <wgrant> eg. http://blog.launchpad.net/
[01:10] <poolie> i get the same problem even with my entire egg directory deleted
[01:10] <wgrant> Look at that first image.
[01:10] <wgrant> poolie: What if you remove the egg from download-cache?
[01:11] <poolie> for oauth?
[01:11] <wgrant> Yeah.
[01:11] <poolie> i think i already did that
[01:11] <wgrant> So buildout cannot find it.
[01:11] <poolie> hm, maybe not
[01:12] <poolie> wgrant, the full stop at the end of the line?
[01:12] <wgrant> poolie: Yes.
[01:13] <wgrant> They are little things.
[01:13] <poolie> with the ironic red arrow?
[01:13] <wgrant> But they make the UI look far more awful than it actually is.
[01:14] <poolie> i think we need ui review in the sense that everybody checks for it
[01:14] <wgrant> Indeed.
[01:14] <poolie> also, how ironic to get so many mp reviews about missing full stops in comments, and for this to get through in the ui
[01:14] <wgrant> Heh.
[01:15] <poolie> this may be an instance of a kind of thing that is easier to spot in review in a screenshot
[01:15] <poolie> or maybe not
[01:16] <poolie> but the punctuation perhaps stands out more from the code punctuation there
[01:16] <wgrant> Apparently not.
[01:16] <wgrant> Because there is a screenshot.
[01:16] <poolie> on the mp?
[01:16] <poolie> ah :)
[01:16] <wgrant> I'm not sure if there was one there.
[01:17] <wgrant> thumper: What's the easiest way to force failed scans to be retried?
[01:17] <thumper> wgrant: lock and unlock the branch
[01:17] <wgrant> thumper: There are a few hundred.
[01:17] <wgrant> Is that still the easiest way?
[01:17] <thumper> wgrant: I have a simple plugin that allows me to do that
[01:17] <thumper> um...
[01:17] <thumper> why did they fail?
[01:17] <wgrant> This is from the package-import incident last week.
[01:17] <wgrant> Which exposed the bzr stacking bug.
[01:18] <poolie> ok, even with the download cache and all the eggs deleted, it still fails with "We have no distributions for oauth that satisfies 'oauth'"
[01:18] <lifeless> there is an API to force a scan isn't there ?
[01:18] <poolie> i looked for buildout documentation about this but i couldn't find any
[01:18] <wgrant> lifeless: Does requestMirror still work?
[01:18] <wgrant> I don't really recall.
[01:18] <lifeless> poolie: is this in a clean tree ?
[01:19] <thumper> wgrant: if you want to use launchpadlib, I think there is a method
[01:19] <thumper> no, requestMirror doesn't work
[01:19] <wgrant> :(
[01:20] <poolie> lifeless, as in ' make clean'd tree?
[01:20] <lifeless> no, as in freshly branched
[01:20] <lifeless> or bzr remove-tree and then checkout again, kindof thing
[01:20] <thumper> wgrant: it is the branchChanged method, which is triggered by the unlock code
[01:20] <thumper> wgrant: and nothing is exposed over the api
[01:20] <lifeless> poolie: I think you're well past diminishing returns
[01:21] <thumper> wgrant: what I did was to get a list of the failed branches, and wrote a bash loop to process them with 'bzr rescan'
[01:21] <thumper> wgrant: which takes advantage of my bzr-expert privileges
[01:21] <wgrant> Yeah.
[01:21] <wgrant> Can I give you a list of branches?
[01:22] <thumper> wgrant: sure
[01:22] <thumper> wgrant: pastebin?
[01:22] <wgrant> poolie: Could you requeue the top p-i failure? 92 packages failed due to some unidentified librarian breakage for ~20 minutes yesterday.
[01:22] <wgrant> thumper: Gimme a sec.
[01:22] <wgrant> Hopefully I can grep it out.
[01:24] <poolie> lifeless, you mean well past this being sufficiently easy to clean up that it's worth doing?
[01:24] <poolie> i agree
[01:24] <lifeless> yes
[01:24] <poolie> regretfully
[01:24] <poolie> ok
[01:24] <poolie> i shall abandon it and explain where i got to
[01:26] <poolie> pisses me off to have it be so hard to remove copy and paste though
[01:26] <lifeless> agreed
[01:26] <poolie> but, i shall be po'd about something more important
[01:27] <lifeless> this is the problem with having 4 different dep systems in play
[01:27] <poolie> wgrant, will do
[01:27] <poolie> right
[01:27] <poolie> wgrant, actually for the sake of proceeding towards handoff, let's ask a losa (spm?) to do it instead, and i'll help
[01:27] <wgrant> poolie: I would, except spm seems to be even more excessively busy than normal.
[01:27] <lifeless> u1 melted down in the weekend
[01:28] <wgrant> Again.
[01:28] <lifeless> no
[01:28] <lifeless> uniquely
[01:28] <wgrant> Oh.
[01:28] <wgrant> Awesome.
[01:28] <poolie> i came in this morning to have all my tomboy notes conflicted
[01:28] <lifeless> I doubt he'll have time for anterior irritation amelioration today
[01:29] <lifeless> or posterior :P
[01:32] <poolie> wgrant, hm, so that's kind of a problem if we're not going to be able to do it without them in future
[01:32] <poolie> anyhow
[01:33] <wgrant> poolie: Well, we are getting lots of new LOSAs :)
[01:33] <poolie> indeed
[01:33] <poolie> that's 92 packages failed with key bzrlib.errors.InvalidHttpResponse
[01:33] <poolie> is this a bug for it?
[01:34] <poolie> i guess it was just an lp operational glitch?
[01:34] <wgrant> The librarian was half-broken for a while.
[01:34] <poolie> maybe udd should retry it
[01:34] <wgrant> No idea why.
[01:34] <wgrant> RIght.
[01:34] <wgrant> I'd requeue_package --auto it
[01:38] <maxb> Sourceforge have fixed their svn ssl cert, happily
[01:38]  * maxb is restarting imports
[01:42] <poolie> https://bugs.launchpad.net/udd/+bug/718483
[01:42] <_mup_> Bug #718483: should delay and retry on http 503 from librarian <Ubuntu Distributed Development:Triaged> < https://launchpad.net/bugs/718483 >
[01:43] <poolie> oh, will --auto be enough maybe?
[01:43] <wgrant> I think so.
[01:45] <poolie> ok done
[01:45] <wgrant> thumper: http://paste.ubuntu.com/566819/ should be most of them.
[01:45] <thumper> wgrant: http://people.canonical.com/~tim/new-recipe-built-daily.png
[01:46] <wgrant> thumper: I'm not sure if the (?) belongs on the title or description. But that looks fine.
[01:47] <wgrant> Consistency in terminology is the main thing.
[01:48] <thumper> ok
[01:49] <thumper> hmm... almost time to collect mini-mes
[02:10] <lifeless> grah
[02:10] <lifeless> these bug search pages are scary messy
[02:21] <wgrant> The code behind them?
[02:21] <lifeless> the structure & code
[02:21] <lifeless> bug 717394
[02:21] <_mup_> Bug #717394: Distribution:+bugs timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/717394 >
[02:22] <lifeless> 3.5 seconds overhead on every ubuntu bug search, the results are effectively constant
[02:25] <wgrant> thumper: Did you have any luck with rescanning those branches?
[02:25] <thumper> wgrant: yep, over 100 triggered so far
[02:25] <thumper> it is a little slow as there are 14 vfs calls
[02:25] <wgrant> Ouch.
[02:25] <wgrant> Thanks.
[02:44] <thumper> wgrant: all rescans initiated
[02:45] <poolie> wgrant, re your comment on bug 716175
[02:45] <_mup_> Bug #716175: api calls fail while launchpad is readonly <Launchpad itself:Triaged> < https://launchpad.net/bugs/716175 >
[02:45] <poolie> (i ask only for my education; i'm happy to leave it low)
[02:45] <poolie> the "consumer check" is to do with the oauth validation?
[02:45] <wgrant> poolie: Yes.
[02:46] <wgrant> Even for anonymous requests it does a consumer lookup.
[02:46] <poolie> is this the kludge that we create a temporary login for anonymous requests?
[02:46] <wgrant> Possibly to allow us to blacklist.
[02:46] <poolie> why does it do that?
[02:47] <wgrant> So we can kill off misbehaving applications, I guess.
[02:54] <LPCIBot> Yippie, build fixed!
[02:54] <LPCIBot> Project db-devel build (363): FIXED in 5 hr 41 min: https://hudson.wedontsleep.org/job/db-devel/363/
[03:38] <wgrant> thumper: Still around?
[03:39] <lifeless> we have a very spec compliant oauth implementation
[03:39] <lifeless> the standard solves problems we don't have
[03:39] <wgrant> Oh?
[03:40] <lifeless> you can do a much more direct solution to the 'hand out a cookie to login a client' problem
[03:41] <lifeless> doing nonces in a layer on top of http is rather gruesome
[03:44] <wgrant> Archive:+index is looking reasonably healthy now.
[03:44] <wgrant> Might almost deserve to have its timeout override removed.
[03:56] <wgrant> huwshimi: Do you have a plan for desaturating the buttons?
[03:56] <wgrant> There are still 1.0-style large buttons around in the facet colours.
[03:56] <wgrant> They have been deprecated for years, but are still used.
[03:56] <huwshimi> wgrant: Where abouts are they?
[03:58] <wgrant> Hmm. They're in the facet colours, but they don't seem to all correspond to the relevant facet. https://code.staging.launchpad.net/ has a few.
[03:58] <huwshimi> wgrant: Ah yes;
[03:58] <wgrant> They look very odd now that everything else is grayscale.
[03:59] <huwshimi> wgrant: Well not *everything* is greyscale :)
[03:59] <wgrant> Ahhh, they actually are app colours.
[03:59] <wgrant> But Code uses them inappropriately.
[03:59] <huwshimi> wgrant: but yes, they do need some love
[03:59] <wgrant> There are 6 left.
[04:02] <wgrant> Time for another icing purge, I think.
[04:08] <lifeless> wgrant: so where is your target brnach?
[04:10] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/stop-using-targetnamecache
[04:10] <wgrant> But alone it is not enough to disable the script, unless we want to take it out temporarily and hope that nobody notices sort drift while my rewrite makes it through the system.
[04:21] <wgrant> Wow, Distribution:+search is quite a piece of work.
[04:29] <lifeless> whats the name of the feature flag context manager
[04:31] <wgrant> I only know of FeatureFixture.
[04:33] <wgrant> thumper: When you're back, could you try rescanning one of the branches, to check that our DB purge worked?
[04:53]  * lifeless does a naughty
[04:53] <poolie> wgrant, that's the only contextmgr i know of too
[04:54] <poolie> wallyworld, it seems to me there's a bit of a split here (in qatagger) between
[04:54] <poolie> trying to get the right accurate model, which probably requires adding features to lp
[04:54] <wgrant> https://lpstats.canonical.com/graphs/LaunchpadOpenBugs/20100215/20110215/ says launchpad has like 9600 bugs open.
[04:54] <wgrant> https://bugs.launchpad.net/launchpad says 5800.
[04:55] <poolie> vs just something pragmatic that people can use
[04:55] <lifeless> wgrant: heh
[04:55] <poolie> wgrant, one difference, though I don't know if it would account for all of them, is that lpstats tends to include private bugs
[04:55] <lifeless> wgrant: also, https://bugs.launchpad.net/launchpad-project is what we need to look at.
[04:55] <poolie> even private bugs nobody on the team can see
[04:55] <wgrant> lifeless: I know, but that's only 1000 more.
[04:55] <wallyworld> poolie: sorry to cut you off - i am just going to get Lachie from school - running late. i'll talk to you when i'm back
[04:55] <poolie> np, no rush
[04:57] <wgrant> Ah
[04:57] <wgrant> Does not exclude dupes.
[05:00] <wgrant> poolie: What's happening with the forking debugging?
[05:00] <wgrant> Do we know what's happening, or should I land the cowboy to turn it off?
[05:09] <wgrant> Who moderates blog comments? There are a couple waiting, and I'm wondering if I should approve them as I see them.
[05:09] <LPCIBot> Yippie, build fixed!
[05:09] <LPCIBot> Project devel build (438): FIXED in 5 hr 40 min: https://hudson.wedontsleep.org/job/devel/438/
[05:18] <poolie> wgrant, i can moderate them
[05:18] <poolie> you should be able to too?
[05:19] <poolie> wgrant, i presume jam is going to look at the data on the bug, if any
[05:19] <wgrant> poolie: I can, but I wonder if I should.
[05:19] <poolie> too late!
[05:20] <poolie> but, generally
[05:20] <poolie> they were obviously not spam
[05:20] <poolie> i don't see any benefit in sitting on them
[05:20] <poolie> if in doubt about the policy, talk to someone else
[05:20] <poolie> i think the more we post the better
[05:20] <thumper> wgrant: which one
[05:20] <wgrant> thumper: Any of them.
[05:20] <wgrant> thumper: They all failed again.
[05:20] <thumper> :(
[05:21] <wgrant> thumper: Bug #718511
[05:21] <_mup_> Bug #718511: Failed initial scans require manual cleanup <branch-scanner> <Launchpad itself:Triaged> < https://launchpad.net/bugs/718511 >
[05:21] <thumper> what cleanup?
[05:21] <wgrant> poolie: I agree.
[05:21] <wgrant> thumper: Deleting the branchrevisions.
[05:21] <wgrant> Which we have done.
[05:21] <thumper> wgrant: lp:debian/wheezy/php-xml-htmlsax3
[05:22] <wgrant> Thanks.
[05:22]  * thumper has to make dinner for hungry munchkins
[05:22] <thumper> wgrant: if you want the rest poked, let me know and I'll kick it again
[05:22] <wgrant> thumper: You will hopefully be poked in a couple of minutes. Thanks.
[05:23] <wgrant> thumper: Consider yourself poked.
[05:24] <wgrant> It worked, thanks.
[05:24] <wgrant> And p-i only has 72 jobs remaining.
[05:24] <wgrant> Excellent.
[05:41] <wallyworld> poolie: wrt qa tagging, the two goals you mentioned - accurate model and easy to use - don't have to be mutually exclusive :-)
[05:44]  * thumper pokes the script again
[05:44] <thumper> script is running
[05:44] <wgrant> Thanks.
[05:47] <wgrant> It's working.
[05:57] <huwshimi> lifeless: Really like the queries time indicator. I have a question though. Every document load (before images, javascript, css etc.) takes about 2.5 seconds longer than the query time. Is that just the time it takes to execute the files, render the templates etc?
[05:58] <lifeless> huwshimi: we are currently 100% overcommitted in the datacentre
[05:58] <lifeless> huwshimi: so things are queueing a page in advance, and thats within 3 seconds, 99% of the time
[05:59] <lifeless> huwshimi: its our top rt
[05:59] <lifeless> huwshimi: or approx; I'm going to pounce on mthaddon today to try and get it moving; we should have traction on it this weke
[06:00] <lifeless> huwshimi: bug 716760, which needs someone to grab it and run with it, is about measuring this gap
[06:00] <_mup_> Bug #716760: no measurement of in-datacentre queue timings <Launchpad itself:Triaged> < https://launchpad.net/bugs/716760 >
[06:00] <lifeless> huwshimi: (sort of actual transfer times)
[06:01] <huwshimi> lifeless: It's interesting, once you have one bit of information (the query times) readily available, you notice things.
[06:01] <lifeless> huwshimi: I mentioned that bug to stub, but I don't know if he's going to poke at it
[06:01] <lifeless> huwshimi: yes, continual partial attention
[06:02] <lifeless> huwshimi: I think it would be really excellent to also show the time after the initial document - time to get other assets, fire js etc etc
[06:02] <lifeless> huwshimi: I expect a similar psychological effect
[06:03] <huwshimi> lifeless: For example on the lp.net homepage about 75% of our load time is that load overhead (the queries, js, images etc. load in the other 25%)
[06:17] <lifeless> wgrant: bug 31820
[06:17] <_mup_> Bug #31820: mysterious exception during accept on ltsp 0.75 <lp-soyuz> <soyuz-upload> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/31820 >
[06:17] <lifeless> wgrant: wtf
[06:19] <wgrant> lifeless: Probably librarian down.
[06:20] <lifeless> wgrant: any reason not to invalid it and wait for a reoccurence with diagnostics ?
[06:21] <wgrant> lifeless: I doubt it.
[06:35] <wgrant> thumper: lp:debian/wheezy/libjconv lp:debian/wheezy/atom4 lp:debian/wheezy/netrek-client-cow
[06:35] <wgrant> lp:debian/wheezy/biosquid lp:debian/wheezy/quilt
[06:35] <wgrant> thumper: I missed those five. All the rest are scanned, though.
[06:38] <thumper> wgrant: doing those now
[06:38] <wgrant> thumper: Thanks.
[06:38] <wgrant> p-i should finish in a couple of minutes.
[06:41] <wgrant> thumper: Thanks, all scanned successfully.
[06:51] <wgrant> poolie: Apart from nexuiz-data, we appear to be done.
[06:51] <wgrant> Everything is scanned, p-i processing new Ubuntu uploads.
[06:52] <poolie> hooray
[06:53] <wgrant> poolie: Except https://code.launchpad.net/~ubuntu-branches/debian/wheezy/xserver-xorg-video-voodoo/wheezy
[06:53] <wgrant> Created, but unlinked and unpushed.
[06:54] <wgrant> Ah, the squeeze branch is pack-0.92!?
[06:55] <wgrant> Yeah, we have some rich-root-pack branches.
[06:55] <wgrant> How very odd.
[07:36] <lifeless> Ursinha: hi
[07:36] <lifeless> bug 718566 should be on loggerhead not launchpad
[07:36] <_mup_> Bug #718566: DatabaseError on loggerhead trying to view a revision on staging <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/718566 >
[07:37] <Ursinha> lifeless, hello
[07:38] <Ursinha> yes, I know
[07:38] <Ursinha> am changing right now
[07:38] <lifeless> coolio :)
[07:38] <Ursinha> oh, I like the query count on the top
[07:38] <lifeless> Ursinha: excellent
[09:02] <mrevell> Hey
[09:03] <_starbuck> morning mrevell
[09:03] <mrevell> _starbuck, Nice nick
[09:04] <_starbuck> :)
[09:04] <_starbuck> thanks
[09:05] <adeuring> good morning
[09:11] <al-maisan> moin adeuring
[09:11] <adeuring> salü al-maisan!
[09:28] <bigjools> Ursula has gone all BG on us
[09:32] <spiv> Would some kind lp committer please shove https://code.launchpad.net/~spiv/launchpad/haproxy-for-twisted-services/+merge/48427 at ec2test or whatever the next step is?
[09:36] <lifeless> ERROR:qa-tagger:Something went wrong when marking bugs: 'LPQAStagingDeployment' object has no attribute 'deployed_source_revno'
[09:52] <lifeless> wgrant: just bug 717363 needs qa and we can has deploy.
[09:52] <_mup_> Bug #717363: prf WalkerBase.walk can fail if self.open raises an exception <product-release-finder> <qa-needstesting> <Launchpad itself:Fix Committed by sinzui> < https://launchpad.net/bugs/717363 >
[09:52] <lifeless> night all
[09:56] <allenap> Cheerio lifeless .
[10:27] <LPCIBot> Project devel build (439): FAILURE in 5 hr 18 min: https://hudson.wedontsleep.org/job/devel/439/
[10:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][no-qa] Use the new, correct lazr.restful-0.16 egg.
[10:27] <LPCIBot> * Launchpad Patch Queue Manager: [rs=wgrant][rollback=12363] Revert r12363. The extra subquery makes
[10:27] <LPCIBot> bug searches perilously slow for non-registry-admins.
[10:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=benji, bac][bug=717363] Recover from an open() failure when the
[10:27] <LPCIBot> product-release-finder calls walk().
[10:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=68203] Do not accept whitespace comments when
[10:27] <LPCIBot> reporting a bug.
[10:36] <bigjools> dpm: hi, around?
[10:37] <dpm> hi bigjools
[10:37] <bigjools> dpm: hi - do you admin the ubuntu-translators list?
[10:37] <dpm> yes
[10:38] <bigjools> dpm: great - can you please unsubscribe help (at) launchpad.net, or it might be launchpad-help at canonical .com
[10:39] <wgrant> Could also possibly be feedback@
[10:39] <stub> lifeless: What got patch-2208-41-0.sql ?
[10:39] <bigjools> not according to the mail headers
[10:42] <dpm> bigjools, done
[10:42] <bigjools> dpm: awesome, thanks
[10:42] <dpm> np
[10:42] <bigjools> yay for less email
[10:46] <stub> bigjools: Any fallout from switching to debversion? There are other places in our schema we could switch too (eg. ProductSeries.name and other places with version_sort_key indexes)
[10:46] <bigjools> stub: no, swimmingly well actually
[10:47] <bigjools> seems a lot faster
[10:47] <stub> Ta
[10:48] <bigjools> Archive:+index has fallen out of the top 10 timed-out pages \o/
[10:48] <wgrant> 99% @ 9.67
[10:49] <bigjools> details details :)
[10:49] <wgrant> Which is >3s better than before
[10:49] <bigjools> the debversion thing plus some other improvements I made have helped a lot
[10:49] <wgrant> Yup.
[10:49] <wgrant> We have lost a few thousand soft timeouts a day :)
[10:50] <bigjools> well the latest report is for the weekend which is not as busy, let's see tomorrow's
[10:50] <wgrant> True.
[10:52] <bigjools> wgrant: so, the last soyuz-report cleanup we can do is to turn the routine errors into non-oops
[10:53] <wgrant> bigjools: Right.
[10:53] <wgrant> The key errors.
[10:53] <bigjools> FatalUploadError etc
[10:53] <wgrant> Although I'm not sure about that NoneType has no email thing.
[10:53] <wgrant> Is that the account/person mess again?
[10:53] <bigjools> don't see that
[10:54] <wgrant> 2 occurrences on the 11th.
[10:54] <wgrant>         OOPS-1868PPA545, OOPS-1868PPA546
[10:54] <bigjools> could be
[10:55] <bigjools> wgrant: your config changes seem ok then, I think
[10:55] <wgrant> bigjools: Thanks.
[10:55] <wgrant> It makes the inheriting configs much simpler.
[10:56] <bigjools> FSVO
[10:56] <henninge> jtv: Any news on my MP?
[10:56] <wgrant> The diff is bad. But the configs are nice.
[10:56] <bigjools> who can I assign loggerhead questions to?
[10:56] <wgrant> It's LP-maintained now.
[10:56] <wgrant> So your squad :)
[11:03] <jtv> henninge: no, was trying to figure out the XPI bug.  But I can get back to your MP if it's urgent.
[11:03] <jtv> There was some mention of it not being critical any more.
[11:03] <jtv> Does that still apply?
[11:04] <henninge> jtv: it's not release-critical anymore because we had the release
[11:04] <henninge> jtv: the bug still is and re-enabling Ubuntu imports depend on it.
[11:05] <henninge> Yes, it is urgent. ;-)
[11:05] <jtv> Ah!
[11:05] <jtv> henninge: in that case,
[11:06] <jtv> —why do you skip unreadable/nonexistent files instead of requiring the user to get their act in order?
[11:06] <jtv> — why do you require a distroseries to be specified among the options but assume a distroseries to be specified?
[11:07] <jtv> — where does the circular import on IDistributionSet come from, since this is a script?
[11:08] <henninge> jtv: as mentioned, this is adapted from reupload-imports
[11:09] <henninge> I had meant the script for my personal benefit initially but thought it might be useful for others, too.
[11:09] <henninge> So, the answer to the first question is "to keep it simple" but I guess a warning would be appropriate.
[11:10] <jtv> henninge: there is a warning, but it doesn't say what the problem is.  I say just dump the check.
[11:10] <henninge> The answers to the other two are: "Because I copied that from the originial script.
[11:10] <henninge> I like robust scripts, though.
[11:11] <jtv> henninge: I don't recall off the top of my head but there may be a way to specify to optparse that a particular option is required.
[11:11] <jtv> Typo in the test: is_trackging
[11:14] <jtv> henninge: also, a copyright notice of 2009 on a new script in scripts/rosetta/ may be taking "adapting the existing script" a bit far.  :)
[11:14] <henninge> I agree ...
[11:19] <jtv> henninge: doesn't is_upstream_import_on_sourcepackage duplicate logic you had somewhere else?
[11:19] <jtv> I thought you already implemented that part.
[11:19] <henninge> no, I don't think so.
[11:20] <jtv> Then sorry—wasn't sure so I thought I'd ask.
[11:20] <jtv> Oh, there's a misplaced import in there.
[11:20] <allenap> Does anyone know if the bug expiry stuff is meant to be running now?
[11:20] <jtv> henninge: lines 777—778 of the diff
[11:20] <henninge> jtv: you already reviewed this code, so maybe you are remembering that.
[11:20]  * henninge looks
[11:20] <jtv> ohhh could be
[11:20] <stub> bouncy bouncy
[11:22] <henninge> jtv: hm, I think I had circular problems on that one but I can check that again.
[11:23] <jtv> henninge: even then, please move it to the top of the method and comment it.
[11:24] <jtv> henninge: I'm having trouble figuring out what exactly _makeMessages in the test is supposed to do.  It crams a lot of scenarios into one method and it's not clear to me how the parameters are meant to interact.
[11:27] <henninge> hm, does the docstring not help?
[11:27] <jtv> That's after reading the docstring!
[11:27] <henninge> Maybe I should add that is_tracking only makes sense if the other two are False?
[11:28] <henninge> I had tried to think of other interfaces for the method but this was the best I could come up with.
[11:28] <jtv> Why not have multiple methods?
[11:29] <jtv> I mean, it helps to know that is_trackging doesn't combine, but it'd help more to have smaller and more self-evident chunks.
[11:29] <jtv> Also, what's "this message" in the docstring?
[11:36] <henninge> sorry, got called to the door
[11:37] <henninge> jtv: there is a finite permutation of possible combinations that the method I am testing has to deal with.
[11:37] <henninge> I had a table on paper and tried to have something else in code.
[11:38] <henninge> Maybe I should change it to not use the tri-state bools.
[11:40] <jtv> Well more parameters probably aren't the answer either.  The method already spends a fair portion of its space just trying to figure out what it was that the caller requested.
[11:40] <jtv> Can't you do something along the lines of "makeIdenticalUpstreamMessage"?
[11:42] <jtv> The tests themselves look good, by the way—nice and thorough, well-documented.
[11:43] <jtv> (repeated typo in the tests: identcal)
[11:44] <jtv> They're also nice and concise.
[11:47] <wgrant> Hahaha
[11:47] <wgrant> real	1m4.066s
[11:47] <wgrant> Down from 18 hours.
[11:47] <jtv> wgrant: what is?
[11:47] <wgrant> jtv: update-bugtask-targetnamecaches.py
[11:47] <jtv> wgrant: add some sleep()s to avoid surprises.
[11:48] <jtv> Also, nice cache of future "optimizations" for those lazy days.
[11:48] <wgrant> Indeed.
[11:51] <henninge> jtv: expanded docstring
[11:51] <henninge> http://paste.ubuntu.com/566935/
[11:51]  * jtv looks
[11:52] <henninge> jtv: I guess I could use _makeUpstream, _makeUbuntu and _makeSuggestion methods and pass other messages as is_identical into it.
[11:53] <henninge> s/method/message/ on line 21 of that paste
[11:53] <jtv> henninge: I think it'd be better to split it up, yes.
[11:54] <henninge> I will have to carry pofile and potmsgset around which I was trying to avoid ...
[11:55] <jtv> henninge: yes, that is a bit of pain.  But I suppose potmsgset would be implicit in the TM in most places.
[11:55] <henninge> yes, I was just thinking about that.
[12:00] <deryck> Morning, all.
[12:00] <henninge> Hey deryck!
[12:00] <jtv> hi deryck
[12:06] <wgrant> henninge: Can I throw a review your way?
[12:06] <henninge> wgrant: sure but please don't aim for any tender parts ...
[12:07] <wgrant> henninge: https://code.launchpad.net/~wgrant/launchpad/bug-718004-rewrite-targetnamecache/+merge/49612
[12:08] <stub> yay 70% packet loss between ISP and the USA. Think I'll go read a book.
[12:31] <henninge> wgrant: That looks very good. Is it ok for you, though, if I finish this after lunch?
[12:32] <wgrant> henninge: I'm about to vanish for the night, so I won't be around, but that's fine.
[12:32] <henninge> wgrant: ok, g'night ;)
[12:33] <wgrant> henninge: Thanks for reviewing.
[13:14] <gary_poster> deryck, I figure if I exposed my ignorance enough I'd force someone, probably you, to respond :-) thanks, and I look forward to the "now this is what to do" email ;-)
[13:14] <deryck> heh
[13:14] <deryck> gary_poster, actually, I think bac is doing the right thing ;)
[13:14] <deryck> finishing that reply now
[13:15] <gary_poster> heh, ok cool, deryck, thanks
[13:22] <adeuring> henninge-lunch: could you have another look at https://code.launchpad.net/~adeuring/launchpad/bug-702468/+merge/49205 ?
[13:22] <bac> thanks deryck.  i was hoping you'd give your 2 cents.
[13:23] <bac> gary_poster: are you fixing my blog post?
[13:24] <bac> mrevell-lunch: does the 'front-page' *category* not put it on launchpad.net?  you have to add a tag?
[13:24] <mrevell> bac, Yeah, it's a tag, rather than a category
[13:24] <bac> what does the category do?
[13:24] <gary_poster> bac, I was approving a comment, and was going to ask if you wanted me to meddle.  I approved it, and now I'll leave the rest alone for you :-)
[13:24] <bac> can we get rid of that one as it confuses people like me
[13:25] <bac> mrevell: ^^
[13:25] <bac> gary_poster: thanks
[13:25] <gary_poster> np
[13:26] <bac> mrevell: do all comments have to be moderated?
[13:27] <mrevell> bac, I didn't know there was a front-page category. Sure, let's kill it. As for comments ... from new people they do.
[13:27] <mrevell> Once you've had one comment approved, it's open season.
[13:27] <bac> mrevell: thanks
[13:31] <LPCIBot> Project db-devel build (365): FAILURE in 2 hr 51 min: https://hudson.wedontsleep.org/job/db-devel/365/
[13:31] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12370,
[13:31] <LPCIBot> 12371, 12372 included.
[13:51] <jtv> crazy busy day
[13:54] <jtv> henninge-lunch: test_accept_upstream_no_ubuntu says: "If there was already an upstream translation, but no ubuntu one, the suggestion replaces both."  There is only one translation to replace, of course; and might it be better to say "accepting the suggestion" rather than "the suggestion"?
[13:57] <pindonga> I was wondering, how do you manage to automatically sign the deb packages created from recipes? (ie, without the user entering his passphrase?)
[13:57] <pindonga> I'm trying to achieve this myself, but on a local machine
[13:58] <maxb> pindonga: The signing keys of PPAs are stored by Launchpad. Not even the owner of the PPA has access to the private key.
[13:59] <pindonga> maxb, so you have a script that does the signing
[13:59] <pindonga> I'm using bzr dailydeb
[13:59] <pindonga> and I want to automate the signing of the packages I create
[13:59] <pindonga> you know any way I could do?
[14:00] <maxb> In the way you mean, packages are not signed.
[14:00] <maxb> Apt archives are what is signed
[14:00] <pindonga> this is essentially for a plugin for tarmac I'm building
[14:00] <maxb> What software are you using to build the Release and Packages files?
[14:01] <pindonga> maxb, when I run bzr dailydeb and use the dput option it will push the dsc/changes stuff to launchpad
[14:01] <deryck> henninge, abentley, adeuring -- coming, sorry.  2-3 more minutes.
[14:01] <pindonga> for that it will sign the package
[14:01] <pindonga> sorry, not pacakge
[14:01] <pindonga> but changes/dsc files
[14:01] <pindonga> I was wondering if there is a way to have the credentials stored in a way that doesn't require the user to put it in
[14:02] <pindonga> bzr dailydeb uses debsign internally to sign the files
[14:02] <jml> !!!
[14:02] <maxb> Whether or not you have a passphrase set on the key is your own decision.
[14:03] <pindonga> max, ah, so if I create a key without a passphrase that should work
[14:03] <maxb> Obviously an unprotected key that enables any possessor to impersonate you to Launchpad is a dangerousl thing
[14:03] <pindonga> maxb right
[14:03] <jml> http://paste.ubuntu.com/566971/
[14:03] <maxb> pindonga: I think we should continue this on #launchpad, as it is not -dev related
[14:04] <pindonga> maxb, sure
[14:04] <pindonga> thanks anyway
[14:11] <jtv> henninge: you have my vote—sorry for the delays.
[14:13] <jml> I just got this error when running a clean build of a branch.
[14:13] <allenap> bigjools: Have there been any problems recently when adding new builders? I think I've found a bug where the buildmaster will create a new SlaveScanner for new builders every 5 minutes until it's restarted.
[14:13] <jml> http://paste.ubuntu.com/566971/
[14:14] <deryck> abentley, if you'll point me at that mp, I'll review later, after I finish a handful of emails.
[14:14] <henninge> jtv: thanks!
[14:14] <abentley> deryck, first I have to create the MP.
[14:15] <deryck> ah, ok :-)
[14:15] <jtv> henninge: on an unrelated note, I see that POTMsgSet.setSequence has a case for TranslationTemplateItem.sequence < 0.  I have _no_ idea what sense that would make.  Can you think of anything?
[14:16] <henninge> jtv: I was not aware of that and nothing comes to mind about it.
[14:16] <abentley> sinzui, could you please have a look at https://code.launchpad.net/~abentley/launchpad/merge-translation-script/+merge/49099 ?
[14:16] <jml> allenap: because NewBuildersScanner doesn't update self.current_builders?
[14:16] <allenap> jml: That's the badger.
[14:16] <jtv> henninge: thanks, just checking my sanity.  :)
[14:16]  * sinzui looks
[14:17] <jml> allenap: I don't know of any production issues, but I guess I've just confirmed there's a logic bug in the code.
[14:18] <henninge> jtv: I don't see what you mentioned, though ...
[14:18] <allenap> jml: Okay, I'll file a bug. How would you triage it? I'm tempted to mark it critical.
[14:18] <bigjools> allenap: urgh
[14:18] <henninge> jtv: can you paste the version of setSequence you are seeing? Or give me the revno?
[14:18] <jtv> henninge: there's a check for sequence >= 0 (which should always be the case), and then there's an else: pass.
[14:18] <jml> allenap: I guess critical, but that's probably only because I'd just fix the bug :)
[14:18] <henninge> oh, that's what you meant
[14:19] <allenap> jml: Yeah, that was my plan too :)
[14:19] <bigjools> allenap: critical
[14:19] <henninge> jtv: that's because our style guide used to require that else
[14:19] <abentley> sinzui, thanks.
[14:19] <jtv> henninge: it's not that—it's that there's an "elif" instead of an "else" in the first place.
[14:20] <henninge> jtv: hm, you mean that condition should be checked in an assert?
[14:20] <jtv> henninge: an "assert sequence >= 0" would have made more sense!  Maybe this grew out of an "if sequence > 0" that then also absorbed the "sequence == 0" case.
[14:21] <bigjools> has anyone managed to land anything via ec2 lately?
[14:21] <henninge> jtv: I agree
[14:21] <bigjools> I'm on attempt #4 and it's still bloody failing in windmill
[14:21] <jtv> Thanks.
[14:21] <jtv> bigjools: I did, yesterday.
[14:21] <bigjools> :/
[14:21] <jtv> bigjools: I did run rocketfuel-setup first, IIRC, after hitting our windmill problem.
[14:21]  * henninge relocates
[14:21] <bigjools> how does that affect ec2?
[14:22] <jtv> bigjools: newer AMI maybe
[14:22] <jtv> I don't know how those propagate.
[14:23] <bigjools> it just picks up the latest automatically
[14:23] <sinzui> abentley: r=me
[14:23] <abentley> sinzui, thanks.
[14:23] <bigjools> actually, now it's showing connection refused errors in librarian tests
[14:36] <bigjools> ec2 testing is about as reliable as a chocolate teapot lately.
[14:37] <bigjools> and now bzr lp-land is crashing!  I am doomed.
[14:43] <gary_poster> "about as reliable as a chocolate teapot
[14:43] <gary_poster> "
[14:43] <gary_poster> -> an analogy I would have never thought of
[14:43] <gary_poster> and like :-)
[14:44] <bigjools> gary_poster: the other one is a chocolate fireguard - fairly standard stuff this side of t'pond :)
[14:45] <abentley> deryck, https://code.launchpad.net/~abentley/launchpad/share-existing-packagings/+merge/49634
[14:46] <bigjools> bac: hey, the no-email-for-own-bug-actions is totally awesome
[14:46] <deryck> abentley, got it, thanks.  Will review very shortly.
[14:46] <bac> bigjools: yes.  danilos and gary_poster did a great job.  (i just got to announce it)
[14:46] <bac> bigjools: and it was only six years in the making
[14:46] <bigjools> is there a reason it wasn't done for questions?
[14:47] <bac> bigjools: that is on our plate.  look for it in 2017
[14:47] <bigjools> heh
[14:48] <deryck> heh
[14:49] <deryck> yeah, bac, danilos and gary_poster are to be praised for this work.  many lp users will rejoice.
[14:49] <bigjools> we're not worthy
[14:49]  * bigjools does the Wayne's World thing
[14:50]  * deryck joins in since it was time for a stretch break anyway
[14:51] <sinzui> henninge: do you have time to review https://code.edge.launchpad.net/~sinzui/launchpad/packagebugs-search-0/+merge/49479
[14:54] <gary_poster> lol :-)
[14:57] <henninge> sinzui: r=me
[14:58] <sinzui> thank you henninge
[15:10] <allenap> henninge: Do you have time to review a fix for bug 718761? https://code.launchpad.net/~allenap/launchpad/new-builders-scanner-calm-down/+merge/49645
[15:10] <_mup_> Bug #718761: NewBuildersScanner schedules a new SlaveScanner every 5 minutes for new builders <Launchpad itself:In Progress by allenap> < https://launchpad.net/bugs/718761 >
[15:11] <henninge> allenap: I am currently looking at another review but will pick yours up right after that.
[15:12] <allenap> henninge: Thanks :)
[15:12] <dobey> hey all
[15:12] <dobey> did something break the API this morning?
[15:12] <dobey> i keep seeing this in tarmac:
[15:12] <dobey> NotImplementedError: Can't look up definition in another url (https://api.launchpad.net/1.0/#branch)
[15:12] <leonardr> dobey: you're probably using edge, which is gone
[15:13] <dobey> leonardr: ^^ that URL doesn't have edge in it though... hrmm
[15:14] <leonardr> dobey: edge redirects you to api.launchpad.net, but launchpadlib thinks it's using edge
[15:14] <leonardr> it's telling you that api.edge.launchpad.net served it urls from another server (api.launchpad.net)
[15:28] <jml> is there a step in the nodowntime rollout process for marking "Fix committed" bugs as "Fix released"?
[15:28] <jcsackett> jml: i believe people have done that manually.
[15:28] <jcsackett> or did you mean in documentation?
[15:29] <deryck> bigjools, did you ever get past your windmill test failure?
[15:29] <jml> I meant the latter but I would have tolerated being pleasantly surprised wrt automation :)
[15:29] <bigjools> deryck: yes but I didn't change anything
[15:29] <bigjools> I get other errors in ec2 now :/
[15:29] <bigjools> none of them to do with my branch of course, and since it was attempt #4 at ec2 I gave up and pqm-submitted it
[15:30] <deryck> bigjools, ah, ok.  I've got a call and review and then can look to see if something stands out to me.
[15:36] <leonardr> dobey: try this branch and see if it helps you https://code.launchpad.net/~leonardr/launchpadlib/fake-edge
[15:39] <leonardr> henninge: would love a review of https://code.launchpad.net/~leonardr/launchpadlib/fake-edge/+merge/49651
[15:42] <dobey> leonardr: i did this: https://code.launchpad.net/~dobey/tarmac/no-more-edge/+merge/49649
[15:43] <leonardr> dobey: you don't need to import lpnet_service_root, you can just use the string 'production'
[15:43] <leonardr> but you have the right idea
[15:43] <leonardr> similarly 'staging'
[15:45] <dobey> well i'd rather import the strings than using literals everywhere.
[15:46] <LPCIBot> Project devel build (440): STILL FAILING in 5 hr 14 min: https://hudson.wedontsleep.org/job/devel/440/
[15:46] <LPCIBot> Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=607960] Permit turning targetnamecache off
[15:46] <LPCIBot> via malone.disable_targetnamesearch feature flag.
[15:46] <leonardr> dobey: those constants aren't relaly meant to be re-imported
[15:46] <leonardr> maybe i should change them to be the strings
[15:47] <abentley> henninge, could we mumble about https://bugs.launchpad.net/launchpad/+bug/716586 ?
[15:47] <_mup_> Bug #716586: Diverged translation cannot be converged again. <regression> <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/716586 >
[15:48] <henninge> leonardr, abentley: otp atm
[15:48]  * jcsackett sighs.
[15:48] <jcsackett> local codehosting is not the easiest thing to get working.
[15:48] <abentley> henninge, oic
[15:49] <abentley> jcsackett, what problem are you having?
[15:49] <jcsackett> abentley: a general inability to push or pull branches to try and test mp stuff.
[15:50] <jcsackett> abentley: when i try to push, i get an error about needing to supply create-prefix.
[15:50] <jcsackett> when i try to pull, i get a NOT A BRANCH error.
[15:50] <jcsackett> i'm rebuilding something right now, when that's done i can supply you more specific errors.
[15:50] <abentley> jcsackett, are you running "make run_all"?
[15:51] <jcsackett> abentley: no, i was not aware of run_all. i take it that gets everything else up and running?
[15:51]  * jcsackett prepares to edit wiki page on development codehosting.
[15:51] <abentley> jcsackett, yes.  "make run" doesn't start codehosting.
[15:51] <jcsackett> abentley: fantasitc. thanks. :-)
[15:53] <abentley> jcsackett, I've never used "make run_codehosting" like that page says, but I guess that works, too.
[15:53] <jcsackett> abentley: make run_codehosting wouldn't run for me, thus trying make run.
[15:53] <jcsackett> oddly, make run_all *is* working. i should find out why codehosting wasn't.
[15:54] <abentley> jcsackett, that would be very good to know.
[15:54]  * jcsackett nods.
[15:54] <jcsackett> thanks, again, abentley. this has gotten me past the current hurdle. :-)
[15:54] <abentley> jcsackett, np
[15:58] <abentley> jkakar, did you get anywhere with that ClassAlias issue?
[16:00] <jkakar> abentley: Hey, sorry about that, the other day... I looked at it and then got distracted.
[16:00] <jkakar> abentley: So yeah, I looked at it, but I don't understand why you want to use ClassAlias in that code...
[16:00] <jkakar> abentley: It's usually useful when you self-join a table, which didn't seem to be the case, if I remember correctly.
[16:01] <jkakar> abentley: Anyway, it did seem a touch odd that the ClassAlias wasn't being used, because I would expect it to be.
[16:01] <abentley> jkakar, I want to use the POTemplate table two ways: I want to find Products that link to POTemplates, and I want to find packages that link to POTemplates.
[16:02] <jkakar> abentley: Can you paste the query again, please?
[16:04] <abentley> jkakar, looking...
[16:05] <jkakar> abentley: Ta.
[16:05] <abentley> jkakar,  http://pastebin.ubuntu.com/565962/
[16:06] <abentley> jkakar, the english version is "Find me packagings where the product and the sourcepackage each have POTemplates"
[16:08] <jkakar> abentley: Hmm, are the POTemplates the same for a product and sourcepackage, or do products and sourcepackages each have their own POTemplate?
[16:09] <jkakar> If they're not the same, I suspect you'll need to run two queries or use subselects or something.
[16:09] <abentley> jkakar, the products will have different POTemplates from the sourcepackages.
[16:10] <jkakar> abentley: In that case, I don't think the join you have here is going to work.
[16:10] <abentley> jkakar, The direct SQL works just fine.
[16:10] <jkakar> abentley: The SQL that's generated at the bottom of the paste you mean?
[16:10] <abentley> jkakar, no, I wrote this as SQL first and got a losa to run it against staging.
[16:11] <abentley> jkakar, I'm trying to Stormify that sql.
[16:11] <jkakar> abentley: Is that SQL at the bottom your hand-written working SQL or what's generated?  If it's generated, can you paste the working SQL, please?
[16:11] <abentley> jkakar, that's the generated SQL.  The SQL I want is: https://pastebin.canonical.com/43146/
[16:12] <joey> jml: yeah, needs love
[16:12] <joey> jml: fixed!
[16:13] <jml> joey: thanks :)
[16:13] <joey> my pleasure
[16:13] <joey> and you're very welcome
[16:13] <joey> I have one action I can't do on -meeting so I  had to mail off for a group request for that
[16:14] <abentley> henninge, ping me when you can chat.
[16:16] <henninge> abentley: now
[16:16] <henninge> ;-)
[16:17] <jcsackett> abentley: so i thought i had this working, but it turns out the pushing wasn't putting anything into launchpad.dev, but just pushing into my home directory on my machine. thoughts?
[16:19] <jkakar> abentley: Hmm, my conversion of that SQL looks a bit different than yours: https://pastebin.canonical.com/43286/
[16:19] <jkakar> abentley: Does that work?
[16:19] <abentley> jcsackett, OTP
[16:19] <jcsackett> abentley: ah, sorry.
[16:20] <henninge> abentley: https://translations.qastaging.launchpad.net/mailclipper/trunk/+pots/testcase/fr/+translate
[16:20] <jml> sinzui: would your squad be able to finish up the two remaining High priority feature-flags bugs?
[16:20] <sinzui> maybe
[16:21] <abentley> jkakar, I can try it, but shouldn't my version have generated a FROM statement with "AS" in it?
[16:21] <sinzui> jml: I think the answer is yes. Looks like jcsackett and wgrant have booked their next few days. I will be taking a new bug in a few hours
[16:21] <jml> sinzui: https://bugs.launchpad.net/launchpad/+bug/670019 and https://bugs.launchpad.net/launchpad/+bug/708999.
[16:21] <jkakar> abentley: Yes, I'd expect that.  I don't understand why that isn't happening.
[16:21] <_mup_> Bug #670019: audit facility for feature flags <feature-flags> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/670019 >
[16:22] <_mup_> Bug #708999: code.branchmergequeue, code.incremental_diffs.enabled feature flags not documented <code> <feature-flags> <Launchpad itself:Triaged> < https://launchpad.net/bugs/708999 >
[16:22] <jml> sinzui: thanks.
[16:22] <abentley> jkakar, okay, I'll file a bug then.
[16:22] <jkakar> abentley: Thanks.
[16:36] <bac> hi deryck
[16:40] <deryck> bac, hey
[16:40] <allenap> danilos: Hi there. Could you triage bug 714521 if possible? If I do it, it's likely to be a guess.
[16:40] <_mup_> Bug #714521: Partial translation export feature gone <regression> <upstream-translations-sharing> <Launchpad itself:New> < https://launchpad.net/bugs/714521 >
[16:41] <danilos> allenap, well, I wanted to leave it for deryck's team to triage, but considering it's a regression, I am sure it should be critical according to our 'regression' policies
[16:42] <allenap> danilos: Ah, yes :) I'm getting used to this slowly :) I'll update it.
[16:43] <danilos> allenap, it would be nice to get Henning's opinion as well, because he marked it as 'invalid'
[16:44] <allenap> Cool, I'm in favour of that.
[16:46] <cr3> can someone help me understand why bugattachment.data.open() seems to return a buffer with a read() method, as per the api documentation, but the open method in the LibraryFileAlias class doesn't return anything.
[16:46] <henninge> leonardr: I won't be able to look at your mp, I am sorry.
[16:47] <leonardr> ok, i'm sure i can get someone to look at it since it's a partial solution to an active emergency
[16:47] <allenap> wgrant: Mind if I ask you about a build issue? I think bug 718790 is something the user can correct himself - i.e. avoid running javadoc on .class files - but I wanted a second opinion as I am not at all familiar with builds.
[16:47] <_mup_> Bug #718790: FTBFS with java due to illegal characters <Launchpad Auto Build System:New> < https://launchpad.net/bugs/718790 >
[16:54] <abentley> jkakar, filed as https://bugs.launchpad.net/storm/+bug/718864
[16:54] <_mup_> Bug #718864: ClassAlias does not generate AS in FROM clause <Storm:New> < https://launchpad.net/bugs/718864 >
[16:58] <abentley> henninge, if a suggestion is not diverged, there's no way of knowing whether it was suggested for upstream or ubuntu, right?
[16:58] <henninge> abentley: right, and suggestions can not be diverged anyway.
[16:59] <henninge> i.e. potemplate should only be not None if one (and only one) of the is_current_* flags is set.
[17:00] <abentley> henninge, thanks.
[17:04] <cr3> nevermind, folks, found answer in HostedFile in lazr.restfulclient
[17:05] <jml> Off for a bit. Back later.
[17:49] <leonardr> is there anyone who can help me understand PATCHPlugin in launchpad/javascript/client/client.js?
[17:53] <benji> leonardr: I too seek enlightenment.
[17:56] <jtv> I, on the other hand, seek review: https://code.launchpad.net/~jtv/launchpad/bug-715854/+merge/49676
[17:56] <jtv> Any takers?
[17:57] <leonardr> jtv, i'll take it if you'll take https://code.launchpad.net/~leonardr/launchpadlib/fake-edge/+merge/49651
[17:58] <jtv> leonardr: OK
[18:01] <jtv> leonardr: I wonder whether we ought to use the new LP import format for launchpadlib.
[18:02] <jtv> src/launchpadlib/launchpad.py: from launchpadlib.uris import STAGING_SERVICE_ROOT, EDGE_SERVICE_ROOT
[18:05] <jtv> leonardr: similar for the list constant in src/launchpadlib/tests/test_launchpad.py
[18:11] <lifeless> moin
[18:11] <jtv> hi lifeless
[18:12] <leonardr> jtv: i think i need to push a more recent version
[18:13] <leonardr> yeah, you didn't have the version that included the deprecation warning. sorry about that
[18:13] <jtv> leonardr: it does have that
[18:13] <leonardr> sorry, i meant...
[18:13] <leonardr> the version that will give you a deprecation warning if you use EDGE_SERVICE_ROOT
[18:13] <leonardr> it's a minor change
[18:13] <jtv> That's not in _dereference_alias?
[18:14] <leonardr> i changed EDGE_SERVICE_ROOT to 'edge'
[18:14] <jtv> Ah
[18:14] <leonardr> which will trigger the warning when it goes into _dereference_alias
[18:14] <jtv> as opposed to 'production'
[18:14] <leonardr> right. it'll get converted to production after the warning
[18:14] <jtv> I see
[18:15] <jtv> leonardr: my one gripe is with the test.  It seems to test multiple things at once:
[18:15] <jtv>  * Looking up edge on the web service gives you production.
[18:16] <jtv>  * A web lookup for edge also gives you production.
[18:16] <jtv>  * Exactly one of these gives the warning.
[18:16] <leonardr> well, that's easy to fix
[18:16] <jtv> Nobody said it had to be hard. :)
[18:20] <leonardr> jtv: problem with catching the warning. the warning only happens once, and i don't know how to guarantee which test it happens in
[18:20] <jtv> surprising… why is that?
[18:21] <leonardr> ordinarily a deprecation warning only happens the first time you do the deprecated thing
[18:21] <jtv> I would maybe the first…
[18:21]  * leonardr rereads the module doc
[18:21] <jtv> I would _have expected_ maybe the first.
[18:22] <leonardr> it's not
[18:24] <jtv> Then can you guarantee that this test won't fail arbitrarily, e.g. when run in combination with specific other tests?
[18:25] <jtv> Arrgh, I have to go.
[18:26] <leonardr> jtv: pushed a new revision that should please you
[18:26] <leonardr> i'll take a look at your branch now
[18:26] <jtv> cool, thanks
[18:31] <abentley> lifeless, stub still needs to sign off on database reviews, right?
[18:31] <lifeless> yes
[18:31] <lifeless> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[18:31] <lifeless> both of us need a db review requested
[18:32] <leonardr> jtv: reading your mp i kind of get what's going on but i don't know what a file reference actually is. is that the file in which a translatable string occurs?
[18:33] <abentley> lifeless, could not find that page on dev.launchpad.net.
[18:33] <jtv> leonardr: yes, the place in the project's source tree where it's found.
[18:33] <jtv> (I had that in the MP at one point but must have taken it out again)
[18:33] <lifeless> abentley: I find it from the policy and process list when I need to
[18:33] <abentley> lifeless, I mean it's there if you know the URL, but not linked to in https://dev.launchpad.net/PatchSubmission or anything.
[18:34] <jtv> leonardr: I'm done with yours.  Have to run now!
[18:34] <lifeless> abentley: ah, it probably needs to be referenced
[19:18] <lifeless> statik: hi
[19:22] <lifeless> I can has review? https://code.launchpad.net/~lifeless/launchpad/bug-704446/+merge/49580
[19:43] <jcsackett> lifeless, have a moment to talk?
[19:43] <jcsackett> regarding the revision that had to be rolledback?
[19:45] <lifeless> sure
[19:45] <lifeless> irc/voice?
[19:45] <jcsackett> uh, voice might well be easier.
[19:45] <jcsackett> mumble or skype?
[19:45] <lifeless> s
[19:47] <lifeless> whats yoiur skype id?
[19:47] <jcsackett> lifeless: j.c.sackett
[19:47] <jcsackett> i'm online now.
[19:47] <lifeless> durham ?
[20:39] <gary_poster> leonardr: http://code.google.com/p/httplib2/issues/detail?id=97 !  cool.
[20:40] <leonardr> yay
[20:42] <lifeless> nice
[20:42] <lifeless> nasty bug there
[20:42] <thumper> morning
[20:44] <thumper> deryck: ping
[20:54] <jam> lifeless: I just got rejection emails for proposals against loggerhead trunk...
[20:55] <jam> Is there any context I can give you that will help?
[20:55] <jam> (emails, merge proposal, etc.?)
[20:57] <lifeless> jam: what mail was rejected?
[20:57] <lifeless> jam: as in the address that was sent to
[20:57] <jam> lifeless: one was a new merge proposal, one was a comment follow up to an existing proposal
[20:58] <jam> lifeless: the rejection message was: From: launchpad-bugs-owner@lists.canonical.com
[20:58] <jam> So I assume launchpad-bugs@lists.canonical.com
[20:58] <LPCIBot> Project devel build (441): STILL FAILING in 5 hr 12 min: https://hudson.wedontsleep.org/job/devel/441/
[20:58] <LPCIBot> Launchpad Patch Queue Manager: [r=adeuring][bug=631206] Make Builder:+history load in 2 seconds
[20:58] <LPCIBot> instead of timing out.
[20:59] <jam> lifeless: digging into the content, it looks like it was actually launchpad-bugs@lists.ubuntu.com that it was getting sent to
[20:59] <jam> (From an old Received: line)
[21:03] <lifeless> ok thats ~launchpad
[21:03] <lifeless> you proposed to trunk yea?
[21:03] <lifeless> flacoste: hi
[21:03] <flacoste> hi lifeless
[21:03] <lifeless> we up ?
[21:03] <flacoste> i'm ready for our call
[21:04] <thumper> leonardr: mumble?
[21:04] <leonardr> thumper, i'm on it
[21:10] <jam> lifeless: yes, this is to lp:loggerhead
[21:11] <leonardr> https://code.launchpad.net/~thumper/launchpad/daily-ajax/+merge/49295
[21:18] <lifeless> flacoste: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-categories.html
[21:20] <jam> lifeless:  should I be adding sinzui to my loggerhead request-for-review for the ui stuff?
[21:20] <jam> or should I be targetting ~loggerhead-team and asking for ui, or how is that done?
[21:20] <lifeless> jam: generally ask here
[21:20] <lifeless> jam: I suggeset huwshimi, who is tasked with making loggerhead look more like lp, and sinzui
[21:21] <sinzui> lets give huwshimi a go first
[21:21] <jam> huwshimi and sinzui: https://code.launchpad.net/~jameinel/loggerhead/revert-colors/+merge/49705  is the link
[21:21] <jam> sinzui: fine with me, just making sure I conformed to whatever protocol is applicable
[21:26] <sinzui> why is the person picker showing me a non-active user?
[21:31] <jml> huwshimi: care to join me on mumble?
[21:31] <huwshimi> jml: Sure
[21:33] <jml> ... or not. I can't seem to sign on.
[21:33] <poolie> hello jml, huwshimi, leonardr, all
[21:33] <huwshimi> jml: You look online to me now
[21:33] <jml> poolie: hello
[21:33] <huwshimi> poolie: Morning
[21:33] <poolie> can i have a mini-preimpl discussion on https://bugs.launchpad.net/launchpad/+bug/643224
[21:33] <_mup_> Bug #643224: dkim whitelist should be in configuration <dkim> <feature-flags> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/643224 >
[21:33] <jml> huwshimi: skyping you instead
[21:34] <poolie> specifically as to whether the the approach described is ok
[21:37] <thumper> leonardr: how do I change an exposed method so it doesn't appear in 'devel' api?
[21:38] <thumper> leonardr: I've changed the setRecipeText from being a callable method to being a mutator on recipe_text
[21:38] <thumper> leonardr: also, do I need to annotate the new mutator in any way to make it say devel only?
[21:38] <poolie> lifeless, can you have a quick glance at 643224?
[21:38] <leonardr> thumper: put @operation_removed_in_version("devel") at the top of the annotations
[21:38] <thumper> leonardr: I'm not entirely clear on this point
[21:39] <thumper> leonardr: ok
[21:39] <leonardr> you don't need to annotate the mutator because there is no preexisting code that will break now that this field can be edited
[21:40] <thumper> ok
[21:40] <leonardr> i think you can make that work if you really want to, but i don't remember how--i think you would use operation_for_version
[21:41] <thumper> leonardr: is a mutator a write_operation?
[21:42] <thumper> leonardr: or more specifically, do I need @export_write_operation as well as @mutator_for ?
[21:43] <leonardr> thumper: yes, you define a write operation and _then_ make it a mutator
[21:43] <leonardr> so if you want it to be a mutator in one version and not another, you would define it in the earlier version, then put @operation_for_version() on top, and put @mutator_for on top of that
[21:44] <wgrant> allenap: There are probably better people at 4am, but sure.
[21:46] <thumper> leonardr: I'm just pushing a change, then I'll get you to look at the diff, and how I've done it to see if there is a more sane way
[21:46] <leonardr> ok, i'll take a look
[21:59] <jml> huwshimi: http://www.ubuntu.com/community
[22:02] <thumper> leonardr: line 196(ish) of https://code.launchpad.net/~thumper/launchpad/recipe-inline-edit-recipe-text/+merge/49585
[22:06] <leonardr> thumper: you might not need two different methods. try putting @operation_for_version("devel") right on top of @operation_removed_in_version("devel")
[22:06] <thumper> leonardr: what of the mutator?
[22:06] <thumper> leonardr: it seems a bit weird to stack them like this
[22:07] <poolie> leonardr, re your comment about LPNET_SERVICE_ROOT='production'
[22:07] <leonardr> thumper: @operation_removed_in_version basically clears the slate. you can start from scratch on top of it
[22:08] <thumper> leonardr: do the annotations work from the outside in, or the inside out?
[22:09] <leonardr> thumper: they work from bottom to top
[22:09] <leonardr> the only restriction is you can't put an older version on top of a newer version
[22:10] <thumper> leonardr: do I need two @export_write_operations ?
[22:10] <leonardr> thumper: yeah, you have to start all over
[22:10] <leonardr> including the parameters, i think
[22:11] <thumper> leonardr: so if I'm starting over, why do I need the @operation_for_version("devel") ?
[22:11] <thumper> isn't that the default?
[22:11] <thumper> as I don't need it for the current one
[22:11] <leonardr> thumper: you might not need it. i'd put it in just to make it clear that you're reinstating it for devel
[22:11] <thumper> hmm.... ok, let me try
[22:21] <thumper> well... it works
[22:22] <leonardr-afk> ok, if you can do without two methods i think that's better (although you could argue two methods is actually more readable)
[22:22] <leonardr-afk> but i think if you do it with one method you should explicitly state @operation_for_version as a way of signalling its return
[22:23] <wgrant> sinzui: https://code.launchpad.net/~wgrant/launchpad/icing-purge/+merge/49590 seems like your sort of thing. Could you take a moment to review it?
[22:23] <thumper> leonardr-afk: yep, I've done that
[22:23] <sinzui> wgrant: I will
[22:23] <jam> lifeless: any chance you could teddy bear on ideas for diagnosing the file handle leak issue? https://bugs.launchpad.net/launchpad/+bug/717345
[22:23] <_mup_> Bug #717345: Updates to SFTP server leak file handles in use_forking_server mode <Launchpad itself:In Progress by jameinel> < https://launchpad.net/bugs/717345 >
[22:23] <jam> I just ran hammer-ssh with 200-way concurrency
[22:23] <wgrant> sinzui: THanks.
[22:24] <jam> and got 186 concurrent connections for 60s
[22:24] <jam> without falling over anywhere
[22:24] <jam> at least that I can see
[22:24] <jam> a bit hard to check every one of 2k connections
[22:24] <wgrant> jam: You were requesting a smartserver on every connection?
[22:25] <jam> wgrant: yep
[22:25] <jam> wgrant: 'echo hello' which is the cheapest request we have
[22:25] <jam> but still the full stack
[22:25] <wgrant> :(
[22:27] <jam> wgrant: and running locally, and running 'lsof' while connecting and afterwards shows 0 stale handles, etc.
[22:28] <wgrant> jam: :(er
[22:28] <jam> yep
[22:28] <jml> g'night all
[22:28] <wgrant> It sounds like productions children must just not be dying :/
[22:28] <jam> so apparently qastaging and dev is immune from whatever was killing production...
[22:28] <jam> now, I'm not triggering failures, and some other stuff, which I can try to inject
[22:28] <jam> but something really smells here
[22:29] <jml> g'night all.
[22:29] <jam> wgrant: and I just checked again, all of those spawned connections return a valid response
[22:30] <jam> so not only is it connecting, the requests are getting through and responded to
[22:32] <jam> I could try changing the test script to actually do something more than just 'hello', but I'm not sure what that would tell me yet
[22:34] <lifeless> jam: sure
[22:37] <lifeless> jam: did you want voice or irc?
[22:40] <jam> lifeless: irc is ok. I'm not sure what else to fill in just yet, other than what I mentioned above to wgrant. I'm trying to redo the hammer_ssh script a bit to do more actions per connection
[22:40] <lifeless> jam: one possibility is expensive queries and then detach
[22:40] <lifeless> jam: you thought error cases might be important too
[22:41] <lifeless> jam: also on loggerhead, both sinzui and huwshimi are online know, if you want to mention the theme thing to them.
[22:42] <jam> lifeless: detach? meaning disconnect, or do you mean run in the background?
[22:42] <lifeless> disconnect
[22:44] <lifeless> huwshimi: sinzui: bug 718968
[22:44] <_mup_> Bug #718968: trunk should use old trunk color scheme <ui> <loggerhead:Confirmed for jameinel> < https://launchpad.net/bugs/718968 >
[22:47] <lifeless> jam: I've commented on the bug too, fwiw
[22:48] <jam> lifeless: I ran 300, and it only got 1900 connections total
[22:48] <jam> so I think I'm hitting a cpu bottleneck with the ssh handshake
[22:48] <wgrant> jcsackett: So, what's youre codehosting issue?
[22:50] <lifeless> jam: it has a fd limit of 1024
[22:50] <lifeless> jam: so wouldn't expect it to get passt 255 concurrent
[22:50] <jam> lifeless: sure
[22:51] <jam> well, theoretically 341
[22:51] <jam> (1024/3)
[22:51] <wgrant> jam: Plus the SSH FD.
[22:51] <jcsackett> wgrant: broadly, it doesn't work. more specifically, when make run_all or make run_codehosting, i can neither push branches too, nor get branches from lp.dev
[22:51] <lifeless> jam: network, in, out, err == 4
[22:51] <jam> wgrant: right
[22:51] <wgrant> jcsackett: Sounds like you need SSH config. Have you run utilities/make-lp-user?
[22:51] <jam> lifeless: right, and I'm guessing I'm currently bottlenecked on "network" only
[22:51] <jcsackett> wgrant: i have.
[22:51] <jam> which is why I'm trying to set the connection to do a bit more before it exits
[22:52] <jam> though now after a couple secs it hangs waiting for a child to exit. but I'll work on that
[22:52] <jcsackett> i'm not sure it's ssh; the error i get when pushing is that a path or parent directory doesn't exist.
[22:52] <wgrant> jcsackett: http://paste.ubuntu.com/567140/ is what I have in my ~/.ssh/config.
[22:52] <wgrant> jcsackett: replace ppa-user with the username you gave to make-lp-user.
[22:52] <wgrant> jcsackett: It is probably SSH. It's connecting to your system sshd instead of the LP one.
[22:53] <jcsackett> wgrant: ah, that makes sense.
[22:53] <jcsackett> trying that now.
[22:55] <huwshimi> jam: In regards to the colours in loggerhead and making it themeable, I'm in the process of skinning LH so that it looks like launchpad.  Whatever we do we should make it easy to maintain different themes for LH vanilla and LH Launchpad or make them the same.
[22:55] <jcsackett> wgrant: http://paste.ubuntu.com/567142/
[22:55] <jam> huwshimi: atm, I'm just proxying for max kanat-alexander, who was the one that preferred the old default theme (non-lp)
[22:56] <jam> and beuno who was the one that said they were requested that the themes look different
[22:56] <jcsackett> wgrant: on the plus side, that is a *different* error, which frequently implies progress. :-P
[22:56] <huwshimi> jam: In that case making it themeable might be a good way to go, right?
[22:57] <jam> huwshimi: themeable would be great
[22:57] <jam> and a good answer for the bug
[22:57] <jam> but far outside of my scope :)
[22:57] <huwshimi> jam: ok sure.
[23:00] <wgrant> jcsackett: Ah, you need the forking service now.
[23:00] <wgrant> jcsackett: Or to disable the forking service.
[23:01] <jcsackett> wgrant: ?
[23:01] <wgrant> jcsackett: Set use_forking_daemon to False in the development config.
[23:01] <wgrant> This is the new thing that jam is debugging.
[23:02] <jam> wgrant: I doubt that is the failure, but hey, eliminate variables all you want :)
[23:03] <jam> note the IP address is also custom
[23:03] <jam> specifically 127.0.0.88 or something like that
[23:03] <wgrant> jam: Does run_codehosting start the forking service now?
[23:03] <jam> wgrant: yep
[23:03] <wgrant> Oh :(
[23:03] <jam> otherwise it wouldn't work :)
[23:03] <wgrant> It wouldn't be the first time that development codehosting didn't work :)
[23:04] <lifeless> jam: huwshimi: I might have a quick chat to poolie about the theme
[23:04] <jam> lifeless: fine with me, time for me to EOD
[23:04] <lifeless> jam: kk
[23:06] <wgrant> lifeless: Did your testfix make it through?
[23:06] <wgrant> I don't see it.
[23:07] <jcsackett> wgrant: we may have success. no error msgs on the push, i'm syncing branches and checking the web interface.
[23:07] <wgrant> jcsackett: Excellent.
[23:07]  * wgrant works out why it didn't work.
[23:08] <sinzui> wgrant r=me
[23:08] <jcsackett> wgrant: looks like that was it.
[23:08] <jcsackett> thanks!
[23:08] <wgrant> sinzui: Thanks.
[23:08] <wgrant> sinzui: I wanted you to look over it because I thought you might have left them for a reason last time.
[23:09] <wgrant> jcsackett: Great,
[23:09] <sinzui> wgrant: I remarked that something was using the translate button a few months ago, well maybe 6 months ago
[23:15] <wgrant> jcsackett: Odd. It works fine for me locally with the forking service.
[23:15] <lifeless> wgrant: huh, let me see
[23:16] <wgrant> lifeless: I bet you forgot [testfix]
[23:16] <wgrant> But PQM should have mailed you :)
[23:17] <wgrant> Ooooh, sub-second local LP pushes with the forking service.
[23:17] <lifeless> beuno: hey, on bug 718968 - question for you
[23:17] <_mup_> Bug #718968: trunk should use old trunk color scheme <ui> <loggerhead:Confirmed for jameinel> < https://launchpad.net/bugs/718968 >
[23:17] <wgrant> That is awesome.
[23:17] <lifeless> wgrant: I put the testfix at the end
[23:17] <lifeless> silly regeex ordering
[23:17] <wgrant> jcsackett: Is there a launchpad-forking-service running?
[23:17] <wgrant> lifeless: Hah.
[23:18] <lifeless> resubbing in a sec
[23:18] <wgrant> Thanks.
[23:18] <wgrant> Test runs with that breakage are valid, but have 4 errors?
[23:18] <lifeless> yes
[23:19] <wgrant> Great.
[23:22] <lifeless> wgrant: so, staging appears to have restored successfully; how are you estimating its age ?
[23:24] <wgrant> lifeless: I normally look for when the stream of new bugs finished.
[23:24] <wgrant> As long as bugs.staging.launchpad.net doesn't time out...
[23:24] <wgrant> Which it does.
[23:25] <wgrant> Ah, there we are.
[23:25] <wgrant> Doesn't look very restored.
[23:26] <wgrant> Where is staging-restore.sh?
[23:26] <wgrant> I can't find it in any of the usual places.
[23:26] <wgrant> It restored fine on the 5th. It should have presumably restored again on the 12th, but I wonder if it didn't do it because there was no new rev to update to.
[23:28] <lifeless> I got the restore log 2 days back
[23:29] <wgrant> You mean the cronspam?
[23:29] <wgrant> That it sends every time it updates?
[23:32] <wgrant> lifeless: https://pastebin.canonical.com/43311/
[23:32] <wgrant> It always restores on a Saturday. This time it did not.
[23:32] <wgrant> Perhaps a backup was missed due to the rollout.
[23:32] <wgrant> Or something like that.
[23:34] <lifeless> ah yesm wrong ting
[23:34] <wgrant> staging_restore.sh does not always restore staging :(
[23:35] <wgrant> LOSA ping.
[23:41] <spm`> yo
[23:43] <wgrant> spm: What is in sourcherry:/srv/staging.launchpad.net/dumps_from_prod/?
[23:45] <beuno> lifeless, hey, will look in a bit
[23:45] <spm> are you trying to determine what's up wit hthe staging restore?
[23:45] <wgrant> spm: Yes.
[23:45] <wgrant> Last weekend's did not.
[23:45]  * beuno replies
[23:46] <spm> there's nothing helpful in the staging restore email?
[23:46] <wgrant> Config schemas with production database servers referenced: Australia says argh
[23:47] <wgrant> spm: The emails are not useful.
[23:47] <wgrant> The logs on carob only report when a new backup is found.
[23:47] <wgrant> So all the information I have is that it finds a new backup every Saturday except the last one.
[23:49] <spm> 2011-02-09 06:38 & 2011-02-14 06:35 <== no restore
[23:50] <spm> oh I wonder. possibly the rollout on friday night may have messed things up there.
[23:50] <lifeless> spm: are you able to trigger a qastaging restore ?
[23:50] <spm> sure
[23:50] <wgrant> spm: That was my suspicion.
[23:50] <lifeless> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[23:50] <spm> lifeless: as in a DB restore (to confirm)
[23:50] <lifeless> spm: yes
[23:50] <wgrant> lifeless: Again? :/
[23:50] <wgrant> lifeless: Still works fine from here.
[23:50] <lifeless> wgrant: may be intermittent
[23:51] <wgrant> Well, it's happening from at least two places, so I guess we have to investigate...
[23:52] <spm> erm. is tehre a reason we'd have 49 x /usr/bin/python2.6 /srv/bazaar.launchpad.net/production/launchpad-rev-12351/eggs/bzr-2.2.2_lp_2-py2.6-linux-x86_64.egg/EGG-INFO/scripts/bzr launchpad-forking-service --path /srv/bazaar.launchpad.net/var/launchpad_forking_service.socket --pid-file /srv/bazaar.launchpad.net/var/launchpad_forking_service.pid
[23:52] <spm> all dating from Feb 11.
[23:52] <wgrant> Are they all from Friday?
[23:52] <wgrant> Yeah.
[23:52] <wgrant> Kill them all.
[23:52] <wgrant> I said the process count was infalted.
[23:52] <spm> ta
[23:52] <wgrant> But nobody mentioned those :/
[23:52] <wgrant> Actually.
[23:52] <wgrant> If you haven't killed them all.
[23:53] <wgrant> Maybe keep a couple around.
[23:53] <wgrant> jam might like to investigate.
[23:53] <lifeless> spm: (yes to db restore of qastaging)
[23:53] <wgrant> Although that's not enough to cause much of a problem.
[23:56] <wgrant> #44028
[23:56] <_mup_> Bug #44028: cups reports "printer fault" and refuses to print <cupsys (Ubuntu):Invalid> < https://launchpad.net/bugs/44028 >
[23:56] <wgrant> Er. ECHAN, but yeah.