[00:18] <wgrant> mwhudson, thumper: Isn't that recipe deletion work going to explode horribly if a build has succeeded and produced a SourcePackageRelease?
[00:19] <mwhudson> wgrant: i think you should ask abentley that question
[00:19] <thumper> wgrant: explode horribly is a bit drastic, oops perhaps
[00:19] <abentley> wgrant, I don't have enough data.
[00:19] <thumper> but I don't think any thing will explode
[00:21] <wgrant> Well, it's the sort of object that is impossible to delete, and nulling the FK is dangerous, so there is probably no good solution.
[00:21] <abentley> wgrant, do you have any suggestions about which things should be deleted and which things should be nulled?
[00:23] <wgrant> abentley: Deleting the SPRB for an SPR removes all indication of who uploaded the package. Having an SPRB hanging around without a recipe sounds like a recipe for trouble. And having a recipe hanging around without its branches also doesn't sound very good.
[01:36] <lifeless> monring poolie :P
[01:38] <poolie> hi there
[03:03] <mwhudson> grr
[03:03] <mwhudson> AssertionError: result must be a Zope result object, not <testtools.testresult.real.MultiTestResult run=0 errors=0 failures=0>.
[03:03] <mwhudson> this is probably using a new ec2 test with an old branch :(
[03:04] <mwhudson> in particular: new ec2-test-remote
[03:04] <mwhudson> haaaaaaaate
[03:21] <cody-somerville> mwhudson, My ec2 instance is no longer active but I didn't get any e-mail nor did my merge proposal get marked as merged.
[03:21] <mwhudson> cody-somerville: :(
[03:21] <mwhudson> that happens sometimes
[03:23] <cody-somerville> errr... is anyone working on fixing it?
[03:25] <mwhudson> i don't think it's well understood
[03:25] <mwhudson> cody-somerville: you could run it attached with -p and see what happens at the end
[03:25] <cody-somerville> so no one is working on it? Not very LEAN :P
[03:32] <mwhudson> cody-somerville: well more that i don't have the status of every infrastructure issue launchpad development faces embedded in my brain
[03:33] <cody-somerville> I figured the fact that this bug has a very measurable cost to every time it occurs, I figured folks would be motivated to fix it.
[03:35] <mwhudson> actually, i think one potential cause has been fixed
[03:35] <mwhudson> so if it's happening again, more investigation has been required
[05:23] <wgrant> OOPS-1571H345
[05:23] <wgrant> Can someone please give me a traceback for that one?
[05:23] <lifeless> oops 1571H345
[05:23] <lifeless> oops OOPS-1571H345
[05:23] <lifeless> bah
[05:23] <wgrant> mup is sad.
[05:24] <wgrant> Or maybe only ubottu does them.
[05:24] <lifeless> timeout
[05:25] <lifeless> 20000.0  1  launchpad-main-master  SELECT PackageUpload.archive, PackageUpload.changesfile, PackageUpload.date_created, PackageUpload.distroseries, PackageUpload.id, PackageUpload.pocket, PackageUpload.signing_key, PackageUpload.status FROM PackageUpload WHERE packageupload.distroseries = 103 AND packageupload.archive IN (1, 534) AND packageupload.status IN (0) ORDER BY PackageUpload.id DESC LIMIT 7 OFFSET 0
[05:26] <wgrant> lifeless: Was that rendering the index, or performing the accept?
[05:26] <lifeless> +queue
[05:26] <lifeless>  /srv/launchpad.net/production/launchpad-rev-9191/lib/lp/soyuz/browser/../templates/distroseries-queue.pt
[05:26] <lifeless> Line 19, Column 4
[05:26] <lifeless>    - Expression: <PathExpr standard:u'view/decoratedQueueBatch|nothing'>
[05:26] <wgrant> Right, but which action was called? (alternatively just pastebin the traceback)
[05:27] <wgrant> Hmmm. That's odd.
[05:27] <lifeless> wgrant: patience kemosabe ;P
[05:27] <lifeless> I'd say db locking issue
[05:28] <wgrant> Ah.
[05:28] <lifeless> that queury which I pasted took 20000 seconds and was interrupted
[05:28] <lifeless> but it looks like a normally very fast query
[05:28] <wgrant> I thought that was during an accept, though, which should not actually be rendering that at all.
[05:28] <wgrant> Unless it was after the redirect.
[05:28] <lifeless> its on +queue
[05:28] <lifeless> so after the redirect, I think
[05:28] <wgrant> +queue performs actions too, though.
[05:28] <lifeless> oh
[05:29] <lifeless> no args
[05:29] <wgrant> If you POST to +queue, it will do stuff then redirect you back to +queue.
[05:29] <lifeless> it was a post
[05:29] <wgrant> So WTF is it trying to render anything... gah.
[05:29] <wgrant> lifeless: Thanks.
[08:08] <lifeless> anyone know how to get 'me' with launchpadlib ?
[08:09] <lifeless> bah, I see it.
[08:19] <adeuring> good morning
[09:06] <mrevell> Morning
[09:13] <jpds> What's the difference between @cachedproperty and @property ?
[09:18] <bigjools> jpds: @cachedproperty is only called once, its return value is cached
[09:18] <jpds> bigjools: I should so be using that for the mirror listings.
[09:19] <bigjools> jpds: it comes with many caveats, you should have a pre-imp with someone about it
[09:22] <jtv> henninge: for now, I want to set up a pottery-capable branch in a project on staging.
[09:22] <jtv> henninge: if we can have the config change cowboyed in there, we can verify that pushing changes will generate the jobs we want.
[09:23] <jtv> henninge: it should produce triples of Job, BranchJob, and BuildQueue.
[09:23] <henninge> jtv: how do we see jobs? sql?
[09:23] <jtv> henninge: yes
[09:24] <jtv> Then on dogfood, we manually recreate those triplets.
[09:24] <henninge> jtv: have we figured out the branch pulling part?
[09:25] <henninge> I mean, getting the branch unto dogfood?
[09:25] <jtv> henninge: "unto"?  Very biblical.
[09:26] <henninge> ;-)
[09:26] <henninge> yes, I read my scriptures in English atm ... ;)
[09:26] <jtv> The good news there is that we can create jobs referring to branch URLs on staging.  The bad news is, we probably still need to give the slaves permission for that bit of traffic.
[09:26] <jtv> (But the URLs themselves are already usable)
[09:27] <jtv> That Gideon guy again?  Goes around the world from hotel to hotel, and _always_ forgets his bible.
[09:28] <henninge> In Dallas he also forgot a Book of Mormon - which I only noticed on the last night ...
[09:29] <jtv> Personally I wouldn't pay any attention to the reading recommendations of someone who's this consistently sloppy.
[09:29] <jtv> Also, you'd think he'd know the thing by heart now.  Why bring a bible on every single trip?
[09:30] <jtv> Get a new book, for God's sake!
[09:32] <wgrant> jtv: How do you propose to reference branches on staging?
[09:33] <jtv> wgrant: IIRC I just tried it once and found that it worked.  Production would work as well here though.
[09:34] <henninge_> jtv: daily  reconnect. I'll have to move that to some other time of the day ...
[09:34] <wgrant> jtv: dogfood's config references production codehosting (ie. the branch prefix is lp:, not lp://staging/ or similar).
[09:35] <wgrant> So any recipes will have lp:-prefixed branches.
[09:35] <jtv> henninge_: "at" + "curl" to your modem should do the trick once.  Or cron + curl to make it repeatable.
[09:35] <jtv> wgrant: this feature deliberately generates http branches
[09:35] <jtv> URLs, I mean.
[09:36] <wgrant> jtv: Oh, right, I was thinking of recipes, which use lp: URLs.
[09:37] <jtv> wgrant: that's something I always forget to ask about.  We implemented a way to ask for a specific schema (http by default) for this, and maybe recipe builds should just do the same.
[09:37] <wgrant> jtv: Why? lp: works just fine?
[09:37] <wgrant> s/?$/./
[09:37] <jtv> wgrant: you just pointed out where it didn't
[09:37] <wgrant> jtv: Well, dogfood is broken, so I don't think it can be used as a counterexample.
[09:37] <jtv> Not production, I know, but still valuable.
[09:39] <jtv> wgrant: predictable http URLs eliminate the "use whatever the lp: schema maps to in this case" concern as well.
[09:43] <jtv> henninge: do you happen to know any specific (and preferably small) branches on LP that pottery will work for?  I'm using gedit at the moment.
[09:44] <jtv> Haven't yet verified that the pottery compatibility check and template generation actually work on it though.
[09:44] <henninge> jtv: I never looked for branches on Launchpad
[09:45] <henninge> I used gimp, though (apt-get source) because it has multiple templates.
[09:45] <jtv> henninge: to copy that branch to staging, you can bzr push -d lp:gedit lp://staging/~jtv/my/branch --use-existing-dir
[09:45] <jtv> henninge: shall I start a wiki page for the staging/dogfood testing?
[09:45] <henninge> jtv: that would be great
[09:46] <jtv> henninge: and once we have it, maybe you can add a simple recipe for checking that a branch is suitable?
[09:46] <henninge> jtv: it's supposed to be any intltool branch.
[09:48] <jtv> henninge: oh, that's nice—I thought it was only the more recent intltool setups for now.  In any case, it would be nice to know for sure.  If the code decides not to generate for a particular branch, it doesn't say why.
[09:49] <henninge> jtv: you no more about different versions of intltool setup than I do, then.
[09:50] <jtv> henninge: unlikely.  :)  But there was mention of multiple possible setups in Belgrade, and how we were aiming for only the most modern setup initially.
[09:51] <henninge> jtv: the best way to find out is to try it out ... ;-)
[09:52] <jtv> henninge: that doesn't tell me what the different setups are, and trying them all out would probably not be the best way there.
[09:53] <wgrant> I didn't manage to find a branch that Just Worked.
[09:53] <wgrant> I had to hack GETTEXT_PACKAGE into configure.ac or something like that.
[09:54] <henninge> jtv: so, there is only one supported setup, then.
[09:57] <jtv> wgrant: speaking as a complete n00b on this subject, doesn't that default to autoconf's regular notions of what package it's setting up?
[09:58] <wgrant> jtv: Not when pottery is grepping through it, AFAICT.
[09:58] <wgrant> But I didn't look hard.
[09:58] <wgrant> I just looked at the code and poked things until it worked.
[09:58] <jtv> wgrant: so that may well be a bug in pottery?
[09:58] <wgrant> jtv: I try to remain blissfully ignorant of autofoo.
[09:58] <jtv> Well, sorely missing feature anyway  :)
[09:59] <jtv> wgrant: funny how people think of drugs as things that make you stupid, when they actually are a way to obtain bliss without ignorance
[09:59] <wgrant> Heh.
[09:59] <jtv> wgrant: a bit like saying "if you think the glass is half empty, you're a pessimist" when in reality it's just being forward-thinking.
[10:07] <jtv> henninge: first piece of page is up on the wiki.  https://dev.launchpad.net/Translations/GenerateTemplatesOnTestServers
[10:07] <jtv> I've renamed the one for local machines from Build[...] to Generate[...] to avoid confusion.
[10:08] <jtv> (I love how changes "to avoid confusion" always create immediate confusion no matter how appropriate they may be)
[10:14] <jtv> wgrant: by the way... you mentioned how dogfood refers to production codehosting.  I guess that also means we must be careful not to push test branches to dogfood!
[10:15] <wgrant> jtv: Well, if you tried it would fail, since there isn't even a bazaar.dogfood.launchpad.net.
[10:20] <wgrant> noodles775: Hi. I want to present package diffs on +queue. Do you have any UI ideas?
[10:23] <noodles775> wgrant: I'd suggest creating something (with balsamiq?, but up to you), and then getting feedback from the people like StevenK/ScottK (but cc'ing the dev list)?
[10:26] <noodles775> wgrant: It may not be relevant, but we started collecting use-cases etc., for the queue page during 3.0, but never got the time to do anything with it. https://dev.launchpad.net/SoyuzDistroSeriesQueuePage
[10:27] <noodles775> But if you think it's worthwhile, you could add a use-case there too.
[10:30] <noodles775> wgrant: but if it's a very straight-forward change, and you already have a good knowledge of the use-cases for the queue page, just a simple mockup will be perfect (balsamiq or screenshot).
[10:34] <wgrant> noodles775: Yeah, it's a really simple change. The data is all there already, just not exposed anywhere. I plan to just add another row to the upload file table linking to the diff -- mainly wondering about the text.
[10:41] <noodles775> View the [link]difference from the previous package[/link]? Or simpler, without the "View the"? What had you thought of so far?
[10:41] <wgrant> noodles775: The other files just give a filename and its size.
[11:04] <deryck> Morning, all.
[11:06] <jml> bigjools: hi
[11:06] <jml> deryck: good morning
[11:07] <bigjools> jml: helleau
[11:07] <jml> bigjools: let's talk about timeouts.
[11:08] <bigjools> jml: there's already a timeout test in test_manager.py and it doesn't use clock
[11:08] <bigjools> but happy to talk more and learn!
[11:08] <jml> bigjools: it's probably wrong :)
[11:08]  * jml brandishes the confidence of the ignorant
[11:09] <bigjools> hehe
[11:09] <jml> yeah
[11:09] <bigjools> I have found a load of bugs in the manager tests though :/
[11:09] <jml> it's not wrong per se, but why wait five seconds when you can wait almost none
[11:09] <bigjools> jml: I agree
[11:10] <jml> we can use a clock for this, but I need to page in the code again
[11:11] <bigjools> jml: notice how test_resumeHost_timeout uses addErrBack
[11:11] <bigjools> so if the code doesn't fail as expected, the test still passes :)
[11:12] <jml> :(
[11:12] <bigjools> and the config doesn't get popped .... but, all easy to fix
[11:12] <jml> :(
[11:12] <jml> I wrote assertFailure for precisely this reason.
[11:12] <jml> or maybe I didn't, maybe someone else did
[11:15] <bigjools> jml: so we can use assertFailure instead of assertIsInstance( ...
[11:15] <jml>  yeah, d = self.slave.resumeSlave()
[11:15] <jml> d = self.assertFailure(d, ProcessTerminated)
[11:15] <jml> d.addBoth(lambda ignored: config.pop)
[11:15] <jml> return d
[11:16] <jml> actually, hmm
[11:16] <bigjools> nope, addCleanup FTW :)
[11:16] <jml> awesome
[11:16] <jml> good. because the addBoth I described was buggy :)
[11:16] <bigjools> lol
[11:16] <bigjools> yes, it is :)
[11:17] <bigjools> anyway it's not returning Failure any more
[11:17] <bigjools> there's that three-tuple with the stdout/err/exit code
[11:18] <jml> oh right.
[11:18] <jml> that kind of makes sense though, doesn't it?
[11:19] <bigjools> yes it's what we want
[11:19] <bigjools> I'm nearly done with the tests now
[11:19] <bigjools> and if we can improve the timeout one to use clock, that'd be awesomw
[11:20] <jml> so I figured it out
[11:20] <jml> reactor implements a clock interface
[11:20] <jml> so does twisted.internet.task.Clock
[11:21] <jml> make clock an optional parameter to whatever is doing the .callLater() calls
[11:21] <jml> pass in a t.i.task.Clock from your tests
[11:21] <jml> and then call clock.advance(seconds) to magically go forward in time
[11:21] <bigjools> schweet
[11:22] <jml> and then, when clock isn't passed in, default to using the reactor.
[11:23] <jml> lp.services.twistedsupport.tests.test_task has some examples.
[11:23] <lifeless> wouldn't it be simpler to pass in a reactor
[11:23] <bigjools> cool, I'll slap that in when I get the rest of the tests passing :)
[11:23] <lifeless> then you can modify that, and do controlled interactions of other sorts too
[11:24] <lifeless> jml: ^ bigjools: ^
[11:24] <lifeless> a small decorator would let you pass in the installed reactor with a custom clock
[11:25] <bigjools> lifeless: sounds OTT for this test, but I can lookl
[11:25] <bigjools> thanks
[11:25] <lifeless> http://jcalderone.livejournal.com/51888.html suggests passing in a reactor to things, FWIW
[11:26] <jml> lifeless: that's what I'm describing.
[11:26] <lifeless> jml: it didn't sound like it.
[11:26] <bigjools> didn't to me either
[11:26] <lifeless> jml: it sounds like you were suggesting passing in a IHasClock, which wouldn't implement callLayer etc
[11:27] <jml> lifeless: uaoesnthuiaoesndaoe-ucaonseiudht
[11:27] <lifeless> jml: EPARSE
[11:27] <jml> lifeless: t.i.task.Clock implements callLater
[11:27] <jml> lifeless: reactor implements callLater
[11:27] <lifeless> oh wow
[11:28] <lifeless> jml: perhaps you are describing it in a round-about way, or perhaps we mean something different.
[11:29] <lifeless> if we agree that jcalderone's blog post sounds good, we can assume violent agreement and move on
[11:30]  * jml does so
[11:37]  * bigjools bitches about spawnProcess's stupid arguments
[12:24] <bigjools> jml: clock.advance FTW!
[12:25] <jml> bigjools: sweet
[12:26] <bigjools> jml: interested in reviewing this if you have time.  I don't mind if you want to punt.
[12:26] <bigjools> err there should be a "?" in there somewhere ...
[12:27] <jml> bigjools: if I do, it'll be later in the day
[12:53] <leonardr> bac, i am recreating your error and i noticed that i am using the system httplib2 (0.4.0), not the 0.6.0 packaged with launchpad
[12:54] <leonardr> i don't see how that could be causing the problem, but it's a problem i don't understand right at the point of the error
[12:56] <leonardr> are you also using 0.4.0?
[13:54] <leonardr> bac, because of the 0.4.0 problem i can't see what's happening in httplib2. i'm going to put off work on this until i hear from you
[13:58] <bac> leonardr: i'm not sure which version i was using.  it should be in the traceback.  let me find that paste...
[13:58] <leonardr> i didn't see it
[13:59] <leonardr> because your error didn't happen in httplib2
[13:59] <leonardr> i'll paste mine
[13:59] <leonardr> i don't get as far as you
[13:59] <bac> oh, you're right, httplib2 was not involved in the traceback
[14:00] <leonardr> bac, http://pastebin.ubuntu.com/419239/
[14:01] <bac> leonardr: well, i see you're not using the LP version of lazr.restfulclient either
[14:02] <leonardr> bac: i get the same error when i do. use-0.6.0 was an attempt at putting a httplib2>=0.6.0 requirement in lazr.restfulclient itself, in addition to the launchpad one
[14:02] <bac> leonardr: oh
[14:03] <bac> File "lib/lp/registry/tests/../doc/launchpadlib/lp-proj.txt", line 35, in lp-proj.txt
[14:03] <bac> Failed example:
[14:03] <bac>     print httplib2.__file__
[14:03] <bac> Differences (ndiff with -expected +actual):
[14:03] <bac>     + /home/bac/launchpad/lp-sourcedeps/eggs/httplib2-0.6.0-py2.5.egg/httplib2/__init__.pyc
[14:03] <bac> so i am picking up the correct one
[14:03] <leonardr> aargh
[14:05] <leonardr> bac: why would i be picking up the site-packages 0.4 version?
[14:06] <bac> leonardr: i don't know.  i recently fought some problems and it was caused b/c i had an old storm package in site-packages and it was getting it
[14:06] <bac> sounds like a foundations issue to me.  :)
[14:15] <leonardr> yeah, if only anyone who knew about this stuff was around
[14:18] <leonardr> bac: ah, i've just got an egg file lying around in my site-packages
[14:18] <leonardr> it's not even unzipped
[14:18] <leonardr> $#%!$#5
[14:18] <bac> leonardr: you conjured up gary_poster quite nicely
[14:19]  * gary_poster will not look for trouble, but will be happy to help if needed
[14:20] <leonardr> well, let's see what happens now
[14:25] <leonardr> bac: i got a little further. now getting AttributeError: 'Parameter' object has no attribute 'options'
[14:25] <leonardr> which could indicate a problem with the wadl
[14:51] <leonardr> bac, do me a favor
[14:52] <leonardr> put a breakpoint in lazr.restfulclient resource.py, right before send_as_is_params is defined
[14:52] <leonardr> or rather, have it print out this value:
[14:52] <leonardr> [x.name, x.options for x in params]
[14:52] <leonardr> bac: dammit, nm
[14:52] <leonardr> i'm using an old wadllib
[14:53] <leonardr> i must have accidentally installed the launchpadlib ubuntu package or something
[14:58] <leonardr> bac: ok, i can now duplicate your error
[14:59] <bac> progress.
[15:01] <leonardr> bac: if i had to guess i'd say that request is going into the xml-rpc request handler, not the web service request handler
[15:08] <leonardr> bac: ok, here's the problem
[15:08] <leonardr> (Pdb) method
[15:08] <leonardr> 'get'
[15:08] <leonardr> (Pdb) self.getAcceptableMethods(environment)
[15:08] <leonardr> ['GET', 'HEAD', 'POST', 'PATCH', 'PUT', 'DELETE', 'OPTIONS']
[15:08] <leonardr> (Pdb) method in self.getAcceptableMethods(environment)
[15:08] <leonardr> False
[15:14] <bac> so it's just case?
[15:39] <henninge> danilos: We are dealing with the current behaviour for pofile export to replace the plural information with that information from the language record, right?
[15:45] <leonardr> bac: yes. i believe if the request goes all the way through httplib2, it gets uppercased
[15:47] <henninge> danilos: only, I cannot see where that is happening.
[15:49] <leonardr> but since wsgi_intercept handles the request, that code doesn't run
[15:51] <leonardr> bac, if i do a new release of lazr.restfulclient, will you integrate it into launchpad?
[15:51] <leonardr> i think l.r is the place to fix this
[15:51] <bac> leonardr: sure
[15:52] <danilos> henninge, right
[15:52] <danilos> henninge, let me take a look
[15:58] <danilos> henninge, gettext_po_parser.py look for getRawHeader() 'plural-forms' key handling
[15:58] <henninge> danilos: I have been there ...
[15:59] <henninge> getRawContent
[16:00] <henninge> danilos: but that is what POHeader parsed originally
[16:02] <henninge> danilos: I think its here:
[16:02] <henninge> lib/lp/translations/model/pofile.py:1723:            number_plural_forms = None
[16:02] <henninge> lib/lp/translations/model/pofile.py:1731:                number_plural_forms = self._pofile.language.pluralforms
[16:02] <henninge> lib/lp/translations/model/pofile.py:1735:            translation_header.number_plural_forms = number_plural_forms
[16:02] <danilos> henninge, sounds right :)
[16:28] <ricotz> bigjools, hello
[16:32] <leonardr> bac: i think this would be a better solution, since normally lazr.restfulclient + wsgi_intercept doesn't have the problem
[16:32] <leonardr> http://pastebin.ubuntu.com/419325/
[16:32] <leonardr> put that in your launchpad branch
[17:57] <mrevell> Night all
[18:28] <salgado> wgrant, is there anything that would prevent https://code.edge.launchpad.net/~wgrant/launchpad/emailauthentication.txt-2.6-fix/+merge/23449 from landing?  I'd be happy to take it from there and do the changes suggested by Michael if you don't have time for it
[19:36] <jml> g'night all
[22:19] <thumper> morning
[22:45] <wgrant> salgado-afk: noodles wanted a bug reference for the Python bug.
[22:46] <wgrant> salgado-afk: I don't think one exists, so I was digging deeper, but then uni caught up with me.