[00:00] <bdmurray> okay, so creating a new permission name and adding it to permissions.zcml works
[00:01] <sinzui> bdmurray, we do not want to invent permission names
[00:01] <bdmurray> sinzui: that makes sense but where does that leave us?
[00:01] <deryck> Later on everyone.  until tomorrow
[00:02] <sinzui> bdmurray, I do not have a clear path. It took us more than a year to sort the mess out with IProduct, and CommercialAdmin still does not belong the the flacoste cannon.
[00:02] <sinzui> or canon
[00:03] <sinzui> either works for me
[00:06] <sinzui> bdmurray, I am strongly in favor of a Permission like BugEdit that grants supervisors permission to change bugtags and configure bug-trackers
[00:07] <sinzui> bdmurray, I believe the project owner is delegating responsibility to the supervisor to manage the bugs domain. I would expect this person to have the power to do his job.
[00:07] <bdmurray> sinzui: so a new permission that was used in multiple places would be agreeable then?
[00:08] <sinzui> I think we need more than me to agree on this.
[00:08] <sinzui> bdmurray, we have a launchpad.Driver permission
[00:09] <bdmurray> sinzui: from a social standpoint or a technical standpoint?
[00:10] <sinzui> social. The driver is a delegated role, and there is a launchpad.Driver. For the sake of symmetry, I expect launchpad.BugSupervisor
[00:11] <bdmurray> okay, fwiw I've spoken to deryck and the Ubuntu Tech Board about this
[00:12] <sinzui> bdmurray, when we talk about roles, responsibility, and permission, the bug supervisor and driver roles are not very clear, and in 6 months, they could be indistinguishable because of changes to access and notifications...
[00:12] <sinzui> but if there was a permission like BugSupervisor, there were be a clear way to discuss what that role does
[00:13] <bdmurray> yes, I think using a BugSupervisor permission makes sense too
[00:13] <sinzui> and I think if we updated Lp to use launchpad.BugSupervisor, we will discover that driver and supervisor will never converge after the privacy changes are mae
[00:15] <sinzui> bdmurray, lets assume launchpad.BugSupervisor will happen. update your checker and the zcml
[00:18] <sinzui> !!
[00:19] <sinzui> I now know why I am being inundated by requests to close projects. I have seen these projects listed in deryck's script. We have inadvertently reminded people they have dead projects.
[00:19] <bdmurray> yes, not notifying inactive projects might have been a good constraint
[00:20] <sinzui> how do we know they are inactive? if I knew that, I could write a process to deactivate them after 6 months or a year
[00:21] <bdmurray> I don't know but I went to one's page and it said it was inactive ...
[00:21] <bdmurray> https://edge.launchpad.net/10n-linuxme
[00:22] <sinzui> bdmurray, I search for those every 3 months
[00:22] <sinzui> I also deactivate about 2k of projects this year that had no license or artefacts
[00:23] <sinzui> karma cannot be used because milestones and releases to not generate karma
[00:23] <sinzui> and I know if the project is linked to another community like ubuntu, it cannot ever be deactivated,
[00:23]  * sinzui has 9 months to solve this before his goals are up for review
[00:28] <bdmurray> sinzui: if I made a merge proposal for my branch is that something you'd be willing to review?
[00:51] <wallyworld> lifeless: or someone? 2 days ago i landed a branch via pqm, got a success email, but the bug tag is still not updated to qa-needstesting and it's not merged into devel yet. is this expected or have i missed something?
[00:53] <lifeless> wallyworld: what branch did you merge it into ?
[00:53] <wallyworld> lifeless: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/
[00:53] <wallyworld> that was the submit target
[00:53] <lifeless> whats your branch?
[00:53] <wallyworld> bzr+ssh://bazaar.launchpad.net/~wallyworld/launchpad/windmill-1.3r1544
[00:56] <lifeless> wallyworld: no idea; send it again ?
[00:57] <lifeless> forward me the success message, I might be able to get some idea from pqm logs (they are on sodium, if you're interested in looking yourself)
[00:58] <wallyworld> lifeless: ok, i'll give it a go. that one from yesterday (sql logging) also needs to be resubmitted because of translation test failures on ec2. are these fixed now?
[00:58] <lifeless> 2010-10-05 20:14:45 INFO    Database replication lagged 11:06:29.567146. Sleeping up to 10 minutes.
[00:58] <wallyworld> lifeless: i'll look at the logs on sodium as well.
[00:58] <lifeless> bwahaha
[00:58] <lifeless> wallyworld: dunno about test failures
[00:58] <lifeless> wallyworld: I assume its all working all the time ;)
[00:59] <wallyworld> lifeless: yeah, should be but, AssertionError: Failed doctest test for 10-distro-translation-group.txt
[00:59] <wallyworld>   File "lib/lp/translations/tests/../stories/translationgroups/10-distro-translation-group.txt", line 0
[01:00] <wallyworld> can't see how it's at all related to a sql logging change that isn't even activated if the env variable is not set
[01:01] <lifeless> the failure details are later ;)
[01:01] <wallyworld> lifeless: canonical.testing.layers.LayerIsolationError: Librarian has been killed or has hung.Tests should use LibrarianLayer.hide() and LibrarianLayer.reveal() where possible, and ensure the Librarian is restarted if it absolutely must be shutdown: [Errno socket error] [Errno 111] Conne
[01:02] <wallyworld> looks like librarian layer has hung or something?
[01:02] <wallyworld> i knew the failure was later, just didn't want to cut n paste too much :-)
[01:03] <lifeless> that was discussed on the list
[01:03] <lifeless> its fixed
[01:03] <wallyworld> oh ok. thanks. i'm a bit behind in my email reading :-(
[01:04] <lifeless> de nada
[01:11] <lvh> Hello!
[01:11] <lvh> https://dev.launchpad.net/Running/VirtualMachine
[01:11] <lvh> Under Alternatively
[01:11] <lvh> Why does the vm need to be built as root
[01:12] <lifeless> I don't know! poolie came up with that recipe.
[01:12] <lifeless> he might know
[01:12] <poolie> lvh, i think that's just an implementation limitation of vm-builder
[01:13] <poolie> i think because it creates the image using debootstrap, and that creates a chroot, and that can only be done as root
[01:13] <poolie> imbw
[01:13] <wgrant> It needs to chroot, right.
[01:13] <lvh> Oooh. Okay, thanks.
[01:14] <wgrant> vm-builder doesn't use a VM.
[01:14] <lvh> wgrant: Before this recipe I used Virtualbox, hence the confusion.
[01:15] <wgrant> vm-builder doesn't install from an ISO, so it needs to be able to chroot in and install packages.
[01:15] <lvh> right
[01:15] <poolie> wgrant, well, it creates a chroot and then it moves it into a vm
[01:15] <wgrant> poolie: Right. But other VM solutions don't need root because they run the installer in a VM.
[01:16] <poolie> right
[01:16] <poolie> in theory vm-builder could support the same external interface and work by booting a network image within the vm
[01:17] <poolie> if you don't have root on the machine you want to use as the vm host i would suggest following the first set of instructions
[01:17] <poolie> they're similar, just a bit more manual
[01:23] <lvh> It's not really a big deal, I was just wondering :-)
[01:23] <lvh> It's still super-awesome that you people open-sourced lp.
[01:24] <wgrant> Why are you running it in a VM? To avoid destroying your system, or because you don't run Ubuntu?
[01:25] <lvh> wgrant: Former
[01:26] <lvh> wgrant: I virtualize pretty much everything all the time
[01:26] <wgrant> Sounds like a good policy,.
[01:26] <lvh> Well, I'm a Python guy
[01:26] <poolie> mm
[01:26] <lvh> Setuptools is a hard and cruel teacher.
[01:26] <lifeless> wallyworld: replied to your perf tuesday mail; backt o stacking wood for me.
[01:26] <wallyworld> lifeless:  thanks. i'll have a look
[01:27] <lvh> wgrant: Oh by the way, I noticed you guys are starting to do CD
[01:27] <lvh> That's really awesome, I used to do CD at my job and am now blogging about doing it in a reusable fashion.
[01:27]  * wgrant isn't actually quite one of those guys.
[01:27] <lvh> Has whoever it is responsble considered documenting this CD process?
[01:27] <lvh> wgrant: Whoops. Yeah, that "you" was plural
[01:27] <lvh> By which I mean whoever it is now doing CD on lp.
[01:28] <wgrant> lifeless knows a lot about that effort.
[01:28] <wgrant> But he's just run away.
[01:29] <wgrant> Most of it should be documented on dev.launchpad.net.
[01:29] <wgrant> https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone is the LEP.
[01:30] <wgrant> https://dev.launchpad.net/MergeWorkflow, https://dev.launchpad.net/QAProcessContinuousRollouts are relevant.
[01:30] <poolie> lifeless, nice public blog post btw
[01:31]  * poolie works out which of the 20 meanings of "CD" this is :)
[01:31] <poolie> lvh, i'm really pleased we're doing https://dev.launchpad.net/LEP/FeatureFlags now too
[01:31] <poolie> which is subsidiary to CD
[01:44] <lvh> poolie: I meant continuous deployment.
[01:45] <lvh> poolie: Not sure what the other ones are
[02:06] <lifeless> lvh: hi, yes, we are documenting it
[02:07] <lifeless> the LEP documents some specific changes, and links to the MergeWorkflow which links to the qa process and related automation
[02:07] <lifeless> we'll be open sourcing the qa toolchain soon
[02:10] <lifeless> wgrant: yes, rosetta stuff is failing
[02:10] <lifeless> wgrant: did you want the error report?
[02:12] <lvh> lifeless: Awesome!
[02:13] <lvh> lifeless: The only real problem I had implementing this myself was push notification
[02:13] <wgrant> lifeless: No, just wondering about the ec2 failure I had overnight.
[02:27] <lifeless> kk
[03:03] <poolie> lifeless, it would be nice to document the terminology around tasks, events, etc into the arch guide if it ever settles
[03:57] <rockstar> lifeless, https://code.edge.launchpad.net/~rockstar/launchpad/merge-queues-db/+merge/37686
[03:59] <rockstar> lifeless, (please)
[03:59]  * rockstar should learn some manners
[04:00] <lifeless> rockstar: it has a *huge* diff in it.
[04:09] <lifeless> mwhudson: hey
[04:09] <lifeless> mwhudson: do you think a third line by line review is needed of lp-service?
[04:09] <lifeless> mwhudson: spiv went at it hammer and tongs
[04:10] <rockstar> lifeless, the diff is huge because of sampledata.
[04:11] <rockstar> lifeless, the sampledata files are the bane of my existence.
[04:11] <lifeless> right, you need to use pg 8.4 nowadays
[04:11] <lifeless> rockstar: I hates them too.
[04:12] <mwhudson> lifeless: well, maybe not of the code, but i spotted a few little things that could do with fixing in comments & such
[04:12] <mwhudson> lifeless: i'll try to find some time to root them all out
[04:13] <lifeless> mwhudson: needs or nices
[04:14] <lifeless> mwhudson: if its nices, perhaps we can land and iterate?
[04:14] <mwhudson> one need
[04:45] <rockstar> lifeless, I used pg 8.4.  The diff would be a lot bigger otherwise.
[04:47] <rockstar> Oh crap.  Is it SERIOUSLY that big of a difference between 8.4.3 and 8.4.4?
[04:53] <lifeless> apparently
[05:02] <lifeless> stub: hey
[05:02] <stub> yo
[05:02] <lifeless> stub: I was wondering if its 8.4.3 vs 8.4.4 (the bug portlet query thing)
[05:04] <stub> Shouldn't be with a patch release, and we are running 8.4.4 everywhere anyway.
[05:05] <lifeless> ok
[05:06] <rockstar> stub, I put a review in for you.  Apparently there's something wrong with the sampledata that I'm trying to fix now, but the patch is ready for your eyes.
[05:10] <stub> rockstar: Sampledata isn't that bad - only one spurious table moving position. The other changes are for tables your patch touches.
[05:11] <rockstar> stub, yeah, I usually see changes like that in sampledata, but lifeless said in Needs Fixing, so I'm trying to Fixing.
[05:11] <stub> rockstar: The json configuration is a bit of a worry. Soyuz did the same thing several years ago with 'lucille_config' and have been bitching about it ever since.
[05:12] <stub> rockstar: You are running 8.4.3, latest is 8.4.4. That is the likely cause.
[05:12] <rockstar> stub, yeah, this json config thing will not be available to users on the frontend.  It's specifically for Tarmac.
[05:12] <rockstar> stub, basically, it's a way for Tarmac to get configs from Launchpad instead of having to configure it locally.
[05:13] <stub> rockstar: So should it be tarmac_configuration? Or is tarmac going to be mushed into Launchpad and lose its identity as a separate product?
[05:14] <rockstar> stub, well, I don't want to shut out something better from coming along (if something better CAN come along)
[05:14] <stub> rockstar: Is the name column for use in URLs, or is it the displayname?
[05:15] <rockstar> stub, ah, yeah, we _might_ need it in the urls (I'm still only doing the data model right now).  I guess that means that it needs an index.
[05:15] <stub> I'm thinking about a valid_name() CHECK constraint
[05:16] <stub> Shouldn't need an index, as we will be looking it up in conjunction with the owner and there is already an index for that
[05:16] <rockstar> stub, hm, I've never seen a valid_name CHECK constraint, but I'm happy to add it if you can give me an example.
[05:17] <stub> Sure. I'll add it with the needed indexes.
[05:18] <stub> rockstar: So there is no comment on Branch.merge_queue_config. I'm wondering if that is redundant, or why it is different from BranchMergeQueue.configuration
[05:18] <rockstar> stub, so the branch and the queue can both have config values.
[05:18] <stub> And tarmac munges them together into a single config?
[05:18] <rockstar> stub, yeah, kinda.
[05:19] <rockstar> Currently, it actually un-munges them apart for certain contexts.
[05:26] <rockstar> Huh, launchpad-developer-dependencies is broken in the PPA for maverick...
[05:26] <rockstar> *sigh*
[05:28] <rockstar> stub, there's a comment for Branch.merge_queue_config but wasn't one for Branch.merge_queue - I'm remedied this.
[05:28] <stub> oic
[05:32] <rockstar> stub, does this look right? http://pastebin.ubuntu.com/507002/
[05:35] <stub> I've just put in the review
[05:36] <stub> rockstar: Mostly fine. Its missing a comma on the preceding line.
[05:36] <rockstar> stub, yeah, I just found that the hard way.
[05:36] <lifeless> wallyworld: so that test failure looks like the ff *package* rather than ff *product* is showing up
[05:37] <stub> Possibly an ordering problem
[05:38] <rockstar> stub, why do you need an index on BranchMergeQueue.registrant?
[05:38] <wgrant> rockstar: Missing python-codespeak-lib?
[05:38] <stub> rockstar: Because we need an index on every reference to the Person table or the person merge code becomes glacial.
[05:38] <lifeless> stub: as opposed to ? :P
[05:38] <rockstar> stub, ah, okay.
[05:39] <stub> rockstar: Similar with references to LibraryFileAlias and the librarian garbage collector.
[05:39] <wallyworld> lifeless: if the doc test is actually incorrect, how did it get so that it was included in my test run? wouldn't the landing of that other branch have been rejected?
[05:39] <lifeless> wallyworld: my experience has been that usually my change managed to break something nonobvious
[05:40] <stub> wallyworld: There are some tests that rely on ordering returned by PostgreSQL rather than. These can explode at any time.
[05:40] <rockstar> wgrant, it looks related to python-pocket-lint
[05:40] <wgrant> rockstar: There is a known issue with python-codespeak-lib having been renamed to python-py.
[05:40] <wgrant> launchpad-developer-dependencies depends on that.
[05:40] <rockstar> wgrant, http://pastebin.ubuntu.com/507006/
[05:41] <wallyworld> lifeless: ok, i'll recheck. but the my branch is for the sql logging enhancement and the code isn't even activated unless an env var is set. still, i may have missed something
[05:41] <rockstar> wgrant, apparently python-pocket-lint has no installation candidate.
[05:41] <lifeless> wallyworld: bzr diff -r ancestor:../devel | less
[05:41] <lifeless> wallyworld: is a useful way to see whats really different in your branch
[05:41] <rockstar> wgrant, this is on a fresh maverick chroot and rocketfuel-setup
[05:42] <wgrant> rockstar: sinzui uploaded a new pocket-lint yesterday, and the bug ate maverick's copy.
[05:42] <wgrant> We can probably just copy the new one up from lucid.
[05:42] <rockstar> wgrant, okay, is there a fix planned?
[05:42]  * rockstar should probably go read the list...
[05:43] <wgrant> sinzui: Is there a reason that pocket-lint 0.5.5 is only in lucid?
[05:43] <mwhudson> surely launchpad-developer-dependencies doesn't need to depend on py.test any more?
[05:43] <wgrant> How is production-devel looking?
[05:43] <wgrant> Has buildbot blessed it since my fix landed?
[05:43] <lifeless> wgrant: unchanged
[05:43] <lifeless> wgrant: your fix?
[05:44] <wgrant> lifeless: The fix to unfuck Soyuz.
[05:44] <wgrant> _getOtherPublications blah blah.
[05:44] <lifeless> the last I heard was this ProcessAlreadyExited thing
[05:44] <lifeless> is that what you're talking about?
[05:45] <lifeless> twisted.internet.error.ProcessExitedAlready
[05:45] <rockstar> wgrant, Soyuz can be unfucked?
[05:45] <rockstar> :)
[05:45] <wallyworld> lifeless: just checked - the diff is the same as shown on the original mp. ie some extra coding code inside an if block. nothing else. sigh.
[05:45] <lifeless> wgrant: this is what rev 11595 or whatever was meant to fix, but thats in prod-devel and it still fails.
[05:45] <lifeless> wallyworld: throw it at ec2 again :(
[05:45] <wallyworld> s/coding/logging
[05:45] <lifeless> wallyworld: if the test passes locally.
[05:45] <wallyworld> lifeless: will do 4th time lucky hopefully
[05:45] <lifeless> (the failing test I mean)
[05:46] <wallyworld> yeah, i knew what you meant :-)
[05:46] <lifeless> try merging devel into your branch and running the failing test.
[05:46] <wallyworld> just did that before i ran the diff :-)
[05:46] <lifeless> k
[05:47] <wgrant> rockstar: Hopefully, yes.
[05:47] <wgrant> lifeless: bigjools CP'd something last night for me. That's all I know.
[05:47] <rockstar> wgrant, does it involve a Delorian?
[05:47] <wgrant> rockstar: That would be nice, but I think we can work around the lack of one.
[05:48] <rockstar> wgrant, reminds me of this tweet: http://twitter.com/#!/rockstar_/status/26408378955
[05:48] <wgrant> Heh.
[05:48] <wgrant> Sometimes it would be nice to go back and fix the data model, but we're a few years too late :(
[05:49] <wallyworld> lifeless: test passes locally. will try ec2 again. wish me luck :-)
[05:50] <rockstar> wgrant, yeah. I find myself saying that about a lot of things, so much so that I'm afraid to make NEW data models, for fear that I'll be cursing the person who created the data model in a year.
[05:50] <wgrant> Eh, Code's is trivial in comparion. And it's fixable.
[05:51] <rockstar> wgrant, yeah, but source package recipes isn't really "code."  It's kinda the fence between the US and Mexico.
[05:51] <rockstar> In the "kinda broken, probably full of holes, but politicians sure love talkin' about it"
[05:51] <rockstar> ...sense.
[05:52] <wgrant> We'll get there eventually.
[05:53] <wgrant> lifeless: So production-devel is still broken, so we probably won't be rolling out any fixes from it tonight?
[06:02] <mwhudson> lifeless: i just did a line by line review of lp-service
[06:11] <lifeless> wgrant: until someone figures out whats wrong, no.
[06:11] <lifeless> wgrant: hang a sec
[06:13] <lifeless> mwhudson: thank you!
[06:14] <lifeless> wgrant: lp:~lifeless/launchpad/cp
[06:16] <wgrant> The rev I'm interested in isn't in that lot.
[06:16] <lifeless> I just pushed r 9785
[06:16] <lifeless> and forwarded you mail
[06:17] <wgrant> Ah, 9784.
[06:17] <wgrant> Hm, I see.
[06:17] <wgrant> That is odd.
[06:17] <wgrant> Which was the last blessed rev?
[06:18] <wgrant> 9779?
[06:20] <lifeless> hit launchpad.net
[06:20] <lifeless> press ctrl-U
[06:21] <wgrant> .... what.
[06:21] <wgrant> So it hasn't broken since then. It already was. Great.
[06:21] <lifeless>     r9783
[06:21] <wgrant> Yep.
[06:21] <lifeless> is blessed and deployed
[06:22] <wgrant> And neither 9784 nor 9785 could have caused that failure.
[06:22] <lifeless> I can press 'build again' for kicks.
[07:02] <wgrant> Hm, U1 is actually getting somewhere.
[07:02] <wgrant> Finally!
[07:02] <poolie> mm?
[07:03] <wgrant> The website no longer sucks and they are offering new features.
[07:03] <wgrant> And contact syncing is turned on again.
[07:03] <wgrant> And I haven't found any critical security flaws in a while.
[07:03] <poolie> heh
[07:09] <lifeless> wgrant: glad to see you looking on the bright side
[07:10] <bac> hi danilos
[07:11] <wgrant> lifeless: Well, there *is* a bright side now :)
[07:11] <poolie> hi bac
[07:11] <wgrant> For example, I can no longer erase your filesystem by getting you to click a link.
[07:11] <poolie> there's alwaysa  bright side
[07:11] <bac> hi poolie
[07:11] <bac> bye poolie
[07:11] <wgrant> Heh.
[07:12] <poolie> however, C-w in xchat being bound to 'close tab' is not a bright side :)
[07:12] <wgrant> That always hits me when filing bugs.
[07:13] <poolie> argh, i just remembered that when i used emacs and firefox, meta-q was fatal
[07:13] <poolie> soooo awful
[07:13] <poolie> i think they eventually removed it
[07:16] <lifeless> I think I'll use this evening...
[07:16] <lifeless> to ...
[07:16] <lifeless> write some code!
[07:17] <wgrant> !!!
[07:17] <wgrant> How is the tokenised staging librarian going?
[07:17] <lifeless> wgrant: you know what happens when you've got more items to service than servicers?
[07:17] <lifeless> wgrant: thrashing... thats what.
[07:17] <lifeless> wgrant: [its up there with the other highest-priority-we-have LP tickets]
[07:18] <lifeless> wgrant: my first couple of weeks in the job could be paraphrased as 'saturate the losa queue till christmas. Thanks.'
[07:18] <wgrant> Hah.
[07:18] <lifeless> spm: am I wrong?
[07:18] <spm> which year, for christmas, has been left undefined.
[07:18] <wgrant> We don't have that new LOSA yet? :(
[07:19] <lifeless> spm: lol
[07:19] <poolie> the last thing we need is more code :)
[07:20] <spm> wgrant: not yet, we had 3 interviews "today" tho
[07:20] <lifeless> wgrant: I've got >10 tickets at or above pri 80
[07:20] <lifeless> wgrant: nearly all are RFWTAD items
[07:21] <lifeless> wgrant: rt 41202 is the tokenised librarian, its top equal with 3 others, in the LP queue.
[07:23] <lifeless> spm: can I get profiling on staging pretty please?
[07:24] <spm> yah, give us a sec tho. just kick off the slow bit on this update
[07:38] <lifeless> wgrant: can you reproduce the failure?
[07:38] <lifeless> wgrant: it might be a python 2.5 thing.
[07:39] <wgrant> lifeless: I don't know where the failure is.
[07:39] <lifeless> WOW
[07:39] <lifeless> bah
[07:39] <lifeless> wow
[07:39] <wgrant> buildbot emails don't detail the failure.
[07:40] <lifeless> Person:+branding 65 1845.67 411.42
[07:40] <wgrant> Which is pretty awesome.
[07:40] <lifeless> wgrant: huh, sure it did
[07:40] <lifeless> mmm
[07:41] <wgrant> I know that some test failed with that error, but only because Julian said so.
[07:41] <StevenK> They don't, you need access to buildbot to see it
[07:41] <StevenK> FWIW, I can't reproduce it locally
[07:42] <lifeless> StevenK: using production-devel?
[07:43] <StevenK> Yup
[07:43] <lifeless> wgrant: privmsged you
[07:45] <wgrant> I don't see any actual errors in that.
[07:45] <wgrant> Just a lot of noise...
[07:50] <lifeless> wgrant: StevenK: I suspect a python 2.5 issue
[07:50] <lifeless> like the one stub found with filenotfound errors raising different exceptions
[07:50] <wgrant> So, it's unrelated to the one fixed in r11594
[07:50] <wgrant> This error happens when the slave breaks horribly.
[07:50] <StevenK> Bleh, you say after I purged python2.5 yesterday
[07:51] <wgrant> lifeless: It's not showing up in lp or db_lp, though?
[07:52] <lifeless> because they are fucked
[07:52] <lifeless> and don't work at all
[07:53] <wgrant> Well, that's encouraging.
[07:53] <lifeless> yeah
[07:53] <lifeless> we're || close to having wildcherry migrated
[07:53] <wgrant> Wildcherry's happening tonight, yeah?
[07:53] <lifeless> downtime in 7 minutes or so and then tomorrow to switch back
[07:54] <lifeless> spm: tell me when ;P
[07:57] <StevenK> lifeless:   File "/home/steven/launchpad/lp-branches/production-devel/parts/scripts/site.py", line 143
[07:57] <StevenK>     with f:
[07:59] <wgrant> StevenK: You probably need to rebuild your tree for 2.5.
[07:59] <StevenK> Fixing that gives: TypeError: bzrlib._static_tuple_c.StaticTuple is not a type object
[07:59] <wgrant> site.py isn't under version control.
[07:59] <StevenK> Right
[07:59]  * StevenK does so
[08:00] <spm> lifeless: gah. sorry. is restarting now
[08:02] <wgrant> WTF
[08:02] <wgrant> 2010-10-06 12:32:14+0530 [HTTPChannel,1,127.0.0.1] 127.0.0.1 - - [06/Oct/2010:07:02:14 +0000] "POST /rpc/rpc HTTP/1.0" 200 148 "-" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
[08:02] <wgrant> When I run the test locally, that ends up in /var/tmp/buildd/build-slave.
[08:03] <wgrant> Er, /var/tmp/build-slave.log.
[08:03] <wgrant> That's a very odd timezone.
[08:03] <poolie> that control to turn on expiry is kind of hard to find
[08:03] <poolie> being under "Bugs are tracked where"
[08:03] <lifeless> poolie: file a bug :)
[08:04] <StevenK> wgrant: +0530 is a twisted's default timezone, I think
[08:04] <StevenK> wgrant: I came across it during sftp hacking, and jml told me why, I just can't recall
[08:04] <wgrant> To try to break everything that exists, probably...
[08:04] <poolie> somewhere in india?
[08:05] <StevenK> I think so
[08:05] <lifeless> +1230 would be better
[08:06] <poolie> right
[08:06] <StevenK> +0530 is Indian Standard Time
[08:08] <StevenK> +1230 doesn't exist, +1245 is the closest
[08:08] <lifeless> spm: still here?
[08:09] <spm> yup; sorta. doing the incident report for forster/mailman
[08:09] <lifeless> do the profile files rsync on cron
[08:09] <lifeless> or is it totally manual-when-asked?
[08:12] <lifeless> spm: ^
[08:13] <StevenK> lifeless: Can't reproduce with python 2.5 either
[08:17] <wgrant> StevenK: What does your slave log say?
[08:18] <StevenK> wgrant: http://pastebin.ubuntu.com/507065/
[08:18] <wgrant> Right, same here.
[08:18] <wgrant> The one in the failure finishes INIT and starts on UNPACK.
[08:18] <stub> We set the timezone in the test runner to India to catch bugs.
[08:23] <wgrant> It's possible that the production-devel buildbot sucks at timing.
[08:23] <wgrant> The test is probably racy.
[08:24] <lifeless> it was run twice in a row
[08:24] <lifeless> is it the new test?
[08:25] <StevenK> Bleh! This branch is cursed
[08:25] <wgrant> Aha.
[08:25] <wgrant> Adding a time.sleep(1) makes it explode. Not the same way, though.
[08:26] <wgrant> So the test is racy.
[08:26] <wgrant> I think the buildbot might just manage to run the buildd further than my laptop can, so it dies before the test can abort it.
[08:28] <wgrant> That error is well-known by anyone who runs the buildd locally, so it's been around forever.
[08:28] <lifeless> ok
[08:28] <lifeless> so you can fix?
[08:28] <wgrant> Is the test new, do you know?
[08:28] <wgrant> I suspect it is.
[08:29] <wgrant> It is.
[08:29] <lifeless> its new in 9780
[08:29] <lifeless> which is passed and deployed
[08:30] <wgrant> That only means it needed to succeed once, though.
[08:30] <lifeless> 4 times
[08:30] <lifeless> I'll force a build
[08:31] <wgrant> If this doesn't work, I'd disable it. It's not testing anything new, and the whole slave testing framework is broken anyway.
[08:32] <StevenK> wgrant: Isn't Julian fixing that with his new branch
[08:32] <StevenK> ?
[08:32] <wgrant> He's not fixing the slave, but he's probably replacing that bit of the master.
[08:32] <wgrant> Basically, the slave test config works OK for the first couple of hundred milliseconds of a build.
[08:32] <wgrant> After that it explodes spectacularly.
[08:32] <StevenK> And most of the tests are probably touched/re-written
[08:33] <wgrant> We could probably fix it by replacing the test config's unpack command with a sleep.
[08:33] <wgrant> And probably cleanup too.
[08:36] <lifeless> spm: ping
[08:37] <spm> lifeless: sorry, the logs should sync every so often; but iof not there; I'll prod
[08:37] <lifeless> please do; if you can tell me the frequency and phase I'll bother you less
[08:38] <spm> normally every 3 or 6 minutes
[08:38] <lifeless> well, I left it 20 minutes
[08:39] <adeuring> good morning
[08:58] <mrevell> Hello
[09:04] <danilos> bac, hey-hey (sorry, I start late on Wednesdays :)
[09:04] <wgrant> bigjools: Morning.
[09:04] <bac> np, danilos
[09:05] <danilos> bac, how's it going?
[09:05] <bac> danilos: i was wondering if you could look at a patch for me?
[09:05] <bac> http://pastebin.ubuntu.com/507036/
[09:05] <danilos> bac, sure
[09:07] <bac> danilos: i'm trying to insert the robots "noindex" conditionally.  for some reason, even when context/translatables returns products, the noindex is inserted.
[09:07] <bigjools> morning
[09:07] <bac> danilos: so the last test at line 66 fails
[09:07] <bac> hi bigjools.
[09:08] <bigjools> hey bac, how's the orient?
[09:08] <bac> bigjools: having a good time,thanks
[09:09] <lifeless> wow 1 second in 'currentseries'
[09:10] <danilos> bac, right, give me a minute, otp
[09:10] <bac> danilos: ok
[09:11] <bigjools> bac: cool - have you been before?
[09:11] <bac> bigjools: yeah.  this is my fifth trip since 2000.
[09:12] <bac> bigjools: the smog is about to choke me to death, though.  :(
[09:12] <bigjools> bac: urgh :(
[09:13] <bigjools> jml: around yet?
[09:13] <bac> it's breezy and temperate out but i've had to seal up the apartment and turn on the AC.
[09:13] <wgrant> Should I be concerned that my first thought upon seeing "breezy" was "must... kill... sampledata"?
[09:15] <lifeless> losa: can disable staging profiling - thanks.
[09:15] <bigjools> wgrant: it must die but approx 1 million tests will need fixing
[09:15] <wgrant> bigjools: Speaking of tests, have you seen the wonderful probably-race in production buildbot?
[09:16] <bigjools> wgrant: yes
[09:16] <bigjools> currently trying to work out wtf is going on
[09:16] <wgrant> I'm pretty sure it's a race. Try adding a time.sleep(1) in that test.
[09:16] <wgrant> Boom.
[09:16] <wgrant> Different, but very similar, failure.
[09:17] <wgrant> The test slave setup is known to be crap.
[09:17] <bigjools> problem is, why is it happening now?
[09:17] <bigjools> nothing's landed there for ages
[09:17] <wgrant> The test has only been around for a couple of weeks.
[09:17] <wgrant> It last passed the production buildbot two revisions ago. And it's clear that neither of them broke it.
[09:17] <bac> wgrant: which test are you discussing?
[09:18] <wgrant> lp.buildmaster.tests.test_builder.TestSlave.test_abort
[09:18]  * bigjools stabs layers
[09:19] <bigjools> ah that is one of the new tests indeed
[09:19] <wgrant> It was added only two weeks ago.
[09:19] <bigjools> I know what the problem is then
[09:20] <wgrant> Oh?
[09:20] <bigjools> race condition
[09:20] <bigjools> same sort of thing that I fixed recently in the buildd-manager
[09:20] <wgrant> Sort of.
[09:20] <wgrant> There are two issues.
[09:20] <wgrant> The ProcessExitedAlready thing is not the main one.
[09:20] <wgrant> It will still break if you fix that.
[09:20] <bigjools> really?
[09:21] <wgrant> The test slave will pretty quickly fail and end up no longer BUILDING.
[09:21] <wgrant> So the abort will fail.
[09:22] <wgrant> That's what happens if you add the sleep into the test.
[09:23] <wgrant> The ProcessExitedAlready probably happens when the test aborts it at the wrong time. When I run the unmodified test locally, it never makes it out of the INIT stage.
[09:23] <wgrant> The buildbot log I've seen showed it get into and fail UNPACK, then get into CLEANUP, start to fail that, then get aborted.
[09:25] <bigjools> I don't understand why you think catching that exception won;t work
[09:25] <wgrant> The root cause is that the test slave config is only good if you abort it before the build gets anywhere.
[09:26]  * bigjools files bug and disables test
[09:26]  * bac should pay more attenting to those LP downtime messages...
[09:26] <wgrant> We've overrun the window by a long time.
[09:26] <wgrant> So that wouldn't have helped.
[09:27] <lifeless> stub: ping
[09:27] <stub> lifeless: pong
[09:28] <wgrant> bigjools: 	exceptions.ValueError: Slave is not BUILDING when asked to abort
[09:28] <lifeless> what do you think of the idea of caching 'distro.currentseries' rather than calculating it every time?
[09:29] <bigjools> hmm didn't see that
[09:29] <wgrant> bug #236925
[09:29] <_mup_> Bug #236925: Make Distribution.currentseries an explicit DB column <tech-debt> <Soyuz:Triaged> <https://launchpad.net/bugs/236925>
[09:29] <wgrant> lifeless: ^^
[09:29] <wgrant> bigjools: That's what remains of the race if the buildbot exception doesn't occur.
[09:29] <lifeless> wgrant: hah
[09:29] <bigjools> wgrant: ok
[09:29] <lifeless> wgrant: well, see my mail just sent.
[09:29] <lifeless> wgrant: 1 second of bug one is in figuring that out and returning the series object.
[09:30] <lifeless> wgrant: for 6 distros
[09:30] <danilos> bac, you seem to be setting usage on product, whereas a view is on project group, could that be related?
[09:30] <bac> danilos: the usage for a project group is determined by its products
[09:31] <bac> danilos: i'm really stumped, b/c the test at line 49 passes, showing the PG has translatables and that is the condition in the TAL expression
[09:32] <wgrant> lifeless: How is that query so awful?
[09:33] <danilos> bac, I don't think we are doing anything special in there for project groups in translations
[09:34] <lifeless> wgrant: 200ms on avg
[09:34] <wgrant> lifeless: That sounds like a bug.
[09:35] <lifeless> (1sec/6 actually)
[09:35] <wgrant> Hm.
[09:35] <danilos> bac, have you seen an XXX by jcsackett on projectgroup.translatables though (though, I don't expect that'll help much)
[09:35] <wgrant> Something is fairly broken.
[09:35] <lifeless> it load all the series
[09:35] <wgrant> We seem to be out of read-only, but sessions aren't working.
[09:35] <bac> danilos: i did.  i've checked that the two states are in sync.
[09:35] <wgrant> Ah, there we go.
[09:36] <danilos> bac, so I'd say something is wrong with usage determination for project groups (I don't know how's that done)
[09:37] <bac> danilos: ok, thanks for looking.  i thought there might've been something translation-specific i was overlooking, such as earlier when i didn't create a POTemplate for the product
[09:38] <gmb> Anyone else getting "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist." when trying to push to LP?
[09:38] <gmb> Hmm. SSH key failure. That's weird...
[09:38] <gmb> Oh.
[09:38] <gmb> Wait.
[09:38] <gmb> never mind.
[09:38] <wgrant> We just came out of readonly a few minutes ago.
[09:38] <wgrant> Doesn't quite explain it, though.
[09:38] <gmb> wgrant: Yeah, I know what hte problem is.
[09:38] <gmb> Basically, bits of my disk have gone away. This happens.
[09:39] <bac> wgrant: web is back but code hosting isn't
[09:39]  * gmb reboots; bbiafm.
[09:39] <gmb> Aha.
[09:39] <gmb> So, separate problem.
[09:41] <danilos> bac, sorry, but I don't know how you decide if robots meta tag needs to be added or not, and I think that's what's important here; in general, a requirement for a template in a product is still there, but that depends on what condition exactly are you using when generating robots stuff
[09:41] <wgrant> bac: "Permission denied" doesn't seem like an excellent failure mode for that.
[09:41] <bac> wgrant: nope
[09:42] <bac> wgrant: you said bazaar.lp.net takes longer to come back.  why and how much?
[09:42] <bac> danilos: the test is just condition="context/translatables" but i assume you see that in the patch.  are you asking something else?
[09:43] <wgrant> bac: I'm not sure why. It may be because the LOSAs just take a while to start it back up...
[09:43] <bac> it is back
[09:44] <gmb> \0/ login dance
[09:44] <wgrant> Yes, the sessions seem to have evaporated.
[09:44] <danilos> bac, right, I am not sure what's going on and it looks very, very weird
[09:44] <wgrant> And authentication didn't work for a while.
[09:45] <bac> danilos: yeah, thanks for looking.
[09:45] <jml> bigjools: yeah, around now, sort of.
[09:46] <bigjools> jml: can you look at the prod_lp buildbot output, the test_abort that we added is failing.  I'm going to disable it as I don't think there's a quick fix but you might see differently.
[09:48] <jml> bigjools: at a first glance it looks like a race: a bug in the slave maybe
[09:48] <bigjools> jml: we're not waiting for the build to start before trying to kill it
[09:49] <wgrant> The issue is more that you're waiting too long, so the test config crashes.
[09:49] <jml> in either case, bug in the slave
[09:49] <jml> it's a server, it should handle people asking it to do things
[09:49] <bigjools> yes
[09:50] <bigjools> as I discussed with wgrant above, we need to catch that ProcessAlreadyExcepted and also deal with trying to abort something that's not started
[09:51] <jml> yeah, that sounds about right
[09:51] <wgrant> Or just fix the test config to sleep a lot.
[09:51] <bigjools> no :)
[09:52] <wgrant> The problem is that it gets too far. Not that it doesn't get far enough.
[09:52] <wgrant> Adding sleeps won't delay the test suite.
[09:52] <bigjools> I filed a bug 655559 about it
[09:52] <jml> wgrant: even so, the slave should catch the ProcessAlreadyExited exception
[09:52] <_mup_> Bug #655559: test_builder.py / test_abort is failing on buildbot, but not locally <tech-debt> <Soyuz:Triaged> <https://launchpad.net/bugs/655559>
[09:54] <wgrant> jml: Indeed. It happens a bit locally.
[09:54] <wgrant> But blah twisted blah confusing.
[09:55] <jml> not at all.
[09:55] <jml> try: kill_process(); except ProcessAlreadyExited: pass # yay less work for me
[09:56] <bigjools> I wonder if in this case it should not be raising exceptions here, the vast majority of use cases don't care if it's already exited.
[09:56] <lifeless> gmb: so talk to me
[09:57] <bigjools> a return value would be sufficient if you need to know
[09:57] <jml> bigjools: I don't know the use case here, but lots of similar code just swallows the exception
[09:57] <jml> bigjools: it's not so much "kill the process" as "ensure that it's dead"
[09:58] <bigjools> jml: yes - that points to a flaw in the API IMO
[09:58] <jml> bigjools: file a ticket on Twisted if you'd like
[09:58] <bigjools> mebbe
[09:58] <wgrant> jml: OK then, "but blah twisted blah confusing blah slave blah untested."
[09:59] <jml> wgrant: the slave is not going to get any better thinking that way
[10:01] <jml> noodles775: I can't see the ec2 test details you mentioned in your email
[10:02] <noodles775> jml: in the attached file on the message to launchpad-dev? (652838-select-diffs-for-syncing-r9844.subunit.gz)
[10:08] <jml> noodles775: subject?
[10:09] <noodles775> jml: '"ec2 land" and "ec2 test" results should be truthful once more' sent 18 minutes ago.
[10:10] <jml> noodles775: nope, not there.
[10:11] <wgrant> There were ML issues a few hours ago.
[10:11] <wgrant> May still be broken.
[10:11] <noodles775> Seems so, I'll forward it directly.
[10:21] <jml> noodles775: thanks.
[10:23] <gmb> lifeless: So, have you looked at the diff attached to that merge proposal (I'm assuming that that's what you want me to talk to you about)?
[10:23] <lifeless> gmb: yes, and replied.
[10:23] <lifeless> gmb: I suspect your best bet is
[10:23] <gmb> Ah, just saw your reply.
[10:25] <lifeless> bah
[10:25] <lifeless> I suspect your best bet is not splitting the code up
[10:25] <jml> noodles775: which windmill test failed?
[10:25] <lifeless> -or-
[10:25] <lifeless> change the contract for getSFP to not return a resultset
[10:25] <lifeless> and then store the result in a cachedpropery
[10:25] <lifeless> like
[10:25] <lifeless> @cachedproperty
[10:26] <lifeless> def _subscribers_for_persons(self): return {}
[10:26] <noodles775> jml: sorry, I should have included that in the email: test_diff_extra_details_blacklisting
[10:26] <jml> noodles775: interesting
[10:28] <jml> noodles775: something is really borked here. there's way more failures than just that in this test run
[10:28] <lifeless> gmb: and then assign results into that if person is not in self._subscribers_for_persons, or roughly that.
[10:28] <gmb> lifeless: Hmm. Well, we *need* to split the code up for the sake of finishing the better-bug-subscriptions story, so I guess changing the way getSFP works would have to be the way to go.
[10:29] <lifeless> gmb: alternatively, making sure that you don't use *any* subscribers etc other than in the new view's template.
[10:29] <noodles775> jml: what's an example I can search for?
[10:29] <lifeless> the problem is that multiple views is a sure fire way to get potato programming
[10:29] <gmb> lifeless: I don't think that leaving the loop / list() in there will slow the old view down though (that's where the XXX is, btw) because the loop is already there; I've just removed the contents.
[10:29] <jml> noodles775: well, just search for 'failure:' or 'error:'
[10:29] <lifeless> gmb: it will
[10:29] <jml> noodles775: or 10-distro-translation-group_txt
[10:30] <jml> umm, the regex ^error: will work better
[10:30] <lifeless> gmb: well, I'm assuming you're calling into the new template ?
[10:30] <noodles775> jml: I did searcth for failure... (lots of tests have that in their name). I'll take a look soon (just otp)
[10:30] <gmb> lifeless: Let's back up a second...
[10:30] <lifeless> gmb: if you're not, then just list() the getSFP and you're done
[10:30] <gmb> lifeless: Right.
[10:31] <lifeless> (but it would be a good idea to stop generating subscribers *at all* for the non-javascript version.
[10:31] <gmb> Agreed.
[10:31] <lifeless> that or get rid of the separate javascript version.
[10:31] <jml> noodles775: the colon is important.
[10:31] <lifeless> because we're doing the work twice at the moment.
[10:31] <gmb> lifeless: That's what splitting the code will allow us to do.
[10:31] <jml> lifeless: subunit is buggy.
[10:31] <lifeless> jml: all code is.
[10:32] <lifeless> jml: I'd love to talk more about this right now, but if I don't halt(), I'll have had way too little sleep at 6am for the tl meeting.
[10:32] <jml> lifeless: understood.
[10:32] <jml> lifeless: sleep well.
[10:32] <lifeless> gmb: may the force be with you. Or something.
[10:32] <gmb> lifeless: Thanks. Enjoy your evening and may LP not be too broken when you awake.
[10:33] <jml> noodles775: I think I've figured it out.
[10:33] <wgrant> bigjools: Have all the sparc/ia64 pubs been fixed for good? The archive freezes rather soon.
[10:34] <jml> noodles775: let me know when you're off the phone. I'd like to talk it through.
[10:45] <noodles775> jml: back... did you want to mumble, or chat here?
[10:45] <jml> noodles775: chat here is good.
[10:46] <jml> noodles775: if you grep for the LayerIsolationError, you'll see that there are no actual errors before then, and any errors after them were not reported
[10:46] <jml> noodles775: something about it is messing up subunit's parsing
[10:46] <noodles775> Right.
[10:46] <jml> noodles775: if you look in lib/devscripts/ec2test/remote.py, in the  test() method (line 274) you'll see the guts of ec2 test
[10:47] <jml> noodles775: there's some code there like:
[10:47] <jml>             # The process could have an error not indicated by an actual test
[10:47] <jml>             # result nor by a raised exception
[10:47] <jml>             if result.wasSuccessful() and retcode:
[10:47] <jml>                 raise NonZeroExitCode(retcode)
[10:48] <noodles775> I'm hoping the windmill failure that I had (which was reproducible locally with FF, but not Chromium) was the only real error (ie. not related to the librarian failure)
[10:48]  * noodles775 checks buildbot waterfall.
[10:48] <jml> I guess I'd like to know how bin/test managed to have a failed test result but still returned a zero exit code
[10:49] <jml> or if remote.py is buggy in this regard.
[10:49] <bigjools> wgrant: no it's still screwed
[10:49] <bigjools> I've no idea why at the moment
[10:49] <bigjools> a-f keeps publishing the Packages file after it's deleted
[10:49] <noodles775> OK, so it seems the windmill test was the only real failure - great (as this branch obviously landed).
[10:50] <wgrant> bigjools: I guess I'll try to fix it locally. The key bit is getting it out of Release.
[10:50] <jml> noodles775: in any case, I'm going to try to write a fix for this in subunit
[10:50] <wgrant> Everything else is just a bonus, since we can delete Packages and Sources later.
[10:50] <bigjools> wgrant: cheers
[10:50] <jml> noodles775: unfortunately I have no idea how to deploy that fix to our ec2 instances.
[10:51]  * bigjools sighs at PQM taking *so freaking long* to land a branch
[10:51] <wgrant> bigjools: Disabling that test?
[10:51] <bigjools> yes
[10:51] <bigjools> there was a branch in front of mine
[10:52] <wgrant> Yay.
[10:52] <bigjools> and mine's still getting processed
[10:52] <bigjools> this is ridiculous
[10:52] <jml> bigjools: I've filed an RT about it.
[10:52] <bigjools> to land something in PQM is now taking longer than the entire test suite when I first started on LP
[10:52] <bigjools> jml: yay - but do you know what can be done?
[10:53] <wgrant> What takes all the time?
[10:53] <jml> bigjools: well, the RT is mostly asking to give me & other developers access to the config so we can even begin to debug the problem.
[10:53] <wgrant> sn't it just... a merge and grep?
[10:53] <bigjools> I think it runs a make before merging
[10:53] <jml> who knows!
[10:53] <jml> that's the point
[10:53] <jml> silly to talk about what it might do when there's a file on a computer somewhere that could end all speculation
[10:54] <wgrant> But even that won't take very long, unless prasé's a 386...
[10:54] <noodles775> jml: From memory henninge wrote up some instructions after he updated some package versions for ec2, or did you mean something else?
[10:54] <jml> noodles775: oh, mostly I just mean that it's another complex step that I guess I'll figure out when the time comes ):
[10:54] <jml> that was meant to be a smile
[10:54] <noodles775> Yep.
[10:57] <wgrant> bigjools: Is there a bug?
[10:58] <bigjools> wgrant: bug 648715 might fit
[10:58] <_mup_> Bug #648715: Binary publications should not be created for disabled architectures <qa-ok> <soyuz-publish> <Soyuz:Fix Committed by julian-edwards> <https://launchpad.net/bugs/648715>
[10:58] <bigjools> I verified that new Packages entries are not written
[10:58] <wgrant> I don't think so. I'll file a new.
[10:58] <bigjools> yeah
[10:58] <wgrant> +one
[10:59] <bigjools> but the Packages file itself is renewed, for some reason
[10:59] <wgrant> Well, it's fairly clear why. It'll be a simple fix.
[11:04] <bigjools> I haven't looked into it yet because I'm busy cleaning up your bug ;)
[11:04] <wgrant> Er, yeah.
[11:05] <jml> jelmer: is there a PPA w/ latest releases of testtools, subunit etc?
[11:05] <jml> actually, let me try to use Launchpad to find out
[11:07] <jml> that was only a little hard.
[11:08] <maxb> jml: Yes, and as a Launchpad developer, you already should have it enabled by rocketfuel-setup :-)
[11:08] <jml> maxb: no, the release of testtools in that PPA is 0.9.2, latest is 0.96
[11:08] <jml> 0.9.6, rather.
[11:09] <maxb> However, see the ~bzr PPA
[11:10] <jml> interesting
[11:10] <jml> I wonder why https://edge.launchpad.net/ubuntu/+source/python-testtools doesn't list that
[11:10] <jml> https://edge.launchpad.net/ubuntu/+ppas?name_filter=python-testtools times out
[11:16] <wgrant> bigjools: The a-f tests are... special.
[11:16] <bigjools> wgrant: yes.  and one of them fails on maverick
[11:16] <wgrant> What is all this FakeSelectResult crap...
[11:17] <wgrant> Oh, it lives in that module.
[11:17] <wgrant> Even more special :(
[11:22] <bigjools> wow my branch finally landed 1.5 hours after I submitted it
[11:24] <jml> RT #41739, fwiw
[11:24] <_mup_> Bug #41739: Increase number of Retry attempts <Launchpad Foundations:Fix Released by stub> <https://launchpad.net/bugs/41739>
[11:24] <wgrant> bigjools: So we might be able to fix things eventually. Yay.
[11:25] <bigjools> wgrant: I hope so
[11:27] <bigjools> wgrant: I'll assign that bug to you I guess
[11:27] <wgrant> Er, yes, please do.
[11:28] <wgrant> It'd be nice if it let me do that while filing.
[11:28] <bigjools> I thought you could?
[11:29] <wgrant> Only if you're a bug supervisor.
[11:29] <bigjools> sigh - the person picker is timing out
[11:30] <bigjools> I'm not sure if I'm just angry today or if LP is getting on my tits, but this is incredibly frustrating
[11:31] <bigjools> non-js FTW
[11:32] <wgrant> We are no longer on wildcherry.
[11:32] <wgrant> So it's not unthinkable that it might be slow.
[11:32] <bigjools> I see jml filed a bug too
[11:34] <bigjools> jml: bug 655620 made me laugh
[11:35] <_mup_> Bug #655620: "Other versions" list doesn't include interesting other versions <Soyuz:New> <https://launchpad.net/bugs/655620>
[11:35] <bigjools> I had other people asking "why doesn't it show X"
[11:35] <bigjools> the answer is because LP is not a mind-reader :)
[11:36] <wgrant> Tree builds take too long.
[11:36] <bigjools> yes
[11:36] <jml> bigjools: well, sure, Launchpad can't be expected to read minds. However there are two obvious improvements here
[11:37] <bigjools> jml: it sorts by karma.
[11:37] <jml> bigjools: one is that it could act less like a mind reader and explain why it picked those, perhaps having a link to "more" rather than a search...
[11:37] <jml> bigjools: the second is that PPAs w/ newer versions of the package are probably more interesting to people
[11:38] <bigjools> yeah
[11:38] <bigjools> your bug might be a dupe.
[11:49] <allenap> gmb: Do you have any time today or tomorrow to start work on some basic UI for subscribe to search?
[11:49] <gmb> allenap: Define "start work"
[11:49] <jml> noodles775: this subunit test reproduces the bug minimally: http://paste.ubuntu.com/507163/
[11:50] <jml> it looks like it's actually two bugs :(
[11:50]  * noodles775 looks
[11:50] <jml> 1. zope.testrunner's subunit formatter should format KaboomError as a genuine subunit error
[11:51] <jml> 2. subunit's parser should be more robust in the face of stupid input
[11:51] <allenap> gmb: I think there's enough subscription filter API under the hood now, and in db-devel, to write something to subscribe to an advanced search, albeit if that advanced search only filters on statuses, importances and the presence or absence of tags.
[11:52] <allenap> gmb: So it would be cool to have a button on the advanced search page saying "Subscribe to this mofo" that does something.
[11:52] <gmb> allenap: Okay. At the moment my focus is on getting the Wizard integrated with devel (good luck with that) and making it possible to filter individual subscriptions by notification level.
[11:52] <deryck> Morning, all.
[11:52] <gmb> Which seems simpler for Weds wk3, though with continuous deployment being more and more practical maybe that's an unnecessary concern.
[11:53] <gmb> allenap: Are you asking me to take the work on or are you saying you want to talk about how best to do it?
[11:53] <gmb> Morning deryck.
[11:53] <allenap> gmb: Take the work. I might have time to do it if I get a move on. But no worries, just wondering. Ping me if you find you have some time and you're interested.
[11:54] <gmb> allenap: Okay, will do. At this point though I'd be surprised if I have time before next week,
[12:03] <wgrant> bigjools: The a-f test failure in maverick seems to be caused by it becoming a bit more pedantic.
[12:03] <wgrant> bigjools: The test uses a binary named 'foo.deb', which a-f just ignores. Renaming it to 'foo_1.0_i386.deb' fixes it.
[12:03] <bigjools> wgrant: ha
[12:03] <bigjools> nice
[12:14] <wgrant> Heh. I was just going to file a bug about the failure, and entered the summary "test_ftparchive failing on Maverick". The first result the dupefinder found was "test_ftparchive failing on Lucid". So it isn't completely useless.
[12:15] <jml> :)
[12:43] <wgrant> This code is the stuff of nightmares...
[12:48] <bigjools> enjoy :)
[12:49] <wgrant> bigjools: Parts of the a-f code look at DS.architectures, while others look at archtags in lucilleconfig.
[12:49] <bigjools> lucilleconfig needs to die in a furnace
[12:49] <wgrant> Yes.
[12:49] <bigjools> it's absolutely hideous
[12:51] <wgrant> bigjools: Should I fix it for PPAs too? They aren't so critical, and they're a completely different part of the code.
[12:51] <wgrant> NMAF is also used for partner, but partner's release pocket isn't frozen, so that should be fine.
[12:51] <bigjools> wgrant: fix what for PPAs?
[12:52] <wgrant> bigjools: Not publishing disabled archs.
[12:52] <wgrant> PPAs have sparc/ia64 indices.
[12:52] <bigjools> wgrant: I think so
[12:52] <wgrant> As does partner.
[12:53] <bigjools> yeah that's always been wrong, it ignores supported_arches
[12:53] <wgrant> There's no critical need to get it fixed in the next 48 hours, so I'm tempted not to throw more into this CP.
[12:53] <bigjools> +1
[12:53] <wgrant> So they'll drop out of Release (because that code is shared), but the indices will still exist.
[12:54] <jml> anyone able to help twb on #launchpad?
[13:00] <bigjools> I hate test_translationtemplatesbuildbehavior.py
[13:01] <wgrant> It's interfering with your async stuff?
[13:01] <wgrant> Because Translations actually tests stuff? :P
[13:05] <bigjools> no, because the way it tests is crap
[13:05] <bigjools> millions of fake/stub
[13:06] <wgrant> FFS
[13:06] <wgrant> The native publisher still goes through FTPArchiveHandler
[13:07] <jml> how do I get the return code of something I run in bash?
[13:07] <wgrant> jml: $?
[13:10] <jml> wgrant: thanks.
[13:42] <cr3> deryck: hi there, I received a few messages from you about re-enabling auto expiring bugs. usability might've been better sending one message per person listing all their projects, instead of one message per person per project :)
[13:43] <deryck> cr3, yes, I agree.  It was a mistake on my part.  My apologies for the noise.
[13:43] <cr3> deryck: no problem, it was mostly a suggestion for next time rather than whining :)
[13:43] <deryck> cr3, I understand.  Thanks for the suggestion. :-)
[13:44] <cr3> deryck: my concern about next time is that these emails are sent on an adhoc basis, I suspect, so perhaps there should be a system in place to help the next person do the right thing, because it might not necessarily be you
[13:45] <deryck> cr3, yeah, that's my feeling, too.  That we shouldn't have to write ad hoc scripts to email people, which a small mistake has huge ramifications.
[13:45] <cr3> deryck: learning from ones experience is good, learning from other's experience is divine :)
[13:45] <deryck> cr3, or else, we really shouldn't send email at all.
[14:15] <allenap> jml: Are we inextricably tied to zope.test*?
[14:15] <jml> allenap: as long as we use layers, yes.
[14:16] <jml> allenap: but that's the only tie.
[14:17] <allenap> jml: Do you know what it would take to move those to testresources or something like that? I ask because I'm interested in doing it.
[14:17] <allenap> If it's worthwhile.
[14:17] <jml> allenap: roughly speaking, yes. there's been some discussion about this on the mailing list, and I've filed a bug on launchpad-foundations somewhere
[14:18] <jml> allenap: the discussion is quite recent, iirc. Sep maybe.
[14:18] <allenap> jml: I'll try and find it. It rings a bell so I probably read it ;)
[14:19] <wgrant> bigjools: Can we ensure that ia64 and sparc have 0 active publications in the primary archive upon release?
[14:19] <wgrant> bigjools: If we can't, I need DB changes or a set of hacks to prevent indices.
[14:20] <jml> thank you surveymonkey for losing my carefully constructed thoughs.
[14:20] <wgrant> Because ftparchive loves its views.
[14:20] <jml> *thoughts.
[14:21] <wgrant> I guess I'll go with the extra layer of hacks.
[14:33] <bigjools> wgrant: it's possible to run a query to delete all the publications, yeah
[14:35] <wgrant> bigjools: The problem is this: ftparchive dumps BinaryPackageFilePublishing for the relevant (series, pocket), and marks everything it sees as needing a release file.
[14:35] <wgrant> The distroarchseries is hidden behind the view, so I can't filter out disabled stuff.
[14:36] <wgrant> So I can't remove the release file requests -- I have to go through and filter them later.
[14:36] <wgrant> And they are at that point thoroughly stringified.
[14:39] <stub> allenap: There is no longer anything tying us to layers. Teardowns need to be added to the layers that claim they can't be torn down (this is no longer correct). The layers would need to be broken apart into resources. All the tests need to declare their combination of resources rather than their layer, or some sort of compatibility layer added so layer declarations work in the new world order.
[14:41] <allenap> stub: There's hope then! I assume I'm not the only one who thinks that zope.testing is byzantine.
[14:42] <stub> allenap: sure. It never was a particularly good fit for us, but the only option available at the time.
[14:43] <bigjools> wgrant: so we need to unpublish all the BPPHes
[14:43] <wgrant> bigjools: And then really hope that none come back, or we're screwed.
[14:43] <allenap> stub: Interesting. (Also, I wasn't around when it was chosen, and I certainly don't mean to knock the choices that were made.)
[14:43] <bigjools> wgrant: well I'm preventing them in every place they get created now
[14:44] <wgrant> I guess if we do a final check that everything's OK before we freeze the pocket.
[14:45] <bigjools> wgrant: so to summarise: a) stop a-f publishing disabled DASes, b) unpublish them
[14:46] <wgrant> bigjools: It's easy to stop it from publishing empty disabled DASes. Non-empty disabled DASes require a hack which I'm testing now.
[14:46] <wgrant> I think it will work.
[14:46] <bigjools> mmmkay
[14:46] <wgrant> Still, the hack is mostly stolen from another rather hackish piece of work in the Release generator.
[14:47] <bigjools> :'(
[14:47] <wgrant> Which parses string pockets and does things like architecture[7:]
[14:47] <wgrant> (that's to strip 'binary-' of the front)
[14:47] <bigjools> we should not do that kind of hack
[14:47] <wgrant> No.
[14:47] <bigjools> I'd much rather run SQL to delete the publications
[14:47] <wgrant> But that needs refactoring of lots of code and the a-f views.
[14:48] <wgrant> Right.
[14:48] <wgrant> We don't need to actually DELETE the publications. Just Delete them.
[14:48] <wgrant> But I'm worried that some might spring up while we're not looking.
[14:48] <bigjools> you mean status=deleted
[14:49] <wgrant> Right.
[14:49] <wgrant> They need to not be Published.
[14:49] <bigjools> and I'm not too worried about them re-appearing
[14:49] <bigjools> as long as we prevent builds getting created
[14:50] <wgrant> You did fix copies as well, right?
[14:50] <bigjools> yes
[14:56] <wgrant> bigjools: I just pushed up the various changes to https://code.edge.launchpad.net/~wgrant/launchpad/bug-655614-disabled-arch-indices... see what you think.
[14:56] <wgrant> I need to rewrite the tests properly, since they don't catch many a-f cases.
[14:57] <wgrant> Of which there are far too many.
[14:57] <bigjools> wgrant: can you do a WIP MP please
[14:57] <bigjools> gets me a diff :)
[14:57] <benji> hey guys, how I can run a script with the full LP configuration loaded? (adapters registered, etc.)
[14:57] <bac> abentley, adeuring, allenap , bac, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jtv, bigjools, leonard, mars, noodles775: Reviewer Meeting in 2 minutes
[14:57] <wgrant> bigjools: The four revs are deliberately pretty independent. Viewing them in isolation is probably better.
[14:58] <wgrant> We may only want one of them.
[14:58] <bigjools> benji: execute_zcml_for_scripts()
[14:58] <wgrant> And they're tiny.
[14:58] <bac> wgrant: ^^
[14:58] <bigjools> wgrant: ok
[14:58] <benji> bigjools: ah ha!
[14:58] <wgrant> I *think* that branch completely fixes a-f.
[14:59] <wgrant> But the code is so convoluted that it's really hard to tell.
[14:59] <bigjools> benji: yeah, in soyuz world it's a bit ubiquitous :/
[14:59] <benji> heh
[14:59] <deryck> bac, apologies, but I'll miss today.
[15:00] <bac> deryck: thanks
[15:14] <Ursinha> bigjools, hi, could you tell me why did you remove the tag and milestone from bug 566339?
[15:14] <_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/566339>
[15:20] <bigjools> Ursinha: because its not fixed
[15:20] <Ursinha> bigjools, did you consider using --incremental?
[15:21] <Ursinha> removing tags will break the script
[15:21] <bigjools> Ursinha: I attached the bug to the branch incorrectly, so I'm just reversing the change
[15:21] <Ursinha> ah, ok
[15:21] <bigjools> I removed the branch ages ago
[15:21] <bigjools> I just noticed it was still in the milestone
[15:21] <Ursinha> in this case removing the branch should work
[15:21] <Ursinha> thanks bigjools :)
[15:25] <bigjools> Ursinha: np!
[16:12] <jml> allenap: did you find those discussions?
[16:12] <allenap> jml: No, I didn't unfortunately. stub replied here with some interesting information.
[16:13] <jml> allenap: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419691
[16:13] <_mup_> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419691>
[16:14] <tyarusso> Hi, I'm having some trouble installing canonical-identity-provider, at the syncdb step.  Any ideas on this error?  http://pastebin.ca/1955643
[16:15] <jml> allenap: "stories for external test helpers (librarian, memcache, etc)" on launchpad-dev@ (Sep 26)
[16:18] <allenap> jml: Yep. Okay, the priority of that bug is now low, so maybe I should walk away.
[16:19] <bigjools> the person picker on bug pages is constantly timing out today
[16:19] <jml> allenap: the priority doesn't mean very much
[16:20] <jml> allenap: I gave it a priority for the sake of giving it a priority.
[16:20] <allenap> bigjools: Wfm. Any particular names?
[16:20] <wgrant> tyarusso: It used to always default to False. Add 'READ_ONLY_MODE = False' to settings.py.
[16:20] <bigjools> allenap: see if you can assign https://bugs.edge.launchpad.net/soyuz/+bug/55774 to "jelmer"
[16:20] <_mup_> Bug #55774: Soyuz tests explore "Building from Accepted" when the production doesn't <tech-debt> <Soyuz:Triaged> <https://launchpad.net/bugs/55774>
[16:21] <wgrant> bigjools: That bug is wrong, isn't it?
[16:21] <wgrant> Oh, no, it's right.
[16:21] <bigjools> wgrant: :)
[16:21] <tyarusso> wgrant: Thanks.
[16:21] <bigjools> ancestry from the queue is bong
[16:21] <wgrant> I had that stupid difference between source and binary publications.
[16:22] <wgrant> Custom uploads break everything :(
[16:22] <allenap> bigjools: A bit slow, but it worked.
[16:22] <bigjools> allenap: hmmm ok.  must be borderline then, thanks
[16:22] <allenap> bigjools: It is slow though. That kind of thing should be near instant.
[16:23] <bigjools> allenap: it's sometimes very quick, sometimes crawls for me
[16:23] <tyarusso> wgrant: So I got past that step, was prompted to create a superuser, selected yes, gave my info, and after that got this:  Failed to install custom SQL for identityprovider.Account model: must be superuser to create procedural language "plpythonu"  - should I have said no?
[16:24] <wgrant> tyarusso: It's expecting your postgres account to be a superuser.
[16:24] <wgrant> You'll need that either way.
[16:25] <wgrant> I'd "sudo dropuser $USER" and "sudo createuser -a $USER"
[16:25] <wgrant> Then it should work.
[16:26] <wgrant> Or I suppose you can alter the existing user, but I don't know how to do that offhand.
[16:27] <tyarusso> dropuser: removal of role "tyarusso" failed: ERROR:  role "tyarusso" does not exist
[16:28] <tyarusso> I'm guessing you don't actually mean my shell $USER, but the username defined in settings.py then.
[16:28] <wgrant> Well, in a lot of cases that probably is $USER.
[16:28] <wgrant> But if you've configured it differently, then indeed not.
[16:29] <tyarusso> dropuser: removal of role "launchpad" failed: ERROR:  role "launchpad" cannot be dropped because some objects depend on it - argh
[16:29] <wgrant> You don't want to play with the 'launchpad' user if you want to run Launchpad.
[16:29] <tyarusso> There's an actual launchpad user?  Well frick.
[16:30] <wgrant> A PostgreSQL user, yes.
[16:30] <tyarusso> sigh - that's what I called mine :S
[16:31] <wgrant> Launchpad handles its DB users itself, by making your shell account a postgres superuser.
[16:32] <tyarusso> So I should be putting tyarusso in the two DATABASE_USER fields of settings.py then?
[16:32] <wgrant> Unless you have a pressing need to use another user.
[16:33] <tyarusso> mmk
[16:34]  * tyarusso notes that documentation is lacking
[16:34] <wgrant> Setting up a database depends a lot on the given environment, so any specifics
[16:34] <wgrant> are left out, and what is here presented should only serve as a guideline.
[16:34] <wgrant> ::
[16:35] <tyarusso> Yeah.....not helpful.
[16:36] <tyarusso> Only one of many things though - I had to manually finagle a bunch of the python modules too.
[16:37] <wgrant> There's unfortunately no public ISD dev channel, so the relevant team is not accessible.
[16:37] <wgrant> And I haven't run it for a while.
[16:38] <wgrant> (c-i-p isn't developed by the Launchpad team)
[16:39] <tyarusso> I *think* I might have identity-provider running now.  Maybe.  Running through the actual LP install again to see what happens.
[16:39] <tyarusso> btw, is there a way to get db-stable directly, or do I have to get devel first and add it?
[16:39] <wgrant> You could probably hack rocketfuel-setup to grab it directly.
[16:39] <wgrant> But that's fairly pointless.
[16:40] <tyarusso> k
[16:42] <flacoste> am i the only one for whom the person or team ajax selector doesn't work?
[16:42] <flacoste> it always fails with 'Failed to load results'
[16:42] <wgrant> That's the third report of it, and I've seen it too.
[16:45] <sinzui> leonardr, please retarget questions before you answer them. The question will be reopened by the user 50% of the time and getting a different person answers each question is very confusing
[16:45] <leonardr> sinzui: ok, what is the proper target for a 'delete my project' question?
[16:46] <sinzui> launchpad-registry
[16:46] <sinzui> I a doing them now
[16:46] <leonardr> thanks
[16:46] <sinzui> leonardr, you only need to retarget. the teams get to do the work
[16:46] <leonardr> oh, has that changed recently? i thought that was only for bugs
[16:48] <leonardr> (sending out those reminder emails really brought people in to disable their projects)
[16:48] <bigjools> flacoste: yes me too, although when someone else tried it it worked, albeit slowly
[16:49] <tyarusso> Once I get this up, am I going to have to do anything special to get LP to talk to canonical-identity-provider?
[16:50] <tyarusso> Also, is the python virtualenv stuff necessary if I actually want a system install, not just a development environment?
[16:50] <bigjools> wgrant: still up?
[16:52] <mars> sinzui, small annoyance - a recent maverick upgrade has Launchpad thinking that I am logged out, but the original LP login service says I am logged in.  Might come up with other Maverick users.
[16:53] <mars> sinzui, hitting the Login link a second time made the site do the right thing
[16:53] <sinzui> mars, if Lp thinks you are logged in, I think you are, gary or benji could confirm that
[16:54] <mars> maybe it was browser caching
[16:54] <tyarusso> Why do I have to have my SSH key registered with LP just to do a checkout of rocketfuel stuff?
[16:55] <mars> tyarusso, that is so rocketfuel-get can use the bzr+ssh protocol.  IIRC it is not a requirement to fetch the source code
[17:56] <lifeless> moin
[17:59] <mars> jml, you must keep an +activereviews window open :)
[18:03] <jml> mars: email. I basically live in my mail client.
[18:05] <jml> also
[18:05] <jml> how is it at all possible that these tests are failing in stable?
[18:05]  * mars shrugs
[18:06] <mars> jml, I first noticed the failure in production-devel
[18:06] <mars> I have no idea how it got that far
[18:06] <mars> before failing
[18:09] <jml> failing tests in stable is pretty serious.
[18:09] <jml> unfortunately I have to go.
[18:09] <jml> good bye.
[18:09] <mars> good night
[18:13] <jcsackett> danilos: you around?
[18:34] <lifeless> deryck: https://bugs.edge.launchpad.net/malone/+bug/607958
[18:34] <_mup_> Bug #607958: timeouts on Distribution:+bugtarget-portlet-bugfilters-stats <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/607958>
[18:35] <lifeless> deryck: its now failing much more often
[18:35] <lifeless> 1509 /    0  Product:+bugtarget-portlet-bugfilters-stats
[18:35] <deryck> lifeless, ok.  I'll add it to our backlog and have the next person free take a look.
[18:36] <lifeless> thats > 1 / minute :(
[18:36] <deryck> yeah, that's pretty ridiculous.
[18:36] <lifeless> sinzui: / bigjools: 794 /   98  Distribution:+ppas may be a similar fallout
[18:37] <lifeless> deryck: also 432 /  323  Distribution:+bugtarget-portlet-bugfilters-stats
[18:37] <lifeless> We could raise the timeout, but it won't help - its been taking multiple minutes.
[18:39] <lifeless> flacoste: hi
[18:40] <lifeless> flacoste: downtime window - I think we should move to a budget based approach now :)
[18:40] <flacoste> lifeless: i agree
[18:40] <lifeless> 5 hours as an estimate scared me
[18:43] <bigjools> eek
[18:43] <lifeless> bigjools: see canonical-launchpad
[18:43] <bigjools> irc fail, ignore that
[18:44] <lifeless> ll
[18:44] <lifeless> kk
[18:44] <flacoste> lifeless: i had the same reaction
[18:57] <Ursinha> hi abentley, is bug 613958 already QAed?
[18:57] <_mup_> Bug #613958: upload failure emails should include the upload log <qa-needstesting> <recipe> <Launchpad Bazaar Integration:Fix Committed by abentley> <https://launchpad.net/bugs/613958>
[18:58] <abentley> Ursinha, no, but it's not for lack of trying.
[18:58] <abentley> Ursinha, I am waiting on jelmer to fix the staging build farm.
[19:03] <Ursinha> abentley, oh, I see.
[19:04] <Ursinha> abentley, I made a note on the bug. Thanks for the info
[19:57] <lifeless> elmo: hi
[20:54] <jml> can someone do me a favor & run "./bin/test -cvv devscripts.ec2test.tests.test_remote" in stable? (r11681 ideally)
[20:56] <jml> it won't take very long
[21:07] <lifeless> gary_poster: hi
[21:07] <lifeless> uhm bugs
[21:08] <gary_poster> hi :-)
[21:08] <lifeless> pageid + hard_timeout feature flags needs qa
[21:08] <lifeless> needs a losa though, to set the flag on staging
[21:08] <gary_poster> ok
[21:08] <lifeless> e.g. pick a page thats timeing out, ask for a feature-rule with that pageid and (say) 40 second timeout
[21:09] <lifeless> 40000 would be the figure (its ms)
[21:09] <gary_poster> since you are giving instructions, does that mean you are asking for us to do QA? :-)
[21:09] <lifeless> no
[21:09] <gary_poster> (which is fine, just being clear)
[21:09] <gary_poster> oh ok
[21:09] <lifeless> I've been trying to line up the stars with a losa to do it
[21:09] <gary_poster> oh ok cool
[21:10] <lifeless> bug https://bugs.edge.launchpad.net/launchpad-foundations/+bug/395960
[21:10] <_mup_> Bug #395960: proxying user supplied libarian files via the launchpad appserver domain has security and performance issues <librarian> <qa-ok> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/395960>
[21:10] <lifeless> we have the code we haven't qa'd
[21:10] <lifeless> we can't till rt 41202 or something moves forward
[21:11] <gary_poster> so...it sounds like we should remove the qa tag entirely
[21:11] <lifeless> so it will stay fix committed till we've qa'd and flipped the feature flag to enable it.
[21:11] <lifeless> gary_poster: I doubt that that will make the qataggerhappy ;)
[21:11] <lifeless> this raises another subtle workflow change
[21:11] <gary_poster> maybe not...qa-untestable then perhaps
[21:11] <lifeless> 'deploying code' is no longer 'releasing a fix'
[21:12] <lifeless> so the thing that checks 'is merged to prod-stable' is now only right most of the time ;)
[21:12] <gary_poster> heh
[21:12] <lifeless> (because with feature flags we may deploy, but not enable - e.g. due to external constraints, doing a shock n awe thing, etc)
[21:13] <lifeless> dunno if we need to change anything, but certainly should be aware of this difference.
[21:13] <gary_poster> qa-flagged?  qa-deployable?
[21:14] <lifeless> dunno
[21:14] <lifeless> qa does seem all about deployment
[21:14] <lifeless> perhaps we should revamp all the tags
[21:15] <gary_poster> sinzui, leonardr, is there a way around stuartm's concerns?  is this a registry thing, more than a foundations thing? https://bugs.edge.launchpad.net/launchpad-foundations/+bug/655565
[21:15] <_mup_> Bug #655565: Immutable reference to users in API <Launchpad Foundations:New> <https://launchpad.net/bugs/655565>
[21:15] <lifeless> however I don't think we need to move rapidly here - the failure mode is that whoever is driving the thing toggles it back to fix-committed.
[21:16] <lifeless> and most things will be usable immediately, its a rare corner case.
[21:16] <sinzui> gary_poster, There is not and it this issue is much bigger than api
[21:16] <gary_poster> lifeless, ack.  I'll file a bug about the general issue and ask for discussion particularly from matsubara and Ursinha .  For now, for the release, do you agree on qa-needstesting?  Or is there some other gesture better?
[21:16] <lifeless> I set it to qa-ok
[21:16] <gary_poster> cool, lifeless, thanks
[21:17] <bdmurray> How does one set the bug_tracker_link for a project / distro to launchpad for a test?
[21:17] <lvh> Hi
[21:17] <lvh> I'm running rocketfuel-setup and I've gotten this error message twice in a row now:
[21:17] <lvh> ./rocketfuel-setup: line 308:  2072 Killed                  bzr branch lp:~launchpad-pqm/launchpad/devel $LP_TRUNK_NAME
[21:17] <lvh> ERROR: Unable to create local copy of Rocketfuel trunk
[21:17] <lvh> What gives?
[21:18] <gary_poster> sinzui, ack.  so...does that mean this is registry, or...keep it in foundations because it is just a big honking pervasive problem in a way that I don't understand yet but that you don't have to explain to me now? :-)
[21:18] <sinzui> gary_poster: leonardr. users can change their launchpad id while there are emails with links to the old id. team admin see this in pending members requests. Users also complain when someone removes a PPA so to allow a name change
[21:18] <lifeless> lvh: check dmesg, you may be getting OOM killed
[21:19] <lvh> lifeless: Indeed I am! Thanks.
[21:19] <lvh> lifeless: I was running this on a very limited VM
[21:19] <lvh> how much memory do I need?
[21:19] <sinzui> gary_poster, we decided not to expose user db ids, and we are not about to expose this person as long as our engineers reports bugs about the items that wrongly expose ids
[21:19] <lifeless> lvh: a couple of GB is ideal
[21:19] <leonardr> bdmurray: can you find a project that already uses launchpad and use its value for .bug_tracker to set .bug_tracker on the object you're testing?
[21:20] <sinzui> gary_poster, There is a small piece of irony in this bug. Version one of SSO had immutable openid identifiers. Users hated it.
[21:21] <bdmurray> leonardr: that'd be smart but the couple of projects I've checked have null values for it
[21:22] <sinzui> gary_poster, do you have a few minutes to talk about identity on mumble? I think we can come to common understanding that may help us find a sane path through this
[21:22] <gary_poster> sinzui, I'm happy to give it a try, sure.
[21:22] <gary_poster> (lvh, I use 2 MB.  I think I've had success with 1.5 and maybe even 1 in the past.)
[21:24] <leonardr> bdmurray: judging from the apidoc, "null" might actually mean "launchpad"
[21:24] <leonardr> since there's no option for a bug_tracker with a bug_tracker_type of "launchpad"
[21:24] <bdmurray> leonardr: hmm, okay.  maybe I just want to enable bug tracking for the item then
[21:30] <mars> lifeless, fyi, I found out what was wrong with the tests in my feature flags helper branch: LaunchpadBrowserRequest has not .features attribute yet
[21:31] <mars> LaunchpadFunctionalLayer doctests don't use LaunchpadTestRequest, which does have the attribute
[21:33] <lifeless> popping out to the hospital, back in a few hours
[21:33] <lifeless> mars: its set by a request started hook
[21:33] <lifeless> I think.
[21:33] <mars> lifeless, thanks, I'll take a look for it
[21:42] <jam> mwhudson: hi michael. Thanks for the review. I think I've done the changes you requested, and I responded to your email.
[21:42] <mwhudson> jam: ok, cool
[21:42] <jam> Is there anything else I can do for you in the next hr or so before the end of my day?
[21:43] <mwhudson> jam: hope i didn't come across as too picky
[21:43] <jam> mwhudson: it was nice to get actual feedback vs silence
[21:43] <mwhudson> yes, i can see that :)
[21:43] <jam> there are lots of decisions I had to just sort of come up with
[21:43] <jam> so having someone go over it closely is nice
[21:44] <jam> mwhudson: do you know how "lp-production-configs" is set up?
[21:44] <mwhudson> jam: um in what way?
[21:44] <jam> I'm supposed to propose a patch to start rolling this out on staging, but I'd like to set the flag in the right file
[21:44] <jam> I can set "staging-lazr.conf" staging/* lpnet* or ?
[21:45] <jam> All I can surmise is that it is somehow overlay configurations
[21:45] <jam> but I don't really know which ones are active on which servers.
[21:45] <mwhudson> jam: you appear to be subscribed to https://code.edge.launchpad.net/~launchpad-pqm/lp-production-configs/trunk
[21:45] <mwhudson> ah right
[21:46] <mwhudson> yeah, just edit staging-lazr.conf
[21:46] <mwhudson> jam: if you look in staging/launchpad-lazr.conf, you'll see that the first line is "extends: ../staging-lazr.conf"
[21:46]  * mwhudson hopes; going on memory here
[21:47] <jam> sure, but why would one edit "staging-lazr.conf" vs "staging/launchpad-lazr.conf"
[21:48] <jam> I assume one is not always active, etc.
[21:48] <jam> anyway
[21:48] <jam> staging-lazr.conf has a clear [codehosting] section already
[21:48] <jam> so I'll put it in there.
[21:48] <mwhudson> jam: certainly at some point there was more than one staging config
[21:48] <mwhudson> there was staging and bazaar-staging and ... that all extending staging-lazr.conf
[21:48] <mwhudson> this might not be true any more
[21:49] <jam> mwhudson: before I push my patch back to lp, I assume that any branches named "*/lp-production-configs/*" is still private?
[21:49] <jam> I don't want to accidentally publish the secrets in trying to get a merge proposal put up
[21:50] <mwhudson> jam: https://code.edge.launchpad.net/lp-production-configs says "
[21:50] <mwhudson> New branches you create for Launchpad Production Configs are private initially." for me
[21:50] <jam> says "public" for me :(
[21:51] <jam> I'm glad I asked
[21:51] <jam> any idea how to change that?
[21:52] <mwhudson> jam: by saying "losa ping" i guess
[21:52] <mwhudson> i can't see privacy policies
[21:53] <jam> my dearest losa, it seems I have finally been given access to the all-important lp:lp-production-configs and want to submit a merge proposal against it, however it would seem that by default my submission would be public, and would leak all of the secretive goodness out into the world
[21:53] <jam> could you help me prevent that?
[21:59] <jam> Sorry I have to go for now, it seems my son fell in the playground and isn't feeling well.
[21:59] <jam> I'll try to respond to request later on tonight.
[22:01] <mwhudson> jam: sure, i'll reply to your reply in the next couple of hours
[22:02] <mbarnett> jam: if you need a private branch, feel free to create it and an i privatize it for you.
[22:03] <mwhudson> jam: hope your son is ok
[22:10] <wallyworld> abentley: skype?
[22:13] <jml> can someone do me a favor & run "./bin/test -cvv devscripts.ec2test.tests.test_remote" in stable? (r11681 ideally)
[22:14] <mwhudson> jml: ok
[22:15] <mwhudson> jml: i expect i'll have to run 'make' in stable so it'll be a while :-)
[22:15] <jml> mwhudson: 'make compile'
[22:15] <mwhudson> yeah true
[22:15] <jml> which still takes too long
[22:19] <mwhudson> jml:   Ran 68 tests with 7 failures and 0 errors in 21.151 seconds.
[22:19] <abentley> wallyworld: https://pqm.launchpad.net/
[22:20] <poolie> jam, gl
[22:20] <poolie> hello jml, abentley, mwhudson, wallyworld
[22:20] <abentley> poolie: hi
[22:21] <wallyworld> poolie: guten morgen
[22:23] <jml> mwhudson: thanks.
[22:23] <mwhudson> jml: btw zope.testing aaaaaaaaaaaaaaaaaaaa
[22:23] <jml> mwhudson: that's sad news. it means that test failures have made their way into stable :(
[22:23]  * mwhudson just got to that thread in his email
[22:24] <jml> let me know if you have the motivation to actually fix it. :)
[22:24] <mars> mwhudson, 7 failures?
[22:24] <mwhudson> jml: heck no
[22:25] <mwhudson> (sorry)
[22:25] <mars> jml, did you try my patch for the issue?
[22:25] <jml> mars: sorry, I thought you ran the whole suite
[22:25] <mars> no, just the test that prod_lp said was failing
[22:26] <mars> that is why this is even weirder now
[22:28] <jml> well, I've just hit the big red button.
[22:29] <jml> lifeless: ^^
[22:29] <jml> mwhudson: I'd patch upstream if it weren't for the z.testrunner move
[22:30] <jml> mwhudson: as it is I'd have to upgrade Launchpad to use z.testrunner, which is simply more hacking than I have time for right now.
[22:31] <jml> anyway, I have to sleep. Sorry to raise havoc and run.
[22:31] <mwhudson> jml: we can just put a patch in the zope.testing we use?
[22:31] <jml> mwhudson: yeah, that's probably the simplest thing. we then have to chose whether to do it right or not.
[22:32] <lvh> Hm. Is it normal that make schema occasionally takes pretty long?
[22:32] <jml> mwhudson: in any case, I'm pretty sure I've left enough info in the email that anyone on the Launchpad team could do it.
[22:32] <mwhudson> jml: thank heavens i'm no longer on the launchpad team!
[22:32] <mars> lvh, a few minutes at least, and it takes even longer if you stare at the console :)
[22:32] <mwhudson> >:)
[22:33] <jml> mwhudson: bah.
[22:33] <jml> mwhudson: you'll be back.
[22:33] <lvh> mars: Ah, okay
[22:33] <lvh> mars: it's in a VM so I'm going to inflate that number by a factor of ten
[22:34] <EdwinGrubbs> jml:  which seven tests are failing in stable?
[22:34] <jam> mwhudson, poolie: my son seems ok, just a little stunned and unusually quiet (aka, not running around at full speed :). Anyway, thanks for your help in getting this pushed forward, I'll try to be on later tonight to keep some momentum up
[22:35] <jml> EdwinGrubbs: the ones mentioned in my email
[22:35] <poolie> thanks
[22:35] <mars> EdwinGrubbs, ./bin/test -cvv devscripts.ec2test.tests.test_remote
[22:35] <poolie> i'll file the rt for you
[22:35] <jml> EdwinGrubbs: but maybe there's more
[22:35] <jml> EdwinGrubbs: I mean, who knows?
[22:36] <mars> jml, you may have to wait for AsiaPac or morning EU for this to get resolved - we are all close to EOD here
[22:37] <mars> jml, but thank you for raising the alarm
[22:37] <jml> mars: sure.
[22:38] <jml> mars: it's well and truly time for me to go to bed
[22:38] <mars> well, then good night jml!
[22:38] <jml> mars: but one thing I'm keen on chasing up later is this: why didn't alarm bells go off when I mentioned this four or five hours ago?
[22:39] <jml> good night all.
[22:39] <jml> and good luck!
[22:40] <mars> seven failures in devel as well
[22:41] <mars> my patch fixes four of those: https://code.edge.launchpad.net/~mars/launchpad/fix-ec2test-utf-in-devel/+merge/37760
[22:43] <poolie> night
[22:47] <mars> EdwinGrubbs, I'm working on a patch for that problem now
[22:47] <EdwinGrubbs> ok, cool
[23:10] <mars> EdwinGrubbs, could you please review  https://code.edge.launchpad.net/~mars/launchpad/fix-ec2test-utf-in-devel/+merge/37799 ?
[23:13] <mars> mwhudson, ^ would you be able to help?
[23:14]  * mars really really has to leave
[23:15] <mwhudson> mars: reviewed
[23:15] <mars> mwhudson, thanks!
[23:16] <mwhudson> mars: you haven't set a commit message btw
[23:16] <mwhudson> (in case you were about to ec2 land)
[23:16] <mars> mwhudson, I was going to run it through lp-land
[23:16] <mwhudson> ok
[23:19] <mars> sent!
[23:19]  * mars runs
[23:26] <wgrant> How is prod_lp looking?
[23:26] <wgrant> Did my CP finally make it out last night?
[23:37] <wgrant> tyarusso: Did you have any luck with c-i-p?